システム障害を減らすためにできること。やるべきこと。

システム開発に障害は付き物だ。
障害が発生したら現場のエンジニアは夜間だろうと休暇中だろうと、呼び出され、対応を余儀なくされる。
手術台に向かう外科医さながらに、システムの手術をしなければならない。

この障害対応はSEにとって最も不幸なイベントであることに疑いの余地はない。
あまりに多い障害対応は現場のエンジニアを疲弊させ、モチベーションの低下すら招く。

障害を完全に無くすことはシステム屋をやっている限り不可能だが、障害を減らすプロセスを洗練させることはできるはずだ。

ここでは、障害を減らすために組織として行うべきプロセスを考えたい。

プロセスの始まりは「障害の発生」からだ。
ここから見ていこう。

<障害を減らすためにするべきこと>

■障害の発生時
・現象を特定する
ユーザーの目線で、何が起こったのか明確にする。

・障害の内容を記録しておく
いつ、どんな障害が発生して、どんな影響があったのか。どんな対応をして解決したのか。
プロセスを属人化せずにドキュメントに残す。
記録せずに記憶に頼ると、是正案を客観視できず、障害の再発につながる。
障害対応の過程は、第三者が見てもわかるように資料に残すこと。

システムは人より長く組織に残るので、担当者がいなくなっても使える資料にする。

■障害対応のプロセス
①暫定的な対応を行う
まずは火消しを行う。
最低限の機能は動くようにする。

②原因特定
障害は何が原因だったのか特定する。
その際は、三種類の原因を考える。

１．障害を作ってしまった原因。開発時のドキュメント、ソースコードの原因。
２．障害を発見できずに起こしてしまった原因。なぜリリース前に発見できなかったのか。
３．復旧が遅れた場合、その対応の過程のミスの原因を考える。

上記三種類を踏まえて、障害が起こった組織的な原因を発見し、プロセス改善につなげる。

原因を考える際は「なぜ」を繰り返して、深掘りしていくこと。
なぜを考える際は、感覚に頼らずに、実際に起こったことを前提にして行う。
「なんとなくこうじゃないか」ではいけない。

これらの過程は全て文書として必ず記録し、第三者が見ても知識を共有できるようにすること。

第三者が見てわかる資料のポイントは以下の通り。
・日時・場所を記入する
・障害が起こったシステムの箇所を特定する
・障害の報告資料は要約せず、ありのままに残す
・いつ、どこで、どんなタイミングで障害が発生したのか

誰が見てもわかるように書くこと。

以上。

障害を減らすプロセスは、地味で単純で退屈なことかもしれない。
でも、そういう地味な改善にこそ、システムの神様は宿っていると信じている。