Twitter
Facebook
Hatena
「ポストモーテム」をご存じですか?~ インシデントはプロジェクトの問題である ~

はじめに

世の中では日々新しいITサービスが提供され、その機能が改善され、私たちを取り巻く環境は目まぐるしい進化を続けています。一方、IT環境が拡大しあらゆるシステムがつながっていくことで、サイバー攻撃などのセキュリティ事故や、システム障害、部品の故障などによるインシデントも日々多発しています。
システムやサービスにインシデントが発生した時に重要なことは、インシデントを記録し、再発防止策を検討し、対策を実施することです。

ポストモーテムは事後検証と訳されます。インシデントを繰り返さないためのプロセスです。Google社が提唱するSRE(サイトリライアビリティエンジニアリング:サイト信頼性エンジニアリング)はシステム管理とサービス運用についての手法の1つですが、ポストモーテムについて次のように記載されています。
「ポストモーテムの概念は、IT業界ではよく知られています。
ポストモーテムは、インシデントとそのインパクト、その緩和や解消のために行われたアクション、根本原因(群)、インシデントの再発を避けるためのフォローアップのアクションを記録するために書かれるものです。」
出典:O’REILLY 「SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム」 15章ポストモーテムの文化:失敗からの学び

SRE の他にDevOpsというシステム開発の手法があります。DevOpsは、開発(Development)担当者と運用(Operations)担当者が連携してシームレスに作業することで、システム開発がスムーズかつスピーディに進む手法です。DevOpsは「何をすべきか」を重視し、SREは「どうすべきか」を重視します。 つまり、DevOpsは目的、SREは方法に着目した開発手法だといえるでしょう。DevOpsやSREなどのシステム開発手法において、ポストモーテムは非常に重要です。

では、インシデントに備えてポストモーテムを作成するにはどうしたらよいでしょうか。どのような作業が必要なのか、具体的に説明します。

ポストモーテムの作成

次の手順でポストモーテムを作成します。

1)インシデント管理ツールの準備
2)インシデントの記載
3)ポストモーテムのレビュー
4)対策の完了確認

1)インシデント管理ツールの準備

 インシデントに対するポストモーテムを記載するためのインシデント管理ツールを準備します。
 誰でも簡単に記載、参照できるRedmineやJIRAなど、チケット管理ツールの利用が一般的です。

2)インシデントの記載

 インシデント発生時に、発生したインシデントの状況や原因、対策などのポストモーテムをインシデント管理ツールに記載します。漏れなくインシデントが記載されるようにルール化しておきます。

記載する項目
 ①インシデントの状況
 ②インシデントのインパクト
 ③復旧や解消のための対策
 ④インシデントの原因
 ⑤インシデントの再発防止策

 モニタリングツールや監視ツールと連携し、Datadogなどを用いて自動で登録する方法もあるので、これらを活用するとよいでしょう。

3)ポストモーテムのレビュー

 定期的にインシデント管理ツールに記載したポストモーテムをレビューします。
 レビューでの意見は尊重し、建設的に議論を行います。
 レビューは、参加者が多いほど、情報の共有や意識の向上につながります。

4)対策の完了確認

 レビュー時に再発防止策のステータスを確認し、対策、再発防止策が実施され完了したことを確認できた場合に、当該インシデントのポストモーテムをクローズとします。
 正しい対策や再発防止策であっても、実施され完了しなければ再発してしまうかもしれません。

原因究明、再発防止のために重要なこと

ポストモーテムを作成し、インシデントの対策・再発防止策を検討する際に重要なことが2つあります。

1)根本的な原因を追求する
2)根本的な原因をヒューマンエラーにしない

1)根本的な原因を追求する

根本的な原因には、「なぜなぜ分析」が有効です。
なぜなぜ分析は、「なぜ?」という問いを繰り返していくことで、問題の根本原因を探る分析方法です。
例えば、以下のようなインシデントが発生した時の原因を分析してみましょう。

(状況)デイリーのバッチ処理でエラーが発生し処理が途中で止まっていたが、トラブルに気付かなかったため数日間処理が行われないままになっていた。

(問)なぜ、バッチ処理が途中で止まったままになったのか?
→(原因)バッチ処理の中で対向システムにアクセスするが、システムでエラーが発生したためレスポンスが返ってこなかった。


(問)なぜ、レスポンスが返ってこないとバッチ処理が止まったままの状態になるのか?
→(原因)タイムアウトの処理が実装されていなかったため、レスポンスを待ち続けた。
→(対策)タイムアウトの処理を実施する。
→(再発防止策)原因と対策を横展開し、他の処理を見直す。


