復旧には14日かかり、近年最大のSaaS障害となった。

すべての開発プロジェクトを管理するプラットフォーム、社内文書の共有ナレッジベース、ビジネス部門、営業部門、管理部門間のコラボレーションのためのプロジェクトプラットフォームが突然クラッシュし、メーカーから修復に 2 週間かかると言われたらどうしますか。この期間中、すべてのデータにアクセスできず、バックアップ バージョンも利用できませんでした。これはまさに、4 月に Atlassian で発生した大規模な障害の際に 775 社に起こったことです。

Atlassian は、有名なエンタープライズ プロジェクト管理プラットフォーム Jira、エンタープライズ ファイル コラボレーション プラットフォーム Confluence、カンバン コラボレーション ツール Trello を所有する、20 年の歴史を持つオーストラリアのソフトウェア開発会社です。多くの大企業がアジャイル開発プロジェクトの管理に Jira を使用しています。 Atllassian は、非技術系チーム向けのアジャイル プロジェクト プラットフォームも立ち上げました。多くの企業が、ビジネス、営業、ビジネス分析チームのアジャイル管理にこれを使用しています。

今年3月のAtlassianの財務報告によると、Fortune 500企業の75%以上が同社の法人ユーザーであり、世界中で23万社が導入しているという。社内の大規模システム開発プロジェクトのライフサイクル管理に Jira Service Management サービスを利用している企業は 40,000 社を超え、その多くは大企業です。さらに、年間ライセンスサブスクリプション料金が 100 万ドルを超える企業は 178 社あり、これは数千人がライセンス数をサブスクライブしていることに相当します。最も多くのサブスクリプション数を誇る超大手企業でも、50,000ライセンスをサブスクリプションしています。 Atlassian は、サブスクリプション収益だけで年間 13 億ドル以上を生み出しています。

アトラシアンは、インシデントの影響を受けた企業のリストは公表していないが、影響を受けた企業の数は775社だが、そのうち400社が積極的に使用していたとだけ明らかにした。影響を受けた企業に対する海外メディアのインタビューによると、最も小規模な企業でもライセンス数は150件だが、最大規模の企業では4,000件ものライセンスを契約しているという。非公式の推計によると、影響を受けた775社の個人ユーザーの累計数は5万人を超える。この事件はアトラシアンの市場価値にも大きな打撃を与えた。障害発生から完全復旧まで、アトラシアンの株価は2週間で20%近く下落し、5月下旬まで下落を続けました。

Atlassian は、SaaS サービスの運用と保守で 10 年以上の経験、SRE で 6 年の経験、クラウド業界における標準的な災害復旧と復旧計画を持っています。しかし、4 月の大規模な障害を時間内に検出して防止することができず、99.9% のサービス レベル コミットメント (SLA) で約束された 8.76 時間以内に復旧することができませんでした。多くの企業では、アジャイル プロジェクト データを公開できるようになるまで 14 日間も待たなければなりませんでした。

なぜ、このクラウド サービス プロバイダー、つまり SRE 運用および保守の専門家は、この大規模な停止を回避できなかったのでしょうか?

大規模なダウンタイムインシデントは、削除プログラムの誤用により発生しました。

事件が起こった4月5日の朝に戻ると、この日はアトラシアンの年次カンファレンスTeam22の前日でした。 Atlassian は、4 月 5 日に一部の古いバージョンのアプリを段階的に廃止し、これらの古いバージョンのアプリケーションのプログラムを削除する予定でした。停止の原因となったのは、AP の古いバージョンを削除したこのスクリプト プログラムでした。実際の削除が実行されるずっと前に、Atlassian はスクリプトをテストし、問題は見つかりませんでした。正式な環境で 30 人の顧客が使用していたアプリの古いバージョンを削除してみましたが、問題はありませんでした。

削除申請を提出したビジネス チームは、スクリプトによる自動削除の対象リストとして、これらの古いバージョンの AP をまだ使用している法人顧客のリストを提供しました。しかし、重要な誤りは、彼らが提供した ID リストが、削除される AP の ID ではなく、削除されるこれらの AP ID が配置されている Web サイト ID のリストであり、削除指示を実行したエンジニアリング チームに、これらの Web サイト ID 内の古い AP を削除するように指示されたことです。しかし、両者の間にはコミュニケーションのギャップがありました。エンジニアリング チームは、この Web サイト ID のバッチが削除対象のリストであると誤って認識し、削除スクリプトに直接適用して実行しました。 4月5日、このスクリプトは古いバージョンのAPではなく、古いバージョンのAPをまだ使用していた企業のすべてのWebサイトデータを削除しました。

災害の原因: 古いアプリを削除したかったのですが、なぜサイト全体の顧客データをすべて削除したのでしょうか?

