「チームは重大インシデントと既に何時間も闘っており、あなたの調査は徐々に煮詰まっていきます。でもついにあなたは問題を特定することに成功し、グラフは改善し始めます。すべてのシステムが正常に戻ったとき、誰もがほっと息をついて、レスポンスコールを止め、そして再びこのインシデントについて考えることはありませんでした」。

…あるいはそう考えただけかもしれませんが。

先に進む前に、チームがやらなければならないことがもう1つあります。事後検証です。

なぜか？

事後検証は継続的に改善を進める文化を根付かせるのに役立つので、重要なのです。

事後検証なしでは、あなたとあなたのチームは自分たちがしていた正しい行いや、改善できる点、そして最も重要なこととして、何度も何度も何度も同じ間違いをしない方法を学ぶ機会を逃します。うまく設計された、責任を問わない事後検証は、あなたのチームがインフラとインシデントレスポンスのプロセスを改善するのを助けます。

ここで当社が効果的な事後検証（Postmortems）の実施方法に関する包括的なガイドを発表したことをお知らせしたいと思います。

このガイドのように、文化の変化のニュアンス、徹底した分析の実行方法の詳細、および失敗についての冷静で深い会話を促進するために必要な独自のスキルを網羅した資料は、他にありません。これらの概念がなぜ重要であるかを説明し、それらを実行することに関連する課題を説明し、そして責任を問わない事後検証を行うための実行可能な手順を提供します。

まだ事後検証をしたことがない人には、このガイドは、ご自分の組織に新しいプロセスを導入するのに必要とされる知識と戦略を提供します。事後検証の経験を持つ方には、自然任せでは陥りがちな非難の応酬に対処する方法、より深いインシデント分析のための新しい問い合わせの指針、事後検証の会議をより良く活用する方法、そして既存のプロセスを改善するための方法をたくさん学べるでしょう。

インシデントに対応している間は、チームは100％サービスの復旧に集中しています。 彼らは何かを最適な形で行う方法を考えたり、インシデントの原因を深く掘り下げることに時間と精神力を浪費することはできませんし、またそうすべきではありません。それが、事後検証の問題が不可欠である理由です。問題がユーザーに影響を及ぼさなくなったときに、事後検証の問題を反映するための平和的な機会を提供します。事後検証のプロセスでは、集中力を高め、学習の文化を浸透させ、そうでなければ失われる可能性のある改善の機会を特定します。

ちょっと待って、インシデントの事後検証って何ですか？

インシデントの事後検証（Incident postmortem）は色々な別名を付けて紹介されています。次のどれかならご存知かもしれません。

• ラーニングレビュー
• アクション後のレビュー
• インシデントレビュー
• インシデントレポート
• ポストインシデントレビュー
• 根本原因分析（またはRCA：Root Cause Analysis）

事後検証とは、その根幹をなすもので、インシデントにつながった状況要因、インシデントに対応するために取られたステップ、そしてインシデントが2度と起こらないようにするために計画された作業を詳細に説明する文書です。事後検証プロセスには、検証結果について話し合い、それらの学習結果をより幅広い組織や顧客と共有するための会議も含まれます。

大きなインシデントを解決した後、その経験がまだみんなの心に新鮮な間に事後検証をすることを考え始めるべきです。PagerDutyでは、重大な問題が発生してから5日以内に事後検証の処理を済ませています。インシデントの解決がその発生時に最優先事項になるのと同様に、事後検証の完了は計画された作業よりも優先されます。事後検証の延期は、インシデントの再発を防ぐはずの重要な学習の開始を遅らせます。

責任を問わない事後検証

ITの専門家として、私たちは障害が複雑なシステムで起こることを理解しています。それは避けられません。そして、それが起こったときの失敗への対応は重要です。インシデントを引き起こしたとして個人を非難し罰したいという衝動は、将来のインシデントを防ぐために必要な知識の共有を阻むという意図しない効果をもたらします。エンジニアは、インシデントが発生したときには、非難を恐れて発言を躊躇します。この沈黙は、Ackまでの平均時間と解決までの平均時間を増大させ、インシデントの影響を拡大させます。

事後検証プロセスがシステムの改善と学習をもたらすためには、人的エラーを、体系的な問題が起こした症状として扱い、原因そのものだとは考えないようにする必要があります。ソフトウェア開発の複雑なシステムでは、様々な条件が相互作用して失敗を起こします。事後検証の目標は、どのような体系的要因がインシデントを引き起こしたのかを理解し、この種の失敗が再発するのを防げる行動を見つけ出すことです。

誰がミスを犯したかではなく、どのようにミスが犯されたかという点をブレずに検討し続けるべきです。これはエンジニアが罰を受ける恐れを排除することにより、起こったことについての客観的な説明を与え、事後検証の作業を正しく進めるために、Etsy（責任を問わない事後検証の先駆者です）のような多くの先行する組織に活用されている重要な点です。

継続的な改善の文化を望むことに賛成するのは簡単ですが、学ぶために必要となる、責任を問わない検証を実施することは困難です。失敗の本質の驚くべき性質は、それを素直に理解しない方向に人間を反応させます。情報を処理するとき、人間の心は無意識のうちに正確さよりタイムリーに対応しようと近道を取ってしまい、時々誤った結論を導きます。このガイドでは、事後検証分析を妨げる多くのCognitive biasesとそれらを克服するための戦略について詳しく説明しています。

あなたが次に重大なインシデントに遭遇したとき、あなたの対応は事後検証作業が済むまでは終わらないということを忘れないでください。大規模なインシデント対応は時々苦痛ですが、それはまたあなたのシステムとプロセスを学びそして持続的な改善をする素晴らしい機会になります。

私達の新しいガイドを見て事後検証プロセス（Postmortem process）に含まれるステップについての詳細を知ってください。また私たちは、Communityフォーラム（訳注：PagerDutyのサイトに飛びます）で、責任を問わない事後検証を実践するためにあなたが考えるテクニックについてお聞きしたいと思っています。

本記事は米国PagerDuty社のサイトで公開されているものをDigitalStacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。