“デジタル先進国”を掲げる韓国で、政府のデータセンターが火災のため壊滅した。9月26日夜、大田（テジョン）市の国家情報資源管理院（NIRS）で火災が発生。647の政府システムが停止し、行政サービスが広範囲に麻痺した。クラウド運用の鉄則である災害復旧システムが機能せず、過去の教訓も生かせなかった結果だ。
【Infostand海外ITトピックス】647の政府システムがダウン 韓国データセンター火災の衝撃 - クラウド Watch
⇧ う～む...
- 事業継続計画（BCP：Business Continuity Plan）
- 情報技術における事業継続計画（IT-BCP：Information Technology Business Continuity Plan）
あたりの仕組みが構築されていなかったのかね？
コストはかかるが、地理的な遠隔地に「データ」の複製を保存しておくべきだった気がしますが、高過ぎる授業料でしたな...
ただ、
今回の火災で最も深刻だったのは、システム設計の根本的な欠陥だった。通常、データセンターには災害復旧（ディザスターリカバリー）システムが備えられており、自然災害やサイバー攻撃によるシステム停止時に、他の拠点で業務を継続できる。今回の火災では、他の地域センターが緊急時に引き継ぐはずの冗長性システムが機能しなかったのだ。
【Infostand海外ITトピックス】647の政府システムがダウン 韓国データセンター火災の衝撃 - クラウド Watch
また内務安全部によると、データのバックアップは主要システム（Tier 1・2）で1日1回、Tier 3・4では週次から月次のバックアップのみだったという。被害規模は各システムのデータが最後にバックアップされた時期に依存する。「647のシステムすべてを再起動するまで、すべてのデータが保存されているかどうかを知ることは不可能だ」と内務安全部関係者はハンギョレ新聞に述べている。
【Infostand海外ITトピックス】647の政府システムがダウン 韓国データセンター火災の衝撃 - クラウド Watch
⇧ 上記の話が正しいとするならば、主要システムの「データ」は差分が1日ということになりそうだけど。
とりあえず、
- インフラレイヤー
- アプリケーションレイヤー
がきれいに整理できていて、且つ、構築の自動化の対応が済んでいれば、システムの再構築は、そこまで負担にならない気もするが...
属人化していて「ブラックボックス」な部分の割合が多いような状況だと、試合終了ですな...
何やら、
報道によれば、G-Driveは公務員が文書共有などに使う政府用のクラウドストレージで、米Googleのクラウドサービス「Googleドライブ」とは無関係。公務員1人につき30GBのデータ容量を提供しており、韓国の行政機関「行政安全部」は各省庁に対し、全ての業務資料は業務用PCに保存せず、G-Driveに保存するよう求めていたとしている。
韓国、政府のオンラインストレージが火災で焼失 8年分の業務資料858TBが消滅か バックアップなく「気が遠くなる」 現地報道 - ITmedia NEWS
G-Driveは2024年8月の時点で、74省庁の職員12万5000人（政府職員の約17％）が利用しており、858TB（A4用紙4495億枚相当）のデータを扱っていたという。その容量からバックアップもできておらず、G-Driveを多用する行政機関「人事革新処」の関係者は朝鮮日報の取材に対し「8年分の業務資料が完全に消失した。気が遠くなる状況だ」と答えている。
韓国、政府のオンラインストレージが火災で焼失 8年分の業務資料858TBが消滅か バックアップなく「気が遠くなる」 現地報道 - ITmedia NEWS
⇧ 上記だと、「データ」の大部分が復旧困難そうな内容なのだが、情報が錯綜しておりますな...
まぁ、「保守・運用」のコストを削減したいのは分かるのだが、こういった「事例」が人口に膾炙するようになれば、「経営層」に「システム」に莫大なコストがかかることを理解してもらえるのかもしれませんな...
何と言うか、
朝鮮日報や東亜日報の報道によれば9月26日、韓国中部大田にある国家情報資源管理院で、無停電電源装置のバッテリー交換中に火災が発生。リチウムイオンバッテリー384個が燃えた他、サーバが全焼し、政府の647システムがまひしたという。このうち、G-Driveを含む96件のシステムに関する機器は全焼したが、G-Driveを除く95システムについては外部にバックアップがあるため復旧が可能という。
韓国、政府のオンラインストレージが火災で焼失 8年分の業務資料858TBが消滅か バックアップなく「気が遠くなる」 現地報道 - ITmedia NEWS
上記の通りだとすると「ハードウェア」の問題と言う気がするので、どうしようもない気もしますな...
リチウムイオン電池は、内部に燃えやすい溶媒を含むため、発火リスクが特に高いとされています。
⇧ 上記によると、消火も困難そうですし...
東亜日報は4日、復旧作業を統括していた職員が飛び降り自殺したことも報じた。
韓国、政府のオンラインストレージが火災で焼失 8年分の業務資料858TBが消滅か バックアップなく「気が遠くなる」 現地報道 - ITmedia NEWS
⇧ ご冥福をお祈りするしかないのだが、困ったときはお互い様の気持ちが許される雰囲気作りをして欲しいのよね...
「復旧作業」を頑張っている方々は、感謝されこそすれ、非難される筋合いは無いはずですからな。
bashのset -eで、diffの終了ステータスが、0、1、2なので差分なし以外の場合に処理が終了するという罠
■エラーが出た時点で処理を終了する
#!/bin/bash set -e # 何某かの処理
⇧ とすれば「エラーハンドリング」とかできると思っていたのだが、然にあらず。
⇧ 上記サイト様にありますように、「終了ステータス」が「0」以外の場合は問答無用で強制終了してしまうという...
ちなみに、「diff」コマンドの説明を確認すると、
FILES are 'FILE1 FILE2' or 'DIR1 DIR2' or 'DIR FILE' or 'FILE
DIR'. If --from-file or --to-file is given, there are no
restrictions on FILE(s). If a FILE is '-', read standard input.
Exit status is 0 if inputs are the same, 1 if different, 2 if
trouble.
⇧ 上記にあるように、「終了ステータス」については、3パターンが全量ということになるようだ。
「シェルスクリプト」は「エラーハンドリング」の設計思想が考慮されていなかったということなのか分からないのだが、エラーの原因を早期に特定するための仕組みが不完全になってしまっているため、問題が発生した場合の調査が誠にし辛いというね...
とりあえず、
シェルスクリプト (英語: shell script) は主にオペレーティングシステムのシェルまたはコマンドラインインタプリタから実行可能なコマンドの一連の流れをファイルにして再利用できるようにしたものである。
シェルスクリプトで書かれる典型的処理としては、ファイル操作、プログラム実行、テキストの印刷などがある。
シェルスクリプト用インタプリタの多くはコマンドラインインタフェースも兼ねており、各種Unixシェル、Windows PowerShell、MS-DOSのCOMMAND.COMなどがある。他にAppleScriptやグラフィカルな Windows Script Host (WScript.exe) などもあり、コマンドラインインタフェース抜きでコンピューティング環境にスクリプト機能を加えている。
プログラミング
現代の多くのシェルは手続き型プログラミング言語にある基本的な制御フロー構造などに似た豊富な機能を備えている。制御構造、変数、コメント、配列、サブルーチンなどである。それらを使えばかなり洗練されたアプリケーションをシェルスクリプトで書くことも可能である。しかし、シェル言語の多くはデータ型システム、クラス、スレッド、複雑な数学的計算といった高水準言語に見られる機能をほとんどサポートしていない。また、コンパイラや性能重視のインタプリタで実装された汎用言語に比べれば実行速度が遅い。
⇧ 一般的な「プログラミング言語」のような「市民権」は与えられてい無さそうではある...
「エラー」が発生した場合に、原因特定し易いログを残して欲しいお気持ち...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