誤って削除した場合の影響を理解するには、まず APP ID を使用して削除することと Web サイト ID を使用して削除することの違いを知っておく必要があります。これは Atlassiant の技術アーキテクチャから始まります。

すべての Atlassiant サービスは AWS にデプロイされます。データストレージやサービスアーキテクチャーにおいては、高度に分散化されたアーキテクチャーと、組み合わせや再利用が容易なマイクロサービスアーキテクチャーを採用しています。クラウド基盤上には本棚管理層や共有プラットフォームサービス層が設計されており、API を通じて多くのサードパーティベンダーのアプリケーションにも接続されています。すべてのマイクロサービスは AWS のコンテナ化されたサービス上にデプロイされ、内部マイクロサービスの自動構築を提供する Micros と呼ばれる一連の PaaS サービスが装備されています。公共サービスの展開、インフラストラクチャ リソースのスケジュール設定、データ ストレージ管理、コンプライアンス制御まで、すべてがこのプラットフォームによって自動的に完了します。

管理アーキテクチャの面では、Atlassian はマルチテナント アーキテクチャを採用し、ドメインを単一ユーザーの最も基本的な管理単位 (Web サイト ID) として使用します。企業は、Atlassian サービスにログインするためのメイン エントリ ポイントとして URL を指定し、サブスクライブするすべての Atlassian サービスをこの URL に登録する必要があります。 Atlassian では、この URL を Web サイト コンテナーとも呼びます。これは、このエンタープライズ顧客が使用するすべてのデータ、構成、アプリを保持するために使用されます。ウェブサイト ID は、会社のウェブサイト コンテナーを識別するために使用されるコードです。

Atlassian の技術アーキテクチャは分散アーキテクチャを採用しており、クラウド インフラストラクチャで可用性を向上させるだけでなく、アプリケーション システム レベルでも、弾力性と可用性のバランスをとるためにマルチテナント マイクロサービス アーキテクチャ設計を採用しています。

画像出典: Atlassian

Atlassian の Web サイト ID (企業顧客 Web サイト URL) も Web サイト コンテナーです。企業が使用するすべてのデータ、構成、アプリは、管理のためにこの Web サイト ID に登録されます。

画像出典: Atlassian

Atlassian は、この Web サイト ID をエンタープライズ ユーザー アカウントを識別するコードとしても使用します。この企業に関連するすべてのデータ、フォーム、請求書でも、顧客を識別するためのインデックスとしてこの Web サイト ID が使用されます。たとえば、企業の顧客がサポート チケットを送信すると、チケットでは Web サイト ID が顧客のコードとして使用されます。

Atlassian のビジネス ユニットが古い APP の Web サイト ID を削除することを提案したとき、彼らは使用していた古い AP を削除することを希望していました。しかし、実行を担当したチームは、これらの AP ID が配置されている Web サイト ID を削除する必要があると誤って考えていました。これにより、AP が削除されるだけでなく、それらの AP を使用する企業が所有するすべての AP とデータが削除されます。

4月5日7時38分に、古いAP削除スクリプトが実行されましたが、これは法的に認められた削除であったため、エンジニアリングチームは法人顧客のWebサイトが削除されたという警告通知を受け取りませんでした。しかし、10 分も経たないうちに、企業は使用していた Jira Web サイトが切断されていることに気づき、最初の停止サポート チケットを提出しました。削除スクリプトは8時頃に実行されました。調査の結果、775社の883のウェブサイトが一挙に削除されたことが判明した。影響を受ける製品には、Jira 製品ライン、Confluence ファイルコラボレーションプラットフォーム、Atlassian Access ログインメカニズム、Opsgenie インシデント対応サービス、さらには Web サイトステータスクエリページ Statuspage が含まれます。影響を受けた企業は、オンラインでログインできないだけでなく、運用状況ページを開いて利用しているサービスを確認することさえできません。

多くの顧客が次々と停止チケットを提出したため、アトラシアンは8時17分に重大インシデント管理プロセスを開始することを決定し、エンジニアリング部門、カスタマーサポートチーム、プロジェクト管理チーム、外部通信部門を含む部門横断的なインシデント管理チームを編成して共同で事故調査を行い、3時間ごとに会議を開催し、8時24分にインシデントのステータスを「重大」にアップグレードしました。エンジニアリング チームは 20 分も経たないうちに、インシデントの根本的な原因を発見しました。それはハッカーの攻撃ではなく、誤ってデータを削除したスクリプトでした。午前9時3分、サービス状況のウェブページで初めて停止が明らかになった。

