Stripo の障害履歴

1. 2026年10月8日 23:32 UTCinvestigating

   開始: 2026-10-08 22:20 UTC 影響: プラグインは顧客に利用できません。エディタは読み込まれません。 / 応答しません。 お客様からのお問い合わせ 何が起こったのか:で 22:13 UTC Zabbixは、プラグインDBホスト(pg-plugins.stripo.email、172.31.13.64)のエージェントを利用できなくなったと報告しました。22:40 UTCでは、PostgreSQLモニターがライブプラグインに失敗しました。 プラグインは、~22:20 UTC で顧客のために動作を停止しました。 DevOps は調査中です。 詳細は、こちらから更新してください.

2. 2026年10月8日 23:33 UTCresolved

   プラグインは、再び運用されます。 DevOps は、Plugin DB ホストを復元しました。 23:18 UTC 以降、さらにエラーが発生していないことを監視しています。 根本的な原因、タイムライン、行動項目が準備され、短時間公開されます.

3. 2026年10月9日 9:14 UTCpostmortem

   **概要** 2026年10月8日、22:20〜23:18 UTCの間、Stripo Pluginは利用できなくなった:エディタは読み込まれたり、応答しなかった。 所要時間は58分。 顧客データが失われず、他のStripo製品には影響を受けません。 **WHAT 閉じる** プラグインの失われた時間同期の背後にあるデータベースサーバー。 一度にサーバー上で2つのタイム同期サービスが実行されました。標準デーモンは、クロックを徐々に調整し、時計を突然ステップアップするレガシースケジュールされたジョブです。 ミスコンフィギュレーションのスケジュールは、レガシージョブがほぼ毎分実行されるようになりました。 繰り返されたクロックは、プラグインのデータベースが利用できなくなるまでサーバーをデスタシブル化します。 **タイムライン\(UTC, 8 October 2026\)** 21:44 - プラグインデータベースサーバー上でクロックの不安定性が始まります。 22:13 - 私たちの監視は、サーバーの最初のアラートを上げます. 22:20 - プラグインは顧客の読み込みを停止します。 22:40 - プラグインデータベースを未使用に監視する 23:00 - 第一次顧客レポートが届きます。オンデューティーエンジニアが呼び出されます。 23:18 - サービスの復元. プラグインは完全に動作しています。 **ソリューション** 当社のエンジニアは、タイム同期の競合を特定し、サーバーを復元しました。 プラグインは 23:18 UTC で正常な動作に戻り、以来拡張監視中です。 **弊社がこのイベントをPRする場合** * このサーバーと他のすべてのプロダクションサーバが一回限りのソースを使用するように、レガシーなタイム同期ジョブを削除。 * 時計の漂流のための監視を追加すると、サービスに影響を与える前に、この種類の欠陥がキャッチされます。 * アラートエスカレーションを変更します。 当社の監視は、停電の7分前に警告しましたが、アラートはエンジニアのページではなかった。 生産データベースサーバーのクリティカルなアラートは、すぐにオンデューティエンジニアを1時間いつでもページ表示します。 ご迷惑をおかけいたしますが、何卒ご理解賜りますようお願い申し上げます。 ご質問やご質問等がありましたら、サポートチームにお問い合わせください.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月4日 17:03 UTCinvestigating

   エディタ内の画像のアップロード中に問題があります。 時間(UTC):2026-10-04T17:03:09

2. 2026年10月4日 17:04 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月4日 16:46 UTCinvestigating

   エディタ内の画像のアップロード、変更、削除中に問題があります。 時間(UTC):2026-10-04T16:46:22

2. 2026年10月4日 16:47 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年10月4日 16:43 UTCinvestigating

   モジュールライブラリに新しいモジュールを表示、変更、作成する際に問題が発生する場合があります。 時間(UTC):2026-10-04T16:43:49

2. 2026年10月4日 16:44 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月18日 14:19 UTCinvestigating

   現在、Stripo Pluginの機能に影響を与える問題が発生しています。 一部のユーザーは、画像や文書をアップロードしたり、ストレージの認証情報を更新したりすることはできません。 当社のチームは、問題を調査し、可能な限り迅速に正常な動作を回復するために働いています。 開始時間: 9月 18, 13:41 UTC

2. 2026年9月18日 14:54 UTCidentified

   問題が特定され、修正が実装されています.

3. 2026年9月18日 14:56 UTCresolved

   この事件は解決しました.