(問)なぜ、処理が止まっていることに気付かなかったのか?
→(原因)バッチ処理が止まったままになったため、翌日はバッチ処理が二重起動となり失敗していたが、エラーが運用保守担当に通知されなかった。
→(対策)二重起動の失敗を通知する処理を追加する。
→(状況)二重起動の失敗を通知する処理を追加できない。
→(問)なぜ、二重起動の失敗を通知する処理を追加できないのか?
   →(原因)バッチ処理の状態を検知する機能がなかった。
   →(対策)バッチ処理の状態を検知する機能を追加する。

このようにして根本原因および対策を探ります。

2)根本的な原因をヒューマンエラーにしない

 根本的な原因は、そのインシデントに関係した人ではなく、開発における仕組み、システム、プロジェクト管理の問題と考えるとポジティブです。

例えば、以下のような状況を考えてみましょう。
ある人が、花瓶の水を換えようとして落として割ってしまいました。不注意で花瓶を割ってしまい損失を発生させた直接の原因は、ある人の不注意、ヒューマンエラーです。しかし、花瓶には生花が活けられていて一定期間で水を換える必要があり、水を換えるには水場まで花瓶を持って移動しなければなりませんでした。花瓶は丸くて滑りやすく落としたら割れてしまうようなガラス製でした。花瓶の水を換えるのが他の人だったとしても、花瓶を落として割ってしまう可能性は十分にあったでしょう。
では、根本的な原因は何だったのでしょう。花瓶を落としてしまった人の不注意ではないようです。目に見える直接的な原因だけでなく、花瓶の水を換える作業や花瓶自体の材質などについても目を向け、問題とし、根本的な原因を建設的に分析して対策を検討することが大切です。

再発防止の考え方

再発防止策のパターンとしては主に以下の4つがあげられます。

1)絶対にインシデントを発生させない対策
2)インシデントが発生する可能性を減らす対策
3)インシデントが発生した時にすぐ気付くことができる対策
4)インシデントが発生した時に被害を小さくする方法

1)絶対にインシデントを発生させない対策

 同様のインシデントを100%発生しなくなる対策です。
 例えば以下のような対策です。
 ・対象のシステムやサービスをクローズし、やめてしまう。
 ・現在の方法をやめ、違う方法でシステムやサービスを実現する。

 現実的ではない場合も多いですが、同じインシデントを絶対に発生させないことが可能になります。

2)インシデントが発生する可能性を減らす対策

 インシデントの発生はゼロにはならないが、発生の可能性を減らす対策です。
 インシデントの発生率を下げるほど、対策の効果が大きくなります。
 
例えば以下などです。
・開発工程での対策
 開発時には、問題となる実装を入れないことが大切です。レビューでの工夫や開発者共通のセルフチェック項目の作成、もしくは静的な解析ツールなどによって自動的に問題が検出できるように対策します。
・試験工程での対策
 試験工程では、問題を検出できるようにすることが大切です。問題が発生した際に試験観点に追加し蓄積しておき、その蓄積された試験観点で試験項目を作ることで精度を向上させ、試験工程での検出率を向上させます。

3)インシデントが発生した時にすぐ気付くことができる対策

 モニタリングや監視が有効です。
 インシデントの発生事象を早い段階で異常として検知し、素早く保守担当者に通知します。発生したインシデントにスピーディに対応できるようになり、問題の影響範囲をなるべく狭くすることにつながります。
  検知の方法はシステムごとに検討が必要ですが、例えばログなどを活用することで、一定数のエラーや、データ上で通常ではありえない状態を検知する方法があります。

4)インシデントが発生した時に被害を小さくする方法

 インシデントが発生した時に素早く対応することで被害を最小化できます。
 対応に人が介在すると時間がかかるため、ある程度の影響が出てしまいます。これを自動化することでインシデントの発生から対応までの時間を短縮できるので、被害の拡大範囲を抑えることにつながります。


 例えば、一時的なネットワークの停滞でシステムエラーが発生した場合に、一定間隔をあけてリトライすることで問題を自動的に復旧できます。
 また致命的なエラーが発生した時に、自動でシステムを切り離すことで影響を最小化することも可能です。
 これは保守の観点でとても重要な対策です。

まとめ

本コラムでは、ポストモーテムについてご紹介しました。インシデント発生時に、直接的な原因だけに囚われることなく、状況や環境から根本的な原因を分析し、対策して、ポストモーテムをきちんと作成し活用することが、インシデントの再発防止になり、中長期的に安定したシステム運用にもつながります。

ポストモーテムを活用してみてはいかがでしょうか?

ポストモーテムは運用保守の効率化だけでなく、
お客様のサービス・システムの価値向上に大きく貢献致します

富士ソフトBizDevOps

 

 

この記事の執筆者

中村 和弘Kazuhiro Nakamura

システム
インテグレーション
事業本部
ビジネスソリューション部 第1技術部AUグループ
主任 / フェロー

BizDevOps サービス成長促進