インシデントの原因を突き止めた後、次のステップは問題をできるだけ早く解決し、顧客が加入しているサービスを復旧することです。 Atlassian は標準化された復旧方法を確立しようと試みましたが、削除された Web サイトを復元するには、新しい Web サイトを作成し、データの復元に必要な下流の各製品、サービス、データを復元し、各 Web サイトで使用されているサードパーティのエコシステム ベンダーとの接続を再構築する必要があることがわかりました。関連する回復手順は 70 個もありました。これらのウェブサイトを復旧する複雑さは想像をはるかに超えるものであることがわかったため、事故から5時間以上経過した12時38分に、インシデントの深刻度レベルを「最高レベル」に引き上げました。

Atlassian の障害発生後すぐに、Jira が多くの企業でアジャイル開発プロジェクトを管理するために使用されている主要プラットフォームであるため、Twitter で苦情を訴える顧客が増えました。使用できない場合は、アジャイル プロジェクトを開発できないことを意味し、プロジェクトの作業指示書を開いて、どのような作業を処理する必要があるかを知る方法がありません。苦情はますます大きくなり、停止時間がどんどん長くなり、8 時間や 9 時間を超え、Atlassian が約束した 99.9% の可用性が破られたことに気付く人が増えていきました。

影響を受けた多くの企業ユーザーは、Atlassian に障害を報告したり、サポートチケットを提出したりすることすらできなかったと Twitter で不満を述べました。また、Atlassian のサービス窓口が連絡を失い、元のオンライン チャネルを通じて連絡が取れなくなったかのように、申請を送信した後、正式な回答を受け取らなかった人もいました。

アトラシアンが影響を受けた顧客に電子メールで通知し、電話をかけて状況を説明し始めたのは、事件発生から17時間後のことでした。その時までに、この大規模な停電はすでに多くのメディアの注目を集めており、報道され始めていました。

アトラシアンが障害に関する最初の公式声明を発表したのは、事件発生からほぼ2日後のことでした。アトラシアンのパートナーは、事故発生から2日目の終わりまで通知を受け取りませんでした。障害が解決されていないため、アトラシアンの共同創設者も自身の名前で手紙を送り、回復の進捗が遅い理由を顧客に個人的に説明した。

事件発生から4日後の4月8日、アトラシアンはようやく影響を受けた最初の顧客のウェブサイトを復旧することに成功した。しかし、復元チームは、復元方法の最初のバージョンを使用すると、一連の Web サイトを復元するのに 48 時間かかることを発見しました。多くの手作業が必要だったため、一括でしか復元できませんでした。残りのウェブサイトが完全に復旧するには、さらに 3 週間かかります。そこで、彼らは修復プロセスの改善に取り組み始めました。同日、Atlassian はすべてのエンジニアリング部門に対してコードフリーズを実施し、顧客データへの不整合な変更のリスクを軽減するためにあらゆる変更を禁止しました。

翌日の 4 月 9 日には、2 番目の回復方法が実行され、当初の 70 件の手順が 30 件の手順にまで大幅に削減されました。 2 番目のアプローチは、新しい Web サイト ID を作成せずに顧客の Web サイトを再構築することです。代わりに、顧客の古い Web サイト ID が直接使用されます。これにより、古い ID と新しい ID を比較する手順が大幅に削減され、サードパーティのプログラム プロバイダーと 1 つずつ通信する必要がなくなるため、多くの時間を節約できます。現時点では、誤って削除されたウェブサイトは 771 件ありますが、2 番目の方法を使用して復元できます。

ただし、2 番目の方法では依然として多くの手動操作が必要になります。アトラシアンのエンジニアリング チームが 2 番目の方法を高速化する自動復旧ツールを作成し、復旧時間を 12 時間に短縮したのは 4 月 11 日になってからでした。当時、アトラシアンは作業指示書の中で、事故後 2 週間以内に復旧できると顧客に対して約束していました。

4月14日までに、復旧方法の第1版で復旧したウェブサイトの数は112に達し、利用できなくなっていた。 Atlassian は、Web サイトを復元するための完全な検証スクリプトも作成しました。これにより、手動による検証が不要になり、他の Web サイトの復元が高速化されました。 4月16日10時5分までに全ウェブサイトの復旧と自動検証が完了しましたが、まだお客さまによる確認はできておりません。翌日21時48分に、影響を受けた最後の顧客が復旧確認を完了しました。アトラシアンは4月18日午前1時に、影響を受けたウェブサイトは100％復旧したと発表した。この時、事故から約14日が経過していた。しかし、発表時点では、データが「クラッシュの 5 分前」という当初の復旧時間よりも早く復元されたため、その後のデータ変更に追いつく必要のある Web サイトがまだ 57 ありました。

4 月末、Atlassian は 4 月の障害に関する完全な事後分析を発表しました。