事故内容：住民票や印鑑登録証明書などを印刷・発行できない。
システム会社：株式会社TKC（栃木県宇都宮市）
影響範囲：全国142の自治体
同業視点での考察：
まずはご対応お疲れ様でしたと心より思う。機械は予期せぬ動作をするし、人は失敗をする。
さて、本件は事故前日の9/8のプログラム入れ替えがミスっており、9/9朝から窓口業務に支障が出たとのこと。
サーバ環境は、開発環境→(a手動コピー)→テスト環境→(b自動コピー)→本番環境 の３階層。
aのファイルコピー作業で、やたら時間がかかっている様子だったので中断して、コピー先のファイル見てみた。すると、ファイル数とサイズが一致したから、コピーは正常だったと判断したが、実際にはファイルが破損していたそう。
まず第一に「手動コピー」とは何を指しているか。
文脈から、SFTP等の転送方法ではなく、またはコマンド実行ではなく、いわゆるWindowsOSでのフォルダ共有か、またはクリップボードを経由したコピペだったのではと推測。
どんな方法をとったとしても絶対に大丈夫という方法はないと思えるが、特筆するとすれば、sftpは完全性が担保できる、クリップボードは絶対やめたほうがいい。
次に「中断」後の判断について。
中断するなら、やり直しが絶対条件。ファイルサイズと数が正しいことの確認は、あまり意味がない。チェックサムで検査したとするなら一定の信頼に足ると思うが、それでも「コピー処理が終わっていなかったところを、人間が止めた」のだから、やっぱりやり直しが妥当だろう。常に冷静な判断ができるとは限らないし、基礎的なコンピュータリテラシの違いを現場教育で埋めることの難しさでもある。１４０団体に影響するプログラム入替とはいえ、十分に慣れた作業であり、１人か２人でできる段取りだったことが想像できる。
最後に、復旧に６時間を要したことについて。
この点の疑問は大きい。良いとか悪いとかではないのだが、朝一で障害があれば初動で「昨晩のプログラム入替」に原因を求めるはず。事実それが原因だったのなら、すぐにやり直しができたのではないか。仮に再起動が必要だったとしても、60分もあれば再開できるだろうと思う。この辺は、システムのアーキテクチャがどうなっているかわからないが、こういったエラーのたびに、６時間も８時間も止まることが前提だとすれば、MTTRが悪いかなと思う。ハード障害なら別だが。
とはいえ、当日の対応から、謝り文書の作成から、対応策の公表から、大変な一か月だったと思うし、敬意を表したい。全国140もの自治体にクラウドで基幹系システムを展開するなんて、簡単にできることではない。
