115 Split incidents · 2026年4月 — official updates, affected components, duration and resolution details.
現在、この問題を調査中です.
VM インフラストラクチャ上の CI パイプラインは Initialize のステップで失敗しています。なぜなら、タスクは意図したプールの外側のデリゲートに行くからです
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
##**概要** 2026年10月19日、午前12時10分〜12時55分の間、Prod4の経験豊富なエラーとハーネスパイプラインサービスの断続的な利用不能性に関する顧客。 重いパイプラインの実行は、パイプラインサービスでCPUとメモリ使用の急激な上昇を運転し、短期間ですべてのサービスインスタンスが利用できなくなった。 ハーネスエンジニアリングは、サービスを復元する垂直と水平の両方のサービスをスケールアップしました。 根本的な行動の修正がロールアウトされています。 ##**ルート原因** 10月19日には、非常に大きな実行グラフで同時実行回数が増え、クラスターリソースの急激な増加を引き起こします。 サービスは、このフル実行グラフを視覚化目的のために保存し、パイプラインを次の状態に進行させます。 Prod4 のオートスケーラは、CPU とメモリの急激な上昇によるリソースのスケーリングには通常よりも時間がかかりました。 修正の一環として、実行グラフの更新は、フルグラフの代わりにグラフの変更を増分処理します。 段階的な方法でロールアウトされ、初期に完全にロールアウトされます。 ##**インパクト** * 感染したユーザー: Prod4 の顧客。 * 症状:ハーネスプラットフォームにおけるパイプライン機能の異常性。 *データ:データの損失はありません。 ※ 希望の回避策: お客さまから必要ない ハーネスエンジニアリングは問題を解決しました。 * 衝撃の持続時間 約20分、25分程度の性能を発揮します。 顧客との回復および確認されたプラットホームの安定性の後でハーネスは監視を続けました。 ##**レビュー** **即時** ハーネスエンジニアリングは、垂直に\(インスタンスごとのリソース)と横に\(more instances\)のパイプラインサービスをスケールアップし、不健康な状態でインスタンスを削除しました。 インスタンスは安定化され、通常のサービスが復元されました。 修正が完全にロールアウトされるまでシステムをスケールアップします。 **永続的修正とアクションアイテム** そのような問題が起きるのを防ぐため、ハーネスは 1。 影響が誰にも最小限であるため、オートヒール/スケーリングプロセスを調整します。 2. 実行グラフの流れを最適化し、大きなグラフがより速く処理できるようにします.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
お問い合わせ お問い合わせ.
公式のインシデント更新を自動翻訳しています。
現在、Harness Cloud がビルド実行に影響を与える Maven Central にアクセスしたときに HTTP 429 (rate-limiting) エラーが発生しています。 Sonatype と連携し、課題を迅速に解決します。 進捗状況を把握し、更新を行います.
この事件は解決しました.
tldr:\(maven Central\ による短いレート制限がありました) 続くより多くの細部
公式のインシデント更新を自動翻訳しています。
修正を実装し、結果を監視しています.
この事件は解決しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
今後もこの問題について調査を続けてまいります.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
修正を実装し、結果を監視しています。 問題の修正確認をしております.
この事件は解決しました.
# 1. まとめ 2026年10月6日、IaCMステージを含むパイプラインはProd1で約2時間起動できませんでした。 パイプラインが実行計画を作成することを試みたとき、Affected ユーザーがエラーを見ました。 IaCM ステージを使用しなかったパイプラインは、日常的に実行し続けています。 根本的な原因は、IaCM 段階の実行を処理するサービスにおける内部のロギングの欠陥でした: 特定の、まれなタイミング条件下では、サービス独自のロギングシステムが、それ自体の不明確な待機を終わらせることができ、それは順番にパイプラインの実行計画を準備するための広範なプロセスを延期しました。 問題は、1つの顧客のパイプラインからのログ活動の異常に大きい破烈によって誘発されました。 従来の安定版に戻り、恒久的なコード修正がテスト中です。 # 2. インパクト ※Prod1のIaCMステージを使用したパイプラインは、約2時間起動できません。 * Prod1クラスターの複数の顧客は影響を受けました。 ※IaCMステージを使用しなかったパイプラインは、通常は影響を受けず、継続して走っていたことではありません。 ※この事故によりデータが失われたことはありません。 ※このインシデントを解決するために使用されるロールバックの副作用として、1人の顧客のための無関係な修正 \(長期的に実行中のパイプライン\の間に一定の認証トークンが有効残っている期間を延長)一時的に再変換されました。 その修正は、同じ夕方に再適用されました。 # 3. 根本原因 IaCM パイプラインのステージを担当するサービスは、内部のキューを介して活動を記録します。ログメッセージはキューに配置され、単一のバックグラウンドワーカーは継続的にそれから読み出し、メッセージを書き出します。 別に、そのサービスは、特定のログメッセージの重度を同じキューに書き換えることができるフィルタを持っています。 特定の狭いタイミング条件下では、このコマンドはデッドロックを生成しました。キューが完全に完全な瞬間に、書き込まれたメッセージが送信されてしまった場合は、キュー上のスペースを解放する責任のあるワーカーがスペースを解放するのを待っています。この条件は、そのスペースを解放できる唯一のものだったため、解決できませんでした。 それが起こったら、何もログに必要とされたサービスの他のすべての部分が待っていたし、IaCM ステージを使用してパイプライン計画作成プロセスにカスケードされた。 # 4. 決断 * 即時のインシデントを解決した最後の安定したバージョンに戻した。 # 5. 予防行動 1。**根本的な欠陥を最適化する**: ログフィルタを最適化し、ログラインを生成したスレッドでメッセージの重大性を書き換えるので、同じ背景のワーカーのキューを繰り返しているのではなく、デッドロック条件を完全に排除します。 2。**ロギングキューヘルスの監視**:メトリックを追加し、この内部キューに警告して、顧客レポートに依存するのではなく、当社のオンコールチーム上の飽和ページのこのクラスが自動的に表示されます。 3。**限界を評価し、非常に大きなパイプラインで高いストレステストを実行**:
公式のインシデント更新を自動翻訳しています。
10月 7, 2026, から 08:00 UTC へ 11:00 UTC (1:30 PM から 4:30 PM IST), Prod 7 クラスターのパイプライン実行は、ポリシーで断続的な失敗を見ました (OPA) ステップ評価.
公式のインシデント更新を自動翻訳しています。
修正を実装し、結果を監視しています.
この事件は解決しました.
#### 概要 Prod 2の顧客は、起動時にいくつかの検証手順の断続的な失敗を経験しました。 感染した手順は、連続検証\(CV\) が内部ハーネスサービスに到達できなかったというメッセージで起動直後に失敗しました。 接続プールを導入した最近のサービスアップデートから、受信サービスのタイムアウトと互換性のない、パフォーマンスと信頼性を向上させる問題。 顧客データの紛失・破損は行いません。 ### 顧客の影響 顧客CV Verifyの手順 Prod-2では、インシデントウィンドウの断続的なステップの失敗を見ました。 失敗率が低い — ウィンドウ全体で正常に完了した実行の大部分。 CV Verifyの手順を使用しなかったパイプラインは影響を受けません。 ## 根本原因 最近のCVサービス更新では、内部プラットフォームコンポーネントへの接続プールを導入し、そのコンポーネントのアイドルタイムアウトよりも長期間持続可能になりました。 接続のアイドルは、サーバーによってサイレントに閉鎖されていました。CVサービスはこれを検知せず、そのような障害に対して再試行ロジックがなかったため、Verifyのステップ障害として直面するようにしました。 問題は、期限が切れるのに十分なアイドルになるために起こった接続にのみ影響を受けるため、断続的でした。 ##マイティグレーション 受取サービスのアイドルタイムアウト内では、接続の持続期間が減少しました。 障害はすぐにゼロに低下し、このタイプのさらなるステップの失敗は、任意の生産環境で観察されていない。 ## 次のステップ 再発を防ぐため、ハーネスは次のようになります。 ***Fix接続処理:** デフォルトでは、接続の失敗時に自動再試行が有効になっているため、階段接続エラーが透明に処理されます。 ***ステップ起動時にレジリエンスを追加します。** Verifyのステップ開始時に内部サービスコールのバックオフで再試行を導入するので、独立した一時的な障害は即時のステップ失敗として表面しません。 * **警告の改善:** 内部接続エラーレートの監視を強化しました.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
今後もこの問題について調査を続けてまいります.
問題が特定され、修正が実装されています.
この事件は解決しました.
## 概要 **火曜日、6 10月 2026**、**Prod1**で**OpenTofuプラグインを使用するIaCMパイプラインは、生産アカウントのために断続的に失敗し、感染した秘密を正常に注入し、その後、期限切れまたは失敗した認証を処理します。 同じパイプラインは、設定変更なしで再試行に成功しました。 典型的な失敗の実行は、約90分間走った。 他のハーネスモジュールは広く影響を受けていませんでした。 お客様のデータ損失の報告はありません。 トークンの寿命を延ばすパイプラインは、この欠陥によって影響を受けませんでした。 ## 根本原因 IaCM は 1 時間後に期限が切れた認証トークンを削減しました。 ポリシーは、後で長い実行でチェックし、トークンを拒否したので、ステップはタイムアウトまたは失敗した認証をチェックアウトします。 その1時間の寿命は固定されました。 約90分の実行は1時間マークを交差させました。これは、障害が長いパイプライン上に現れ、より短い再試行で頻繁にクリアされた理由です。 同じアカウントのプランエラーの別のセットは、顧客ワークスペースの認証設定から来ており、このインシデントの外にあります。 ## インパクト ***製品エリア:** OPA sdk に話す IaCM プラグインを使用して IaCM パイプライン。 ***顧客体験:** 秘密の注入の後の断続的なタイムアウトおよび認証失敗は、約1時間以上実行します。 ***環境:** Prod1、1つの生産アカウント ***データ:** データの損失が報告されていない。 ## 修正 * * 即時:** 影響を受けるProd1アカウントのステータスページを開き、プラグインの修正が構築された間、IaCMマネージャーが1つのクラスで変更を送信します。 *****お名前 OpenTofu プラグインのホットフィックスを継承し、トークンの有効期限が設定可能です。 生産では、寿命は約6時間に上げられたため、長いパイプラインはトークンを上回らない。 Hotfix は QA で検証され、Prod1 にデプロイされました。 原因の混乱に報じます。 ご不明な点がございましたら、ハーネスサポートにお問い合わせください.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
今後の問題がないか引き続き監視しています。
修正と解決されたSSOの問題を確認します.
## Okta アプリケーション SP-Initiated SSO ログイン失敗 # まとめ 10月5日、2026日、18:18 UTCと10月6日、2026日、0026 UTC、一部のハーネスは、SAMLシングルサインオン\(SSO\)を介してMCPサーバーをホストハーネスにサインインできませんでした。 主要なハーネスポータルユーザ認証は、完全に動作し続けます。 失敗したユーザーはログインエラーを見たり、サインインを補完する代わりに無効なSSOページにリダイレクトされたりしました。 問題は、ハーネスIDサービスのバージョンアップで変更を破ることによって引き起こされました。 弊社では、ホットフィックスのシリーズを固定し、すべての影響を受けたお客様に対して、SSO ログインを完全に復元しました。 # インパクト SAML SSO 経由でハーネス MCP にサインインしたユーザーは、認証を完了できませんでした。 SSO に依存する MCP セッションは更新できませんので、一部のユーザーは再びサインインし、できませんでした。 Hosted MCP への非 SSO のログインは、ほとんどのインシデントで動作します。 顧客データが紛失または露出されていない Okta で独自の汎用 SAML 2.0 アプリケーション構成を使用している顧客は影響を受けませんでした。 # 根本原因 2026年9月29日、オクタ・インテグレーション・ネットワークに、ハーネス・アプリケーションのアップデート版が公開されました。 更新は、複数の応答\(ACS\) URLを登録するためのサポートを追加しました。これにより、複数の地域や環境でハーネスを実行している顧客は複数のコールバックURLを設定できます。 ハーネスには、Oktaに送信するSAML認証リクエストでAssertionConsumerServiceURL値が含まれています。 この更新の前に、Okta は、設定された追加の ACS URL なしで、アプリケーションのデフォルト ACS URL に SAML のアサーションを返さずに、アプリケーションインスタンスの値を検証しなかった。 更新後、この検証は、既存のアプリケーションインスタンス全体で有効になりました。これにより、顧客は追加のACS URLを設定しませんでした。 リクエストされた値は、インスタンスの登録リストに表示されていないため、Okta は HTTP 400 エラーを返します。 更新されたアプリケーションは、公開された統合の既存のインストールに対する後方互換性検証を含むOIN標準の公開レビューを通過しました。 この変更は、追加のACS URLが設定されていないインスタンスの検証動作が、そのレビュー中には表面化されていないため、リリース時に顧客に達しました。 # 修正 **即時対応** ステータスページで2つの回避策が公開されました。Okta\(IdP-initiated login\)のハーネスタイルからサインインするか、Harness Oktaアプリケーションの追加のACS URLフィールドにアプリケーションのOkta SSO URLを登録します。 ハーネスは、影響を受けた顧客を直接関与し、サインインを検証しました。 **決断** 以前のバージョンに戻ってアプリケーションをロールバックすることは、次のリリースに同じ中断を延ばすため、意図的に回避されました。 影響を受けたお客様は、ACS URL の登録を解除する代わりに、ACS URL の検証条件を再度作成するために Okta と連携し、ACS URL が設定されていないインスタンスは、以前に行われたように正確に動作し、顧客のアクションは必要ありません。 # アクションアイテム こうした問題が起きるのを防ぐため、ハーネスは以下の行動項目をとります。 1. 条件付き ACS URL の検証を復元するために Okta と連携することで、追加の ACS URL が設定されていないインスタンスは、以前と同じように正確に動作し、顧客のアクションが不要になります。 2. Harness 文書の Harness OIN アプリケーション専用の構成ガイドを、応答 \(ACS\) URL 要件を含む公開します。 3. 公開された Okta アプリケーションへの将来の更新のための既存の顧客の構成に対して独立した事前リリースの検証ステップを、Okta 自身のレビューと共に加えて下さい。 4. ユーザ認証をハーネス ID に移行し、この検証動作の依存性を完全に削除します.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
当社は、公開されたハーネスオクタアプリケーションを通じてSP-initiatedログインにのみ適用される問題を特定しました。 最近の更新後、設定された SSO URL が追加の ACS URL から欠落したときに、それらのログインは HTTP 400 エラーを返します。 Okta の一般的な SAML 2.0 構成は影響しません。 即時ソリューション: IDP-initiated ログインを使用します。 オクタのハーネスアプリケーションタイルからログインを開始します。 または Harness SSO URL を、公開された Harness Okta アプリケーションで追加の ACS URL に追加します.
この事件は解決しました.
# 1. まとめ 2026年9月29日から、オクタインテグレーションネットワーク\(OIN\)で公開されたハーネスアプリケーションを通じてハーネスにサインインしたお客様は、SP-initiated SSOログインを完了できませんでした。 感染したユーザーは、署名された代わりに Okta から HTTP 400 エラーを受信しました。 この問題は、Oktaが公開されたハーネスアプリケーションの既存のインストールに対して、要求された応答\(ACS\) URLを検証する方法の変化によって導入されました。 第1回報告書の1時間以内にワークアラウンドが公開され、影響を受けたお客様はブロック解除されました。 # 2. インパクト ※SP-initiated login \( Harness\ からサインインする) の Okta インテグレーション・ネットワークから公開されたハーネス・アプリケーションを使用して、お客様は影響が限られました。 これらの試みは、 Okta から HTTP 400 エラーを返します。 ※オクタのハーネスタイルからスタートしたIdP-initiatedログインは、引き続き作業を続けました。 ※Oktaで独自の汎用SAML 2.0アプリケーション設定を使用しているお客様は影響を受けません。 ※お客様のデータが紛失、または公開されなかった場合 # 3. 根本原因 2026年9月29日、オクタ・インテグレーション・ネットワークに、ハーネス・アプリケーションのアップデート版が公開されました。 更新は、複数の応答\(ACS\) URLを登録するためのサポートを追加しました。これにより、複数の地域や環境でハーネスを実行している顧客は複数のコールバックURLを設定できます。 ハーネスには、Oktaに送信するSAML認証リクエストでAssertionConsumerServiceURL値が含まれています。 この更新の前に、Okta は、追加の ACS URL が設定されていないアプリケーションインスタンスの値を検証し、SAML のアサーションをアプリケーションのデフォルト ACS URL に単に返しました。 更新後、この検証は、アプリケーションのすべての既存のインスタンスで有効になりました。これには、顧客が追加のACS URLを設定しませんでした。 リクエストされた値が登録されたリストに表示されていないため、認証リクエストをHTTP 400エラーで拒否しました。 更新されたアプリケーションは、公開された統合の既存のインストールに対する後方互換性検証を含むOINの標準的な公開レビューを通過しました。 この変更は、追加のACS URLが設定されていないインスタンスの検証動作が、そのレビュー中には表面化されていないため、リリース時に顧客に到達しました。 # 4. 修正 **即時対応** ステータスページで2つの回避策が公開されました。Okta\(IdP-initiated login\)のハーネスタイルからサインインするか、Harness Oktaアプリケーションの追加のACS URLフィールドにアプリケーションのOkta SSO URLを登録します。 影響を受けた各顧客を直接サポートし、それらを検証しました。 **決断** 以前のバージョンに戻ってアプリケーションをロールバックすることは、次のリリースに同じ中断を延ばすため、意図的に回避されました。 影響を受けたお客様は、ACS URL の登録を解除する代わりに、ACS URL の検証条件を再度作成するために Okta と連携して、ACS URL が設定されていないインスタンスは、顧客アクションが要求される前に行われたとまったく動作しません。 # 5. アクションアイテム このような問題が起きるのを防ぐため、 |**行動項目** | お問い合わせ | 条件付き ACS URL の検証を復元するために Okta と連携することで、追加の ACS URL が設定されていないインスタンスは、前後に正確に動作し、顧客のアクションが不要になります。 お問い合わせ | ハーネス文書のハーネスOINアプリケーション専用の設定ガイドを、返信\(ACS\)のURL要件を含む公開します。 | | 既存の顧客構成に対して独立したプレリリース検証手順を追加し、Oktaの独自のレビューと共に、公開されたOktaアプリケーションへの将来のアップデートを行います。 | | ユーザ認証をハーネス ID に移行し、この検証動作の依存性を完全に削除します。 お問い合わせ
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
修正を実装し、結果を監視しています.
この事件は解決しました.
#### 概要 2026年9月29日(水)午前11時37分～午後3時01分 PDT(18:37～22時01分 UTC\)の間、Harness CIセルフホストLinuxクラウドランナー(**prod1/prod2\(us-west1\)**)を使用して、パイプラインの実行時に、Git/networkのタイムアウトをメインに使用しています。 **ルート原因** 主に、仮のクラウドプロバイダーの計算能力によって分解されたNATの飽和により、新しいVMのプロビジョニングを防ぎました。 ##インパクト * セルフホスト型Linux CI を稼働させるお客様は、フルな停電ではなく、** 断続的なビルド/パイプラインの失敗を見ました。 * 顧客向きのエラーは、Git のフェッチのタイムアウトを含み、例えば github.com ポート 443 に接続できません: 接続はタイムアウトしました。 **是正** ***Immediate:** 飽和した us-west1 パスからの ARM ビルド VM の負荷を中央 1 の \(部分的に 1 の容量によって制限される) に再バランスをとった ARM のビルド VM の負荷。これにより、パイプラインのネットワークを安定化しました。 **アクション項目** 1。 追加のNATゲートウェイ/IP容量を確保する\(進行中\) 2. NATの飽和の検出を改良し、顧客の影響の先に警告します。 3。 単一の領域の計算の不足分が不正な緩和をブロックしないため、交差規制能力のコンテンシーを評価します.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
修正を実装し、結果を監視しています.
今後の問題がないか引き続き監視しています。
この事件は解決しました.
**概要** Prod-2 の顧客は連続的な検証パイプラインの失敗率を高めました。 検証ジョブは、CVデータ収集ワーカーが作業を調整するプラットフォームサービスと通信できないため、エラーの完了や報告に失敗しました。 これは、私たちのバックエンドシステムに予期しないトラフィックのスパイクによって引き起こされました。 影響を受けたプラットフォームコンポーネントをスケーリングすることでサービスが復元されました。 データの損失や破損が発生しません。 **顧客の影響** Prod-2 で連続検証を使用しているお客様は、インシデントウィンドウで検証パイプラインジョブが失敗したり、タイムアウトしたりします。 この期間中に実行される検証ジョブインスタンスの有意な割合は、運用上の失敗で終了しました。 CVを使用していないパイプラインは正常に動作し続けます。 **ルート原因** 大規模な自動プロビジョニング実行により、共有プラットフォームのコンポーネントを圧倒した短いウィンドウで一貫性のあるCV監視作業員が数多く作成されました。 同時アウトバウンドコールの急増は、各サービスインスタンスの利用可能なネットワーク接続を排出しました。 **住宅** CVサービスの最大スケーリング限界が上がり、要求を満たす能力を拡張できます。 スケールアウト完了後すぐに故障が止まりました。 **次のステップ** 再発を防ぐため、ハーネスは次のようになります。 ***容量のヘッドルームを増加させ、ガードレールのプロビジョニングを追加します。** 破裂負荷下にあるヘッドルームを維持するためのCVサービスのスケーリング限界を上げ、監視されたサービスのバルクプロビジョニングのためのレート制限を導入します。 *** 改善の責任:** ワーカーのレトリーに指数関数的なバックオフとジッタを追加し、再使用可能な接続プールを使用して、オーバーヘッドを削減し、高通貨の下で化合物からの過渡障害を防ぐことができます。 ***監視とアラートの改善:** 異常な1アカウントのワーカー成長率の警戒を強化するので、同様の条件が検出され、以前に行動します.
公式のインシデント更新を自動翻訳しています。
2026年9月28日には、ファイルがnull/emptyファイルとしてコピーされた状態で、エクスポートステップでハーネスファイルストアからファイルをコピーするという問題が起きました。 その結果、Filestore API を使用したすべてのパイプラインは、インシデントウィンドウの間にブロックされていました。 問題は、問題が発見されたときに再変換された機能フラグのロールアウトが原因で引き起こされました。 すべての操作は正常に戻ります.
#### 概要 2026年9月28日、Prod-2 では、パイプライン式 \(例、 `\) を使用して、ファイルストアのコンテンツを読み込み、CD パイプラインの手順で、一部の顧客は失敗を経験しました。 影響を受けた式は、期待するファイルコンテンツの代わりに null を返すため、依存したステップが失敗したり、誤って動作したりします。 問題は、ファイルストアAPIで認可チェックを固めるプラットフォーム更新に追跡されました。 アップデートはロールバックされ、File Storeの式はそのままで動作します。 ### 顧客の影響 * 式を介したファイルストアコンテンツを読み込み、Prod-2 のパイプライン手順のみが影響されました。 ファイルストアの式を使用しないパイプラインは影響しません。 * 影響を受けた式は null に解決し、設定や設定ファイルに依存して誤った出力を失敗または生成する手順を引き起こします。 ※ファイルストアのコンテンツは変更できません。 ファイル、秘密、資格情報、またはアーティファクトが露出されず、データが失われませんでした。 ## 根本原因 継続的なセキュリティイニシアチブの一環として、Harness は、File Store コンテンツを提供する API を含む、複数のプラットフォーム API 間で厳格な認可チェックを展開しました。 パイプラインがファイルストアの式を評価する場合、内部ハーネスサービスは別の呼び出しでファイルを検索します。 新規の承認は失敗し、リクエストが拒否され、nullを返す式になります。 ##マイティグレーション プラットフォームの更新が原因として識別されたら、生産環境を横断してロールバックしました。 ファイルストアの式はロールバックから正しく解決しました。 顧客行動は必要ありません。 ##予防措置と次のステップ ***Audit の影響を受ける API:** 厳格な認可チェックが適用されたすべての API を見直し、内部サービス・ツー・サービス・コールが適切に管理されます。 * **テストカバレッジの改善:** パイプライン実行パス全体でファイルストア式評価を含む自動テストスイートを強化
公式のインシデント更新を自動翻訳しています。
現在、Palo Alto Networksのファイアウォールによって環境が保護されている顧客に影響を与える接続の問題を検討しています。 これらのファイアウォールは、ハーネス API への接続をブロックしています。これにより、次のようになります。 - 失敗したパイプラインの実行 - アプリケーションをデプロイすることができない -ハーネスプラットフォームの機能にアクセスする際に断続的なタイムアウト - サードパーティのツールによる統合障害 -ハーネスプラットフォームとの接続を解除 この問題は、ハーネスサービスの停電ではなく、ネットワーク側のファイアウォールルールによって引き起こされます。 お客様がDNSエンドポイントの例外を行なうようお勧めしています.
利用可能な緩和:ネットワークセキュリティポリシーによってブロックされたハーネストラフィック Palo Altoネットワークのセキュリティ制御によるハーネストラフィックが「AI-Platform」として分類され、顧客のファイアウォール/INETポリシーによってブロックされているため、一部の顧客はハーネスにアクセスできない問題を特定しました。 この問題が発生した場合: 組織のNetwork/Firewall/CyberSecurityチームに連絡し、Palo Altoファイアウォールポリシーで必要なハーネストラフィックが許可されるようにリクエストしてください。 緩和として、お客様は、必要なハーネスエンドポイントの「AI-Platform」URLカテゴリを許可するか、または、その組織の承認/許可リストに影響を受けるハーネスドメイン/FQDNsを追加することができます。 ファイアウォールポリシーの更新後、ハーネスへのアクセスを復元する必要があります。 重要: ファイアウォールポリシーは、お客様のネットワーク/セキュリティチームによって管理されます。 Palo AltoのHarnessエンドポイントが正しく分類されていない場合は、Palo Alto NetworksのURLカテゴリレビューをリクエストすることもできます.
パロ・アルト・ネットワークスと協議後、2026年9月23日(水)より、アプリ・ハーネスの確認ができます。 io は Palo Alto Networks チームによる AI プラットフォームサービスとして分類されました。 Palo Alto Networksは、再分類について8月にお客様に通知を送信します。 この変更は、アプリ.harness よりも異なるポリシーで AI プラットフォーム サービスを置くことができます。 ioの以前の規則セット分類、コンピュータとインターネット情報。 適用されるポリシーは、顧客設定に依存します。 ハーネス顧客は、この分類と内部ネットワークチームとPalo Alto Networksのアラートについて議論する必要があります.
お問い合わせ.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
# まとめ 2026年9月22日には、地域内のネットワークゲートウェイの3つが不健全になり、新たなアウトバウンド接続の試みの少額の割合が排除されました。 問題は、さらなる再発またはフォローオンの影響なしで完全に同じ日の問題を解決しました。 根本的な原因は、それらのゲートウェイの飽和内部のトラフィック監視バッファでした。これにより、健康チェックが遅くなり、不健康なマークが付けられます。 # インパクト ※1つの地域では3つのゲートウェイインスタンスのみの影響を受け、同じ地域の他の地域や他のゲートウェイは影響を受けていません。 ※ 万が一のゲートウェイの再起動で問題が完全に解決され、その後のフォローオンの問題が発生しませんでした。 # 根本原因 アウトバウンドネットワークゲートウェイは、ネットワークトラフィックを監視し、運用可視性を監視する内部コンポーネントを実行します。 持続的な高トラフィックの下で、このコンポーネントの内部バッファは飽和しました。これにより、ゲートウェイの負荷バランサーが許すタイムアウトを超えた独自の健康チェック応答を遅くするのに十分な背圧を重ねました。 タイムアウトが終了したら、ロードバランサーは、影響を受けたゲートウェイを不健康なものにマークし、新しい接続の一部を拒否しました。 実際のパケット転送は、インシデント全体で正常に動作し続けています。 これは、ゲートウェイのコア転送機能の失敗ではなく、特に健康チェックと監視バッファの問題でした。 # 決断 3つの影響を受けたゲートウェイインスタンスは手動で再起動し、飽和監視バッファをクリアし、すぐに正常な健康チェックの動作を復元しました。 接続拒否は、再起動が完了するとすぐに停止し、さらに介入は必要ありません。 # 予防行動 |**アクション** | お問い合わせ | ゲートウェイの全てのゲートウェイに、この方法で飽和させない、より効率的で低いオーバーヘッドの実装で現在のトラフィック Monitoring アプローチを交換し、お客様の目に見えない影響の前に警告します。 | | 固定スケジュールで長時間走るゲートウェイインスタンスの自動定期的な交換を実施するので、この事件で見られる年齢関連の劣化を蓄積することはできません。 お問い合わせ | ゲートウェイインスタンスをネットワークに最適化されたインフラに移行し、ネットワーク容量が大幅に向上し、持続的な高スループットトラフィックに適しています。 | | 長期間の交換が転がっている間、既存の監視バッファの活用を高めて下さい。 | | ゲートウェイヘルスチェック対応レイテンシを中心にアラートを強化し、お客様を目にする前に劣化の早期兆候をキャッチします。 お問い合わせ
公式のインシデント更新を自動翻訳しています。
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
前の根本原因と同じです.
公式のインシデント更新を自動翻訳しています。
現在、この問題を調査中です.
問題が特定され、修正が実装されています.
修正を実装し、結果を監視しています.
この事件は解決しました.
## 概要 2026年9月21日、Prod 2の顧客は分解され、それから約3時間のためのほとんど利用できなくなった配置のダッシュボードを経験しました。 問題は、必要なよりもはるかに多くのデータを読むそれらのダッシュボードの背後にある分析クエリのセットによって引き起こされました。これにより、データベースの容量を削減しました。 影響を受けたサービスの復元されたダッシュボードを完全にロールリスタートし、プラットフォームは以来安定しています。 ## 顧客の影響 ダッシュボードページは14:48と18:11 UTCの間でゆっくりと読み込みました。 パイプラインの実行と展開の記録は、別々のインフラ上で実行し、正常に動作し続けます。 データの損失や破損が発生しません。 ## 根本原因 ダッシュボードのクエリは、最大のテーブルを週単位のセグメントに分割するために使用される列のタイムレンジフィルタが不足していたため、各クエリはリクエストされた期間の代わりに、すべての履歴データを読み込みます。 修正は影響を受けませんでした。ダッシュボードは正しい結果を返します。データが読み込まれた量のみが過剰でした。 データのボリュームが増加すると、データベースが役立つものよりも読み込まれるコストが増加し、失敗したクエリのレトリーはさらなる負荷を加えたため、サービスが再起動するまで条件がクリアされませんでした。 ## 移行 * 影響を受けるサービスのロール再起動を実行し、再試行サイクルを中止し、データベースが卓越した作業を完了できるようにしました * 確認されたダッシュボードのレイテンシーおよびデータベース接続の使用は正常なレベルに戻りました ## 次のステップ 再発を防ぐため、ハーネスは次のようになります。 * 不足しているタイム レンジ フィルターを影響を受けたダッシュボード クエリに追加して、それぞれが要求された期間のみ読み取ります。 * バウンディング、バッキングオフのレトリーで即時のレトリーを取り替えて下さい *データベース接続の使用法およびper-query実行費用の警告を加えることによって検出を改善して下さい
公式のインシデント更新を自動翻訳しています。
