Memsource の障害履歴

1. 2026年10月15日 9:44 UTCinvestigating

   現在、CATエディタ、API、プロジェクト管理、翻訳メモリ、関連コンポーネントなど、EU地域におけるPhrase TMSサービスに関する問題について調査しています。 ユーザーは、この時点で、これらのサービスにアクセスできなかったり、エラーが発生することがあります。 当社のチームは、原因を特定し、可能な限り迅速にフル機能を復元するために積極的に取り組んでいます.

2. 2026年10月15日 9:58 UTCmonitoring

   サービスは、EU地域で安定化され、TMSをPhraseするようになりました。 状況を監視し続けます.

3. 2026年10月15日 10:24 UTCresolved

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

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

1. 2026年9月23日 8:48 UTCinvestigating

   一部のユーザーは、Phrase TMS にアクセスして問題が発生する可能性があります.

2. 2026年9月23日 8:58 UTCidentified

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

3. 2026年9月23日 9:28 UTCmonitoring

   修正を実装し、結果を監視しています。 フレーズTMSは、問題なくアクセスできるようになりました.

4. 2026年9月23日 10:03 UTCresolved

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

5. 2026年9月30日 12:12 UTCpostmortem

   ## 紹介 2026年9月23日、Phrase TMSへのアクセスに影響を受けた事故について詳細をお知らせします。 午前9時02分～午前11時27分頃、Phrase PlatformのPhrase TMSを開くと、サインインが完了できません。 リダイレクト ループでキャッチするか、サインイン エラーで Phrase TMS のログイン ページに戻りました。 既にアクティブな Phrase TMS セッションが影響されず、顧客データが紛失または修正されていないユーザー。 Phrase Platform自体にサインインすると、パスワードとシングルサインオンの両方で、インシデント全体で作業を続けました。 そこで、Phrase TMS ログインページに直接パスワードでサインインしました。 このポスト・モレテムは、何が起こったのか、どのように解決されたのか、また、何が起こっているのかを説明します。 ## タイムライン * **Sep 23, 2026 に 9:02 午前 EST ** – Phrase TMS の Web アプリケーションへの更新は、生産に住んでいた. サインインフローがログイン後にリダイレクトを処理する方法に対するセキュリティ改善が含まれています。 この点から、Phrase Platform から Phrase TMS を開くユーザーはサインインを完了できません。 問題は内部で調査された。 * **Sep 23, 2026 に 10:59 午前 EST ** – 9:02 AM CESTのアップデートは原因として識別され、ロールバックの準備を開始しました。 * **Sep 23, 2026 に 11:13 AM EST ** – 試験環境でロールバックを検証し、生産開始まで展開。 * **Sep 23, 2026 に 11:27 午前 EST ** – ロールバックは、すべての生産地域に住んでいました。 顧客対応のインパクトは終了いたしました。 * **Sep 23, 2026 に 11:28 AM CEST** – 私たちは、フレーズプラットフォームからPhraseTMSに署名が再び働いたことを確認しました. * **Sep 23, 2026 に 12:04 PM EST ** – ステータスページにて、インシデントが解決しました。 ## 根本原因 本件は、Phrase TMS の Web アプリケーションに対するセキュリティ改善により生じた。 その目標は、ユーザーがサインインした後に信頼できる目的地にのみ送信されていることを確認することです。 これを行うには、Webアプリケーションは、Phrase TMS Webアドレス自体へのリダイレクトのみを受け入れます。 しかし、ユーザーがPhrase PlatformからPhrase TMSを開くと、サインインプロセスは、異なるPhrase Webアドレス間でユーザーを合法的に移動します。 当社のサーバーは、信頼されるフレーズドメインのリストに対して、これらのリダイレクトのそれぞれを確認し、それらを許可します。 TMSコアアプリケーションの新しいチェックは、このサーバー側のチェックよりも厳格で、それをオーバーロードしました。 その結果、正式リダイレクトは、Phrase TMS のスタートページに置換され、署名プロセスを再び開始しました。 ユーザーは、サインインを繰り返してループするか、エラーでPhrase TMSのログインページに戻って着陸します。 Phrase Platform自体にサインインすると、パスワードとシングルサインオンの両方で、インシデント全体で作業を続けました。 そこで、Phrase TMS ログインページに直接パスワードでサインインしました。 署名付きユーザーがPhrase PlatformからPhrase TMSに移行するステップで失敗が発生しました。 そのため、一部の影響を受けたユーザーは、パスワードの問題として問題が報告されました。認証情報を入力しましたが、ログイン画面に戻りました。 ## 再発を防ぐアクション 1。 **ロールバック変更** - 問題を引き起こしたアップデートは、通常のサインインを復元した11:27 AM CESTのすべての生産地域にロールバックしました。 2。 **連続サインイン監視** - 私たちは、すべての生産地域および当社のテスト環境で定期的に実行自動チェックを追加します。 各チェックは、Phrase Platform から Phrase TMS までの完全なサインインを実行し、失敗するとすぐに当社のオンコールエンジニアに警告します。 それらに頼る前に、これらのチェックは、この事件で発生した正確な失敗を検出することを確認します.

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

