9章 せっかくのインシデントを無駄にする
問題が発生した際に、あなたができることはいくつかあります。なぜ15ガロンでガス欠になったのかと、その理由を深く追求もできますし、「念のため5ガロン使うごとにガソリンを入れたほうが良いな」と考えることもできます。多くの組織では後者のような選択が行われており、ただただ驚くばかりです。
とりあえず対処療法、あるある。とはいえ、べき論に走って何も対策しないまま問題放置ってなるケースもよく見かけるので、言い方は相手によって選んでます。(98lerr)
SRE本でも ポストモーテム について触れられていたので、本書でも詳細がわかるのかな?っておもうと楽しみ。kyon_mm.icon とあるクライアントでポストモーテムって言葉が通じなかったのを思い出した。たしかにあんまり聞かないかも?インシデントレポートは聞くけど、ポストモーテムで言っていることと微妙に被らないこともあるなーなんておもったり。kyon_mm.icon
直訳するとインパクト強めの単語なので,使い所に悩んだことがありました (hayase)
9.1 良いポストモーテムの構成要素
それなりの規模のインシデントが発生すると、人々は責任のなすりつけ合いを始めます。
ここも、インシデントの話をする話始め方で苦労するところ。相手の性格を見て、問題の話から入るか、安全な場なのを意識づけしてから始めるかを選びます。(98lerr)
これめっちゃおもう。。。なんというかこういうのをやりがちな人ってある程度いるよなっておもっていてつらいkyon_mm.icon
この考え方は、システムの問題を個人の問題としてとらえてしまっています。トレーニングプログラムが不十分な場合、そのエンジニアを非難しても問題は解決しません。
問題を解消するのを手順とかフローとかで解決して「システムの問題として解決させてる」と思ってる状態だと、起きがちなのが「この仕組みを作ってるのになぜ使わない」という人への攻撃。攻撃してる本人はシステムの話をしてるつもりなので「その仕組みがより活用できる考えを話しましょう」とかに誘導していきたい。(98lerr)
+1 (hayase)
複雑な手順書作っても、いざという時読めない
非難する文化のもう一つの副作用は透明性の欠如です。誰も自分が犯したミスのために罰を受けることを望んでいません。
原因が判明していく中で自分が関与していたと分かるだけでも「罰」になるので,非難は不要だと感じています。(hayase)
わからないっていえば個人を非難してもいいと思っている人がいて、そういうのがよくないだぞっておもっているkyon_mm.icon
攻めてる人はアクションする人を決めて達成したいだけ(その中で一番問題への解像度の高い原因に怪人を指名している)だったりするけれど、言われる側は責められた感じがする
問題の原因に近い人たちは、アクション以外に報告とか根本の解消とかいっぱい抱えててそれどころじゃないことも
しかし、あなたがそのシステムの完全な専門家でもない限り、あなたのモデルには乖離があると考えるのが妥当でしょう。
ここは、チームにシニアエンジニアがいた時に、その人のメンタルモデルが完璧だと盲信してしまうところにも怖さがある。ここに書いてるように理解の共有というのは日常的に話せるようにしたい。(98lerr)
理解を絵に描いて共有するのはとても大事だと思う。最近 miro でそれが容易にできるのが便利。(98lerr)
ホワイトボードツールはほんとうに便利ですね。アイコンもつかえるし。kyon_mm.icon
24時間ルールとは、自分たちの環境でインシデントが発生した場合、24時間以内にそのインシデントに関するポストモーテムを行うべきだというシンプルなものです。
「素早く障害報告を行うため」っていうところで結果的にこういう対応にはなるけれど、ここに書いてあるようなところの意識は明確に共有できていなかったかも。(98lerr)
インシデントの勢いを利用して、それを何か良いことに使うのです。
これを明示的に書いている事に、ちょっとびっくりしました。たしかに効果的だと思うのですが、顰蹙も買いそうで。 (hayase)
普段「やらないといけないよね」が、インシデントだと「やらなきゃまずい」が伝わる
ツール買いましょうとかも、いい機会になる
もし誰かが一度でもルールを破ったら、経営陣が「誰の責任にしようか」と探しているほかの会議と同じだというシグナルになります。
言い切っていてすごいなって思うけど、まぁわかるわ。。。kyon_mm.icon
全体的に、言いにくいことをズバズバいってくれてる本
この本の最初のところにも繋がる
不祥事とかも大体普段からできてないことの積み重ね
9.2 インシデントの発生
午前1時30分ころに呼び出しを受け取ったときには熟睡していました。そのアラートには「ワーカの処理キューのサイズが異常に大きい」と書かれていました。ショーンがアラートを読むと、それは問題が発生しているというよりも状況を知らせているだけに見えました。
アラート文の書き方の難しさのわかりやすい例ですね。「キューサイズが大きいのはまずい」と思う人と、「で、それがなんだ」という人で、受け取った時の温度感全然違ってしまう。新人の頃にまさにそういうメッセージ出そうとして、指摘されたことありました。(98lerr)
人間にとりあえずメッセージを出すも不幸だし、それに説明をつけるのも現実的じゃない。アクションが定まらないから出さない判断も難しい。そういうところでも自動化が大事
アラート疲れの話もあった。どうやったら意味のあるメッセージを書けるか。
ショーンは、アラートを出しているキューが何に使われているのか、よくわかっていません。
身につまされる (hayase)
9.3 ポストモーテムの実施
まず招待すべきは、インシデントからの復旧プロセスに直接関与したすべての人です。
これ、ついつい参加者の日程都合つかないからって、トラブルに近い人だけ集めて始めてしまいがち。関与した人たち、調整する気まんまんだったりするのに。(98lerr)
9.3.1.3 人事担当者
インシデント要因の 1 つがリソースや人員配置にあるとわかっている場合には、間違いなく招待することをお勧めします。
... どこでこの手を使うかは慎重に選ぶ必要があります。
この観点はなかった。「インシデントの勢いを利用して、それを何か良いことに使う」の一環か。(hayase)
9.3.2 タイムラインの振り返り
インシデントのタイムラインは、インシデント中に発生した一連のイベントをドキュメント化したものです。発生した一連のイベント、その順番と時間について全員が合意できれば、ポストモーテムはよりスムーズに進みます。
これないと、話がぐちゃぐちゃになる。(98lerr)
とはいえ、結構ここ作るの手間かかったりする。pagerdutyとかがチャットから自動生成してくれるって聞いて、どのくらい実際活用できるのか気になってます。(98lerr)
これ気になっているけど試していない。。。kyon_mm.icon
ポストモーテムからこそ学べるんだっていうのはところ、すごいわかりみがふかかった。SRE本でも信頼性ピラミッドの中盤からやや下くらいにいる。kyon_mm.icon
https://scrapbox.io/files/6600f0242e56620026951a83.png
それ!したがないと信頼性の根拠がない。。。
(ポストモーテムの開始までに用意しておくタイムラインについて)この時点では解釈やコメント、動機などを一切排除する必要があります。
私は書いてしまいがちだったかも知れないです。タイムラインを障害対応中に書きはじめているので、文脈を残したくなってしまうのかも (hayase)
タイムラインでスイムレーン的にわけていますねkyon_mm.icon
色付けでもいい (98lerr)
アクションアイテムは、「誰がいつまでに何をするか」という形式で明確に定義されなければなりません。
これのアサインの失敗も度々起きる問題だと思ってます。単純に仕事を足し算するとか、言ったもん負けになるとか。こういう時のためにも、普段のタスクの透明性大事ですね。(98lerr)
特定の人に負荷が集中したりしがちですよね。(hayase) 👍
先にアサインを決めてしまうの、アジャイルなやりかたではないような気がしてきました。(hayase)
無理だったら他の人がうけとれるっていう動き方とセットなんでしょうねkyon_mm.icon
できる人、イメージ湧いてる人に集中するのをみんなで避けたい(98lerr)
ポストモーテムのアクションアイテムを完了させるためのフォローアップの重要性は、いくら強調しても足りません。
ほんと、温度が急激に冷めていったり。前の章であった、改善はすぐやろうというのは7章 7章 空の道具箱 の話にも繋がる。(98lerr) 長期目標の優先度が,時間経過で下がりがちに思います (hayase)
9.3.4 ポストモーテムのドキュメント化
ポストモーテムの結果をドキュメント化することは非常に大きな価値があります。これは、ポストモーテムチーム以外の人に伝えるための記録として、また将来同じような問題に遭遇したときの歴史的な記録として役立ちます。
これをチャットに書いて満足してる人いない?(ドキュメント側形式だけにしてないか)という問題提起を聞いたことがある。(98lerr)
ウォークスルーの節はエンジニアを対象としていますが、エンジニアが経験や知識を持っているという前提で書いてはいけません。
相手がエンジニア知識を持ってる前提で書く運用ドキュメントは、往々にしてエンジニア知識持ってる人にも伝わらないぐらい端折られてたりする印象あります。書くのに必死になりがちなので。一旦相手に知識がなくても前提で書くくらいでちょうどいいと思います。(98lerr)
9.4 本章のまとめ
みんなからのコメント
実践する/伝えるためのハードルはなにか?
一緒に使うと良さそうなプラクティスやマインドセットはなにか?
ハードルの乗り越え方はなにか?実践/伝える方法はなにか?
どれくらい効果がありそうか?