概況

  • Atlassian の2022年4月のクラウド障害は一部の顧客に影響を与えたが、この出来事は大きな説明責任の教訓を残した。影響を受けたのは共有サービスコンポーネントではなく、顧客サイトそのものだったからである。
  • メンテナンスツール、テナント削除の安全策、バックアップリストアの順序、顧客固有の復旧見積もり、ステータスページの表現、そして SaaS の復旧が単なるサービス可用性ではなくビジネスの文脈を回復したことの証明について、誰が実質的な管理権を持っていたのか？
  • 説明責任の課題は、コラボレーションとワークフローの SaaS プラットフォームが業務記憶を保持しているため、一般的な「サービス復旧」の声明よりも、顧客固有の復旧証拠が重要になる点にある。
  • ソフトウェアチーム、IT 部門、プロジェクトマネージャー、中小企業、エンタープライズ顧客、監査人、SaaS 購入者は、テナントの復旧、顧客通知、バックアップ設計が継続性の義務として管理されていた証拠を必要としていた。
  • 本記事では、Atlassian の声明は同社が公に報告した内容の証拠として、ステータスページとトラストページは運用上のコミットメントと用語として、契約書類は顧客向けの責任分担として、標準規格は事後的な調査結果ではなく管理基準として扱う。

このケースがリスクと説明責任のファイルに含まれる理由

Atlassian はクラウドサイトの復旧をテナント継続性の説明責任テストにした。なぜなら、この公的なトリガーが、クラウド購入者がしばしば曖昧にする違いを明らかにしたからだ。SaaS プラットフォームは、全般的には利用可能であっても、特定のテナントが存在しない、不完全である、または検証済みの復旧を待っている状態であり得る。この違いは、Jira Software のボード、Jira Service Management のキュー、Confluence のスペース、インシデント記録、リリース履歴、承認証跡、調達メモ、顧客リクエスト、内部エンジニアリングの記憶において重要である。そうした環境では、顧客サイトは単なるコンテナではない。それは、作業が記述され、優先順位付けされ、承認され、監査され、エスカレーションされ、記憶される場なのだ。

https://www.atlassian.com/blog/atlassian-engineering/april-2022-outage-updateでの Atlassian の公開されたエンジニアリングアップデートは、SaaS の説明責任について極めて示唆に富む障害パターンを説明している。Atlassian によれば、このインシデントは約400の顧客に影響を与え、メンテナンススクリプトが誤った実行モードと誤った顧客サイト ID のリストで実行され、復旧には単にサービスを再びオンにするのではなく、バックアップからの再構築が必要だったという。これらの公開事実は内部管理の詳細をすべて証明するものではなく、本記事はそれらを私的なフォレンジックファイルとして扱わない。しかし、これらは、実質的な管理対象にメンテナンスツール、削除の安全策、バックアップ設計、リストアの順序決定、顧客固有のコミュニケーションが含まれる理由を示している。

この管理対象は説明責任の枠組みを変える。従来の障害レビューは、サービスが稼働しているか、インシデントコミュニケーションがタイムリーだったか、プロバイダーが根本原因を特定したかどうかを問う。これらの問いは依然として必要だが、影響を受けた単位が業務履歴を含むテナントである場合には十分ではない。顧客は、特定のサイトが復旧したか、添付ファイルやリレーションシップが無傷か、インテグレーションが安全に再開できるか、自動化ルールを再実行すべきか、サービスチケットが失われたり遅延したりしなかったか、監査証拠が障害前の意思決定を依然として裏付けているかどうかを知る必要がある。コンポーネントのステータスが「グリーン」であることは、テナントレベルのこれらの問いにそれだけでは答えられない。

したがって、中心的な問いは修辞的なものではない。メンテナンスツール、テナント削除の安全策、バックアップリストアの順序、顧客固有の復旧見積もり、ステータスページの表現、そして SaaS の復旧が単なるサービス可用性ではなくビジネスの文脈を回復したことの証明について、誰が実質的な管理権を持っていたのか？その答えは、プロバイダー側の管理と顧客側の継続性義務を区別すべきである。Atlassian は内部メンテナンスツール、ターゲットリスト、削除パス、バックアップリストアの仕組み、復旧を説明する表現を管理していた。顧客は一部のエクスポート、ローカルプロセスの回避策、ベンダーリスクのエスカレーション、下流の調整を管理していた。しかし、顧客は Atlassian の内部バックアップシステムから Atlassian のクラウドテナントを復旧することはできなかった。この非対称性こそが説明責任の課題である。

テナントは単なるサービスコンポーネントではなく、運用記録である

