はじめに
LuupのSREチームに所属している、ぐりもお（@gr1m0h）です。
この記事は、LUUP のTVCM放映に合わせた一足早い「Luup Developers Advent Calendar 2024」の18日目の記事です。
11/9に広島県で開催されたオープンセミナー2024@広島に登壇しました。
本内容は、Luupでの取り組みとはほぼ関係ありません。「インシデント対応において必要な力」についての個人的な整理です。事例として一部Luup SREチームで行っている取り組みを取り上げています。
登壇資料は公開していますが、話した内容が資料にすべて反映されているとは言えないので、ブログを書こうと思います。
資料は以下です。
「君は見ているが観察していない」
きみは確かに見てはいる。だが観察はしない。 見るのと観察するのとでは、大違いなんだ。たとえばの話、この家の玄関からこの部屋まで上がってくる階段、きみは何度も見ているだろう。[1]
この「君は見ているが観察していない」という言葉は、シャーロック・ホームズの名言です。
この言葉は、ワトスンが「どうしてそんな推理ができるんだ？」とホームズへ尋ねた際に返された言葉です。ホームズはワトスンが医者を開業していると推理できたのですが、ワトスンは「自分と何が違うんだ？」と不思議に思ったのでした。
この状況、二人の能力の差を図にしてみると、以下のような感じかなと思います。
ワトスンは、ヨードホルムの匂いや硝酸銀の黒いシミ、シルクハットの膨らみといった証拠を身につけていますが、その証拠に気づいていない、もしくはその証拠をもとに「自分が医者を開業した」と推理できるとは思っていません。
しかし、ホームズは同じ証拠を見て、観察眼という虫眼鏡を使って、それぞれの証拠の背景にある事象や証拠同士のつながりまで推理しています。
この言葉が伝えたいのは、「ただ目に見える表面的な事実を追うのではなく、深く観察して本質や隠された意味を見抜くことが大事だ」 ということです。
エンジニアとして、SREとして、この考え方はすごく役に立っていると感じています。
そして、この観察の姿勢は、今回のテーマであるインシデントマネジメントでも非常に重要です。
SREとインシデントマネジメント
SREは、SLI・SLOを使ってデータに基づいた信頼性を管理し、データドリブンなコントロールを実現しています。また、SLIの設計には、「ユーザー体験に大きく関わる操作（CUJ）かどうか」を重視する考え方が取り入れられています。
しかし、信頼性に最も影響を与えるのが「インシデント」です。
インシデントが発生すると、一時的にSREの手から信頼性のコントロールが離れてしまうため、インシデントについてしっかりと考え、対策を講じることが非常に重要になります。
ソフトウェア開発者も日常的にインシデントレスポンスに対応しているかもしれません。
しかし、SREは単なる問題解決を超えて信頼性の確保を目標としているため、インシデントレスポンスを含むインシデントマネジメントが重要になります。
インシデントを適切に管理し、迅速に対応することで得られる学びからシステムを改善していくという、プロセスが重要です。
これにより、開発組織やサービスの信頼性が向上し、最終的にはユーザー体験の改善やビジネス価値の最大化にもつながります。
インシデントは、SREにとって信頼性についての課題を突きつけるものですが、それをインシデントマネジメントというプロセスを通じて克服し、さらに信頼性を高めるための貴重な機会にもなるわけです。
「観察」の難しさ
「君は見ているが観察していない」という言葉を胸に刻み、日々仕事に取り組んでいるものの、これを本当に実践するのは非常に難しいと感じています。
なぜ、この言葉を体現するのが難しいのか？インシデントマネジメントで「観察眼」を発揮できないのはどうしてなのか？難しさについて深堀りします。
ホームズとワトスンというキャラクターを使って、「観察眼」を発揮できている人とできていない人の動きをイメージして、どんなところが難しいのか、要素分解して考えてみたいと思います。
最初に紹介したワトスンとホームズの違いについての図を、インシデントレスポンスの状況に置き換えてみます。
証拠となるのは、モニター、ログ、トレース、メトリックなどです。
ワトスンは、インシデントが発生したとき、アラートやエラーメッセージを見ています。システムの複雑さやドメイン知識の不足から、問題の背後にある原因を特定できず、対処に時間がかかってしまいます。
ホームズは、インシデントが発生したとき、アラートだけでなく、システム全体のメトリクス、ログ、デプロイ状況など、多角的に情報を観察します。ツールを活用し、問題の根本原因を迅速に特定します。
観察の難しさを細かく分けてみると、以下4つの要素に分けられるかなと思います。
- 経験と勘所の必要性
- 深いドメイン知識の必要性
- システムの複雑性とスケールの増大
- 時間とリソースの制約
上図を見て分かる通り、大きな違いは「観察眼」があるかどうかということです。「観察眼」を鍛えるためは、「経験と勘所」、「深いドメイン知識」が必要になります。
「経験と勘所」というのは、ドメインによらない、技術力や経験からくる直感のことです。
「深いドメイン知識」は、そのシステム特有の構成や依存関係、ビジネスロジックなどを指します。
そして「システムの複雑性とスケールの増大」というのは、昨今のマイクロサービス化やクラウドネイティブ化により、システムがどんどん複雑になり「深いドメイン知識」を得るのが難しくなっているという話です。
最後に、「時間とリソースの制約」というのは、そもそも観察眼を発揮できるような余裕があるのか？という話です。
ということで、残念ながら「観察眼」を身につけない限り、ワトスンが私立探偵としてモリアーティと対峙することは難しいでしょう。
次の項では、ワトスンが「ホームズ級の推理力」を得るための手段、つまり「観察眼」を鍛えるためのサポートや工夫について紹介します。
「観察眼」が無いので道具に頼る
まずは、「観察眼」が無いときにツールを使って「観察眼」の役割を代替することを考えてみます。
以降、紹介する工夫はDatadogとWaroomを使った工夫になります。
「観察眼」を代替するための工夫として、オブザーバビリティとランブックを紹介します。
オブザーバビリティ
まず、オブザーバビリティの基本である、ログとトレースの紐付けについてです。
まだLuupではあまり実現できていない部分なので、Datadog公式サイトを参考にします。
パフォーマンスや動作を追跡・観測するトレースと、そのtrace IDに紐づいたログを確認できます。トレースからログを辿ることもできますし、逆にログからトレースを辿ることも可能です。よくあるケースとしては、エラーログを検知して、そこからトレースを辿る流れが多いかと思います。
次はデプロイメトリクスについてです。
インシデントが起きたときに、最近のデプロイ情報を確認するのも重要です。新しいコードのリリースや設定変更が原因で問題が発生していることもあります。
Luupでは、Cloud Run Functions、Firestore、Firebase hositngのデプロイ情報をグラフ化しています。
デプロイのタイミングをメトリクスとして集めてダッシュボードに表示しておけば、他のレイテンシー、エラー率、CPU負荷、メモリー使用率なんかと照らし合わせて確認できます。
また、インシデント発生時に、その直前のデプロイ状況もすぐに把握できるようになります。
Waroomでは、インシデント詳細画面、インサイト画面でデプロイ情報を確認できます。
インシデント詳細画面では、右側のバーに以下のように表示され、インシデントと関連がありそうな直近のデプロイ情報を確認できます。
インサイト画面では、デプロイごとのインシデント率など、デプロイとインシデントの関係を分析できます。
ランブック
次にランブックです。
ランブックは、インシデント対応の手順やチェックリストをまとめたドキュメントであり、対応者に必要な「観察」の視点を提供します。
ダッシュボードなどでデータを確認するときにどう解釈するか、どんな意味があるかを理解する必要がありますが、慣れていなければわからないということもあると思います。
ランブックにあらかじめ、このあたりを補助するようなドキュメンテーションを追加することで、確認すべきデータの解釈方法や、それが良い状態なのか悪い状態なのかを判断するための視点を得ることができます。
「観察眼」を鍛える取り組み
「観察眼」を鍛える取り組みとして、ポストモーテムとインシデント対応訓練を紹介します。
ポストモーテム
ポストモーテムは、単なる形式的な振り返りではありません。インシデント発生時に原因を分析し、再発防止策を検討するためのプロセスです。
「Blameless Postmortem（非難のないポストモーテム）」 という考え方があり、個人の責任を追及するのではなく、システムやプロセスの改善に焦点を当てるアプローチです。
こうすることで、ドメイン知識や直感を磨き、学びを得る貴重な機会が増えます。逆に、個人の責任にばかり目を向けると学びのチャンスが減ってしまいます。
シャーロック・ホームズのように、ポストモーテムでもデータや事実に基づいた客観的な分析が重要です。ログやメトリクス、アラート、コミュニケーションの履歴などを集め、インシデントのタイムラインを詳細に作成することで、何が起こったのかを正確に「観察」し、それを再発防止の基礎にします。
さらに、先入観を持たず、特定の人に責任を押し付けないことが大切です。システムやプロセスに目を向け、改善を図るためには、責任追及を避けてオープンに話し合える心理的安全性が必要です。人的ミスも単なるミスで終わらせるのではなく、なぜそのミスが起きたのかを「観察」て、システム全体の改善につなげていきます。
また、ポストモーテムではレビューや公表します。レビューを通じて知識の共有し、公表することで組織全体が失敗から学ぶ機会を得ることができます。
このプロセスにより、個別のチームだけでなく、組織全体が成長し、信頼性が向上します。
次に、ポストモーテムで使うテンプレートについてお話しします。
このポストモーテムテンプレートに工夫を加えることで、ポストモーテムでもランブックと同じように「観察」の視点を持つことができ、インシデントをいろんな角度から分析できるようになります。
Luupでは、Waroomのデフォルトのテンプレートに少し手を加えています。
分析と振り返りの項で「うまくいったこと」「うまくいかなかったこと」「幸運だったこと」を記録するようにしています。
これによって、ポストモーテムの際にネガティブな面だけでなく、ポジティブな動きにも目を向けられるようになります。
インシデント対応訓練
インシデント対応訓練は、シミュレーションを通して実際のインシデント状況を再現し、チームメンバーが素早く正確に対応するスキルを磨く場を提供してくれます。この訓練を通じて、メンバーは深く「観察」する習慣を身につけられます。
Waroomでもインシデント対応訓練がβ版で提供されています。
さいごに
個人的な「インシデント対応で必要な力の整理」を紹介しました。
このように整理した経緯としては、自分の現時点の一番の悩みが、この力が身に付いていないと感じているからです。
この記事で紹介した工夫や取り組みを通じて、この力を身に付けていきたいと思います。
最後に、弊社のプロダクト開発やSRE、使用技術に興味を持っていただけた方は、以下のリンクからお気軽にご連絡ください！私のX(Twitter)アカウントでもDMを受け付けています。
副業や転職をお考えの方だけでなく、気軽に話を聞きたいという方も大歓迎です！
Discussion