1. 2026年9月10日 5:06 UTCinvestigating

   現在、Phrase Strings と Phrase TMS の間のジョブの同期にEU地域における Webhooks による影響する問題について調査しています。 2つの製品間での翻訳ジョブを同期する際に、不具合や遅延が発生する場合があります。 私たちのチームは、根本的な原因を特定し、可能な限り迅速にフル機能を復元するために積極的に取り組んでいます.

2. 2026年9月10日 5:34 UTCmonitoring

   Phrase Strings と Phrase TMS 間での Webhook 同期の失敗に対処するために修正が実装され、デプロイされました。 現状を監視し、完全な安定性を確認しています。 解像度を検証したら、さらにアップデートを行います.

3. 2026年9月10日 6:03 UTCresolved

   Phrase Strings と Phrase TMS の Webhook 同期の問題は、米国データセンターの顧客を含む、完全に運用されているように解決および検証されていることを確認しています。 終了いたしました.

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

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

   現在、Phrase TMS (EU) 内の Jobs ビューで遅い問題を引き起こしている問題を調査しています。 プロジェクト管理機能にアクセスする際には、負荷時間を遅らせたり、性能を低下させる場合があります。 私たちのチームは、根本原因を特定し、可能な限り迅速に正常な性能を回復するために積極的に取り組んでいます.

2. 2026年9月1日 15:00 UTCinvestigating

   問題の根本原因を特定しました。 私たちのチームは、積極的に修正を実施しています。 進捗状況を把握し、更新を行います.

3. 2026年9月1日 15:34 UTCmonitoring

   修正が展開され、結果を監視しています。 問題が発生した場合は、ブラウザのキャッシュをクリアし、TMSで開くすべてのタブを閉じる必要があります.

4. 2026年9月1日 16:23 UTCresolved

   問題は解決され、性能は安定しています.

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

1. 2026年8月31日 15:06 UTCinvestigating

   弊社では、現在、第三者の翻訳ベンダーであるGengoと通信する際に断続的なエラーが発生しています。 これは、価格計算のタイムアウトと502エラーを引き起こし、Gengoを介してルーティングされた翻訳注文のための注文送信を引き起こし、EUとUSデータセンターの両方に影響を与えます。 ゲンゴは、終端の問題を確認し、調査しています.

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

   Gengoは、末尾に根本的な問題を解決しました。 Gengoへの価格計算と翻訳注文の投稿が再び機能します.

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

1. 2026年8月31日 13:11 UTCinvestigating

   ユーザーは、既存のジョブを開いたり、Phrase TMS プロジェクト内で新しいジョブを作成することができません。 課題を調査しています.

2. 2026年8月31日 13:22 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年8月31日 13:46 UTCidentified

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

4. 2026年8月31日 16:02 UTCmonitoring

   修正を実装し、結果を監視しています.

5. 2026年8月31日 16:53 UTCresolved

   問題は解決しました.