「サイト」という言葉は管理的に聞こえるかもしれない。SaaS の継続性において、それははるかに重要である。クラウドサイトには、製品リリースを定義する課題グラフ、顧客との約束を定義するサービスデスクキュー、プロセス記憶を定義する Confluence スペース、監査を支える承認チェーン、そして他のツールに何が起こったかを伝えるインテグレーション状態が含まれうる。そのサイトへの通常のアクセスを失うことは、作業そのものを混乱させ、同時に作業が調整される証拠も混乱させる。したがって、復旧は可用性以上のものを回復しなければならない。文脈を回復しなければならないのだ。

説明責任の問題は、プラットフォームの健全性とテナントの健全性の区別に見られる。公開ステータスページhttps://status.atlassian.com/は、Atlassian がアクティブなインシデントやコンポーネントの問題を報告しているかどうかを顧客に伝えることができる。これは不可欠な共通証拠である。しかし、ステータスページは多くの読者に共有される。設計上、特定の顧客の Jira 課題リンク、Confluence ページ、添付ファイル、権限、自動化ルール、マーケットプレイスアプリの状態、インテグレーション履歴が信頼できる状態に戻ったことを証明することはできない。テナントの復旧には、より低レベルの証明ファイルが必要である。

また、顧客はテナント障害をその役割に応じて異なる形で経験する。小規模なソフトウェアチームはスプリントボードとリリースノートを失うかもしれない。サポートチームはオープンな顧客チケットの可視性を失うかもしれない。規制対象のエンタープライズは、変更承認やインシデント管理履歴を示す能力を失うかもしれない。調達チームは、選択した SaaS プロバイダーがサイト固有の復旧見積もりを迅速に提供できなかった理由について、内部からの問いに直面するかもしれない。したがって、同じプロバイダーインシデントが、エンジニアリング、法務、コンプライアンス、カスタマーサポート、経営幹部に対して異なる説明責任義務を生み出す。

これが、「サービス復旧」という一般的な文言が正確ではあっても不十分であり得る理由である。サイトにビジネス記憶が含まれている場合、復旧には調整レイヤーが含まれなければならない。顧客は、影響を受けた時間枠、回復不能なデータがあったかどうか、回避策期間中に実行された操作を再入力する必要があるかどうか、接続されたツールを再同期すべきかどうか、監査の説明にプロバイダー障害を開示すべきかどうかを知る必要がある。プロバイダーは顧客固有のビジネス上の問いすべてに答えられるとは限らないが、それらの問いに答えられるようにするための証拠を管理している。

インテグレーションがサイト復旧をクロスシステムイベントにする

テナントの境界は製品 UI よりも広い。Jira や Confluence のサイトは、しばしば ID プロバイダー、マーケットプレイスアプリ、チャットツール、インシデント管理ツール、ソースコードプラットフォーム、カスタマーサポートシステム、ビジネスインテリジェンスのエクスポート、自動化ルールと接続されている。そのため、復旧されたテナントは技術的には利用可能であっても、接続された運用環境は依然として不確実な状態にある可能性がある。不足している証拠は、単にデータを復旧したかどうかだけではない。顧客が、障害時間枠中にどの外部システムが古い、欠落した、重複した、または遅延した状態を消費したかを判断できるかどうかである。

このインテグレーションレイヤーは復旧順序の意味を変える。課題トラッカーがデプロイメントワークフローにフィードする場合、チケットの欠落はリリースを遅延させたり、承認ギャップを隠したりする。サービスデスクキューが顧客コミュニケーションワークフローにフィードする場合、復旧の遅延は顧客に伝えられる内容とタイミングを変えうる。Confluence ページが運用手順のソースである場合、チームはキャッシュコピーやローカルエクスポート、記憶を頼りに作業し、権威ある記録が利用できない。サイトが戻った後、組織はどの一時的記録が正統であるか、障害中に実行された作業をプラットフォームに書き戻す必要があるかどうかを決定しなければならない。

ここで、プロバイダーと顧客の分担が特に明確になる。Atlassian はテナントを復旧し、製品レベルの検証証拠を提供できる。しかし、顧客が接続したすべての下流システム、失敗したすべての自動化、サイトの代わりに使われたすべての手動回避策を知ることはできない。顧客は自身の依存関係マップを必要とする。しかし、顧客の依存関係マップは、影響を受けた時間枠、復旧段階、既知の例外、関係する製品領域に関するプロバイダーの証拠に依存する。その証拠がなければ、顧客はローカルなインテグレーション問題とプロバイダーの復旧による結果を区別できない。

マーケットプレイスアプリは別の説明責任レイヤーを追加する。顧客は、コア製品データとともに存在するアプリ固有のフィールド、自動化、権限、レポート、インテグレーション状態に依存する可能性がある。コア製品テーブルについては完全なテナント復旧であっても、ビジネスプロセスが完全に信頼できる状態になる前に、顧客またはアプリベンダーによる検証が必要になる場合がある。これは、Atlassian がすべてのサードパーティアプリの動作に責任を負うことを意味しない。むしろ、公開される復旧に関する表現は、サイトへのアクセスだけがコラボレーション環境全体がインシデント前の状態に戻ったことを証明するわけではない、ということを含意すべきであることを意味する。

