個人的まとめ

先に個人的なまとめから。

要約は正直ちゃんと短くまとまりませんでした。
スライドにして４０枚。
高橋メソッドでももっと枚数少ないんではないかと。

「アラート疲れ？ああ、狼少年のあれね」
となんて言うなかれ、
適切なアラートとそれに対応するためのオンコールローテーションを効果的に運用することで、スタッフの幸福度があがるのみならず、システムの（技術的・ビジネス的）負債を返済することにもつながるんだよと言うお話。
お金と契約の話のくだりなどはアメリカンな匂いもするがまあ訳本だからね。

振り返ってLIFULLはどうか。
オンプレ時代のZabbix+メール通知
→ ZabbixとAWSのCloudWatchのログ解析+チャット通知
→ 社内の技術基盤に関わる部署が開発したDevOps基盤+Slack通知と進化して、
システムの監視もアラートも一昔前より随分よくなった。「技術的負債」と言う用語をエンジニアのみならず企画職や役員からも聞くようになりリファクタリングが社内文化として根付いてきている結果だと言えるだろう

しかしながら、アラート疲れが解消されたかというと、そんなことはなく、やっぱりバッチの処理結果がメールで届いたり届かなかったりなどで時々運用部署から連絡が来たりはしている。
メトリックスのしきい値の設定は最適かとか、インシデントを生かしてシステム負債の返済につなげられてるかとかまだまだ改善できるところはたくさんありそう。

つまり、
伸びしろしかない！
（しかないは言い過ぎw）

では本編です。

アラート疲れ

システムの本番投入時にシステムが故障する可能性に備えるつもりでアラートを大量に設定した結果、アラートシステムに多くのノイズが発生、それらはすぐに無視され、アラートが発生しているのが正常だと見られてしまう。

このパターンをアラート疲れと呼ぶ。これはチームを深刻な燃え尽き症候群に導く可能性がある。

本章ではチームのオンコールに焦点を当てる

本章の内容

オンコールのベストプラクティスの活用
オンコールのローテーションのための人員配置
オンコールの幸福度の追跡
オンコール体験を改善する方法

6.1 苦労話

この節ではシステムのアラートにまつわる苦労話を元にアラート疲れを定義する。アラート疲れがどんな場合に起こるのかが具体的な例で述べられている

アラート疲れの定義

アラート疲れ はオペレータが頻繁に多くのアラートにさらされることで、アラートに鈍感になってしまう場合に起こる。オペレータが偽のアラートに慣れてしまうと、どんどん鈍感になっていき、アラートへの応答時間が悪化する。これによりアラートシステムの全体的な有効性が低下する

6.2 オンコールローテーションの目的

この節では詳細に入る前説としてオンコールプロセスの基本的な定義が述べられる。

オンコールローテーションの定義
オンコールローテーションでは特定の個人を一定期間、システムまたはプロセスの最初の連絡先として指定する

そして、オンコールローテーションの具体的な例が述べられ、オンコールローテーションを定義することで得られる効用と技術的観点で何が中心になるのかが述べられる。

効用

オンコールローテーションの定義によりスケジュールが決まることで担当メンバーの対応能力の期待値が設定できる

技術的観点で中心になるもの

メトリクスツール
モニタリングツール
アラートツール

アラート通知は自動化されていることが重要

自動通知システムの例

これらのツールではチームのオンコールスケジュールを管理でき、多くのモニタリングシステムやメトリクスシステムと連携しあるメトリクスが定義した閾値の１つを超えたときに通知プロセスを開始できる。

6.3 オンコールローテーションの設定

この節ではオンコールローテーション設定の設定要素と閾値を決める基準（SLO）について説明されている

オンコールローテーションを設定する際には次の要素を含めるとよい

プライマリオンコール担当者
セカンダリオンコール担当者
マネージャー

プライマリオンコール担当者はそのローテーションでの連絡先として指定され、オンコールイベントが発生した場合には最初にアラートを受ける人物である。

セカンダリオンコール担当者は、プライマリオンコール担当者が何らかの理由で対応できない場合の予備の担当者である。

最後の砦となるのが マネージャー 。プライマリとセカンダリの両方のオンコール担当者が対応できない場合、通知先としてだけでなく、オンコール対応を迅速に行うためにもチームマネージャーの関与が必要となる。

このようにさまざまなオンコールの段階を経ることをエスカレーションと呼ぶ。エスカレーションするべきタイミングはチームによって異なるが、アラート通知への応答時間のサービスレベル目標（SLO）を定義する必要がある。SLOは通常、３つのカテゴリに分けられる

確認までの時間
開始までの時間
解決までの時間

6.3.1 確認までの時間

エンジニアがアラート通知の受信を確認するまでの時間として定義される。
SLO時間内に確認されない場合、セカンダリ担当者にエスカレーションされる
さらにSLO時間内に確認されない場合、エスカレーションパスの次の人にエスカレーションされる