6. 2026年9月4日 8:45 UTCpostmortem

   ## 紹介 2026年8月31日、ファーゼTMSに罹患した事故について詳細をお知らせします。 2:26 と 5:57 PM CEST の間、レガシープロジェクトページの一部のユーザーは、ジョブの作成や編集などのツールメニューのアクションを使用しなかったり、分析を実行したり、ジョブの実行をしたりするなど、CAT の Web エディターが期待どおりに起動しなかったり、プロジェクトページにユーザーを返したりした。 このポスト・モレテムは、何が起こったのか、どのように解決されたのか、また、何が起こっているのかを説明します。 ## タイムライン * ** 2026年8月31日 2:26 PM CEST** – 読み込まれたユーザーのためのプロジェクトページでスクリプトの実行を破った欠陥を含むコード変更が生成されました。 * ** 8月 31, 2026 に 2:49 PM EST ** – 最初の顧客レポートは、ツールメニューのボタンを無効化して、エディタで開くのに失敗したジョブを記述しました。 ※** 2026年8月31日(金)午後3時10分頃までに、当社のチームは問題の根本原因を特定しました。 ※** 8月31日(水)午後3時48分に2026時00分～下流不具合の修正が完了しました。 * ** 8月 31, 2026 に 4:04 PM EST ** – プレプロダクション環境で修正を行いました。 * ** 2026年8月31日 5:18 PM CEST ** – 生産開始の修正の展開. * ** 8月 31, 2026 に 5:57 PM EST ** – すべての影響を受けた顧客のために固定は生産で十分に生き、正常な機能性は元通りにありました。 ## 根本原因 共有プロジェクトページの無関係、マイナーな表示問題の修正を目的としたコード変更による事件が発生しました。 つまり、値がページ内で直接埋め込まれたスクリプトにどのように入力されたかを変更しました。 ページをレンダーするシステムは、安全のための値を自動的にエンコードしますが、エンコーディングは、スクリプト内の定期的なページコンテンツに存在する値と区別しません。 その結果、変更が生成されたら埋め込まれたスクリプトの構文はサイレントに壊れていました。 ブラウザは、無効なスクリプトの構文に遭遇すると、ページ上のすべてのスクリプトが実行を停止するので、元の変更に関連する部分だけではありません。 これは、顧客が2つの別々の問題のように見えるものを経験した理由です\(無効なメニューボタンとジョブはエディタで開くことができません\)、実際には、同じ単一の欠陥のダウンストリーム効果。 リリース前の問題は未だに行われている検証は、下流データが修正されたことを確認したため、リリース前には、実際のページをブラウザに読み込まなかったため、正しくレンダリングされ、最後に実行されたことを確認しました。 ## 再発を防ぐアクション 1。**Fix デプロイ** - 根本的な不具合を修正し、同一日に特定された生産に展開しました。 2.**エンジニアリングガイダンスを更新しました** - 内部エンジニアリングの文書を更新し、この特定の失敗パターンを明確に記述し、それを処理するための正しい、安全な方法が明確に示しています。そのため、コードレビューの進行中に、この間違いのカテゴリがキャッチされます。 3。 **自動検出改善のアンダーウェイ** - 私たちは、フロントエンドの故障のこのクラスに自動監視を追加する作業をしています。そのため、顧客のレポートに依存するのではなく、顧客が影響を受ける前に同様の問題が対処できます.

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

1. 2026年8月19日 12:16 UTCinvestigating

   現在、Phrase TMS(EU)の翻訳メモリ機能に影響を及ぼす問題について調査しています。 ユーザーは、この時間に翻訳メモリーやその他の関連操作を作成する問題が発生することがあります。 当社のチームは、原因を特定し、可能な限り迅速にフル機能を復元するために積極的に取り組んでいます.

2. 2026年8月19日 12:34 UTCidentified

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

3. 2026年8月19日 13:19 UTCmonitoring

   修正を実施し、状況を監視しています.

4. 2026年8月19日 14:09 UTCresolved

   事件が解決しました.

5. 2026年10月6日 8:14 UTCpostmortem

   ##**導入** 2:11 PM CESTと4:10 PM CESTのPhraseで発生したイベントの詳細は、2026年8月19日、Phrase TMS \(EU\)で翻訳メモリの劣化や、これらの問題が再発を防止するためにPhraseのエンジニアが何をしているかについて詳しく紹介したいと思います。 ##**タイムライン** * ** 8月 19, 2026 に 2:11 PM EST:** Phrase は、Phrase TMS \(EU\) の翻訳メモリ機能に影響を及ぼす問題を特定しました。 ユーザーは、翻訳メモリの作成や関連する操作の実行時にエラーが発生しました。セグメントの確認、関連するサービスやユースケースのエラー率の上昇などを含みます。 * ** 8月 19, 2026 に 2:32 PM EST:** ルート原因は特定され、エンジニアはクラスターを再バランスし、影響を受けたノードを再起動することによって、影響を受ける環境に修正を適用し、回復をスピードアップしました。 * ** 8月 19, 2026 に 3:10 PM EST:** 翻訳メモリ作成と関連業務が正常に機能するように確認されました。 * ** 8月 19, 2026 に 4:10 PM EST:** 持続的な監視期間が経過した後、再発は認められなかった。 ##**ルート原因** 調査では、翻訳メモリデータを格納するデータベースクラスターに発生したインシデントが明らかにした。 単一の翻訳メモリは、時間が経つにつれて、非常に大きく成長し、より広いクラスターの健康とメタデータ管理を調整したノードによって提供される読み取りアクティビティのdisproportionate共有が必要です。 クラスターはゼロダウンタイムメンテナンスの日を経っていたため、大量の協調アクションとクラスター内の協調ノードの高負荷が発生しました。 これらの2は、ピーク負荷と組み合わせることで、複数の協調ノードのパフォーマンスが低下し、誤差率を上昇させ、性能を低下させました。 ##**再発を防ぐ行為** 将来的に同様の事件を防止し、負の影響を緩和するために、次の取り組みを行います。 * 翻訳メモリ検索や更新のためのより多くのヘッドルームを作成するためにクラスターとその裏付けインフラストラクチャをバランス調整しました。 * 影響を受けたトランスレーション・メモリ・クラスターの継続的なメンテナンスをPaused。 * 調整ノードの容量を改善し、クラスターのトポロジーを改善して、突然のリクエストピーク時にクラスターの影響を防ぐことができます.

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

