「アラート対応で疲弊してるチームが今できること」というタイトルでAKIBA.AWS ONLINE #04に登壇しました #AKIBAAWS

オペレーション部　加藤です。

今日は以下のイベントで登壇させていただきました。

【6/25（金）リモート開催】AKIBA.AWS ONLINE #04 – こんなときどうする⁉︎ トラブル・インシデント対応 編- #AKIBAAWS

監視運用の嫌なことあるあるを解消する、AWSの便利なツールのご紹介です。 発表タイトル「今できること」の通り複雑な設定が必要なツールはないので、もし気になるものがあればちょっとだけ触ってみてください。

資料

概要

監視運用4つのあるあるを解消できそうなAWSのツールを紹介させていただきました。

• 毎晩プロセス再起動のために起こされるマン
• 月末絶対来るけど静観するアラート
• なんとなくしきい値低めのWarning
• 対応する必要があるかどうかわからないアラート

過去の経験から、私は監視・インシデント対応には「自動化」と 「脱オオカミ少年」が必要と考えています。
インシデント対応のほとんどが意味のない作業になってしまうと、担当するチームは疲れてしまいます。

そんな状況を改善するために、このスライドが皆様の監視、インシデント運用のヒントになれば幸いです。

質疑

いただいた質問と回答を紹介します。

時間切れ前に頂いたため回答できなかったご質問への回答や、登壇中回答したけれどもブログ化にあたって回答を補足したものもあります。
登壇中うまく回答出来なかった点に補足いただいた同僚たちに深く感謝いたします。

Q: SSM Incident Managerは主にEC2への対処で使われるケースが多いかと思いますが、サーバーレス（Lambda, DynamoDB, API Gateway, Appsyncなど）やコンテナ（ECS Fargateなど）で組んでいるシステムでの導入事例などはありますでしょうか？

始まったばかりのサービスということもあり、事例は存じ上げていません。 しかしながら、EC2以外のサーバーレスのサービスたちに関してもインシデント起票、Automationの起動、エスカレーション電話、等などの機能を利用することができます。 これからが楽しみなサービスだと思います。

+++

Q: AutomationのRunbookで外部サービス(Postmanなど)を呼び出すことは可能でしょうか？
SyntheticでのAPIコールがStatus:200以外の場合にアラームを投げて、動作確認のための退行テストを自動で流す、というような運用ができないかと考えています。

可能です。AutomationでLambda関数を起動することができます。

+++

Q: CloudWatchダッシュボードは環境の規模の大きさによらず有用でしょうか？一定以上の規模になると、ダッシュボードで目視チェックは厳しい等の感覚があれば教えてください。

規模によってはダッシュボードを分割したり、見たいメトリクスをより絞り込むために設計の検討が必要であったりと工夫する必要はありますが、有用です。

私の肌感覚ですが、規模の大小問わず、自分たちが欲しい情報を一撃でダッシュボード化することはとても難しいと感じています。（こんな登壇タイトルにしておいて恐縮ですが…） 初めはむしろ、本当に役に立つのか？と思うようなこともあるかもしれません。
しかしながら、ある程度練り上げられたダッシュボードから得られる情報は本当に大きいです。
ダッシュボードはチームみんなで育てていく必要があります。 まず最初に誰かがたたき台的なダッシュボードを作り、みんなで自分たちに本当に必要な情報を考え、初めて自分たちのシステムにマッチしたダッシュボードが得られるんだと思います。

出来上がったダッシュボードは朝会でみんなで眺める、とかもオススメです。システムの置かれている状況が共有できて実務上役に立ちますし、愛着もわきますよ。

お手本になりそうなブログ記事をご紹介させていただきます。
CloudWatchダッシュボードを利用してオートスケール環境の稼働状態を可視化してみた | DevelopersIO

+++

Q: 監視用の設定はマネコン画面から実施されていますでしょうか？　複数環境などに同様の設定を入れるような場合に「同じように」設定できているか不安になりそうです。（CLIなどの利用有無等）

監視やダッシュボードの設定はCLIやCloudFormationによるIaC化が可能です。
手作業がご不安なのはよくわかります！ CloudFormationを利用したブログがDevelopersIOにも有りましたのでご参考ください。

CloudFormation で AWS Chatbot と CloudWatch Alarm を定義してSlackにアラート通知してみた | DevelopersIO

CloudFormationを利用してCloudWatchダッシュボードを設置してみた | DevelopersIO

put-metric-alarm — AWS CLI 1.19.100 Command Reference

Q: 設定内容の把握・整理はどのように実施されていますでしょうか？また、設定値に対するレビューなどを実施されているのかという点が気になりました。

IaC化するのでプルリクエストを用いたレビューが可能です。
現職ではなく過去の経験ですが、例えばまだ開発中で本番運用後の負荷状況が予測できないような場合、
初めにある程度エイヤで入れてしまって、運用開始後にみんなでダッシュボードを見ながら改めて設定値を検討し、調整をしていました。 ダッシュボードがあると、しきい値等の根拠にしやすいのでいいと思います。

まとめ

「アラート対応で疲弊してるチームが今できること」というタイトルで登壇させていただきました。

もし気になるツールがあればちょっとだけ触ってみてください。しんどかった監視運用の改善、やっていきましょう！