本ブログは、こちらに掲載されている英文ブログの意訳です。万が一内容に相違がある場合は、原文が優先されます。
2022年4月18日 23:57 UTC時点で、サービス停止の影響を受けたお客様サイトの復旧を完了しました。
2022年4月4日(月) PTに、アトラシアンクラウドをご利用の約400社のお客様が、アトラシアン製品全体を通してサービスの停止を経験されました。2022年4月18日現在、影響のあったお客様サイトの復旧を完了し、各サイトの窓口ご担当者宛てにご連絡申し上げました。
当社のサポートチームは現在、個々のお客様に合わせたサイト特有のニーズに対応しています。支援を必要とする事象のあるお客様は、当該サポートチケットへその旨ご返信ください。至急エンジニアリングチームより対応させていただきます。
今回のインシデントはサイバー攻撃や、システムの拡張に問題があったものではありません。また、一部のお客様にて、障害発生の5分前程度までのデータ損失に関する報告があった以外、復旧が完了している大半のお客様にデータ損失は発生しておりません。
まず、本インシデントおよび応答時間は当社が自ら設定している基準を満たすものではなく、アトラシアンを代表してお詫び申し上げます。当社の製品はお客様にとってミッションクリティカルであり、サービスの停止によってお客様のビジネスへ多大な影響を与えることは十分理解しております。当社は現在、本件を最優先事項として24時間態勢で復旧作業を進めております。
何が起こったのか
「Insight – Asset Management」と呼ばれる、Jira Service ManagementおよびJira Softwareのためのスタンドアロンアプリは、当社製品のネイティブ機能として完全に統合されました。そのため、当該アプリがインストールされていたお客様サイトのレガシーアプリを無効化する必要がありました。当社のエンジニアリングチームは、既存のスクリプトを使用して当該スタンドアロンアプリのインスタンスを無効化しようと計画していたのですが、2つの重大な問題が発生しました。
- コミュニケーションギャップ：まず、無効化を依頼したチームと無効化を実行したチームの間にコミュニケーションギャップがあり、無効化の対象となっているアプリのIDを提供する代わりに、アプリの停止を実行するクラウドサイト全体のIDを提供してしまいました。
- スクリプトの不具合：2つ目に、利用したスクリプトには、（リカバリー可能であることが望ましいような）日常のオペレーションで利用する「削除マーク」機能と、コンプライアンス上の理由などから恒久的にデータを削除する必要がある場合などに利用する「恒久的削除」機能が兼ね備えられていました。そのスクリプトが、間違った実行モードで、間違ったIDリストのもとに実行されてしまいました。その結果、約400社のお客様のサイトが不適切に削除されてしまいました。
当社のグローバルエンジニアリングチームは、このインシデントから復旧するために、影響を受けたお客様を復旧させるための系統だったプロセスを実施しました。
復旧に向けての作業内容
当社のデータ管理プロセスの詳細は、「アトラシアンによる顧客データの管理」にて確認いただけます。
高可用性を確保するために、複数のAWS Availability Zone(AZ)にて、同期型のスタンバイレプリカをプロビジョニングし、維持しています。AZのフェイルオーバーは自動化されており、通常60～120秒で完了します。また、データセンターの停止やその他の一般的な障害にも定期的に対応しており、お客様に影響を与えることはありません。
また、データ破損のイベントに対する耐性を持つように設計されたイミュータブル（不変的）バックアップを保持しており、スナップショット取得時点へのリカバリーを可能にしています。バックアップは30日間保持され、アトラシアンはストレージバックアップの復元を継続的にテストし、監査しています。
このバックアップを利用して、個々のお客様や、誤って自分のデータを削除してしまった一部のお客様を定期的にロールバックしています。また、必要に応じて、すべてのお客様を一度に新しい環境にリストアすることも可能です。
まだ自動化されていないのは、大規模な一部のお客様を、他のお客様に影響を与えることなく、既存の（現在使用している）環境にリストアすることです。
当社のクラウド環境では、各データストアに複数のお客様のデータが格納されています。今回削除されたデータは、他のお客さまも利用中のデータストアの一部に過ぎないため、バックアップから個別に抽出・復元する作業を手作業で行っています。各お客様のサイトの復旧には、社内での検証や、サイト復旧時の最終的なお客様の確認が必要で、時間のかかる、複雑な作業となっています。
復旧プロセスのステップ
お客様サイトの復旧は、当初は半自動化されたものでした。そのため、リストアした各サイトの顧客データを手動で検証する必要があり、一連の複雑な手順で時間がかかっていました。
現在、下記のような自動化度合いの高いプロセスへ移行しています：
- 削除されたサイトのメタデータを中央管理システムで再度有効化する。
- バックアップから抽出されたユーザーやパーミッション等を含む顧客データをリストアする。
- お客様が生成したデータと直接関連づけられていない、エコシステムアプリ、請求データ、その他データを再度有効化する。
サイトごとに複数のデータストアを抽出して復元する必要があるため、サイトのテストを行い、個々のお客様と密接に連携して復元の精度を高めています。
現在、60テナントまでのバッチごとにお客様データの復元にあたっています。エンド・ツー・エンドで、お客様にサイトをお戻しするまでに4〜5日の経過時間が必要です。現在、当社のチームは複数のバッチを並行して実行する機能を開発し、全体の復元時間を短縮することに成功しています。
お客様の復旧が最優先事項
このようなインシデントは信頼を失墜させるものです。これまで影響を受けたお客様に直接アプローチすることに重点をおいてきたコミュニケーション活動を含め、当社が自ら設定した厳しい基準に適合するものではありません。
本件は、引き続き私の技術チームと当社全体の最優先事項であり、すべてのお客様のサイトが復旧するまで、24時間態勢で作業を進めて参ります。
今後について：
- お客様サイトの復旧： 引き続き、影響を受けたお客様とサポートチケットやカスタマーサポートチームを通じて直接連携し、できる限り早期のサイト復旧にむけて取り組んでまります。
- 日次のアップデート：影響を受けたお客様に対して、チケットを通じて、またステータスページの更新を通じて、毎日状況を報告することを約束します。
- インシデント事後レビュー：障害対応完了の後、調査結果と次のステップを記したポスト・インシデント・レビューを実施し、共有します。この報告書は公開される予定です。
最後にお客様に向けて：復旧に向けて多大な協力をいただいていることに感謝申し上げるとともに、当社のミスにより、お客様のビジネスに大きな支障をきたしていることをお詫び申し上げます。一刻も早くお客様のサービスを復旧させ、お客様のためにできることをすることをお約束します。