監査人や取締役会にとって重要な問いは、インテグレーションの調整が障害前に計画されていたかどうかである。成熟した SaaS の継続性ファイルには、重要インテグレーションの登録簿、各インテグレーションがサポートするビジネスプロセス、それを検証できる責任者、プロバイダー復旧後に完了するために必要な証拠が含まれる。この登録簿は手の込んだものである必要はない。ただし、人々が数日分の作業をチャットメッセージ、ローカルノート、スクリーンショットから再構成する前に存在しなければならない。

スクリプト障害が、削除管理により高い基準が必要な理由を示す

Atlassian の公開説明は、メンテナンススクリプトの問題をインシデントの中心に据えた。簡単に言えば、レガシーアプリデータを削除するためのツールが、限られた顧客セットに対して、本来よりも広範なサイト削除を引き起こすモードと ID リストで実行された。重要な説明責任のポイントは、スクリプトが失敗したことではない。あらゆる複雑なプロバイダーは管理ツールを使用する。ポイントは、SaaS プロバイダー内部の破壊的ツールは、単なるエンジニアリング上の便宜ではなく、継続性リスクとして扱われなければならないということである。

破壊的ツールに関しては、通常のアクセス制御は最初のレイヤーに過ぎない。より強力な管理ファイルは、そのツールにドライランの動作、影響範囲の制限、デュアル承認、顧客サイト許可リスト、予期されるオブジェクトタイプに対する検証、停止条件、不可逆操作の警告、レート制限、独立した監視があったかどうかを問う。意図されたターゲットがアプリデータオブジェクトであったときに、ツールがテナント全体を削除できたかどうかを問う。オペレーターが、実行前に期待されるオブジェクトの母集団と実際に選択された母集団の違いを確認できたかどうかを問う。これらはエンジニアリングコントロールとして表現されたガバナンスの問いである。

2022年4月の出来事は、「稀」が「低影響」と同じでない理由も示している。一部の顧客であっても、影響を受けた各組織にとっては深刻な事業中断を表しうる。SaaS の説明責任は、プロバイダー全体に対する影響の割合だけに依存すべきではない。影響を受けた顧客テナントでの重大性も評価すべきである。プロバイダーが数十万のテナントにサービスを提供し、そのうち数百だけが影響を受けた場合、集計された可用性のパーセンテージは許容範囲に見えても、影響を受けた顧客は数日間の業務障害に直面する。継続性ガバナンスはその両方を測定しなければならない。

同じポイントは運用の承認にも当てはまる。削除スクリプトは過去の実行のほとんどで正しくても、将来の誤ったターゲットセット、誤ったフラグ、誤った環境、誤ったオペレーターの仮定を前提とした保護モデルが必要である。正しい問いは、メンテナンスタスクが正当だったかどうかではない。正当なタスクが、本番テナントの状態に触れる前に十分に多数の独立したチェックを通過できたかどうかである。SaaS プラットフォームにおいて、内部メンテナンスの利便性がテナントの回復可能性よりも優先されてはならない。

顧客固有の見積りは管理記録の一部である

コミュニケーションはしばしば広報機能としてレビューされる。テナントレベルの障害では、それは運用管理記録の一部である。サポートチームを手動の回避策に留めるか、リリースを一時停止するか、自身のユーザーに通知するか、代替のノートを保存するか、規制当局にエスカレーションするかを決定する顧客は、行動を導くのに十分に具体的な時間見積りを必要とする。「作業は継続中」という全体的なアップデートは真実でありながら、顧客の次の意思決定を支援できない。

https://www.atlassian.com/blog/atlassian-engineering/post-incident-review-april-2022-outageでの Atlassian のインシデント後レビューは、短いステータスノートを超えて改善テーマを記述している点で重要である。説明責任の目的では、インシデント後レビューの価値は、それが反省的に聞こえることではない。不確実性を狭めるべきだということである。トリガー、影響を受けたオブジェクト、顧客への影響、復旧方法、予防コントロール、フォローアップオーナーを結びつけるべきである。レビューがこれらのリンクを作っていない場合、顧客はプロバイダーが実際の故障モードを修復したのか、それともその周りのメッセージングを改善しただけなのかを推測するしかなくなる。

顧客固有の見積りは、ストレス下での運用上の真実を必要とするため難しい。復旧キューは、バックアップのサイズ、製品の組み合わせ、データ関係、マーケットプレイスアプリ、検証チェック、手動レビュー、エンジニアリングのボトルネックに依存する可能性がある。あまりに早く正確な見積りを公表することは、前提が変わった場合に顧客をミスリードする恐れがある。広範な表現だけを公表することは、顧客を計画不能にさせる。説明責任のある答えは、見積りの根拠を開示することだ：何が分かっているか、何がまだテスト中か、何が日付を変えうるか、次のアップデートが有意義になるのはいつか。