1. 2026年8月7日 7:27 UTCinvestigating

   現在、ブランチがマージされると、適用されない変更を引き起こす可能性のあるPhrase Strings (EU) で欠落しているブランチイベントの問題について調査しています.

2. 2026年8月7日 7:54 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年8月7日 8:18 UTCidentified

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

4. 2026年8月7日 8:30 UTCmonitoring

   修正を行いました。 欠落したイベントのバックログが処理されるようになりました。 キューが完全に処理されると、未統合のブランチが自動的に不足している変更を自動的に受け取ります。 キューと結果を監視しています.

5. 2026年8月7日 14:12 UTCresolved

   インシデントウィンドウ内のブランチへの変更が完全に適用されます。 影響を受けた枝が特定され、影響を受けたお客様は直接連絡を受けています。 この事件は解決しました.

6. 2026年9月11日 6:11 UTCpostmortem

   ## 紹介 2026年8月6日～8月7日にかけて、EUプラットフォームで発生したPhrase Stringsに影響を受けた事件について詳しく紹介したいと思います。 この期間中、ブランチで行われた変更は、変更処理パイプラインによって記録されていない。 その結果、インシデント中にマージされたブランチは、そのウィンドウの間に変更することなくマージすることができ、差が生じた場合でもブランチ比較画面は違いを示すことができません。 このポスト・モレテムは、何が起こったのか、どのように解決されたのか、また、何が起こっているのかを説明します。 ## タイムライン * ** 8月 6, 2026 に 5:44 PM CEST** – ネットワークの中断は、当社の変更処理パイプラインがデータベースの変更を読むために使用して接続を重ねました. 接続が復元できず、ブランチの変更が処理されなくなってしまいました。 影響を受けたコンポーネントは、健康的に報告し続けたので、自動アラートは発生しません。 * ** 8月 7, 2026 に 09:11 午前 EST ** – 顧客レポートに従った問題が特定されました。 * ** 8月 7, 2026 に 09:19 午前 EST ** – 事故は、最も厳しいレベルにエスカレーションされました。 * ** 8月 7, 2026 時 約10:20 EST ** – 影響を受けたコンポーネントは再起動して復元され、再開処理を変更しました。 * ** 8月 7, 2026 に 10:46 午前 EST ** – 保留中の変更のバックログは完全に処理され、パイプラインが巻き上げられました。 * ** 8月 7, 2026 午後** – 影響を受けたお客様は、変更を復元するために必要なデータと個別に識別され、連絡を行いました。 ## 根本原因 インシデントは、システムがデータベースから変更を分岐処理パイプラインに流すための接続を解除する一時的なネットワーク中断によってトリガーされました。 この接続が自動で再接続しようとすると、再接続の試みは、成功または失敗するのではなく、無期限に掛けられた。 コンポーネントが失敗を報告したことがないため、プラットフォームの自動回復メカニズムはエラー状態を報告するコンポーネントを再起動します。 コンポーネントは、変化を全く処理せず、正常に動作するように思われた状態で残っています。 これは、接続の標準的な再起動が問題を解決しなかった理由です, 完全に根本的なプロセスを再起動しながら、, 新鮮な接続を確立しました, やった. このパイプラインの監視は、事件全体で「健康」を報告し続けた信号に依存しているため、状況はすぐに検出されず、実際に流れ、処理されたかどうかを別々に測定しませんでした。 ## インパクト * 事件中に変化していたブランチは、** 合併がデータを失うことはありませんでした。 パイプラインが回復したら、その変更が処理されました。 * 事件時にマージされる **were** のブランチは、インシデントウィンドウの間にそれらに行われた変更なしでマージされた。 事故前の変更は影響を受けない。 ※お客様の数が少ないだけに影響を受けました。 それぞれが個別に接触し、影響を受けた変化を回復するために必要なデータと手順で提供されます。 ## 再発を防ぐアクション 1。** 修正された誤解を招く監視** - 私たちは、さまざまな生産環境を一緒にグループ化した監視構成を修正しました。これにより、問題の意識が遅れていました。 2.**意味のある健康信号を追加** - パイプラインを通して変化が実際に流れているか、その背後にあるかを測定する監視をしています。しかし、作業が行っていない間に「健康」を報告できるステータス信号に依存するのではなくです。 これは、類似の屋台がすぐに検出されるようにします。 3。 **自動回復の改善** - 当社は、このコンポーネントの再接続と再試行の動作を見直し、スタックされた接続は、自動再起動をトリガーする本物的な失敗になります.

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