4. 2026年9月18日 15:52 UTCpostmortem

   **ルート原因** 初期画像保存サービスに使用されるアクセスキーの計画的な回転中に問題が発生しました。 新しいキーは、ストレージ操作の処理を担当するサービスの1つに正しく伝播されませんでした。 その結果、そのサービスからのリクエストは、ストレージに認証できないため、画像やドキュメントのアップロード操作が失敗する可能性があります。 また、キーの回転手順に関する社内文書のギャップを識別し、事件に貢献しました。 **決断** ストレージの資格情報を修正し、すべての影響を受けたサービスに正常に伝播しました。 設定が更新されたら、正常に機能が返されます。 また、関連する内部のドキュメントを更新し、以前の未踏の構成ステップを含む。 **予防措置** すべての依存サービスがカバーされていることを確認し、設定の変更が前後の回転で検証されるように、クレデンシャル・ローテーション手順を見直しています。 また、今後同様の事故のリスクを低減するために、内部の文書や検証手順を改善しています。 チームが課題を解決するために働いたとき、私たちは混乱を心からお詫び申し上げます.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月16日 13:39 UTCinvestigating

   現在、Stripo Web Editor で劣化したパフォーマンスを経験しています。 一部のユーザーは、メールの開口部、利用できなくなったエディタの設定、編集機能、または「インターネット接続なし」エラーが発生することがあります。 既にメールが開いているユーザーの場合、ページが再ロードされていない限り、変更は自動保存によって保存されるべきです。 当社のチームは、問題を積極的に調査し、正常な動作を回復するために働いています。 開始時間:9月16日、13:25 UTC

2. 2026年9月16日 15:12 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月9日 15:18 UTCinvestigating

   モジュールライブラリに新しいモジュールを表示、変更、作成する際に問題が発生する場合があります。 時間(UTC):2026-09-09T15:18:49

2. 2026年9月9日 15:19 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月9日 15:13 UTCinvestigating

   モジュールライブラリに新しいモジュールを表示、変更、作成する際に問題が発生する場合があります。 時間(UTC):2026-09-09T15:13:49

2. 2026年9月9日 15:15 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月9日 15:11 UTCinvestigating

   モジュールライブラリに新しいモジュールを表示、変更、作成する際に問題が発生する場合があります。 時間(UTC):2026-09-09T15:10:49

2. 2026年9月9日 15:11 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年9月6日 7:17 UTCinvestigating

   お客様のアカウントへのアクセスに問題がある可能性があります。 時間(UTC):2026-09-06T07:17:04

2. 2026年9月6日 7:19 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年8月5日 13:59 UTCinvestigating

   We are aware of an issue with the Stripo Plugin: the editor may fail to initialize and does not load for end users. Our team has identified the affected service and is working on a fix. We will post an update as soon as we have more information.

2. 2026年8月5日 14:00 UTCidentified

   The issue has been identified and a fix is being implemented.

3. 2026年8月5日 14:49 UTCmonitoring

   A fix has been implemented and we are monitoring the results.

4. 2026年8月5日 14:57 UTCresolved

   This incident has been resolved.

5. 2026年8月5日 16:03 UTCpostmortem

   At 13:45 UTC the AWS host running the database and cache for our plugin environment failed. Auto-recovery restarted it by 14:00 UTC, but the cache service and several microservices required manual restarts. Full recovery: ~15:00 UTC. **Impact \(UTC\).** Autosave was unavailable 13:48–13:57, then severely slow \(~86 s per request vs. under 7 s normally\) until ~14:40. Some plugins using external AutoSave callbacks saw saves fail. Co-editing was degraded 14:16–15:00. Editor initialization also failed for some users early on. **Data.** No evidence of loss: crash recovery completed correctly, all patches that reached the database were persisted, and duplicate resubmissions were safely rejected. Contact us with a timestamp if you suspect otherwise. **Cause.** Hardware failure on the underlying AWS host. It escalated because autosave retries external callbacks synchronously inside the request, exhausting the database connection pool; the cache had no auto-start on reboot; and connection pools did not self-heal. No alarm covered host status or cache availability, so detection came from user reports. **Fixes.** Alerting on host status checks and cache availability; cache auto-start with a health check; connection pool recovery; moving external callbacks out of the request path; alerts on pool saturation, error rate and callback latency; a redundancy review for this environment. We apologize for the disruption. If the impact on your users differed from the above, please contact our support team.

1. 2026年7月31日 8:30 UTCinvestigating

   ユーザーがログインできなくなったり、不足しているチームメンバーを見たり、メールの読み込みが遅くなったりするレポートを調査しています。 私たちのチームは、原因を特定するために働いています.