その開示は復旧段階も区別すべきである。サイトは、影響を受けたと特定され、復旧のキューに入れられ、内部環境に復旧され、プロバイダーチェックで検証され、顧客に公開され、再有効化後に監視され、顧客確認後にクローズされうる。各段階は異なる運用上の意味を持つ。「復旧中」という単一のラベルは、作業を再開するかどうかを決定する必要がある顧客にとって粗すぎる。より良いステータス表現は、段階、証拠、残りの顧客アクションをマッピングするだろう。

復旧順序はガバナンス上の決定である

復旧順序は時にエンジニアリングキューとして説明されるが、それはガバナンス上の決定でもある。影響を受けたすべてのテナントを一度に復旧できない場合、プロバイダーは順序を選択しなければならない。その順序は、バックアップサイズ、製品の複雑さ、技術的依存関係、検証の信頼度、サポートエスカレーション、契約上のコミットメント、規制対象の用途、顧客の重要度に依存しうる。各要素は擁護可能である。説明責任のリスクは、これらの要素が見えず、顧客が技術的必要性、運用トリアージ、サポートエスカレーションのノイズのいずれによって待たされているのか分からない場合に発生する。

説明責任のある復旧順序は、顧客の公開ランキングを公表することを要求しない。後でレビューに耐えうる内部ルールセットを要求する。プロバイダーは、最も単純なテナントを最初に復旧してプロセスを証明したのか、最も複雑なテナントがより大きなリスクを抱えていたために優先したのか、類似の製品構成をバッチ処理したのか、あるいは既知の公共サービスや規制上の継続性義務を持つ顧客をエスカレーションしたのかを説明できるべきである。このルールは重要である。プロバイダーがまだ障害を修復している間に誰が停止時間を負うかを決定するからである。

顧客は、その推論の一部を行動に翻訳したものを必要とする。顧客がそのサイトに通常とは異なる製品の複雑さがあるためにキューで後回しにされている場合、バックアップ検証がまだ完了していないために待っている顧客とは異なる計画を立てることができる。顧客が「復旧は継続中」とだけ知らされている場合、自身のステークホルダーに過剰にコミットするかもしれない。復旧が技術的には完了したが、復旧後検証が保留中であることを顧客が知っていれば、内部検証チームを準備できる。同じ推定日付は、その背後にある段階と理由によって異なる意味を持ちうる。

復旧順序は証拠の保存にも影響する。数日間待つチームは、早期に復旧されたチームよりも多くの手動記録、より多くの重複作業、より多くの顧客とのコミュニケーション、より多くのインテグレーションのずれを蓄積する可能性がある。後者の顧客はより強固な調整ガイダンスを必要とする。復旧されたすべてのテナントを同等に扱うプロバイダーは、時間の累積的負担を見逃している。したがって、説明責任の記録は、経過した停止時間、復旧段階、既知の例外、顧客の調整負担を区別すべきである。

取締役会にとって、これは SaaS 集約の不快な部分である。多くの組織が1つのプロバイダーの内部復旧キューに依存する場合、そのプロバイダーは事業継続の一時的な割り当て者となる。その割り当ては必要であり、技術的に合理的かもしれない。しかし、それは不可視であってはならない。インシデント後レビューは、復旧順序がどのようにガバナンスされたか、どのような指標が使用されたか、次の復旧キューがより短く、より良く証拠付けられ、顧客が解釈しやすくなるために何が変わったかを述べるべきである。

バックアップ証拠は、それが障害から分離可能である場合にのみ意味を持つ

バックアップはしばしばレジリエンスとして宣伝されるが、2022年4月の出来事は、説明責任の問いは単にバックアップが存在するかどうかではないことを示している。それは、プロバイダー側のコントロールプレーンが障害の原因である場合に、テナントを復旧するために、バックアップが十分に独立し、完全であり、テスト可能であるかどうかである。本番テナントと同じ欠陥のあるパスで保存、承認、削除、復旧されるバックアップは、真の分離を生み出さないかもしれない。存在するが、ビジネスクリティカルなテナントのために十分迅速に復旧できないバックアップは、顧客が購入したと思っていた継続性の期待を依然として満たさないかもしれない。

https://www.atlassian.com/trust/resilienceにある Atlassian の信頼性とレジリエンスに関する資料は、同社が信頼性、回復力、運用慣行をどのように提示しているかについて有用な用語を提供する。本記事はその資料を現在の管理コンテキストとして使用しており、2022年4月にすべての管理が特定の方法で動作したことの証明としては使用していない。同じ境界がhttps://www.atlassian.com/trust/security/data-managementにも適用され、これは読者が Atlassian がデータ管理と保護責任をどのように説明しているかを理解するのに役立つ。公開トラストページは、プロバイダーがその保証モデルの一部と見なしているものを顧客に伝えるため価値がある。それらはインシデント固有の証拠を置き換えるものではない。