1. 2026年8月6日 8:11 UTCinvestigating

   We are currently investigating an issue affecting Connectors in Phrase TMS. Customers may be unable to access or use Connector functionality during this time. Our engineering team is actively working to identify the cause and restore full service as quickly as possible.

2. 2026年8月6日 8:18 UTCinvestigating

   We are continuing to investigate this issue.

3. 2026年8月6日 8:43 UTCmonitoring

   We have identified the root cause and the issue has now been resolved. Connectors should be appearing as active again. We will continue to monitor the situation to ensure full stability.

4. 2026年8月6日 12:00 UTCmonitoring

   We continue monitoring the situation.

5. 2026年8月6日 13:19 UTCresolved

   The incident has been resolved and all components are back to operational.

1. 2026年7月28日 7:19 UTCinvestigating

   エンジニアリングチームは、新しいワークフローエンジンがワークフローを実行していない Orchestrator の問題を特定しました。 問題は調査中です.

2. 2026年7月28日 7:53 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年7月28日 8:30 UTCidentified

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

4. 2026年7月28日 8:35 UTCmonitoring

   修正を実装し、結果を監視しています。 ワークフローエンジンは、保留中の実行のキューを処理します.

5. 2026年7月28日 11:49 UTCresolved

   すべての実行が処理されました。 この事件は解決しました.

6. 2026年7月30日 7:09 UTCpostmortem

   ## 紹介 2026年7月27日～28日に発足したプラーゼ・ Orchestrator に影響を受けた事件について詳しく紹介したいと思います。 この期間中、Next-Genワークフローエンジンのワークフローの実行が進行できず、「実行」状態に立ち往生したままになりました。 事故時にデータが失われない このポストモレテムは、それが解決されたとき、何が起こったのかを説明し、再発を防止するために取られた手順。 ## タイムライン * ** 27 7月 2026 に 18:55 CEST ** – ワークフローエンジンは、データベースクエリのパフォーマンスが劣化してエラーを生成しました。 ワークフローの実行が停止し、進行を停止します。 * ** 27 7月 2026 に 20:54 CEST ** – 「実行」で立ち往生する実行の最初の顧客のレポートが届きました。 * ** 27 7月 2026 に 22:39 CEST ** – 事件は正式に宣言された。 * ** 28 7月 2026 で 02:18 CEST** – サービスの再起動は一時的な救済を提供しました; ワークフローの実行は再開しました。 * ** 28 7月 2026 に 05:15 EST ** – 問題は、基礎となるデータベースのパフォーマンス問題として再発します。 * ** 28 7月 2026 に 09:56 CEST ** – 根本原因は特定され、対処された。 実行が失われませんでした。しかし、部分的なサービスの再起動により、実行中の一部のアクションはリトリビュートされ、そうでなければ成功しなかった場合、少数の実行を引き起こしました。 * ** 28 7月 2026 に 13:46 CEST ** – 固定された実行の完全なバックログがクリアされたように確認されました。 システムは安定して宣言されました。 * ** 28 7月 2026 に 13:48 CEST ** – 事件は解決しました. ## 根本原因 ワークフロージョブスケジューリングシステムで用いられるデータベースインデックスで進行中のbloatによるインシデントが発生しました。 これらの特定のインデックスのパフォーマンスは、以前の書き込みと更新からデッドインデックスエントリを蓄積したため、徐々に時間をかけて劣化します。 ジョブスケジューリングエンジンは、ディスパッチするジョブを決定するために、これらのインデックスをクエリしながら、データベースレベルの調整ロックを取得します。 インデックスの検索が遅くなるにつれて、データベースの構成文のタイムアウトを上回りました。 タイムアウトによってルックアップがキャンセルされたとき、その作業がクラッシュし、再起動する責任のあるスケジューリングプロセス。 スケジューラが実行されていないと、ワークフローの手順はディスパッチされず、すべてのインプログレッシブワークフローの実行が停止しました。 データベースサーバー自体は、通常の CPU と接続レベルで、インシデント全体で健康を維持しました。 問題は、スケジューリングレイヤー内でのみロックとレイテンシーの分裂でした。 サービスの再起動は、クラッシュされたプロセスをクリアし、一時的に実行を復元しました。 しかしながら、インデックスのブロートはまだ存在していたため、クエリの読み込みが再開された時に同じ劣化が再発される。 マニュアルインデックスは、完全に復元されたパフォーマンスを再構築し、問題を解決しました。 ## 再発を防ぐアクション 1。 **自動化されたインデックスメンテナンスが追加されました** - 影響を受けたインデックスのメンテナンスをスケジュールしました。 これにより、このインシデントをトリガーする条件を時間をかけて蓄積し、排除できないブロアが保証されます。 2.**レガシーインデックス削除** - 未使用のレガシーデータベースインデックスが特定され、削除され、全体的なメンテナンス表面を削減し、将来のインデックス衛生を簡素化します。 3。**監視カバレッジの更新** - 当社のモニタリングランドスケープは、ワークフローエンジンの現在の状態を反映するために見直し、更新されています。 この作業は、最初の顧客のレポートの前に、劣化が検出されないままになることを可能にするギャップを閉じます.

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

