# Practices for Making Alerts Actionable Navigation: [[index]] | [[アクショナブルアラート]] | [[アラート疲労]] ## 概要 [[Sohei Iwahori]]（[[GREE, Inc]]、インフラ/Monitoring Unit Leader）が SRE NEXT 2020（2020-01-25）で発表したスライド資料である。グリーが 2015年のオンプレ→AWS 移行後に直面したアラート増加問題と、2018年以降に実施したアクショナブル化の取り組みを体系的に報告する。「アラートは緊急感を持って対応できる手段であるべき」という SRE Book Chapter 6 の原則を実践的にどう実装するかを示す事例発表。 ## 主要メッセージ - オンプレ由来のアラートルールをそのままクラウドに持ち込むと、オートスケーリングによる一時的なスパイクや台数調整で「静観アラート」（復旧アクション不要で事象が収まるもの）が急増する（p.13-14）。 - アクショナブル化の第一歩は「計測」である。月次Top10をSumoLogic+PagerDutyで集計・通知し、毎月検討する定例運用が改善の起点になる（p.18-19）。 - アラートの振り分けを3段階で設計することで、過剰なオンコール通知を抑制できる（p.22）。 - 定型アクション（プロセス再起動など）は AWS Lambda + AWS SSM による Alert Operator で自動化できる（p.27-28）。 - SysLoad のような「誰が見ても飽和状態を判断できる」共通指標を整備することで、オンコール担当者の判断コストを下げられる（p.31-33）。 ## 視覚的に重要な図表 **p.7 現在のクラウド環境監視構成** ![[_attachments/practices-for-making-alerts-actionable/page-007.png]] Prometheus/Grafana/gangi/amaneko/yusura を中核に、SumoLogic（ログ集約）・PagerDuty/Slack/JIRA（通知）を組み合わせた監視スタック全体図。yusura が SQS 経由でアラートを収集・振り分け・抑制する中心機能を担う。 **p.12 アラート数推移（2018/06〜2019/07）** ![[_attachments/practices-for-making-alerts-actionable/page-012.png]] 2018/09 に月 300 件超のオンコールアラートがピーク。その後の取り組みにより下降傾向が見られる。縦軸は月次オンコールアラート件数。 **p.25 改善後のアラート数推移** ![[_attachments/practices-for-making-alerts-actionable/page-025.png]] 同グラフに「Reduce useless on-call alerts」の矢印を追記。2018/12〜2019/07 にかけて概ね 180〜220 件水準に安定。ピーク比で約 4 割削減。 **p.23 Slack 通知 + JIRA チケット自動起票** ![[_attachments/practices-for-making-alerts-actionable/page-023.png]] yusura からの通知がアラート詳細（product/role/region/hostname/alert-distributor-setting）を構造的に付与して JIRA チケットを自動起票する実装例。 **p.28 Alert Operator 実行例** ![[_attachments/practices-for-making-alerts-actionable/page-028.png]] `service xxx status → sleep 10 → service xxx restart → service xxx status` というコマンド列を AWS SSM で実行し、結果をチャット通知する実行ログのスクリーンショット。 ## 環境規模と監視スタック - **環境規模**: 50+ 本番 AWS アカウント（ゲームタイトルごと・リージョンごとに分割）、2000+ 仮想ホスト、VPC≒アカウント単位で監視セットが存在（p.4-5） - **監視スタック**: - Prometheus + Grafana（メトリクス） - gangi（内製 ganglia 互換 Exporter） - amaneko（内製監視エージェント。cron + チェックプラグイン） - yusura（内製アラートコントロールシステム。SQS 経由でアラートを収集・振り分け・抑制・サマライズ） - fluentd（ログ監視 + アラート伝達） - SumoLogic（ログ集約・分析） - PagerDuty / Slack / JIRA / Amazon SNS（通知経路） ## アクショナブル化の5本柱 ### 1. 定期的なモニタリング（月次計測） 月ごとにオンコールアラートを SumoLogic + PagerDuty で集計し Slack に通知。上位 10 件を対象に毎月「どう扱うべきか」を検討する（p.18）。改善の PDCA を回す起点として機能する。 ### 2. 判定条件の最適化 - 厳しすぎるアラート条件の緩和 - Prometheus の `for x min` による期間判定（一時的スパイクの除去） - チェック系監視の `occurrences` による連続検知判定（誤検知抑制）（p.21） ### 3. 振り分けの3段階設計 緊急度・対応種別に応じて通知先を分離する（p.22）。 | 対応種別 | 通知先 | |---|---| | 発生を知りたいが即時アクション不要 | Slack のみ（流量注意） | | 即時不要だが何らかの対応が必要 | JIRA チケット自動起票 | | その場で直ちに具体的アクションが必要 | PagerDuty オンコール | ### 4. 自動復旧（Alert Operator） アラート種別に応じて AWS SSM でコマンドを実行する AWS Lambda Function。プロセス再起動などの副作用がない定型アクションを自動化し、結果をチャット通知する（p.27-28）。導入プラクティス: 副作用がない・実行前より状態が悪化しない箇所から着手し、自動対応ルールと人間向けルールを分離する（p.29）。 ### 5. 対応基準の明確化（SysLoad） 独自指標 SysLoad を「全 CPU 使用率 / ディスク I/O 使用率 / NIC 割り込み CPU 使用率の最大値（各 100 で飽和）」として定義し OSS 公開。SysLoad=80 超で対応アクション必要という共通基準を全チームで共有する。[[The Four Golden Signals]] の Saturation を可視化するメトリクス。補助ツールとして chatbot（手動手順の代替）、Runbook 提供 [WIP] も整備中（p.30-35）。 ## Recap（p.37） - アラートの計測を行う - 取るべきアクションに合わせて適切な振り分けを検討する - 定型的なアクションは自動対応を検討する - アラート通知に経路・追加をしやすい機構を入れておく - アクションを取りやすい指標、仕組み、手順を用意する ## 概念・実体への接続 - [[アクショナブルアラート]] — 振り分け3段階・SysLoad・Runbook [WIP] が実践事例を提供 - [[アラート疲労]] — 「緊急感を持って対応できる回数は限られる」という SRE Book 引用（p.15）が問題の動機 - [[アラート管理]] — 月次計測・判定条件最適化・自動復旧の全体像 - [[自動復旧]] — Alert Operator の実装パターン - [[Sohei Iwahori]] / [[GREE, Inc]] — 登壇者・組織 ## 限界・不確実点 - transcript なし（スライドとテキスト抽出のみ）。口頭説明・Q&A は不明。 - SysLoad グラフの補助線（赤 80%ライン）の詳細は p.33 に示されるが、画像読み込みエラーのためテキスト抽出で補完。 - アラート数の改善幅「約4割削減」はグラフ読み取りによる概算（p.12/p.25）。 - 各ツールの OSS 公開状況は Appendix の URL 記載に依存（sysload: `https://github.com/gree/sysload`）。