はじめに

前回に引き続き第三章についても読了したのでメモしていきます。

項目まとめ

アラートは二種類が存在する。

大変示唆的な文章がありました。

アラートに対応する修復手順がコピーアンドペーストできるくらいにシンプルなコマンドなら、
手順書のあり方がおかしくなっている兆候です。

私の経験では手順書作成において、ついマイクロな部分まで言及してしまうことがありますが注意しておきたいですね…

うるさいアラートによって、人々は監視システムを信用しなくなり、さらにはすっかり無視してしまうようになります。

これも耳が痛くなる指摘ですね。
現職においても重要性は高くないけれど、頻度の多いアラートがあったりします。
上述の通り、「またか」という感じで各メンバーが他のアラートを見落とすという事態があったり…

アラートに鈍感になってしまうほどたくさんのアラートを受け取ると、アラート疲れを発症します。
長期間のアラート疲れを起こして、メンバーは燃え尽きてしまうでしょう。

結果的に疲労が重なり、離脱や離職につながると述べられています。
アラートのメリットを享受できず、それどころかデメリットとして顕在化してしまうということでしょうか。
これらを防ぐためにヒアリングや調査に基づいた、定期的なチューニングが重要そうです。

復旧作業が既知かつドキュメントに沿って行うだけなら、その部分については自動化を検討することが推奨されています。

一般的に分かりやすいのは コードとして実装して監視システムにそれを実行させることです。

これによって多くの部分で不要なアラートに困らず、エンジニアが本来行うべき必要のある、より重要な作業に集中できます。

もちろん 自動復旧できなかったトラブルについてはアラートを送ることが必須です！

100%正確な監視は不可能に近い、ただしそこを目指すことは重要です。

対応として下記が文中では挙げられています。

監視自体は何も修復してはくれません。
何かが壊れたら、あなたがそれを直す必要があります。

上記についても対応方法が述べられています。

個人的には本章で最も印象に残った項です。

インシデントが発生した後は、インシデントに関する議論の場を常に設けるべきです。
何が問題で、なぜ派生して、再発防止のためにチームでどう対応していくのかを議論しましょう。

インシデント以外の事象に対してもそうですが、振り返りは必須であると述べられています。
また、チームの構築にも関連しそうな部分は下記。

振り返りにはよくない習慣があることに私は気づきました。
それは誰かを非難するという文化です。
※中略
インシデント発生後の対応が誰かを非難するものになるなら、内部に潜む本当の問題を改善することは
絶対にできません。

もはや一般的な言葉になった感じもありますが、心理的安全性を背景にした記述のように思えます。

似たような事例としては航空機事故の調査対応が挙げられますね。

なんでも航空機事故の事故調査結果を、民事訴訟の証拠として採用することは法律で禁じられているのだとか。(ソースを忘れてしまったので、絶対ではないかもですが…)

こうすることで心理的安全性を生み出し、事故当時の状況を再現できる証言を集めて、同一事故を繰り返さないように徹底しているようです。

アラートも危機対処という意味では同義に感じるので、見習っていきたいものです。

気になった箇所の要約になったので全項目を網羅する形にならず申し訳ありません。

とはいえ、現職で即座にやれることも多そうです。

私はインフラ側が専門ではないのですが、それでも協力できることはありそうです。

例えば、

このあたりはこれからも意識してやっていこうと思えた、大変参考になる素晴らしい章でした！

それではまた別の章のメモでお会いしましょう。

ここまでお読み頂きありがとうございました。