- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
ここまで、運用の数字はどれも誰かが引いた線だと見てきました。今回はその線を引き直す材料の出どころ、つまり事故の記録の行き先を見ます。
まず結論
事故の記録を書く目的は、その1件を直すことだけではありません。同じ書式で溜めた記録を束ねると、個別の事故を超えた傾向が読めます。書式が、その後の読み方を決めます。
そのため記録に書く原因は、人の名前ではなく仕組みの名前になります。原因が1つとも限りません。SRE Book は root cause(s) と複数形を許す書き方をしています。
事故の記録(ポストモーテム)を、全社で同じ書式に揃える利点は何だと思いますか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
記録は、1件だけで読まれるのではない
事故の記録を書く理由は、ふつう「同じことを繰り返さないため」と説明されます。正しいのですが、書いたものの行き先まで含めると用途がもう1つあります。溜めて、数えることです。 SRE Workbook の付録は、この用途を明示しています。
At Google, we have a standard postmortem template that allows us to consistently capture the incident root cause and trigger, which enables trend analysis.
標準の書式があるから原因とトリガを一貫して記録でき、それが傾向分析を可能にする。書式が先で、分析が後です。付録は続けて、分析の使い道を書きます。
We use this trend analysis to help us target improvements that address systemic root-cause types, such as faulty software interface design or immature change deployment planning.
狙う先が systemic root-cause types — 仕組みとしての原因の型です。例に挙がる「設計の欠陥」と「手順の未成熟」は、どちらも仕組みの名前で、人の名前ではありません。
- ・左の行き先は1件で完結する。右の行き先は他の記録が要る
- ・右を使いたいなら、書く時点で欄を揃えておくしかない
右の行き先を知っていると、書くときの選択が変わります。自由文で状況を書けば左は満たせますが、右には乗りません。束ねられる形かどうかは、書いた瞬間に決まります。
実際に束ねた結果は、こう見える
付録は束ねた結果を2つの表で示します。数値は限定つきです。 原文は At Google と書き、標本を a sample of thousands of postmortems over the last seven years(自社の数千件)としています。件数はこれ以上書かれていません。
トリガ 割合Binary push 37%Configuration push 31%User behavior change 9%Processing pipeline 6%Service provider change 5%Performance decay 5%Capacity management 5%Hardware 2%
上位2つはどちらも「push」、つまり何かを配ったことがきっかけで、合わせて 68% です。
カテゴリ 割合Software 41.35%Development process failure 20.23%Complex system behaviors 16.90%Deployment planning 6.74%Network failure 2.75%
合計は 100% になりません。表題が Top five と宣言するとおり上位5つの表で、残り 12.03% の内訳は原文にありません。合計が 100% でない表では、集計漏れを疑う前に「全体の表か、上位の表か」を見ます。
見るべきは数値より分類の語彙です。Development process failure、Complex system behaviors、Deployment planning。人の役職も個人も出ません。この軸で数えられる形で書かれていたから、表が作れます。
SRE Workbook の付録が示す割合(binary push 37% など)を、自分の資料にどう引くのが適切ですか。
では、束ねられる形とは何か
条件は2つです。同じ欄があることと、欄に入る語彙が共有されていること。ここで効くのが、SRE Book 第15章の視点の置き方です。
When postmortems shift from allocating blame to investigating the systematic reasons why an individual or team had incomplete or incorrect information, effective prevention plans can be put in place.
調べる対象は、当人やチームが incomplete or incorrect information(不完全または誤った情報)を持っていた systematic reasons(仕組み上の理由)です。基準がそのとき何が見えていたかに置かれます。
この視点は、集計できる語彙を生みます。「配布先の一覧が古い表を指していた」はどこに情報が無かったかの記述で、設計の欠陥や手順の未成熟という分類に乗ります。「注意が足りなかった」は乗りません。
もう1つ、見落とされやすい点があります。原因は1つと決まっていません。
箇所 原文の表記定義文 the root cause(s)目的の記述 all contributing root cause(s)段落冒頭 the contributing causesレビュー基準 the root cause
定義文と目的の記述は、どちらも括弧つきの複数形です。とくに all contributing root cause(s) は寄与した原因を全部という書き方で、原因を1つに絞る作業は記録として求められていません。
同じ事故を、2通りに書き残す
架空の例です。設定の配布後、一部の利用者が画像を読めなくなりました。
書き方①(その1件を直すために書いた記録)
原因: 配布した設定に誤りがあった。対策: 配布前の確認を徹底する。
間違ってはいませんが、束ねても何も生みません。「誤りがあった」は分類の語彙でなく、「徹底する」も仕組みの変更ではないからです。
書き方②(束ねられる形で書いた記録)
トリガ: 設定の配布。寄与した原因(複数): ①配布対象の絞り込みが全体と同じ画面で行われ、適用範囲が確認できなかった(設計の欠陥) ②配布後に画像取得の失敗率を見る画面が無く、利用者の報告まで検知されなかった(観測の欠落) ③段階配布の手順が文書化されていなかった(手順の未成熟)。
こちらは原因の欄に分類語が入り、それぞれが「何が見えなかったか」の記述です。30件溜まれば、書き方②は「設計の欠陥が何件」と数えられ、書き方①は数えられません。
記録に「根本原因: 担当者が設定値を誤った」とだけ書いた場合、束ねたときに何が起きますか。
事故の記録を束ねる
1件の記録からは、その事故の原因しか読めません。同じ分類語の記録が数千件溜まると、どの型が繰り返し現れるかが読めます。分類語が揃っていなければ後から数え直せません。
枚数 読めること1件 この事故で何が起きたか数十件 同じ分類が繰り返されているか数千件 分類ごとの割合(付録Cの表)
1本の応答時間を束ねる(第13期)
1本の応答時間からは、その1本が速かったか遅かったかしか分かりません。多数を集めて分布で見ると、遅い側がどれくらいの割合かが読めます。記録していない時間帯は後から補えません。
本数 読めること1本 この1本が何ミリ秒か数十本 ばらつきがあるか数千本 分布の形と上位側の位置
事故の記録と、応答時間の測定値。まったく別のものに見えますが、共通する構造は何でしょうか。
「1件では判断できないが、多数あれば判断できる」が両方にあります。集め終わってから軸を決められるでしょうか。
この章のまとめ
- 事故の記録には行き先が2つある。この1件を直すことと、束ねて数えること。後者は書式が揃わないと成立しない。
- SRE Workbook の付録は、標準書式が原因とトリガの一貫した記録を可能にし、それが
trend analysisを可能にすると書く。狙う先はsystemic root-cause types。 - 付録の数値は At Google の 2010–2017 の標本。表 C-2 は上位5つで合計 87.97%(残余あり)。一般の内訳としては引けない。
- 分類できる語彙は、その時点で何が見えていたかを基準に書くと出てくる。
- 原因を1つに断定しない。 原文は
root cause(s)/all contributing root cause(s)と複数を許す。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「根本原因は必ず1つに絞って書く」という指示の評価として、最も適切なものはどれですか。
用語集(4語)
- ポストモーテム
- 事故の記録。SRE Book 第15章は、事故とその影響・とった対応・the root cause(s)・再発を防ぐ追跡行動の記録と定義する。書式を揃えると束ねて数えられる。
- トリガ (trigger)
- 事故が表面化するきっかけとなった出来事。付録では binary push / configuration push などが挙がる。根本原因カテゴリとは別の軸で、同じ事故が両方の表に数えられる。
- systemic root-cause types
- SRE Workbook の付録の語。仕組みとしての原因の型。例は faulty software interface design(設計の欠陥)と immature change deployment planning(手順の未成熟)。人ではなく仕組みの名前。
- 傾向分析 (trend analysis)
- 溜まった記録の集合から、繰り返し現れる型を読み取ること。付録は、標準書式で原因とトリガを一貫して記録することがこれを可能にすると述べる。