システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。
あわせて読みたい
-
あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ
メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 - 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック
- 半年で40kg痩せた！ダイエットでわかるリーンなプロジェクトマネジメント手法
- 心理的安全性ガイドライン（あるいは権威勾配に関する一考察）
#障害の種類と障害報告について
障害には、小さなもの、たとえば画面に表示されているテキストの乱れから、すべての画面で50xエラーが発生しているもの、決済とのつなぎ込みが失敗し、金銭的な影響が大きいものなど様々あります。どのような時に障害報告を書くのかと言われれば、「できればすべて書きましょう」というのが原則になると思います。
大前提として、「障害報告は始末書や反省文ではない」ということです。仕方なく、嫌嫌恥ずかしい思いをしながら書く必要はありません。うちはそういう文化じゃないんだと言う場合は、自分たちのチームから障害報告を始めてみるとよいのではないでしょうか。
#ハインリッヒの法則、あるいはヒヤリハット
http://ja.wikipedia.org/wiki/ハインリッヒの法則
ハインリッヒの法則というものがあります。これは、１件の重大な事故の背後には29件の軽微な事故、300件のヒヤリハット事例(事故にはならなかったけど、ヒヤッとしたこと)が隠れているという統計的な経験則です。
これは、逆説的に言えば、小さな障害報告であってもしっかりとマネージすることで重大な事故を防ぐことができるだろうということを意味しています。
#障害報告のフォーマットについて
障害報告はできれば、ticket/issue管理システムなどで管理した方が良いでしょう。なければ、wikiのようなものでもかまいません。そのときのフォーマットとしては、最低限、次のようなものを用意するといいでしょう。
- 障害内容サマリ
- カスタマーフィードバック
- 障害タイムライン
- 対応差分
- 再発防止策
障害内容サマリ
障害内容のサマリを端的な文章で記述しましょう。このとき、やってしまいがちなのは、「起きた現象」の内容ではなくて、「原因やバグが発生しているモジュール名」などを書いてしまいがちだったりします。ここに書くべきは、技術者以外も含めたメンバーが理解できるような現象面について言及することです。
たとえば、
「HogeFuga_master DBの物理障害が発生」
ではなくて、
「Hoge表示画面でinternal server errorと表示される」
「Hogeの投稿ができない不具合が発生」
などと記述します。
これは、影響の大きさを営業部門やサポート部門と共有するためにも大事なことです。
カスタマーフィードバック
発生した障害に関して、問い合わせの件数やその内容などを記述します。あるいは関連部門の人に記述してもらいましょう。これは、影響の大きさを可視化するのに役立ちます。また、障害発生時にそういった部門との情報共有を必要とするフォーマットになるため、障害対応から問い合わせ応答や、障害発生のお知らせを出すための連携もしやすくなります。
障害タイムライン
障害タイムラインとは、発生時刻、認知時刻、対応開始時刻、対応完了時刻、その他必要な時系列の対応状況に関する報告です。また、それぞれについて、「誰によって」「いつ」「どのように」がわかるとよりよいでしょう。
これを記述する理由は、再発防止策の検討の際にも役に立つからです。たとえば、発生時刻から認知時刻までの差が「２時間」であった場合、これを「１０分」にすることができるだけでも、障害の影響度は変わってきます。また、「認知時刻から対応開始まで」「対応開始から対応完了まで」の時刻も同様です。
障害の影響度については、
障害の影響度＝影響範囲 * 金銭的重要性 * 対応完了までにかかった時間
このように考えるとよいでしょう。
対応差分
対応差分へのリンクを必ず張りましょう。障害の理由は文章だけでは、伝わらないケースも多いです。
再発防止策
再発防止策は、障害報告を書く最大の理由です。障害報告を書いた時点では、すべてを記述する必要はありませんが、再発防止策が完了するまでは、チケットをクローズしないことが重要です。また、再発防止策を記述するときは、「原因(だと思ったもの)」と「対策」をしっかりと記述しましょう。なぜなら、原因だと思ったものが共有されていない場合、対策が的外れになってしまう場合もあるからです。
また、その際に
- 直接原因 ： その不具合が発生した直接的原因
- 間接原因 ： その不具合に至るまでの間接的な原因
- 本当の理由： なぜ、このようなパターンの障害が発生したか
のように３段階くらいに再発防止策を検討していけるとよいでしょう。これが三段階なのは前述のハインリッヒの法則をイメージしてもらうとわかりやすいと思います。一つの障害には、３００のヒヤリとしている事例、あるいはメンバーの慣れや、習慣、努力によってたまたま防ぐことができている障害が隠れています。直接的な原因を潰すだけでは、再発防止策としてはあまり適していないケースが多いです。そうではなくて、もう一段トラブルを引き起こした間接的な問題がはらんでいて、その問題を解決することで本当の再発防止となることが多いからです。
また、前述の通り、障害の影響度の式をイメージして、影響度を減らすための方策も重要です。
- 影響範囲 ：同様の問題が起こっても影響範囲の極小化はできないか？
- 対応完了までの時間 ：同様の問題が起こっても、短い時間で、あるいは自動的に対応できないか？
という問いも再発防止策を検討する上では重要です。
#再発防止検討サイクルについて
チーム振り返り
再発防止策の検討は、定期的にチームで振り返ることが大事です。この際に障害を引き起こしたチームメンバーに対する糾弾のようにならない配慮が重要です。再発防止策の検討には、かならずファシリテータを用意し、画面やホワイトボードに注目させ、また、ブレストのような自由闊達とした雰囲気づくりが重要です。お菓子を用意してもいいですし、適度なアイスブレイクも重要でしょう。
この際に、次に述べる良い再発防止策と悪い再発防止策のペーパーをメンバーは見ることができるようにしておくのも大事です。
また、これはファシリテータの仕事ですが、原因->対策という順番を忘れずに議論することが大事です。
セカンドオピニオン
再発防止策は、チーム外のメンバーで振り返るシーンを作った方が良いでしょう。その理由の１つは、情報を他のチームのメンバーと共有することでより広範囲の問題を解決する案が出てくるかもしれないこと。もうひとつは、チームの事情によってかかるバイアスを排除した意見をもらうことができることです。チームで行動していると、忙しさから場当たり的な問題解決をしがちになりますし、それを互いに指摘し合える関係を他のチームと構築することで、障害という資産を活かすことができる文化が生まれてくるでしょう。
良い再発防止策と悪い再発防止策
良い再発防止策
良い再発防止策について、順位付けするとしたら、
- その種類の問題について二度と意識することがなくなる解決策
- その種類の問題を開発時に自動的に検知することができる解決策
- その種類の問題が発生しても自動的に復旧することができる解決策
- その種類の問題が発生しても影響が局所化される、フールプルーフ、フェールセーフになる解決策
このような順序でしょうか。
悪い再発防止策
悪い再発防止策は、シンプルで人間というコンポーネントを使うことです。
- 責任回避のため稟議、決済経路を追加する策
- 他者の努力／忍耐／根性の不足を指摘し改善を求める策
- 個人／チームの注意力を原因とし、「より注意深く確認します／させます」といった策
- それっぽい言い訳付きのダブルチェック/トリプルチェック体制
- ドキュメントにその旨追記します！的な解決策
これは、そんなことやらないよと思っていると、ついついやってしまいがちなので注意が必要です。
「ちゃんと」「しっかり」というフレーズが出てきたら、危険信号です。
まとめ
- 障害報告は資産。どんなものでも作成し有効活用しよう。
- 人間というコンポーネントを再発防止に入れない
- セカンドオピニオンをもうけよう
以上です。