1. 2026年7月27日 23:48 UTCinvestigating

   エンジニアリングは、新しいワークフローエンジンがワークフローを実行していない Orchestrator の問題を特定しました。 問題は調査中です.

2. 2026年7月28日 0:41 UTCresolved

   すべてのワークフローは、期待どおりに再び実行されます.

3. 2026年7月30日 7:08 UTCpostmortem

   ## 紹介 2026年7月27日～28日に発足したプラーゼ・ Orchestrator に影響を受けた事件について詳しく紹介したいと思います。 この期間中、Next-Genワークフローエンジンのワークフローの実行が進行できず、「実行」状態に立ち往生したままになりました。 事故時にデータが失われない このポストモレテムは、それが解決されたとき、何が起こったのかを説明し、再発を防止するために取られた手順。 ## タイムライン * ** 27 7月 2026 に 18:55 CEST ** – ワークフローエンジンは、データベースクエリのパフォーマンスが劣化してエラーを生成しました。 ワークフローの実行が停止し、進行を停止します。 * ** 27 7月 2026 に 20:54 CEST ** – 「実行」で立ち往生する実行の最初の顧客のレポートが届きました。 * ** 27 7月 2026 に 22:39 CEST ** – 事件は正式に宣言された。 * ** 28 7月 2026 で 02:18 CEST** – サービスの再起動は一時的な救済を提供しました; ワークフローの実行は再開しました。 * ** 28 7月 2026 に 05:15 EST ** – 問題は、基礎となるデータベースのパフォーマンス問題として再発します。 * ** 28 7月 2026 に 09:56 CEST ** – 根本原因は特定され、対処された。 実行が失われませんでした。しかし、部分的なサービスの再起動により、実行中の一部のアクションはリトリビュートされ、そうでなければ成功しなかった場合、少数の実行を引き起こしました。 * ** 28 7月 2026 に 13:46 CEST ** – 固定された実行の完全なバックログがクリアされたように確認されました。 システムは安定して宣言されました。 * ** 28 7月 2026 に 13:48 CEST ** – 事件は解決しました. ## 根本原因 ワークフロージョブスケジューリングシステムで用いられるデータベースインデックスで進行中のbloatによるインシデントが発生しました。 これらの特定のインデックスのパフォーマンスは、以前の書き込みと更新からデッドインデックスエントリを蓄積したため、徐々に時間をかけて劣化します。 ジョブスケジューリングエンジンは、ディスパッチするジョブを決定するために、これらのインデックスをクエリしながら、データベースレベルの調整ロックを取得します。 インデックスの検索が遅くなるにつれて、データベースの構成文のタイムアウトを上回りました。 タイムアウトによってルックアップがキャンセルされたとき、その作業がクラッシュし、再起動する責任のあるスケジューリングプロセス。 スケジューラが実行されていないと、ワークフローの手順はディスパッチされず、すべてのインプログレッシブワークフローの実行が停止しました。 データベースサーバー自体は、通常の CPU と接続レベルで、インシデント全体で健康を維持しました。 問題は、スケジューリングレイヤー内でのみロックとレイテンシーの分裂でした。 サービスの再起動は、クラッシュされたプロセスをクリアし、一時的に実行を復元しました。 しかしながら、インデックスのブロートはまだ存在していたため、クエリの読み込みが再開された時に同じ劣化が再発される。 マニュアルインデックスは、完全に復元されたパフォーマンスを再構築し、問題を解決しました。 ## 再発を防ぐアクション 1。 **自動化されたインデックスメンテナンスが追加されました** - 影響を受けたインデックスのメンテナンスをスケジュールしました。 これにより、このインシデントをトリガーする条件を時間をかけて蓄積し、排除できないブロアが保証されます。 2.**レガシーインデックス削除** - 未使用のレガシーデータベースインデックスが特定され、削除され、全体的なメンテナンス表面を削減し、将来のインデックス衛生を簡素化します。 3。**監視カバレッジの更新** - 当社のモニタリングランドスケープは、ワークフローエンジンの現在の状態を反映するために見直し、更新されています。 この作業は、最初の顧客のレポートの前に、劣化が検出されないままになることを可能にするギャップを閉じます.

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

