この記事は、Product Manager #pdmAC Advent Calendar 2017の3日目です。
ローンチしたサービスをチームとして運用していく中で、必ず直面するであろう「障害」への向き合い方についての事例を説明します。

■ 前提

ローンチしたサービスを保守運用していく上で、インシデント管理は非常に重要です。
インシデントばかりでサービスの稼働率が低いと自然とユーザも離れていってしまいます。
ここでは、障害を起こさないためのインシデント管理ではなく、障害を早く復旧する方法としての「障害管理」の方法を記載したいと思います。

■ 障害訓練について

障害訓練とは端的に言うと
**「インシデント対応者以外の人が「障害シナリオ」をもとに意図的にシステムに障害を起こし、対応者がいかに早く障害を復旧させるかのプロセスを学習するプログラム」**です。

目的や学習するべき部分は下記になると考えられます。

原因追求のアプローチ改善
- 障害起因に対して、障害原因の箇所の「追求」から「発見」に至るまでのアプローチ方法を改善することで、全体を通した復旧までの時間を短縮する。
復旧までのアプローチ改善
- 障害原因の「発見」したら、いかにその障害を早く「復旧」させるかのアプローチの仕方を改善することで全体を通した復旧までの時間を短縮する。
報連相の粒度・質・タイミングの改善
- 報告をエスカレーションする必要がある場合は、どんな報告・連絡・相談をするべきかをある程度標準化することで全体を通した復旧までの時間を短縮する。

■ 障害訓練の実施の流れ

▼ 障害訓練の流れ

補足として障害訓練における目標復旧時間を定めて、その時間以内の復旧を目指すようにするとさらに緊張感が生まれると思います。

▼ 下記に障害訓練を実施するにあたる役割を記載します。

役割	説明
障害起因役	障害起因を起こす及び障害シナリオを作成する人
インシデント対応者	障害起因に対して、障害原因を探し復旧させる。(チーム)
プロセス記録役	障害訓練の最中にインシデント対応者がどういった行動を行なっていたかを詳細に記録する人

■ プロセス記録役は何を記録するのか。

障害訓練は、プロセス記録役が非常に重要です。ここで記録したプロセスをもとにどこを改善すればよいかが見えてきます。
ここでは障害対応中の**「会話のプロセス」及び「アクションのプロセス」**を記録することをオススメしています。
例えば、下記のほうな形です。

人	時間	プロセス
Aさん	10/28 10:00	〇〇より障害を検知しました。私のほうで調査に入ります。
Bさん(リーダー)	10/28 10:10	承知しました。対応お願いします。
監視ツール	10/28 10:20	障害対象ではないアプリケーションでエラー通知
Bさん	10/28 11:00	Aさん、状況どうでしょうか？
Aさん	10/28/11:20	障害原因を突き止められずに試行錯誤していた結果、他アプリケーションにも影響がでてしましました。
Cさん	10/28 11:00	Aさん、私のほうで15分前に障害原因を特定し、復旧作業に入っています。

上記のようなプロセスを取ることで、下記の問題点が可視化されます。

★Aさん、Cさんによる単独的な行動が可視化され報連相の粒度・質・タイミングの改善ポイントが見える。

上記の場合は、まずインシデント対応者のリーダーであるBさんが状況を詳細に把握して体制を組むべきと考えます。それから人的リソースがどのくらいいるかを判断し適切にインシデント対応者をアサイン、原因追求の分担を行うような流れがよいと考えます。

■ 振り返りについて

障害訓練が終わったら、関係者全員で振り返りを行うことを推奨しています。その場で行うことは下記です。

① 「会話のプロセス」及び「アクションのプロセス」の読み合わせをし、改善点を全員で出し合う。
② 復旧プロセスについての技術点議論を行う。障害起因役を中心にどうやったら早く復旧できる道筋があったかをインシデント対応者と議論します。

■まとめ

上記に書いたとおり、この取り組みをだいたい四半期に1度行うと形骸化せずに上にも書きましたが下記のような成果ができるとおもいます。

原因追求のアプローチ改善
復旧までのアプローチ改善
報連相の粒度・質・タイミングの改善

以上です。皆さんもぜひ障害訓練を行なってみてください。