![見出し画像](https://assets.st-note.com/production/uploads/images/162986747/rectangle_large_type_2_fab98b3d482c97f8a161d5daf754672e.png?width=1200)
DevOpsDays ビデオ鑑賞会 #6
Agile Developer Community での 海外の DevOpsDays 動画を見る会、第6回です。
今回の動画
今回はDevOpsDays London 2024 から。
Ashley Sawatskyさんの「Making Better Decisions in Incidents (Why Playbooks Aren’t the Answer)」です。
講演の概要は、本人のLinkedInに投稿されたグラレコがわかりやすいです。
大体、以下のような内容で捉えてます。
On-Call対応で、プレイブック(対応手順書)は欠かせない
しかし全てはプレイブックでカバーできない、燃やしたくなる分厚いものができる
3つの話を分けて考えよう
自動化するもの、わかりやすいのはこれで!
経験則で動くもの、最悪の手段を考えてだがここを中心にしない
検知するもの、今のうちにできる判断!
インシデントレスポンスは大変だけど、楽しいものにしていこう
オンコールを楽しむという考え方
なかなか、できないですよね。
会話してても、辛い日々が思い返されてしまうトピックです。
復旧の仕組みを考えていくとか、
そもそものアーキテクチャとか、
人の関係性とか、
諸々の組織文化の醸成から始まっていくところが難しそうです。
一方で、学びの多い場所でもあるので、
これを楽しめるくらいの状態でありたいというのもその通り。
楽しむためには改善の裁量も必要だし、
改善していける余裕も必要だなというのを会話してました。
プレイブックのポリシー
途中のスライドに "What playbooks won't teach you" というタイトルの元、前提に必要なポリシーの話が入ってました。
プレイブックが教えてくれないこと
電話をする判断の方法
顧客がどう感じているか
初見の問題をどう解決するか
あなたが本当に「責めない」文化を持っているか
ルールを破るべき時はいつか
一番最後の「ルールを破るべき時」というところ、
ここは手順書に「捉われすぎる」ことで危険を作ってしまう可能性を持ちますね。
こういったことを判断すべきタイミングもあるのだと理解しておくのも、インシデントレスポンス体制として大事ですね。
次回
次回も、DevOps Days London 2024から。
「DevOps Topologies 10 years on: what have we learned about silos, collaboration, and flow?」
Team Topologies 著者の一人、Matthew Skeltonさんの講演です。