この種のイベントに対する説明責任のあるバックアップ記録は、少なくとも6つの問いに答える。影響を受けた各テナントにどのバックアップセットが使用されたか？それはどの回復時点を表していたか？どのような復旧順序が適用されたか？製品データ、権限、添付ファイル、リレーションシップが無傷であることをどのような検証が示したか？回復できなかったデータがあったとすれば、それは何か？復旧後にどのような顧客アクションが必要だったか？これらの問いは学術的ではない。それらは、顧客が復旧されたテナントを権威ある記録として信頼できるかどうかを決定する。

最も強力な証拠は、復旧リハーサルも示すだろう。現実的な規模でテナントレベルの復旧をテストしたプロバイダーは、インシデント中に依存関係を発見するプロバイダーとは異なるコミュニケーションができる。リハーサルは驚きを排除しないが、証明ファイルを変える。リハーサルによって、プロバイダーはプレッシャーの中で考案することなく、予想される段階、一般的な例外、検証ゲート、エスカレーションパスを公開できる。業務記憶を保持する SaaS プラットフォームにとって、復旧リハーサルは、リハーサル自体が内部的なものであっても、顧客向けの継続性義務である。

法的な分担は運用の明確さを代替できない

契約とサービスレベルは重要だが、それらが説明責任の記録のすべてではない。https://www.atlassian.com/legal/atlassian-customer-agreementの Atlassian の顧客契約とhttps://www.atlassian.com/legal/slaのサービスレベル資料は、顧客がクラウド製品を使用する法的および商業的条件を定義するのに役立つ。これらの文書は、調達チームや法務チームが救済措置、コミットメント、除外事項を理解する必要があるため関連する。それらは、復旧されたサイトに完全な添付ファイルがあるかどうか、サポートチケットの履歴が信頼できるかどうかをエンジニアリングチームに単独で伝えるものではない。

この区別は、クラウド購入者が契約上の分担と運用上の準備を混同しうるため重要である。契約はリスクを割り当て、責任を制限し、クレジットを定義することができる。継続性計画は依然としてビジネスを稼働させ続けなければならない。プロバイダーが唯一の実際的な復旧パスを管理している場合、顧客はプロバイダーの復旧設計が運用上信頼できるという証拠を必要とする。顧客がデータをエクスポートしたりローカルの緊急時記録を維持する義務を負っている場合でも、プロバイダーはテナント自体が利用不能になったときにエクスポートで何ができて何ができないかを説明する必要がある。

https://support.atlassian.com/security-and-access-policies/docs/understand-data-residency/の公開情報は、別の理由で有用である。これは、クラウド顧客がデータがホストされている場所の観点で考えることが多く、コンプライアンスやガバナンスにとって重要でありうることを示している。しかし、所在地は回復可能性と同じではない。テナントは期待されるリージョンに位置していても利用不能になりうる。バックアップはレジデンシーの約束を尊重しつつ、独立した復旧管理が必要である。したがって、SaaS リスクガバナンスは、データレジデンシー、契約 SLA、テナント継続性を交換可能な概念として扱うことを避けるべきである。

同じ区別はクラウド移行とエンタープライズ採用にも当てはまる。https://www.atlassian.com/enterprise/cloudの Atlassian のクラウドエンタープライズ資料は、組織の作業をクラウド製品に移行するためのプロバイダーのより広範なケースを反映している。そのケースが強力になればなるほど、継続性の負担も強力になる。プラットフォームが日常業務の場になったとき、プロバイダーの復旧証拠は顧客自身のリスクファイルの一部となる。調達部門は、顧客サイトが通常のアクセスから消える前に、次のインシデントの前にその証拠を求めるべきである。

顧客側にも継続性の義務がある

プロバイダーの説明責任は顧客の責任を消し去らない。ビジネスクリティカルな作業を SaaS プラットフォームに依存する顧客は、どのチームがそれに依存しているか、それが利用不能になったときにどのプロセスが停止するか、どのエクスポートやローカルレポートが必要か、どのワークフローに手動のフォールバックがあるか、どの顧客や従業員に通知しなければならないか、どの内部責任者が低下した運用を受け入れられるかを知っておくべきである。Atlassian が失敗したメンテナンスパスを管理していたという事実は、すべての下流の継続性の選択が Atlassian に属していたことを意味しない。

顧客側の問題は、多くの SaaS プラットフォームが徐々にクリティカルになることだ。小規模なチームが課題追跡から始める。別のチームがサービス管理を追加する。第3のチームがポリシーのために Confluence を使う。インテグレーションがクロスツールの依存関係を作り始める。自動化ルールがワークをルーティングする。監査証拠が蓄積される。サイト障害が発生する頃には、そのプラットフォームはもはや誰かが一日無視できるツールではない。それは調整システムである。顧客は、プロバイダーインシデントがストレス下でそれを発見させる前に、その依存関係を棚卸しする必要がある。

