アラート対応で疲弊してるチームがいまできること

2021/06/25 AKIBA.AWS Online #4

Transcript

1. アラート対応で疲弊してるチームが 今できること AWS事業本部オペレーション部 加藤早織
2. 自己紹介 加藤早織 クラスメソッド AWS事業本部オペレーションチーム 2020年1月入社、2021年5月に産育休から復帰 - クラスメソッドメンバーズのテクニカルサポート - 業務改善ツール開発 ユーザ系SIer→ネトゲ会社→ (フラフラ) → クラスメソッド
3. ブログ企画の宣伝 弊社メンバーに沢山いい記事書いてもらいました アクセスキー運用、ぜひ一度確認を https://dev.classmethod.jp/referencecat/accesskey-secure-comitee/
4. 発表タイトル アラート対応で疲弊してるチー ムが今できること
5. Amazon CloudWatch AWS Systems Manager お話するサービス
6. いやだ アラート疲れ
7. つかれちゃう4選 定形作業で復旧するアラート ・毎晩プロセス再起動のために起こされるマン 対応の必要がないアラート ・月末はいつも負荷かかってアラートがくるけど、この程度なら毎月のことだから静観で大丈夫 ・なんとなくしきい値低めの Warning 対応する必要あるかどうかわからないアラート ・CPU使用率98%です。で？問題はでているの？ → わかりません
8. 1. 定形作業で復旧するアラート 「このアラートが出たら プロセス再起動しておいて！」 （夜中にくるアラート） （目処のつかない根本対応）
9. AWS Systems Manager Automation - EC2インスタンスなどの操作を自動化（RunBookの作成） - AWSのAPIを操作したり、OS内でのコマンド実行もできる
10. AWS Systems Manager Automation 例えば… - CloudWatchアラームをトリガーに 予め設定したランブックを呼び出し アラート検知 RunBook実行 アラート復旧 プロセス再起動 (Runbook) 調子悪い…
11. AWS Systems Manager 2021/05 素敵なアップデート
12. AWS Systems Manager Incident Manager
13. AWS Systems Manager Incident Manager インシデント管理機能と 進化した自動化フロー - CloudWatch Alarmをトリガーにして、 - SSM Automationのランブックを実行 - インシデントの管理ページを作成（事象サマリ、時系列、振返り etc） - アラート発生から一定時間解決しない場合、電話やSMSなどの通知設定可能 - 一定時間担当者が対応開始しなければ 別の担当者へエスカレ電話するようなフローも組める
14. AWS Systems Manager Incident Manager
15. AWS Systems Manager Incident Manager ClooudWatch Alermのアクション設定画面から連携可能
16. AWS Systems Manager すぐパソコン開けないけど とりあえず復旧はしてるみたい アラート発生！ アラート復旧 自動処理の進捗 (Runbook成否など) ※ 左のチャットの図はイメージです。ちょっと異なります
17. 1. 定形作業で復旧するアラート 「このアラートが出たら プロセス再起動しておいて！」 「はい、自動化しておきました！」󰢎✅
18. 2. 対応の必要がないアラート　その１ 「月末はいつも負荷かかって アラートがくるけど、 この程度なら毎月のことだから静観でヨシ」
19. CloudWatch Anomaly Detection(異常検出) - メトリクスの履歴を機械学習で分析 - 分析結果に応じてしきい値パターンが変化
20. CloudWatch Anomaly Detection(異常検出) 学習がこなれるまでは こんな取り入れ方もオススメ - 従来型のアラートと並行して運用 - 最初は予測のバンドを狭く(敏感に)設定→ 徐々に広くしていく 敏感 鈍感気味
21. 向き不向きはある 傾向がある程度読めるメトリクス向き - 月初に多い - 土日に少ない - 朝のバッチ処理時間中は多い　など 突発的なイベントの予測はできない - ブラックフライデー - 超人気商品の発売日 など
22. 2. 対応の必要がないアラート　その１ 「月末はいつも負荷かかって アラートがくるけど、 この程度なら毎月のことだから静観でヨシ」 「対応が必要な通知だけ飛ばしましょ」󰢎✅
23. 3. 対応の必要がないアラート　その２ 「なんとなく様子を見たいから Warningのしきい値は低めにしておこう」
24. SPAMとまではいわんが Warning → Recover(自然復旧) Warning → Recover(自然復旧) Warning → Recover(自然復旧) Warning → Recover(自然復旧) Warning → Recover(自然復旧) Warning → Recover(自然復旧) 以下略 何で使用率XX%程度でWarning飛ばしてるんだろ？ 答：なんとなく不安だから
25. CloudWatch ダッシュボード - システムのメトリクス傾向が知りたいなら、 アラートではなくダッシュボードでモニタリングしよう - 朝に5分眺める習慣から 普段の利用率この程度なら、 このくらいの値になったら 通知が欲しいかな あれ？ しきい値は超えてないけど , 明らかに今日は何かが起こっ てるぞ…！？
26. 3. 対応の必要がないアラート　その２ 「なんとなく様子を見たいから Warningのしきい値は低めにしておこう」 「様子はダッシュボードで観察して 　通知に適切なしきい値を設定しましょ」󰢎✅
27. 4. 対応する必要あるかどうかわからないアラート 「CPU使用率が98%です！」 「で？なにか問題はでているの？」 「…確認します！」
28. AWS Systems Manager Automation ふたたび CPU使用率の例 - アラート発生時、topコマンドを実行する 等のRunbookを作っておく - どのプロセスが暴れていたのか特定するために、ログを記録しておく
29. CloudWatch Syncetics 合成監視サービス - URLを監視して、 ユーザの体験（可用性、レイテンシー）のメトリクスを取る - 4XX、5XXエラーが返ってこないか？ - レスポンスが一定時間内に返ってくるか？ - 前述の異常検出との組合わせも可能（”いつもより遅い”がわかる）
30. CloudWatch Syncetics - 主なメトリクス - レスポンスタイム(ms) - レスポンスコード 2xx, 4xx, 5xx, レスポンス無し の数　など - Webサービスの死活監視にも - Webサーバの健全性だけでなく DBアクセスに失敗したら5xxを返す ようなURLを監視するのがよさそう
31. 向き不向きはある - WebサービスのようにURLがないと利用できない
32. 4. 対応する必要あるかどうかわからないアラート 「CPU使用率が98%です！」 「で？なにか問題はでているの？」 「…確認します！」 「顧客へ提供しているAPIは生きていそう」 「調査に必要な情報は記録取れていたので 落ち着いて調査を進めます」󰢎✅
33. まとめ - 脱・オオカミ少年 - どんどん自動化 - AWSの便利サービスを活用して 自分たち好みの監視/障害対応に ブラッシュアップ