0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

『入門 監視』第三章 メモ

Posted at

はじめに

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

項目まとめ

3-1 どうしたらアラートをよくできるか

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

  1. 緊急性の高いアラート
    文中では、誰かを叩き起こすためのアラートと呼称
  2. 参考としてのアラート
    緊急性は高くないがアラートが来たことを誰かが確認する必要のあるアラート

3.1.2 手順書を書こう

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

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

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

3.1.4 アラートを削除し、チューニングしよう

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

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

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

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

3.1.6 自動復旧を試そう

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

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

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

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

3.2 オンコール

3.2.1 誤報を修正する

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

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

  • オンコール担当が前日に送られたすべてのアラート一覧を作成する
  • 上記一覧の各アラートをどのように改善できるか、アラートから削除できないかを検討する

3.2.2 無用の場当たり的対応を減らす

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

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

  • オンコール担当者は場当たり的対応をしていない時間に、システムの回復力や安定性向上の作業に取り組む
  • オンコールで収集した情報に基づいて、次週スプリントの計画として改善事項を組み込む

3.4 振り返り

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

例えば、

  • 不明点や気になった点を積極的に専門のメンバーに伝える
    • 100%アラートを目指す行動
  • 他メンバーのインシデント対応に 感謝の意を伝えて心理的安全性を確保しつつ、自分自身でも対応できるように知見共有を依頼する

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

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

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?