中小企業にとって、これは特に難しい。小規模な組織は、ベンダーリスクオフィス、正式な事業継続チーム、エクスポートやインシデントプレイブックを維持する時間を持つ内部 Atlassian 管理者を欠くかもしれない。しかし、クラウド SaaS が小規模チームが自身のインフラを運用することを回避する方法であるため、彼らは Jira や Confluence に大きく依存するかもしれない。その経済的論理は合理的である。それはまた、プロバイダーのコミュニケーションと復旧証拠が、専任のレジリエンススタッフを持たない組織にも理解可能でなければならないことを意味する。顧客が小さいからといって、中小企業の継続性がより軽い義務であるわけではない。

エンタープライズにとって、問題は異なる。大規模顧客は継続性プログラムを持っているかもしれないが、彼らはより複雑なテナント、より多くのインテグレーション、より多くの規制対象記録、より多くの内部ステークホルダーを持つ可能性もある。技術的に機能する復旧であっても、ID プロバイダー、サポートポータル、デプロイメントワークフロー、リーガルホールド、監査レポートにわたるエンタープライズ調整が必要になる場合がある。プロバイダーの証明ファイルはその調整をサポートすべきである。顧客は、プロバイダーの復旧段階を自身のビジネスプロセスにマッピングできなければ、自身の内部インシデントを責任を持ってクローズできない。

ステータス証拠は、共通の可視性と私的な証明を分離すべきである

ステータスページはクラウドの説明責任において重要な役割を果たす。それらは、プロバイダーが問題を認識し、コンポーネントの健全性をどのように説明しているかを顧客が確認できる共通の公の場を作る。しかし、ステータスページはすべての私的な復旧の詳細を運ぶことはできない。設計上の課題は、機密性の高い復旧情報のための顧客固有のチャネルを維持しながら、誤った安心感を防ぐのに十分な精度を持たせることである。

テナントレベルの障害に対する有用なステータスアップデートは、影響を受けた製品ファミリー、影響を受けた顧客のクラス、影響を受けたオブジェクトの性質、現在の復旧段階、次の意味のあるマイルストーン、影響を受けた顧客がサイト固有の情報を受け取るチャネルを特定すべきである。問題がテナント固有であるときに全般的なプラットフォーム障害を暗示する表現を避け、最初の内部段階しか完了していないときに完全な復旧を暗示する表現を避けるべきである。正確さは単に文章の好みではない。それはコントロールである。

https://status.atlassian.com/の Atlassian の公開ステータスページは、したがって1つの証拠レーンとして最もよく理解される。それは共有されたインシデント履歴とプロバイダー向けのコンポーネント用語を示すことができる。影響を受けた顧客のサポートケース、直接のメール、管理者コンソール通知、復旧後検証レポートは別の証拠レーンを形成する。イベントをレビューする規制当局、監査人、取締役会は両方を期待すべきである。公開ステータス記録のみが保存される場合、顧客固有の証明が消える可能性がある。私的なサポートスレッドのみが存在する場合、公開説明責任記録はパターンを過小評価するかもしれない。

同じ論理は、復旧後の顧客コミュニケーションにも当てはまる。プロバイダーは、システムが再有効化されたというだけの理由でインシデントをクローズすべきではない。クローズは証拠に結びつくべきである：検証の完了、既知の例外のリスト化、要求された顧客アクション、未解決の質問の割り当て、将来の予防コントロールの説明。これは、プロバイダーが機密性の高いアーキテクチャの詳細を開示することを要求しない。プロバイダーが、ビジネス文脈が戻ったという主張をどのような種類の証拠が裏付けているかを説明することを要求する。

テナントが戻った後にはネガティブプルーフが重要になる

復旧は第二の証明問題を生み出す：顧客は、何が復旧されたかだけでなく、何が起こらなかったかも知る必要がある。プロバイダーは回復不能な記録を見つけたか？添付ファイルが除外されたか？権限状態が製品コンテンツよりも後のソースから再構築されたか？自動化ルールが無効化されたか、再実行されたか、顧客が検査するために残されたか？マーケットプレイスアプリの状態がプロバイダーの検証境界の外にあったか？これらのネガティブな声明は、ポジティブな復旧の主張よりも書くのが難しいことが多いが、顧客のリスク決定にとってより有用である。

理由は単純である。顧客は目に見えるものをテストできる。欠けているかもしれないものをテストするのはより難しい。プロジェクトマネージャーはボードを開いて課題を見ることができる。サービス管理者はキューを見ることができる。監査人はいくつかのページを検査できる。これらのチェックのいずれも、すべてのリレーションシップ、添付ファイル、履歴コメント、ウェブフックの状態、権限エッジがインシデント前と完全に同じであることを証明しない。したがって、プロバイダーの検証レポートは、どの完全性テストが実行されたか、どの領域がプロバイダーの保証の外にあるかを顧客に伝えるべきである。