2. 2026年7月31日 8:30 UTCidentified

   根本原因を特定しました。内部キャッシュサービス(Redis)はメモリから実行され、書き込みを拒否し始めました。 その結果、アクセス許可はキャッシュをバイパスし、アカウントサービスに過度な負荷をかけ、遅い応答、ログインの失敗、およびアカウントデータが不足していることを確認します。 キャッシュ容量を増加させ、恒久的な修正を準備しています.

3. 2026年7月31日 8:31 UTCmonitoring

   キャッシュ容量が増加し、システムが回復しています。 キャッシュが暖まるにつれて、応答時間が正常に戻ります。 恒久的な修正が展開されています.

4. 2026年7月31日 8:49 UTCresolved

   恒久的な修正は、すべての生産クラスターに展開され、すべてのシステムが正常に動作しています。 事件中 (7月 30, 22:48 UTC – 7月 31, ~04:30 UTC, 残留速度で ~08:49 UTC), 一部のユーザーは、ログイン障害を経験しました, 不足しているチームメンバーのデータ, 電子メールの読み込みを遅く. データの紛失は行いません。 利用者に影響を及ぼす前に、この問題のクラスを検知するメモリセージアラートを追加しました。 大変申し訳ございません.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月28日 14:02 UTCresolved

   7月28日、午後1時28分～午後1時58分(UTC)の間、Stripo Pluginは組み込み統合の初期化に失敗しました。 問題は、プラグインの初期化リクエストを遅くし、内部統計サービスの劣化性能によって引き起こされました。 当社のチームは、影響を受けるサービスを再始動し、プラグインの初期化のための一時的に無効な統計収集を解除し、通常の操作を復元しました。 プラグインは期待通りロードされます。 ご迷惑をおかけいたしますが、何卒ご了承くださいますようお願い申し上げます.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月25日 9:18 UTCinvestigating

   エディタ内の画像のアップロード、変更、削除中に問題があります。 時間(UTC):2026-07-25T09:18:22

2. 2026年7月25日 9:20 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月24日 11:27 UTCresolved

   7月24日(土) 09:20～9:50 UTC の間、プラグインエディタでリアルタイムの共同編集が一時的に利用できなくなった。 スケジュールされたリリース中に、データベースのスキーマの更新は期待以上にかかり、簡単にデータベースをオーバーロードし、共同編集サービスが再起動を引き起こしました。 当社のチームは、原因を特定し、完全にサービスを復元する 09:50 UTC. 顧客データが失われず、他のすべてのStripo機能が利用できなくなりました。 再発を防止するために、リリースプロセスにセーフガードを追加しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月23日 9:39 UTCinvestigating

   お客様のアカウントへのアクセスに問題がある可能性があります。 時間(UTC):2026-07-23T09:39:04

2. 2026年7月23日 9:49 UTCinvestigating

   [Opsgenieからのコメント]Dmitry Kudrenkoは警告を認めた:「Stripoアカウントのバックエンド部分の作業における部分的な停電」

3. 2026年7月23日 10:02 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月20日 18:11 UTCinvestigating

   ストリップセキュリティインシデント はじめに ESPアカウントに関連する珍しい活動に関する2件の顧客レポートを受領しました。 個々のレポートは、構成の問題、レガシーの統合、またはプロバイダ固有の要因を含む、様々な原因に起因する可能性がありますが、第二のレポートは、異なるEPSプロバイダーに関与し、同様の特性を展示しました。 その時点で、観察されたパターンは包括的なセキュリティレビューを保証し、より広範な調査を開始することを決定しました。 現在のステータス 保存された ESP の資格情報でアカウントを識別するため、お客様はキーを優先的に回転させるよう依頼しました。 これは、単一の完全パスではありませんでした。調査が続行すると、同じ通知が必要な追加のアカウントを識別し、確認した時点でそれらに連絡しました。 Stripo に接続されている ESP 認証情報と、まだそれらを回転させていない場合: 1. 古いキーを取り消し、新しいキーを生成すると、古いキーを自動的に無効にしません。 2. ESPアカウントで新しいキーを生成します。 3. プロジェクト設定→インテグレーションの下のStripoの新しいキーを更新して下さい。 4。 ESPまたはCRMアカウントの最近の活動のレビュー:ログイン履歴、連絡先リストの変更、および任意のキャンペーンや、認識していない送信。 これは、すべて進行中にあるときに1つのリマインダー:私たちは、電子メールまたはサポートチャットでキー、トークン、またはパスワードを送信するように依頼しません。 継続的な調査 当社の調査は継続中です。 お客さまに被った素材であることが判明した場合は、遅滞なく伝えます.

