ポストモーテムの文化 - エムティーアイエンジニアリングブログ

Dockerおじさんの西川です。ここのところ、Lambdaばかり使っていてDockerとの触れ合いが足りていないと感じる今日このごろです。

さて、今日は近年の技術書で最も良書じゃないかと思われるSRE本からポストモーテムについてポエムりたいと思います。

前口上

SRE本にはGoogleの各種サービスの信頼性を支える運用エンジニアの文化、プロセス、具体的なテクニックが書かれています。これだけの有益な情報を体系化して公開してくださったGoogleのエンジニアの皆さんに足を向けて眠れません。（と言ってもGoogleエンジニアは世界中に居るので天空に足を向けるしかなくなってしまいますが…） SRE本はぜひ読んでもらいたいのですが、サックリと何が書いてあるか知りたい方は吉田真吾さんのブログエントリを同じShingoとしておススメします。

yoshidashingo.hatenablog.com

本題

ポストモーテム is 何？

ポストモーテムはプロジェクトマネジメントの文脈ではレトロスペクティブと同様に「振り返り」を意味しますが、SREの文脈ではいわゆる障害報告書を意味します。例えば次のようなものです。

ポストモーテムには次のような事が書かれます。

発生したこととその影響範囲
その緩和や解消のために行われたアクション
根本原因
再発防止策

一般的な障害報告書と同じですね。

ポストモーテムといわゆる障害報告書は何が違うのか

障害報告書というと苦い思い出がよぎる人が多いと思います。私もその一人です。アレを書くのは大変です。痛みを伴い、体力を削られます。ポストモーテムもそれは同じですが、なぜそんな思いをして書くのかという目的が障害報告書とポストモーテムでは違います。

	ポストモーテム	障害報告書
想定読者は誰か	身内のエンジニア	お客様
何のために書くのか	失敗から学ぶ	事業者としての説明責任

そう、SRE本の15章のタイトルにあるとおり失敗からの学びが目的であるというところが大きく異なっています。

事業者として平易な言葉でお客様に説明をすることは必要ですが、それ以上に求められるのは再発防止策であり、そのためにはエンジニアが自分たちのために深くツッコんだ議論が必要になります。その議論に必要な道具としてポストモーテムは存在します。したがってポストモーテムは非技術者向けにデフォルメした表現をするのではなく、技術者向けに正確な技術用語を用いて書くべきでしょう。

失敗からの学びに非難は要らない

冒頭でレトロスペクティブについて触れましたが、両者の本質的な価値観は組織を強くするための継続的改善という点で同じです。 組織を強くするというところがポイントで、そのためには建設的な議論が必要です。

以下SRE本からの引用です。

悪い行動や不適切な行動をもって特定の個人やチームを糾弾すること無く、インシデントに影響を及ぼした原因を特定することに集中しなければなりません。

大体において、やらかした張本人というのはやらかしたことを悔いています。それ以上に当人を責めて追い詰める必要があるのでしょうか。

エンジニアらしい改善とは

ミスをした人を叱って個人の能力を上げることも改善方法のひとつかもしれませんが、SREによる改善はこうです。

人を修正することはできませんが、システムやプロセスを修正して、複雑なシステムの設計やメンテナンスを行う際に、人々が正しい選択をすることをうまく支援することはできる

7章で述べられている自動化指向がこれを後押ししています。

7.1.2 プラットフォーム

<前略>
十分な人数によって同じ手順が実行されている場合とは違って、コード中のバグを修正するのは一度限りで済みます。人間に追加のタスクのやり方を指示するよりも、プラットフォームを拡張して追加のタスクを実行できるようにするほうが楽です。

そして、ポストモーテムとはサービスのどの部分をどうすれば改善できるのかを提起するものでなければならないと定義されています。

コラボレーションと知識の共有

書かれたポストモーテムは価値あるものですが、関係者が知恵を出しあって議論することそのものにも価値があったりします。ポストモーテムはエスケープゴートが黙々と書かされる罰ゲームではなく、関係者のコラボレーションの末に出来上がる集合知の結晶です。そのために、ポストモーテムを書くにあたって使われるツールには次のような特徴が求められます。（Googleの場合にはそれはGoogle Docsです）