アトラシアン、JiraやConfluenceのサービス障害が1週間以上続く。原因は、保守スクリプトの実行ミスによるユーザーデータの消去。消去データのリストアに想定外の手間

今回は「アトラシアン、JiraやConfluenceのサービス障害が1週間以上続く。原因は、保守スクリプトの実行ミスによるユーザーデータの消去。消去データのリストアに想定外の手間」についてご紹介します。

関連ワード （全面、処理、直面等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、Publickey様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

アトラシアンがクラウドサービスとして提供しているJIRA SoftwareやConfluenceなどを利用しているユーザーの一部で、障害によって1週間以上これらのサービスが使えなくなっています。

下記は同社サービスのステータス画面。Jira SoftwareやJira Service Mangement、Confluenceなどのサービスで記事執筆時点（4月13日22時現在）も障害が続いており、インシデントの赤いマークが付いているのが分かります。

この障害について同社CTOのSri Viswanath氏が中間報告として記事「Update on the Atlassian outage affecting some customers」（日本語訳）を公開しています。

この中間報告とステータス画面の情報などから、障害の原因や同社の対応をまとめました。

4月4日に障害発生、1時間後には原因が判明するが……

障害が発生したのは4月4日午後8時（世界協定時。日本時間4月5日火曜日午前5時）頃、その1時間後にはステータス画面に「Investigating（調査中）」と表示され、一部のユーザーに対してサービス障害が発生したことが明らかになります。

さらに1時間後にはステータス画面に「Identified（原因判明）」と表示。障害の原因が判明しました。

原因は、使われなくなったソフトウェアを無効化するために同社が実行したスクリプトの設定にミスがあり、間違ったユーザーに対して誤ってデータを消去してしまったことでした。

このミスによって約400ユーザーが影響を受け、サービスが利用できなくなりました。

原因はスクリプトの実行ミスによるデータ消去

同社CTOのSri Viswanath氏による中間報告では、ミスの原因として2つの理由が説明されています。

1つ目は、スクリプトの実行を依頼したチームと、依頼を受けて実行したチームのコミュニケーションに問題があったこと。

• コミュニケーションギャップ：まず、無効化を依頼したチームと無効化を実行したチームの間にコミュニケーションギャップがあり、無効化の対象となっているアプリのIDを提供する代わりに、アプリの停止を実行するクラウドサイト全体のIDを提供してしまいました。

2つ目は、スクリプトに不具合があって実行内容が間違っていたこと。

• スクリプトの不具合：2つ目に、利用したスクリプトには、（リカバリー可能であることが望ましいような）日常のオペレーションで利用する「削除マーク」機能と、コンプライアンス上の理由などから恒久的にデータを削除する必要がある場合などに利用する「恒久的削除」機能が兼ね備えられていました。そのスクリプトが、間違った実行モードで、間違ったIDリストのもとに実行されてしまいました。その結果、約400社のお客様のサイトが不適切に削除されてしまいました。

こうして、消去されるべきでないユーザーのデータが消去されてしまったわけです。

想定外だった一部の顧客データだけのリストア

スクリプトの実行ミスによって約400もの間違ったユーザーのデータが失われたことが原因であることは、サービス障害の発覚から1時間程度で判明しました。

しかしここからが大きな問題でした。失われたデータの復旧が著しく困難であることに同社は直面するのです。

それがこの障害が1週間以上長引き、今なお完全復旧に至らない理由です。

今回障害が発生したクラウドサービスはAWS上で稼働しており、複数のアベイラビリティゾーンを利用した高可用構成でした。しかも定期的にスナップショットを取得し、バックアップは30日間保存されています。同社は定期的にバックアップとリストアのテストも行っていると説明しています。

一見、データのバックアップ体制は万全に聞こえます。

しかし、今回のように一部の顧客のデータだけが失われた場合、それをどのように復旧させるかまでは想定されていませんでした。

今回データを失ったユーザーは一部であり、それ以外のユーザーは影響を受けていません。影響を受けていないユーザーは障害とは関係なく現在に至るまで作業を行い、データの入力や変更などを行っています。

すると、もしも障害を受けたユーザーのデータをリカバリするため、障害発生から1時間後にスナップショットを元に戻す、あるいはバックアップからリカバリを行った場合、今度は障害を受けなかったユーザーの作業が1時間分巻き戻されて、その間のデータが失われることになります。

つまりあらかじめ想定された手段でのロールバックやリカバリは不可能だったのです。

CTOのSri Viswanath氏による中間報告から、説明を引用しましょう。

当社のクラウド環境では、各データストアに複数のお客様のデータが格納されています。今回削除されたデータは、他のお客さまも利用中のデータストアの一部に過ぎないため、バックアップから個別に抽出・復元する作業を手作業で行っています。各お客様のサイトの復旧には、社内での検証や、サイト復旧時の最終的なお客様の確認が必要で、時間のかかる、複雑な作業となっています。

これが障害発生から1週間以上かかっても完全復旧しない最大の原因でした。

全体のバックアップから個別のユーザーのデータだけを探し当てて抜き出し、それを現在も稼働中のクラウドサービスに対して矛盾や齟齬（そご）のない形で適用し、顧客ごとにサービスを復旧させる作業は、想像したくもない面倒な作業でしょう。

データストアごと、あるいはバックアップ単位ごとにユーザーデータが分離されていない、いわゆるマルチテナント構成の難しさが露呈した形です。

現在も24時間体制で復旧作業中

同社は現在も24時間体制で復旧作業を続けていますが、現時点で影響を受けてユーザーに対して約45％の復旧率とのことで、まだ完全復旧には時間がかかりそうです。CTOのSri Viswanath氏も平謝りの状態。

このようなインシデントは信頼を失墜させるものです。これまで影響を受けたお客様に直接アプローチすることに重点をおいてきたコミュニケーション活動を含め、当社が自ら設定した厳しい基準に適合するものではありません。

本件は、引き続き私の技術チームと当社全体の最優先事項であり、すべてのお客様のサイトが復旧するまで、24時間態勢で作業を進めて参ります。

同社はソフトウェアのライセンス販売からクラウドサービス提供へとビジネスモデルの転換を2年前に発表しています。

• アトラシアン、今後はクラウドサービスにフォーカス。買い切り型のソフトウェアライセンスは販売終了と発表

影響を受けたのが一部のユーザーとはいえ、このタイミングで大きな障害を引き起こしてしまった同社にとって、これは非常に大きな教訓になったといえそうです。

関連記事

• Spotifyが全世界でログインできなくなった3月8日の障害について原因を報告。Google CloudのTraffic Directorの障害がgRPCライブラリのバグを踏んだと
• テスラ、サーバエラーでアプリによる操作が一時不能に。自分のクルマに乗れなくなるなどの障害発生
• Facebookが10月5日の全面ダウンの詳細を報告。バックボーンの停止がBGP停止となりインターネットから離脱、外部からのアクセスを失いデータセンターに乗り込んで対応
• 9月2日木曜日に発生したAWS東京リージョンの大規模障害、原因はネットワークデバイスの新プロトコル処理に潜在的なバグがあったこと。AWSが報告書を公開

「障害報告」タグの記事一覧