1. 2026年7月20日 12:53 UTCresolved

   2026年6月16日(木)から1:00PM CESTと6月17日(日)まで、Prase Job Syncコネクタが劣化した性能を発揮します。 既定の接続タイプ 経験豊富な障害で Job Sync を使用しての顧客。 エンジニアリングチームは根本原因を特定し、修正を行いました.

2. 2026年7月20日 12:54 UTCpostmortem

   ### 導入事例 2026年6月16日、01:00PM CESTと6月17日、Phrase Strings APIのパフォーマンスを低下させ、お客様がJob Syncをデフォルトの接続タイプで使用することで、Phrase Strings APIのパフォーマンスを低下させ、障害が発生しました。 今後、このような事故を未然に防ぐことをお詫び申し上げます。 ### タイムライン **Jun 16, 2026 @ 01:00 PM CEST** – ジョブ同期は、デフォルトの接続タイプを使用して顧客に失敗し始めました. コネクタは、Phrase 文字列 API に対して認証できませんでした。 **Jun 17, 2026 @ 10:00 午前EST ** – エンジニアリングチームにより認証障害が特定されました。 **Jun 17, 2026 @ 10:28 AM CEST** – 影響範囲が確認されました: デフォルトの Job Sync 接続を使用しているお客様は影響を受けました。 個人的なアクセストークンベースのコネクターを使用しての顧客は影響を受けませんでした。 **Jun 17, 2026 @ 10:29 AM CEST** – ルート原因が特定されました: いくつかの既存のプラットフォームトークンでマルチプラットフォームトークンのサポートを誤って導入エラーを追加した最近の変更. **Jun 17, 2026 @ 10:40 AM CEST ** – 修正は準備され、レビューのために提出されました. **Jun 17, 2026 @ 10:53 AM EST ** – 修正が展開され、JobSyncの機能が完全に復元されました。 ## 根本原因 マルチプラットフォーム認証トークンのサポートを追加するために導入されたコード変更では、プラットフォームトークンの検証と処理方法をPhrase Strings APIで変更しました。 この変更は、デフォルト接続タイプで使用される既存のトークンフォーマットと互換性がありません。 その結果、プラットフォームトークンは `401 Unauthorized` 応答で Strings API によって拒否されました。 コネクタは、その再試用予算を排出するまで接続を確立し、影響を受けるすべての操作が失敗する。 個人アクセストークンを使用しての顧客は、トークンが異なるコードパスに従って影響を受けませんでした。 ##再発を防ぐアクション 根本原因は、開発中に検出されていないトークン処理に対する後方互換性のない変更でした。 次のアクションが受けられます。 *** auth 変更の互換性テストのトークン形式:** 既存のトークン/認証フォーマットを既存のものと一緒に導入する際には、テストは、新しい検出ロジックで処理される旧式のトークンを、分離の各形式だけではなく、トランジションケースを明示的にカバーしなければなりません.

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

1. 2026年7月16日 15:47 UTCinvestigating

   現在、当社のメトリックサービスに影響を及ぼす問題について調査しています。これにより、一部の顧客のメトリック消費の重複が生じる可能性があります。 当社のチームは、影響を受けたコンポーネントを識別し、根本原因を決定するために積極的に取り組んでいます。 情報が増えるにつれて、さらなるアップデートが提供されます.

2. 2026年7月16日 16:29 UTCidentified

   私たちは、特定のブローカーの不安定性として根本的な原因を特定しました。これは、当社のメトリックサービスで繰り返された消費者グループ再バランスを引き起こし、メトリック更新の重複処理につながることです。 これは、誤った消費の計算や予期しないアカウントブロックを経験する一部の顧客につながる可能性があります。 今後も修正に取り組んでまいります.

3. 2026年7月16日 17:31 UTCmonitoring

   私たちは、問題の進行を中止し、組織が影響を受けたりブロックされたりするなど、インパクトのフルスコープを特定するために取り組んでいます。 欠陥のあるアカウントは、重複排除プロセスを通じて解決のために優先されますが、これは完了する時間がかかります.

4. 2026年7月16日 19:04 UTCidentified

   ブロックされたすべての組織のメトリクス消費を巧妙に排除しました。 私たちは、明日の朝にこれらの修正をスケーリングするフルチームと、正確な請求サイクルデータを確実にするために、組織化の重複排除ツールを開発するために継続的に取り組んでいます.

5. 2026年7月17日 13:02 UTCmonitoring

   引き続き、7月16日に特定された重複したメトリック消費問題の解決に取り組みます。 根本原因は特定され、対処されています。 最後の更新以来、当社のチームは以前にブロックされたすべてのアカウントの重複したデータを修正しました。 現在、影響を受けたアカウントの残りのセットを運用し、このクリーンアップが今後続くことを期待しています。 さらに重複が起こらないため、この作業は履歴データのみを処理します.

