6月14日の6時58分、Slackへ通知アラートが届いた。
内容は、オンプレミスで運用中のファイルサーバのICMPエラーであった。
メンバー１人がデータセンターに駆けつけて状況を確認すると、OSがダウン状態であることを知る。
（保守技術員の診断結果では、RAIDコントローラのハード障害が原因であった）
ただちにスタンバイ機への切り替えを実施したが、復旧するまでに 2時間以上要してしまった。
スタンバイ機への切り替えについては、DFS の向け先変更等の作業で、10分程度で終わるはずだったが、スタンバイ機での運用を決断してから、ユーザーが利用できるようになるまで約60分。つまり、50分のロスとなってしまった。
貴重な障害の機会を得たので、次回同様の障害が発生した場合の参考のためにも、まとめておきたい。
今回、課題は４つ見つかった。
第１に、チャットでの連携不足があった。責任感が強いメンバーが即動いてくれたが、現状復旧または切り替え実施の決断の判断材料がわかるまでに時間がかかった。各人がどういうアクションを取っていて、今どういう状況なのか？
管理者はそのホットな状況が知りたいだけだ。単にチャットの使い方の問題もあるが、普段から意見を率直にぶつけることができる環境構築が最重要か。
第２に、スタンバイ機への切り替え手順の方法のマニュアルが正式に無かったこと。
ナレッジには、切り替えテストの記録はあったのだが、実際に作業手順書と呼ばれるものでは無かった。
こちらについては、マニュアルを早急に整備し、緊急用ファイルへ紙ベースでも保管しておくことで、時間短縮かつミスなく移行処理ができるようになるはずだ。
第３に、非常時の作業の役割分担が不明瞭であったこと。
これは、リーダーの仕事である。
きちんと、適切にメンバーへ指示を与えて、効率よく作業を実施してもらうだけの話。「この作業は、Ａさんしかできない」とならないように、普段から属人化しないためにも訓練が必要になってくる。
最後に、平常心を忘れないこと。責任感により、どうしても「すぐにサービスを使えるようにしなければ！」という焦りで慌ててしまうとロクなことにならない。
とにかく、深呼吸して、平常心をキープする。これが一番難しいのだが、命まで取られるわけではないので、毅然とした態度で行動していきたい。
以上の４点、今の弱点が見えたことが大収穫である。明日へとつなげていきたい。
