組織的なインセンティブ
理想を言えば、上層部は効果的なポストモーテムについて、支援し奨励するべきです。この章では、組織が健全なポストモーテムの文化を動機付けする方法を説明します。文化の失敗を示す危険信号に注目し、それに対しての解決策を提案します。また、ポストモーテムのプロセスを合理化・自動化するためのツールとテンプレートも提供します。
非難のない振る舞いをモデル化し、それを守らせる
エンジニアリングリーダーは、ポストモーテムの文化を適切に支援するため、一貫して非難の伴わない振る舞いを実践し続けることで範を示すべきです。そしてポストモーテムの議論のあらゆる側面において、非難が行われないことを奨励するべきです。組織内で非難の伴わない振る舞いを守らせるには、いくつかの具体的な戦略があります。
非難の伴わない言葉を使う
非難が伴う言葉遣いはチーム間の共同作業を妨げます。以下のシナリオについて考えてみましょう。
[シナリオ]
SandyはサービスFooについてのトレーニングをしていなかったため、特定の更新コマンドをどのように実行するかわからなかった。
それに対応の遅れは最終的にサービス停止を長引かせた。
[メッセージ: Jesse(SRE) -> Sandyのマネージャ]
「あなたはマネージャです。みんながトレーニングを終了したことを確認していないのはなぜですか。」
このやりとりには、受信者を防御的な思考にさせてしまうような質問が含まれています。以下がよりバランスの良いメッセージです。
[メッセージ: Jesse(SRE) -> Sandyのマネージャ]
ポストモーテムを読んだところ、オンコール担当が、より迅速にサービス停止を解決できるようにするための重要なトレーニングをしてなかったようです。
オンコールローテーションに参加する前にこのトレーニングを完了する必要があったかもしれません。また 「対応の手が止まってしまいそうな時は、迅速にエスカレーションするように」と伝えておくことも出来たと思います。
結局のところ、エスカレーションは罪ではありません。特にそれが顧客の苦痛を軽減するのに役立つならばなおさらです！
長期的には、トレーニングにあまり頼るべきではありません。感情的になっている状況ではトレーニングで学んだ内容は容易に忘れられるものです。
ポストモーテムの署名(Author)にすべてのインシデント参加者を含める
ポストモーテムが単独で、または単一のチームによって作成されていると、サービス停止の主な要因を見逃してしまいがちです。
フィードバックを集める
ポストモーテムのための明確なレビュープロセスとコミュニケーション計画は、組織内で不適切な言葉や見方が広がるのを防ぐのに役立ちます。推奨される構造化レビュープロセスについては、 ポストモーテムのチェックリストの項 を参照してください。
ポストモーテムがもたらす結果に報いる
上手く書かれ、それを元にアクションが実行され、広く共有されてる。このようなポストモーテムは、積極的な組織変更を推進し、サービス停止が繰り返されることを防ぐための効果的な手段です。
ポストモーテムの文化を動機づけるためには、以下のような戦略があります。
アクションアイテムの完了に対して、報酬を与える
関連するアクションアイテムを完了させることではなく、ポストモーテムの文章を書くことに対してエンジニアに報酬を与える場合、クローズされないポストモーテムが多く生まれるリスクがあります。ポストモーテムを書くことと、アクションを実行することの間で、バランスよく動機付けが働くようにしましょう。
「組織にもたらすポジティブな変化」に報いる
ポストモーテムを組織全体に影響を与える機会として提示することで、ポストモーテムの手法の広範な実施を奨励することができます。このような広範囲の影響は、ピアボーナス、業績評価への加点、昇進などで報いられます。
「信頼性の向上」にスポットライトを当てる
時間が経つにつれて、効果的なポストモーテムの文化は、より少ない停止時間と・より信頼できるシステムにつながります。
その結果、チームはインフラストラクチャのパッチ適用ではなく、機能実現のベロシティーの向上に集中できます。
レポート、プレゼンテーション、およびパフォーマンスレビューで信頼性の改善点に光を当てることで、内発的動機付けを高めることができます。
(訳者のメモ(揚げ足取り): 「褒める・承認する」ことって外発的動機づけでは？)
ポストモーテムの所有者を、指導者として扱う
電子メールや会議を通してポストモーテムを祝福したり、ポストモーテムの著者に聴衆に学んだ教訓を教える場を与えることによって、称賛されるべき行動をしたことを公的にアピールすることが出来ます。
失敗の種類とその回避について「専門家」として所有者を設定することは、同僚から承認されたい欲求を持つ多くのエンジニアにとって、やりがいのあることです。たとえばこんなことを誰かが言うのを聞くかもしれません。
「サラに話しかけてください。彼女は今エキスパートです。彼女はそのギャップを修正する方法を考え出したポストモーテムを共著したばかりです！ 」
ゲーミフィケーション
システムの弱点の修正や信頼性の向上など、達成感や大きな目標に向かっての進捗状況によって動機付けがある人もいます。
これらの個人にとっては、ポストモーテムの行動項目のスコアボードやバーンダウンがインセンティブになるでしょう。
Googleでは、年に2回「FixIt」週を開催しています。最もポストモーテムのアクションアイテムを完了したSREは、感謝の気持ち・そして自慢する権利を表す、小さなトークンを受け取ります。
図10-3は、ポストモーテムのリーダーボードの一例です。
オープンにポストモーテムを共有する
組織内で健全なポストモーテムの文化を維持するためには、ポストモーテムを出来るだけ広く共有することが重要です。
以下に紹介する方法はいずれも効果的です。
組織全体にお知らせをシェアする
内部のコミュニケーションチャネル、電子メール、Slackなどで、ポストモーテムのドラフトが利用可能になったことを発表しましょう。
定期的な社員全員参加の会議があるなら、興味を集めた出来事について、最新のポストモーテムを共有しましょう。
チームを跨いだレビューを実施する
チームを跨いだレビューを実施しましょう。
障害に立ち会ったチームはインシデントを一通り説明していきます。他のチームは質問をしたり、そのインシデントを追体験することを通じて学んでいきます。
グーグルでは、いくつかのオフィスに置いて、すべての従業員が参加可能な、非公式のポストモーテム読書クラブがあります。
さらに、開発者、SRE、および組織のリーダーによる機能横断型のグループが、ポストモーテムプロセス全体をレビューします。これらの人々は、ポストモーテムプロセスとテンプレートの有効性を確認するために毎月会います。
トレーニングを開催する
新しい技術者を訓練するときは、不運の輪を使用してください。
エンジニア達はそのポストモーテムに出現する役割のキャストとなり、以前のポストモーテムを再現します。そのポストモーテムの実際のインシデント指揮官も出席し、経験を可能な限り「本物」に近づけるためのを手助けをします。
インシデントとサービス停止を毎週報告する
過去7日間のインシデントとサービス停止を含むサービス停止レポートを、毎週作成しましょう。
レポートはできるだけ広い範囲の読者に、共有しましょう。
毎週のサービス停止の記録を編成し、定期的にインパクトが大きいものだけを集めたレポートを作成し、それも共有しましょう。
ポストモーテム文化の失敗への対応
ポストモーテムの文化の崩壊は必ずしも明白ではないかもしれません。
以下は一般的な失敗パターンと、それに対する推奨の解決方法です。
失敗パターン: ポストモーテムプロセスに関わるのを避ける傾向
ポストモーテムプロセスから距離を置く行動は、組織のポストモーテム文化が失敗している兆候です。たとえば、SRE Director Parkerが次の会話を聞いたとしましょう。
SWE Sam：うわー、あの巨大な爆発について聞いたことがありますか？
SWE Riley：ええ、それはひどかったです。彼らは今ポストモーテムを書く必要があるでしょう。
SWE Sam：うわー！関わっていなくて良かったです。
SWE Riley：ええ、アレが議論される会議には参加したくありません。
解決策
視認性の高いポストモーテムが非難の言葉でレビューされないことを確実にしましょう。
質の高い事例を共有し、関与した人々がどのように報いられたかを議論することで、個々人のポストモーテムへのエンゲージメントをさらに高めることができるでしょう。
失敗パターン: 文化を強化できない
上級管理職が非難の伴う言葉を使用しているときに対応するのは難しい場合があります。
サービス停止についての会議での上級リーダーが以下の発言をしたらどうなるでしょうか。
VP Ash：
私たちは非難のない言葉を使うべきだと私は知っていますが、ここは安全な場所です。
誰かが前もってこれが悪い考えであることを知っていたにちがいない。それでなぜあなたはその人に耳を傾けなかったのですか？
解決策
話をより建設的な方向に動かして、聞き手に与えるダメージを軽減しましょう。
例えば：
SRE Dana：
うーん、全員が最善の意図を持っていたのはわかっています。
非難のない議論を続けるために、気づけた危険信号があったか・それが見過ごされたかもしれない理由があったのかを、一般論的に考えてみましょう。
個人は誠意を持って行動し、利用可能な最善の情報に基づいて決定を下します。
責任を明確にすることよりも、誤解を招く情報の原因を調査することの方が、組織にとってはるかに有益です。（あなたがアジャイルの原則に遭遇したことがあるなら、これはあなたにはおなじみのはずです。）
失敗パターン: ポストモーテムを書くための時間がない
質の高いポストモーテムを書くには時間がかかります。チームが他のタスクで過負荷になると、ポストモーテムの質が低下します。完了しないアクションアイテムを伴う低品質なポストモーテムは、インシデントの再発の可能性の高めてしまいます。
ポストモーテムは、あなたが将来のチームメンバーへの手紙です：あなたが誤って将来のチームメイトに悪い教訓を教えることがないように、一貫した品質を保つことは非常に重要です。
解決策
ポストモーテムの作業に優先順位を付け、ポストモーテムの完了を追跡してレビューしましょう。チームが関連するアクションを実行するのに、十分な時間を取れるようにしましょう。ツールとテンプレートで説明しているツールは、これらの作業に役立ちます。
失敗パターン: 同じようなインシデントが繰り返されている
解決策
過去のインシデントと同じようなインシデントが発生している場合は、問題をさらに深く掘り下げる必要があります。
次のような質問をすることを検討してください。
- アクションアイテムを完了するのに時間がかかり過ぎていませんか？
- 機能実現の速度と信頼性の修正のバランスが取れていますか？
- そもそも正しいアクションアイテムが上がってましたか？
- リファクタリングを怠った結果、失敗しがちなサービスになってしまったのではないですか？
- 深刻な問題について、場当たり的に対応していませんか？
体系的なプロセスや技術的な問題を発見した場合は、一歩引いた視野から全体的なサービスの健全性を検討する必要があります。
類似したインシデントのポストモーテムの共同作業者と協力し、再発防止のための最善の行動方針について話し合いましょう。
ツールとテンプレート
一連のツール・テンプレートを使うと、ポストモーテムの作成・関連データの管理を容易になり、ポストモーテムカルチャーをより効果的にすることができます。
このようなツール・テンプレートを、Googleや他の企業からがいくつも提供しています。
ポストモーテムのテンプレート
テンプレートを使用すると、完全なポストモーテムを書いて組織全体で共有するのが簡単になります。標準化されたフォーマットを使用することで、ドメイン外の読者からも、ポストモーテムをより把握しやすくなります。
必要に応じて、テンプレートをカスタマイズできます。たとえば、チーム固有のメタデータを取得すると便利な場合があります。データセンターチームだったらハードウェアの製造元/モデル、モバイルチームだったら影響を受けたAndroidのバージョンなどです。
チームの成熟し、より洗練されたポストモーテム書けるようになっていくのに併せて、テンプレートをカスタマイズしていきましょう。
Googleのテンプレート
Googleは、Google Docs形式のポストモーテムテンプレートのバージョンを共有しています。
Google社内では、共同編集とコメントによるコラボレーションを容易にするため、主にGoogle Docsを使用してポストモーテムを作成します。
私たちの社内ツールの中には、ポストモーテムの記述をより簡単にするために、このテンプレートにメタデータを事前設定するものがあります。
Google Apps Scriptを利用して署名の一部の自動化・大量のデータを特定のセクションや表にキャプチャして、分析のためにデータを解析しやすくします。
(訳者メモ: ↑のリンク見てもチェックリストしかなかったんだが...)
その他のテンプレート
Google以外の会社・個人がポストモーテムのテンプレートを公開しています：
- Pager Duty
- An adaptation of the original Google Site Reliability Engineering book template
- A list of four templates hosted on GitHub
- GitHub user Julian Dunn
- Server Fault
ポストモーテムツール
これを書いている時点では、Googleのポストモーテム管理ツールは社外では利用できません（最新の更新については私たちのブログをチェックしてください）。
しかし、私たちのツールがどのようにポストモーテムの文化を促進しているかを説明することはできます。
ポストモーテムの作成
当社のインシデント管理ツールは、インシデントに関する有用なデータを大量に収集して保存し、そのデータを自動的にポストモーテムに反映します。自動で記入されるデータの例は次のとおりです。
- インシデント指揮官およびその他の役割
- 詳細なインシデントタイムラインとIRCログ
- 影響を受けるサービスと根本原因サービス
- インシデントの重大度
- インシデント検出メカニズム
ポストモーテムのチェックリスト
著者がポストモーテムが適切に行われていることを確認するために、重要なステップ全てを順番にチェックするようなポストモーテムチェックリストが提供されています。以下はチェックリストの一部です:
- インシデントへの影響の完全な評価。
- アクションアイテムの計画的に推進するための、十分に詳細な根本原因分析。
- アクションアイテムがサービスのテックリードによって検査および承認されていることの確認。
- 広い範囲へのポストモーテムを共有。
完全なチェックリストはこちらにあります。
ポストモーテムの保管
私たちはレクイエムと呼ばれるツールにポストモーテムを保存しているので、どんなGooglerでも簡単に見つけることができます。
私たちのインシデント管理ツールは自動的にすべてのポストモーテムをレクイエムにプッシュするので、組織内の誰もが、皆が見える場所にポストモーテムを投稿することができます。レクイエムは個々のポストモーテムからメタデータを解析し、それを検索、分析、レポートに利用できるようにしています。
ポストモーテムのフォローアップ
私たちのポストモーテムはレクイエムのデータベースに保存されています。ポストモーテムに書かれたアクションアイテムはすべて、私たちの一元化されたバグトラッキングシステムにバグとして記録されます。そうすることで、各ポストモーテムのアクションアイテムの完了をモニタリングできるようにしています。
このレベルの追跡を行うことによって、サービスを不安定にするようなアクションアイテムが放置されないことを確実にしています。図10-4は、私たちのツールのポストモーテムのアクションアイテム監視のモックアップです。
ポストモーテム分析
私たちのポストモーテム管理ツールは、データベースに分析のための情報を保存しています。チームはそのデータを使用して、ポストモーテムの傾向に関するレポートを作成したり、最も脆弱なシステムを特定したりすることができます。これによって気づきにくい不安定性の根本原因・インシデント管理の機能不全を明らかにすることができます。
たとえば、図10-5は、分析ツールを使用して作成されたチャートを示しています。これらのグラフは、1組織あたりの1か月あたりのポストモーテム数、インシデントの平均期間、検出時間、解決時間、および影響範囲などの傾向を示しています。
その他の業界ツール
以下はポストモーテムの作成、整理、および分析に役立つ、サードパーティ製のツールです。
ポストモーテムを作成するすべてのステップを完全に自動化することは不可能です。しかしポストモーテムテンプレートとツールを使用するとプロセスがよりスムーズに実行されます。これらのツールが使える時間を増やしてくれるので、ポストモーテムの作者は根本原因分析・アクションアイテムの計画など、ポストモーテムの重要な側面に集中することができます。
結論
ポストモーテムの文化を育てるために継続的な投資していくことで、サービス停止は少なくなり、全体的なユーザーエクスペリエンスは良くなり、そして推進者は多くの信頼を得ることができます。この章のプラクティスを一貫して適用することで、システム設計が改善され、ダウンタイムが短縮され、エンジニアはより幸せになることができます。もし最悪の事態が起こったり、インシデントが再発したときにも、よりダメージを小さく抑え、より早く回復し、さらにそこからサービスを強化し続けるためのデータを多く得ることができるでしょう。