6. 2026年7月20日 12:07 UTCresolved

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

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

1. 2026年7月16日 14:49 UTCinvestigating

   現在、ファーゼ・オーケストラーに影響を及ぼす問題について調査しています。 当社は、根本原因を特定し、より多くの情報が利用可能になったらただちに更新を行います.

2. 2026年7月16日 15:27 UTCinvestigating

   今後もこの問題について調査を続けてまいります.

3. 2026年7月16日 15:27 UTCidentified

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

4. 2026年7月16日 15:41 UTCmonitoring

   修正を実装し、結果を監視しています.

5. 2026年7月16日 16:12 UTCresolved

   5:32 PM CEST以降、オーケスト(EU)が再び利用可能になりました。 保留中の実行はすべて処理されます。 この事件は解決しました.

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

1. 2026年7月10日 14:24 UTCinvestigating

   現在、Phrase 文字列 (EU と US の領域) の翻訳センターに影響を及ぼす問題について調査しています。 当社のエンジニアリングチームは、潜在的な原因を特定し、その解決に積極的に取り組んでいます。 調査が進むにつれて、さらなるアップデートが提供されます.

2. 2026年7月10日 14:37 UTCmonitoring

   修正を実装し、結果を監視しています.

3. 2026年7月10日 15:24 UTCresolved

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

4. 2026年8月7日 7:14 UTCpostmortem

   ## Introduction On July 10, 2026, parts of the Phrase Strings frontend at [app.phrase.com](http://app.phrase.com/) failed to load correctly for a short period, after required stylesheets and scripts failed to load — the underlying service itself stayed available. The issue began at 16:08 CEST and was resolved by 16:27 CEST. This post-mortem explains what happened and what we're doing to prevent a recurrence. ## Timeline * **Jul 10, 2026 at 16:08 CEST** – A deployment introduced new application assets that were never uploaded to our storage service, so the application could no longer load its stylesheets and scripts for customers. * **Jul 10, 2026 at 16:21 CEST** – Issue detected, incident declared. * **Jul 10, 2026 at 16:24 CEST** – Root cause identified. * **Jul 10, 2026 at 16:26 CEST** – Fix applied. * **Jul 10, 2026 at 16:27 CEST** – Customer-facing impact ended. * **Jul 10, 2026 at 16:32 CEST** – Incident downgraded to monitoring while the underlying configuration was addressed. * **Jul 10, 2026 at 17:12 CEST** – Configuration corrected, incident resolved. ## Root Cause During a planned, routine maintenance, a configuration change unintentionally disabled the process that uploads application assets \(stylesheets, scripts\) to our storage and content-delivery service. This went unnoticed at first, since the assets already in place kept working and no new versions had been shipped yet. On July 10, 2026, a deployment shipped new versions of these assets. Because uploading was still disabled, the new files never reached the storage service, and the application could not load its stylesheets and scripts. ## Actions to Prevent Recurrence 1. **Asset synchronization re-enabled** – The disabled process was fixed, restoring correct asset delivery. 2. **Asset availability monitoring** – Adding monitoring to detect asset load failures automatically, before customers are affected.

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

1. 2026年7月8日 12:57 UTCinvestigating

   プロジェクトから消える案件について、ユーザーからレポートを受け取り、現在問題について調査中です.

2. 2026年7月8日 13:08 UTCmonitoring

   問題は特定され、修正が実施され、状況を監視しています.

3. 2026年7月8日 13:55 UTCresolved

   事件が解決しました.

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

1. 2026年7月7日 8:34 UTCinvestigating

   We are currently investigating issues with CAT Web Editor.

2. 2026年7月7日 8:59 UTCmonitoring

   The issue has been identified, a fix was implemented and we are monitoring the situation.

3. 2026年7月7日 9:27 UTCresolved

   The incident has been resolved.

1. 2026年6月29日 7:30 UTCinvestigating

   Hi everyone, this is a test. Please ignore, thank you!

2. 2026年6月29日 8:05 UTCidentified

   Hi everyone, this is a test. Please ignore, thank you!

3. 2026年6月29日 8:09 UTCresolved

   This incident has been resolved.

1. 2026年6月26日 16:19 UTCinvestigating

   Hi everyone, this is a test. Please ignore. Thank you!

1. 2026年6月26日 7:31 UTCinvestigating

   Hello everyone, this is a test. Please ignore, thank you!

2. 2026年6月26日 8:16 UTCinvestigating

   Hello everyone, this is a test. We're "investigating" the issue. Please ignore, thank you!