ネガティブプルーフはプロバイダーを保護もする。明確な境界がなければ、後のあらゆるデータの異常が、顧客のワークフロー、サードパーティのインテグレーションの動作、無関係な設定によって引き起こされた場合であっても、障害のせいにされる可能性がある。何がチェックされ、何がチェックされず、顧客が何を検証すべきかを正確に述べるプロバイダーは、インシデントの残滓と通常の運用上のずれを分離する、よりクリーンな方法を全員に与える。これは、後の論争をより事実に基づいたものにするため、広範な安心感を与えるよりも優れている。

業務記憶を保持する SaaS プラットフォームにとって、最良のクロージング文言は、復旧ステータス、例外ステータス、顧客検証ステップ、サポートエスカレーションパスを組み合わせるだろう。それは実質的に次のように言うだろう：これが我々が復旧したもの、これが我々がそれをチェックした方法、これが我々があなたのために独立して検証できないもの、これがあなたが検査すべきもの、そしてこれが不一致を報告する方法である。これが、サイトが戻ったとアナウンスすることと、顧客が自身の作業記録が完全であると信頼できるように支援することの違いである。

独立した標準は証明の枠組みを提供するが、事実を決定しない

一般的なレジリエンスとリスク管理の標準は、取締役会や顧客に、1つのベンダーのインシデント後言語に限定されない用語を提供するため有用である。AWS Well-Architected Reliability Pillar (https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html) は、障害に備えた設計、監視、復旧、変更管理を強調している。NIST のサイバーセキュリティフレームワーク (https://www.nist.gov/cyberframework) は、特定、保護、検出、対応、復旧のための公開構造を提供する。NIST SP 800-34 (https://csrc.nist.gov/publications/detail/sp/800-34/rev-1/final) はコンティンジェンシー計画の文脈を追加し、NIST SP 800-53 (https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final) は可用性、バックアップ、コンティンジェンシー計画、監査、変更管理コントロールのための管理カタログ用語を提供する。ISO 22301 情報 (https://www.iso.org/standard/75106.html) は事業継続の用語を提供する。Cloud Security Alliance Cloud Controls Matrix (https://cloudsecurityalliance.org/research/cloud-controls-matrix) はクラウド管理カテゴリを提供する。

これらの情報源は、Atlassian に関する調査結果ではない。それらは、クラウドプロバイダーとその顧客が正しい問いをしたかどうかを評価するためのベンチマークである。このインシデントにとって有用な管理ファミリーには、変更管理、特権管理者ツール、データバックアップ、復旧テスト、顧客コミュニケーション、サプライヤーリスク、インシデント対応、事業継続が含まれる。取締役会レビューは、フレームワークがインシデント証拠そのものを含んでいると見せかけることなく、2022年4月の事実をこれらの管理ファミリーにマッピングできるべきである。

この分離は、公開記録を2つのよくある誤りから保護する。第一の誤りは、トラストフレームワークを実際のインシデントが管理されていたことの証明として扱うことである。第二は、インシデントがベンダー固有であるために標準を無視することである。より良いアプローチは、標準を存在すべき証拠のチェックリストとして使用することである。プロバイダーが復旧は完了したと言う場合、フレームワークはその声明を裏付けるどの復旧証拠があるかを問うのに役立つ。顧客がビジネスへの影響は封じ込められたと言う場合、フレームワークはどのフォールバックプロセスがそれを真実にしたかを問うのに役立つ。

情報源の境界は、本記事のトーンにも関係する。これは損害の認定、法的結論、私的なフォレンジック再構築ではない。公開資料に基づく説明責任分析である。Atlassian 自身の声明は、Atlassian が公に報告した内容の主要な証拠である。公開トラストページと法的ページは、プロバイダーの表明したコミットメントと用語を説明する。標準は管理ベンチマークを提供する。ニュースや解説は二次的な文脈であり、顧客固有の損害の証明ではない。これらのレーンを分けておくことは、責任あるリスク記述の一部である。

次回により良い証拠とはどのようなものか

SaaS テナント削除インシデントのための次の説明責任のある証拠ファイルは、インシデント前に始めるべきである。それは破壊的な管理アクションを定義し、テナントレベルの削除を高リスク操作として分類し、ターゲットリストの独立した検証を要求し、厳格な影響範囲の上限を施行し、ロールバックまたは復旧の前提を明示すべきである。それは、プロバイダーのツールが、コマンドが実行される前にアプリデータ、製品データ、サイトメタデータ、テナントコンテナを区別できることを示すべきである。ツールが顧客サイトを消去できる場合、そのツールは継続性リスクの手続き上の重みを負うべきである。

インシデント中、証拠ファイルは、影響を受けたテナントの特定、顧客通知、復旧キューの段階、バックアップセット、回復時点、検証ステータス、既知の例外、顧客向けの次のステップ、コミュニケーション履歴を追跡すべきである。顧客は、広範なステータス用語を解釈することなく、プロセス内のどこにいるのかを確認できるべきである。プロバイダーのリーダーシップは、復旧のボトルネックが技術的か、運用上か、コミュニケーション関連か、顧客の検証に依存しているかを確認できるべきである。監査人は後に、なぜ特定の日に特定の見積りが顧客に提供されたかを再構築できるべきである。

復旧後、証拠ファイルは最終的な謝罪で終わるべきではない。それは管理変更記録を含むべきである。どの破壊的スクリプトが変更または廃止されたか？どの承認ゲートが追加されたか？どの検証チェックが誤ったターゲットリストを防ぐようになったか？どのバックアップ復旧リハーサルが追加されたか？どの顧客コミュニケーションルールが変更されたか？どの指標が時間の経過とともに改善を証明するか？これらの問いに答えられないインシデント後レビューは、過去については正直かもしれないが、予防記録としては依然として弱い。

顧客にとって、より良い証拠とは、SaaS テナント継続性をビジネス影響分析に追加することを意味する。どの Atlassian 製品がクリティカルか？サイトがダウンした場合、どのチームが業務記憶を失うか？どのエクスポートやレポートがプラットフォーム外で保持されなければならないか？24時間、72時間、または1週間、サポート、製品開発、インシデント対応、コンプライアンス作業を動かし続ける手動プロセスはどれか？プロバイダーが唯一の完全な復旧パスを管理している場合、残余リスクをどの幹部が受け入れるか？これらの問いは、プラットフォームが健全な間に答えられるべきである。

読者のための証拠ファイル

本記事は、Atlassian Cloud 2022年障害、顧客サイト削除、復旧順序決定、ステータスコミュニケーション、SaaS テナント継続性の説明責任記録の読書ファイルとして、以下の公開情報源を使用する。各情報源は境界を持って扱われる：企業声明は企業が公に述べたことを証明し、ステータスページとトラストページは運用用語を提供し、契約ページは顧客向けの責任分担文言を提供し、サポートページは現在の製品ガイダンスを提供し、標準文書は事後的な調査結果ではなく管理ベンチマークを提供する。

この証拠ファイルは、SaaS テナント継続性がインシデント時系列以上のものに影響するため、意図的に1つの障害投稿よりも広範囲にしている。同じ顧客がプロバイダーの事実、契約文言、サポートガイダンス、ステータス証拠、独立した管理用語を必要とするかもしれない。本記事は、各情報源がすべての運用事実を証明すると主張しているわけではない。情報源を使用して、公開記録から責任を持って知りうるものと、プロバイダーまたは顧客の証拠ファイル内に残るものを定義している。

取締役会レビューの質問

取締役会レビューは、破壊的なメンテナンスツールが本番リスクシステムとしてガバナンスされていたか、内部の利便性として扱われていたかを問うべきである。その答えは、ツールの所有者、承認モデル、影響範囲の制限、検証チェック、監視、緊急停止パスを特定すべきである。ツールが顧客テナントの状態に影響を与えうる場合、管理基準は通常のスクリプト作成慣行よりも変更管理と継続性ガバナンスに近いものであるべきだ。

レビューはまた、プロバイダーが復旧されたテナントが顧客の信頼に足るほど完全であることをどのように知るかも問うべきである。その答えは、回復時点、バックアップセット、検証テスト、製品固有のチェック、既知の例外、顧客確認ステップ、復旧後監視を挙げるべきである。データが復旧されたという一般的な声明は、業務記憶を含むテナントにとっては十分に具体的ではない。

顧客は、自身の鏡の質問をすべきである：どのビジネスプロセスが Atlassian Cloud に依存しているか、サイトが複数日利用不能になった場合、組織は何をするか？その答えは、サポートキュー、製品ロードマップ、インシデント記録、変更承認、ポリシーページ、インテグレーショントリガー、エクスポート、意思決定の所有権をカバーすべきである。また、内部インシデントをクローズする前に顧客がプロバイダーに期待する証拠が何かを述べるべきである。

最終的な説明責任のテストは、インシデント後の記録が、安心感に頼ることなく新規の購入者がリスクを理解できるようにするかどうかである。記録は、何が失敗したか、なぜテナント復旧がたどった経路をたどったか、どの管理が変更されたか、顧客コミュニケーションがどのように改善されたか、そして現在、同様のメンテナンスエラーが封じ込められることを証明する証拠が何かを示すべきである。それ以下では、次の顧客は、ビジネスのコラボレーション記憶が暗くなって初めて、同じ依存関係を発見することになる。