Takuma Nakagame / kameneko SAKURA internet Inc. https://www.oreilly.com/content/reduce-toil-through-better-alerting/ 

Reduce toil through better alerting • O’REILLYの記事 • アラートの最適化について https://www.oreilly.com/content/ reduce-toil-through-better-alerting/ 

Introduction • Site Reliability Engineering では SLOとSLIに基づいたアラートが推奨されている • 原因ではなく、症状に基づいたアラート • 長期的にアラート作成の労力や システムの堅牢性・信頼性を向上させる 

アラートの基本概念 

なぜアラート行うのか • システムが人間に行動を求めるため • システムが自己解決できない場合にアラートを行う 

なぜアラート行うのか • システムが人間に行動を求めるため • システムが自己解決できない場合にアラートを行う 人間が問題ないと確認するだけの アラートは本当に必要？ 「なんか攻撃しているけどいつものことだからヨシッ！」 

適切なアラートとは • 配送されるまでの時間: インシデント発生からアラートが到着するまで、期待した時間内に届いたか？ • 正しい宛先: アラートが想定した人間に届いたか？その宛先は本当に必要？ • ドキュメンテーション: アラートの説明には人間がそのアラートを評価する情報が含まれていたか？ • アクション: アラートには人間が次に行うステップが正しく記載されていたか？ アラートの評価の多くは主観である 以下は、客観的に示すことのできる一例である 

アラートの成熟ピラミッド • アラートをタイプ別に分け、階層化したもの • 通常、下位から上位に向かってアラートを作成していく 

アラートの成熟ピラミッド リアクティブアラート • サービスに影響を与える直前である • 将来的にSLO違反になる可能性が高い • 例: HTTPのレイテンシ増加 

アラートの成熟ピラミッド プロアクティブアラート • 将来的にサービスに影響を与える • ただしすぐに影響を与えるものではない • 例: キャパシティアラート 

アラートの成熟ピラミッド 調査アラート • システムの異常をトリガーとしたアラート • サービスに直結するものではない • 例: LB配下のサーバダウン 

アラートの成熟ピラミッド • アラートには階層がある • すべてのアラートを 単一のグループが受け取らなくて良い • すべてのアラートが 同一の緊急性や一貫性を持たなくて良い アラートタイプの連携 

アラートのアンチパターン 

アラートのアンチパターン • サービスにSLO/SLIがないか、それをもとにしたアラートがない • SLO/SLIがあるが、発生しているインシデントの多くはSLO/SLIベースで はない 症状 • ビジネスの目的を示すSLO/SLIを定 義する（強く推奨） • SLO/SLIをもとにしたリアクティブ アラートを作成する 解決策 調査アラートのみ設定する 

アラートのアンチパターン • 受信するアラートが多すぎるか、頻発に発生する小さなアラート が存在している • 人間が確認だけして終わる無駄なアラートが存在している 症状 • 上位レベルのアラートを無効にする • ビジネスに本当に必要なアラートは 下位のアラートである • 適切なレベルに落ち着いたら上位の アラートを利用する 解決策 アラート量が多く疲弊している 

アラートのアンチパターン • 過去の事後調査の結果、SLOアラートで発見できなかったインシデ ントが存在していた 症状 • より下位のアラートで対応できないか検討する • SLIを拡張する • ※安易にアラートを作成しない（特に調査アラートは） 解決策 SLO/SLIアラートでは検出できないインシデント 

終わりに 

終わりに • 原因にもとづくアラートが誤りとは限らない • ただし、単一のアラートタイプだけではなく、 複数のアラートタイプを組み合わせ、信頼性と堅牢性を向上させる • 問題発生時、アラートを追加するのではなく削除することを検討しよう 紹介した方法を活用して知恵や経験に頼らない、 データに基づいたアラートを定義しよう