ホーム

スタッフブログ

2022年1月14日

他サービスのシステム障害を、真剣に考える

こんにちは

システムチームマネージャー / プログラマーのAです。

 

2021-2022年の年末年始にかけて、

デキテル・抱きしめーる共に

重大なシステム障害は発生しませんでした。

不安の多い連休でしたが、まずは、良かったと思います。

引き続き、安定稼働をキープしましょう。

 

一方で

他社のサービスやシステムに

重大な障害が発生したというニュースを多く目にしました。

 

今回は、そのうちの1つについて

自分事として、原因と再発防止を考えてみます。

今後の障害対応への参考になれば良いと思っています。

では、はじめます。

 

 

京都大学のデータ 28TBが「完全消失」

昨年の12月28日(火)。

京都大学からシステム障害に関する公表がありました。

 

同学スーパーコンピューター上の

77TBのデータが「消失」し、

28TBのデータが「完全消失」したとのこと。

 

管理ベンダーの報告書には

「100%弊社(管理ベンダー側)の責任」という文言があり、

事態の深刻さを感じ取れます。

 

 

「完全消失」は最悪のシステム障害の1つ

「消失」と「完全消失」の違いは

「復旧できるか否か」にあります。

今回で言えば、28TBのデータが、永久に回復出来ません。

 

個人的には

「個人情報の流出」と並ぶ最悪のシステム障害の1つだと思います。

 

「個人情報の流出」と「データの完全消失」は

共通して、受けたダメージの回復が出来ません。

ダメージが回復出来ない事」が、最大のダメージだと思います。

 

 

原因は、リリース工程の誤り

妙な話ですが、

バックアッププログラムのリリース工程の誤り、が原因でした。

 

バックアッププログラムの実行中に、

バックアッププログラムをリリース(上書き)したことで、

28TBのデータが、誤って、「完全消去」されてしまいました。

 

リリースって「ファイルをアップして終わり」じゃない。

改修内容を考慮した、論理的な工程が必要だと、改めて実感します。

 

 

何故リリース工程を誤った?

 

今回、リリースされたプログラムの言語には

「実行中に上書きされると、挙動が変わる」

といった特性がありました。

 

個人的には

リリース担当者ともなれば、認識していそうなレベルの特性だと思いますし、

普通、「プログラム実行中に上書きする」ようなリリースの工程は踏まないと思います。

 

当時の状況として

・進捗に問題があって急いでいた

・担当者が急に変わった

・プログラム停止の承認が取れず、強行するしかなかった

など、異常な状況にあったのではないかと想像しています。

 

 

再発防止案

恐れ多いですが、自分なりに再発防止案を考えてみました。

 

再発防止は「理論的に再発し得ない」が大事だと思います。

どんな状況でも達成される、でも現実的な、再発防止を求めるべきです。

 

よくあるんですが

「気を付ける」とか「テストを入念に」… はNGです。

一旦、上記の様なアイデアは選択肢から捨ててください。

 

 

① 別ストレージへの常時ミラーリング

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

極端なアイデアですが

常時、別のストレージにも保存しておけば、

1ストレージが消失しても、ストレージの切替で即リカバリできます。

予算、秘匿性、処理速度、と懸念はありますが、確実です。

 

 

② 「上書き」特性の変更

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

今回のプログラムは

実行中に上書きされると、実行内容に影響を及ぼします。

であれば、実行中に上書き出来ないようにすれば良い。

実行前後に、パーミッションを変更することで実現できるはずです。

 

 

③ 重要なファイルをプロテクトする

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

②と似ていますが、

消えてはいけないファイルのパーミッションを変更しておけば、

削除しようとしても、削除されなかったはずです。

 

 

④ 「削除」の概念をシステムから無くす

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

これも極端なアイデアですが、

「削除」しなければ、「誤削除」はあり得ません。

例えば

別ストレージへの「転送」にしておけば、

誤りが発生したとしても、「誤転送」で済みますし、

「圧縮」にしておけば、「誤圧縮」で済みます。

 

 

⑤ ファイル構成確認プログラムの配置

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

今回、データの誤削除が発覚したのは

誤削除開始から、2日後のことでした。

定期的にファイル構成を確認するプログラムが配置されていれば、

もっと早期に確認・異常通達が出来たはずです。

 

—–

 

詳細な状況を把握していないので、

実現不可能な内容もあるかもしれないですが、

上記が、自分なりの再発防止案になります。

 

普段目にするシステム障害のニュースを

流し目で見るのではなく、真剣に捉えると、良い訓練になりました。

 

最後になりましたが

今回被害を受けられた方は、とても気の毒に思いますし、

開発者・ベンダーの方には、同情の想いがあります。

 

悲惨な障害が起きない世の中になれば良いと思いますし、

起こさないような開発者でいようと、思います。

 

 

以下資料です

 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄

スーパーコンピュータシステムのファイル消失のお詫び | お知らせ | 京都大学情報環境機構

https://www.iimc.kyoto-u.ac.jp/ja/whatsnew/information/detail/211228056999.html

 

Lustre ファイルシステムのファイル消失について

https://www.iimc.kyoto-u.ac.jp/services/comp/pdf/file_loss_insident_20211228.pdf

 

システム障害の話題・最新情報

https://news.biglobe.ne.jp/list/007/603/%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E9%9A%9C%E5%AE%B3.html

 

 

求人バナー

このページの上部へ戻る