重要な点

アラートを確認したエンジニアはアラートの解決をする責任をもつというルールを設定すること

こうしておくことで通知が確認されたにも関わらず責任の所在が曖昧になるという事態を避けられる

6.3.2 開始までの時間

問題の解決に向けて作業を開始するまでの時間に対するSLO。
開始までの時間はサービスによって異なるので複雑な例外規定が必要となってしまう。
応答時間が重要な場合には可能性の最も高い事態に基いて計画を立て、エスカレーションパスを決めて支援を提供するとよい

6.3.3 解決までの時間

どれくらいの期間、システムが壊れている状態を許容するかを示すシンプルな指標。このSLOは多少の曖昧さを持つ。
主要なビジネス指標や成果物への影響を理解することが重要であり、解決までの時間は問題に関するコミュニケーションのきっかけとして使うべきである。

6.4 アラート基準

良いアラートの条件

手順書(runbook)があること
行動可能であること
タイムリーであること
適切に優先順位づけされていること

6.4.1 しきい値

アラート戦略の中心。
メトリクスの上限と下限のしきい値を定義するのは重要。
システムは需要の増加によってキャパシティが増加するなど変化していくのでしきい値は常に見直しが必要である。

6.4.1.1 複合アラート

システムコンポーネントのパフォーマンスと実際に顧客に影響が出ているかどうかを結びつけるような複合アラートは非常に重要である。
ある問題が複数の観点にまたがって現れることがわかっている場合にも複合アラートが有効である。

6.4.2 ノイズの多いアラート

オンコールシフトごとにオンコールスタッフに送られた通知の数を追跡したほうが良い。チームメンバーが日常的にどのくらいの頻度で邪魔されているかを把握することはチームの幸福度や無意味なアラートの量を表す素晴らしいバロメーターになる

6.5 オンコールローテーションの配置

本書では、最低４人最大8人以下でローテーションを組むことを推奨。
トラブルシューティングで使用される最も一般的なタスクを自動化し、オンコールエンジニアが問題を適切に「トリアージ」するために十分な情報にアクセスできるようにすることで負荷を減らす

ある技術の専門知識が一人のエンジニアに集中してしまうことは避けるべき
インシデントは素晴らしい学習の機会。その技術の専門家ではない人をオンコールのローテーションに参加させるのはスキルをレベルアップさせるのに最適な方法。
インシデントごとに手順書を更新し続けよう

6.6 オンコールへの補償

金銭的補償
- オンコール週は給与に一律のボーナスを適用する
- 時間給はあまりおすすめできない
休暇
- 人事部にオンコール補償の話し合いに参加してもらう
- オンコール休暇の貯め込みをやめる
- オンコール休暇付与の必要がある場合はどこかに必ず記録する
在宅勤務の柔軟性の向上
- 人によって感じ方が違うので注意する。チームメンバーとの話合いを

6.7 オンコールの幸福度を追跡する

オンコール体験を評価する際に検討すべき情報は以下の通り

誰がアラートを受けているか?
- どのチームメンバーがアラートに対応しているか具体的に知る必要がある
アラートはどの程度の緊急度か?
- 緊急性が低いものは今後の問題の兆しである可能性がある
- 緊急性が高いと従業員の生活に苦痛と摩擦をもたらす
- これらの数を記録することで呼び出しの影響度を把握できる

アラートはどのように通知されているか?
- 緊急性に合わせた通知方法とすることでオンコール体験を改善することができる
チームメンバーはいつアラートを受けているか?
- 生活に影響を及ぼすか把握するには３つに分類すると良い
  - 就業時間
  - 勤務時間外
  - 就寝時間

6.8 オンコール担当中のタスク

オンコール業務の性質上、プロジェクト業務に集中できないことがある。オンコール業務を単に業務時間外のアラートの受け取りとして扱うのではなくオンコールをより良くするための機会にしよう

オンコールサポートプロジェクト
- 通常の優先順位の高い仕事には参加させずオンコールの経験を少しでも良くするためのプロジェクトに集中させることを検討する
  - 手順書の更新・作成
  - 自動化への取り組み
  - アラートシステムの改善
  - 問題の根本的な解決

パフォーマンスレポート
- オンコールエンジニアがシステムの状態をレポートすることは重要
- 全てのKPIを表示したダッシュボードを作成するところから始める
- ダッシュボードにマイルストーンを重ねてみる（デプロイなど）

6.9　本章のまとめ

アラートは、行動可能で、タイムリーで、適切に優先順位づけされている必要がある
ノイズの多いアラートはアラート疲れをお越し、アラートを役に立たないものにしてしまう
オンコール業務はスタッフの負担になるので何らかの形で補償しよう
オンコールによりエンジニアの生活をどれだけ乱しているか理解するためにオンコールの幸福度を追跡しよう
エンジニアが根本的な修正を行う時間を各法できるようにオンコールのローテーションを構成しよう