2. 2026年7月20日 18:15 UTCinvestigating

   2026年7月20日 - 18:15 UTC 修正しました 初期通信では、追加のセキュリティ強化の数を実装しました。 1. 保護監査。 認証情報は、システム全体に保存され、保護が適切に識別された認証情報の追加暗号化を実施する方法を見直しました。 2. 特定されたブラウザ関連の露出のシナリオに取り組むために付加的なブラウザ側の保護を実施しました。 統合画面が開くと、保存された認証情報はブラウザに戻りません。 これにより、上記のストレージ強化と組み合わせることで、クレデンシャルハンドリングに関連する潜在的な暴露リスクを大幅に削減できます。 3. 完全な記録の監査を完了しました。 ログシステムがエンドツーエンドで見直し、ログ設定を更新し、クレデンシャル値がアプリケーションログに記録されるのを防ぎます。 4. 階段データをきれいにして下さい。 利用停止後、保存された古いESP接続を削除し、未使用のキーをファイル上で削除します。 これまでの調査に基づいて、Stripoプラグインへの影響の任意の表示を識別していません。 Stripoは、お客様の財務情報や支払い情報を保管しません。 したがって、これまでの調査に基づいて、Stripoによって維持された財務データや支払いデータへの影響を特定していません。 現在入手可能な情報をもとに、第一次生産システムへの影響は認められていません。 日付に識別された活動は、バックアップ環境に関連付けられているように表示されます。 私たちは、その環境のための追加のセキュリティ対策を実施し、継続的な調査の一環として、より広範な影響があるかどうかを評価し続けています。 コンプライアンス認証 SOC2、ISO認証を取得した独自の監査セキュリティプログラムを維持しています。 この調査の一環として、輸出資格の取り扱いに関する特定の技術的制御を強化する機会を特定しました。 調査中に特定された事項に対処するための追加の保護策を実施しました。 また、この調査から、セキュリティプログラム、リスクアセスメントプロセス、技術制御、将来の監査活動への調査結果を組み入れています。 これらの調査結果は、追加の技術的な安全対策を通知し、セキュリティ管理および監査プログラムに引き続き組み込まれています。 セキュリティ認証は、組織のセキュリティプログラムが独立して認定基準に対して評価されていることを実証しています。 あらゆるセキュリティフレームワークと同様に、新しいリスクや実装の検討として継続的な改善をサポートしています。 継続的な調査 当社の調査は進行中です。 この作業の一環として、関連するデータが保存されるデータベースインスタンスに関するアクセスアクティビティを引き続き見直していきます。 お客さまに被った素材であることが確認された場合は、遅滞なく伝えます.

3. 2026年7月21日 14:23 UTCresolved

   発行日: 2026年7月6日～18日 最終的なインシデントレポート — 保存されたインテグレーション認証情報への不正なアクセス インフォメーション 2026年7月6日〜18日の間に、無許可の俳優は、生産データの限られたサブセットを含む制限された読み取り専用レプリカへのアクセスを読み取った内部、非顧客対面環境へのアクセスを得ました。 完成した調査によると、その環境に格納されている特定の情報にアクセスし、そのアクターは、お客様がStripoに蓄積した特定のサードパーティのESP/export資格情報を含む、特定のアカウントレコードと共に、Stripoに保管していた、読み取りクエリを実行しました。 活動の特定に際し、環境を分離し、廃棄し、是正措置を実施し、事故に当たる調査を完了しました。 事件は、クライアントの要求を介してのみ報告され、当社の標準監視を通じて検出されなかった。 影響を受けたデータ 完全な調査に基づいて、特定の関連するアカウントレコードとともに、お客様が統合を接続するために保存した特定のサードパーティのEPS /エクスポート資格が含まれているように識別された情報。 口座認証データ。 ストライプパスワードはハッシュされた保存と塩漬けで保存されます。つまり、セキュリティのベストプラクティスに沿って、テキストをプレーンにすることはありません。そのため、使用可能な形式では公開されません。 決定された攻撃者は、理論的に、塩漬けのハッシュを時間をかけてクラックしようとすると、我々はチャンスを取らなかった:我々は積極的に、ハッシュが実質的に回復することができる兆候がないにもかかわらず、すべてのStripoパスワードをリセットしました。 各ユーザーは、次のサインインで新しいパスワードを設定するだけです。 私たちが行っていること 1. 社内環境を切断し、解凍することにより、事件を汚染した。 2. 保存されたすべてのESP/exportの資格情報への残りで拡張された暗号化, 既に暗号化されていないものを含む (管理されたAWS KMSで保持されているキー). 3。 統合画面が開いたときに、ブラウザーにリピート資格情報を停止します。 4。 彼らが表示される可能性のある限られたシナリオからアプリケーションロギングとクレデンシャル値を削除した。 当社の調査は、アプリケーションログが攻撃経路の一部を形成した証拠を識別しなかったが、この追加の保護策は、より広範な是正努力の一環として実施しました。 5. 古い/非アクティブな資格情報を保持した後、使用しなくなった。 6. Klavio、HubSpot、Zoho、およびAWeberのために、私達は自動的にすべての承認トークンを取消しました。 7. インフラストラクチャの周囲全体で完全なレビューを実施:すべてのセキュリティグループを監査し、システムノードへのアクセスパスを監査し、すべてのデータベースのパスワードを回転させ、内部のみアクセスへの読み取り専用のレプリカを制限し、内部サービスとスタッフによって保持されたアクセスを見直し、少なくとも優先原則を締めました。 8. すべてのユーザーのパスワードおよび無効なセッションを積極的にリセットします。 9.内部ツールへの認証、外部データベース接続、および機密テーブルの一括読み込みの監視および警告を追加しました。 SOC 2プログラムを含む、認証されたセキュリティおよびデータ保護基準の下で動作します。 継続的なセキュリティプログラムの一環として、この調査結果に基づく技術的および組織的制御を強化し続けています。 影響を受けていない人 ファイル形式(HTML、AMP HTML、PDF、EML、画像など)にのみエクスポートされたお客様は、当社に資格情報を保存せず、影響を受けません。 CleverTap、Customer.io、フォローアップボス、Google Cloud、MailerLite、Mailtrap、Make、Mindbaz、N8n、Netcore、OneSignal、Optimove、Postup、Pubrio、Rapidmail、Reteno、Selzy、Sender.net、ticketor、Unione、Insider、Voizee、WhatCounts、Yespo。 プラグインとセルフホストのデプロイメントは影響を受けていませんでした。環境とレプリカは、セルフホスト製品ではなく、Stripo Cloudインフラストラクチャの一部です。 長期的なアカウント。 当社のデータ保持ポリシーおよびGDPRの義務に沿って、非アクティブ顧客アカウントおよびその個人データは、定期的な削除されるため、長期にわたる顧客に属する情報は、この環境に存在せず、公開されていない可能性があります。 支払データ 当社の調査に基づき、クレジットカード番号(PAN)やCVコードがアクセスされていないと確認しました。 カード決済は、当社の決済プロバイダ(StripeとPayPal)によって処理され、Stripoはフル決済カード番号またはCVコードを保存しません。 ESPパートナーとの協働 これらは、サードパーティの資格情報であるため、私たちは積極的に、パートナーシップの精神と相互顧客を保護するために、関与するESPプロバイダに連絡しているので、影響を受けた資格情報は、追加の保護策として自分の側に取り消すことができます。 お客様が何をすべきか 1。 プロバイダーが上記の「誰が影響を受けていない」セクションでない場合、すでに存在していない場合:Stripoアカウントに接続されたESP資格情報を回転させる - プロバイダーで古いキーを取り消し、新しいキーを生成し、Stripo(プロジェクト設定→統合)で更新します。 OAuth ベースのインテグレーションでは、Stripo の承認をプロバイダで再実行し、再接続します。 2. ESP/CRMのアクティビティを7月上旬に見直し — サインイン、連絡先リストの変更、キャンペーン、送信、または認識しないエクスポート。 キーを回転させると、将来の使用を停止しますが、既に発生した活動は行いません。 3。 あなたのStripoパスワードは既にリセットされています。次のサインインで新しいパスワードを設定します。 オープニング この事件が発生したことを誠意をもってお詫び申し上げます。 影響を受けたお客様に直接連絡し、リクエストに応じてフォローアップ質問にお答えします。 お問い合わせ:[email protected].

公式のインシデント更新を自動翻訳しています。

1. 2026年7月7日 15:26 UTCinvestigating

   エディタ内の画像のアップロード、変更、削除中に問題があります。 時間(UTC):2026-07-07T15:26:22

2. 2026年7月7日 15:27 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年7月1日 3:53 UTCinvestigating

   エディタからPDFファイルとしてメールテンプレートのエクスポートに関する問題があります。 時間(UTC):2026-07-01T03:52:37

2. 2026年7月1日 3:53 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。

1. 2026年6月18日 13:43 UTCinvestigating

   テストメッセージの送信に関する問題は、指定されたメールアドレスや/または、テストメールテンプレートに関連したメールを、Aquel に送信する問題があります。 時間(UTC):2026-06-18T13:43:15

2. 2026年6月18日 13:44 UTCresolved

   この事件は解決しました.

公式のインシデント更新を自動翻訳しています。