「OpsJAWS Meetup#25 インシデント管理」にオンライン参加しました。 今回のイベントはインシデント対応がテーマとのことで、インシデント対応のためのソリューションとして、SystemsManager IncidentManagerとPagerDutyの紹介を中心とした内容になっていました。
schedule
- 19:00 - 19:10 OpsJAWS 運営からご挨拶 OpsJAWS運営一同
- 19:10 - 19:40 Incident Manager を使って実現するインシデント管理 アマゾン ウェブ サービス ジャパン合同会社 上野 涼平 様
- 19:40 - 19:50 Q&A
- 19:50 - 20:20 インシデント対応の成熟度とベストプラクティス PagerDuty株式会社 Solutions Consultant 山田 索 様
- 20:20 - 20:30 Q&A
- 20:30 - 20:40 LT みんなが幸せなインシデント管理 運営 吉井亮
- 20:40 - 20:45 締め OpsJAWS運営一同
Incident Manager を使って実現するインシデント管理
SystemsManagerの機能の一つであるIncidentManagerについてのセッションでした。 私自身はAWSサービスにインシデント対応のためのソリューションがあることを知らなかったのでとてもためになるセッションでした。
資料
AWS Systems Manager Incident Manager で実現するインシデント管理 - Speaker Deck
インシデントとは
そもそもインシデントとは何かといった説明からされていたのが、とてもわかりやすかったです。
- インシデントとはサービスにおける計画外の中断やサービスの中断をもたらすもの
- もう少し具体的にいうと
- サーバがダウンした
- 大量アクセスでレスポンス遅延が発生
- セキュリティインシデント（不正アクセスによる情報流出など）
- 共通するのはとにかくはやく復旧させ、影響を軽減させたいということ
インシデントの対応は以下のようなサイクルを回すと良いという話がありました。
- インシデントの検知とエンゲージメント
- 適切な担当者への連絡と担当者が応答したかの確認
- エスカレーションフローの整備
- 調査と対応
- あちこちに情報があるとやりづらい
- 調査に必要な情報は一元化されているべき
- 自動化されているのが望ましい
- 関係者感でのコミュニケーションの円滑化
- インシデントを分析して次のインシデントにそなえる
- インシデント自体を発生させないための分析など
AWS Systems Manager IncidentManager
インシデントのハンドリングの説明をしたあと、それを実現するためのソリューションとして、AWS Systems Manager IncidentManager（以下IncidentManager）が紹介されました。IncidentManagerとは、AWS Systems Managerの機能の一つでインシデントの解決影響軽減までの時間を短縮することを目的としたサービスになります。
IncidentManagerの全体像についての説明で、先程のインシデントのハンドリングの各フェーズに対応した機能があることが分かりやすく説明されてました。
- CloudWatchやEventBridgeをトリガーにしてイベントが始まる
- インシデントの検知とエンゲージメント
- エスカレーションプランにより設定する
- 調査と対応
- インシデントマネージャー上で必要な情報は一元化される
- AWS Systems Manager Automationと連携しての作業の自動化
- 関係者感のコミュニケーション円滑化
- slackやteamsなどに通知を連携
- インシデントを分析して次のインシデントにそなえる
- インシデントごの分析機能としてテンプレートがあるのでそれに沿って振り返りをする
IncidentManagerの構成要素には以下のものがあります。
- 連絡先
- Eメール、SMS,電話から選択可能
- 言語は英語
- メール等に6桁のコードが表示されるのでそれをIncidentManagerに入力することで、担当者がアサインされる
- 電話は海外の番号からくる
- vcfファイルが公開されているので登録をおすすめ
- エスカレーションプラン
- エスカレーションフローを定義するもの
- 第一連絡者、第二連絡者などを指定
- 時間を指定することで第一連絡者が応答できなかった際に第二連絡者にエスカレーションされる
- 誰かが応答したら後続には連絡はいかない
- オンコールスケジュール
- オンコール担当グループ内でローテーションを設定可能
- １日、週、月の頻度で繰り返し指定が可能
- 夏休みなどの例外設定も可能
- 特定の日だけ別の人に任せることも
- アクティブな曜日を設定できる
- 平日だけ連絡を受けたい等
- オンコールスケジュールをカレンダで確認可能
- チャットチャネル
- インシデントの更新、通知、エンゲージ結果をチャットチャネルにプッシュしてくれる
- インシデントが発生したとき、解決したときなどのイベントにより通知
- 情報受取る以外に、slack,teamsではチャットアプリからaws cli等を実行することも可能
- runbook
- インシデント発生時にrunbookを呼び出し可能
- インシデント対応用のテンプレートもあり
- テンプレートはインシデント対応の一般的なステップが書いてあるので、ステップ毎に実際の処理を記載する
- runbookの補足
- 処理の一式をまとめておくもの
- runbook自体を説明する説明欄はmarkdownで記載
- ステップごとにアクションを定義する
- 自動化処理などを組み込める
- 対応プラン
- インシデントに対応するためのプラン
- 連絡先やエスカレーションプランをこれにまとめる
- どのインシデントにはどの対応プランで対応するかを決める
IncidentManagerで行える基本的なアクションとしては以下のようなものがあります。
- インシデントを作成
- AWSマネジメントコンソールやAPIからインシデントを起票できる
- CloudWatchアラームやEventBridgeトリガーでインシデント発生させることも可能
- 紐づけの際にはどの対応プランを使うかを指定
- インシデントの確認
- インシデントのステータス、影響などが一目でわかるような画面あり
- タイムライン、いつなにが起きたかを確認可能
- インシデント対応にrunbookを使う場合,IncidentManagerのコンソールから操作可能
- インシデント対応(メモの追加)
- 情報を共有したいときにメモを追加できる
- メモはタイムライン上に表示される
- インシデント後の分析
- 対応自体をもっと早める、インシデントを再発させないために振り返りという形で記録として残す
活用例
IncidentManagerの具体的なユースケースについての紹介がありました。私は特にSecurity Hubと連動させて使うやり方がとても良いなと思い、機会があったら使ってみようと思いました。
- case1:CloudWatchアラームトリガーのインシデント
- サービス停止やレスポンス遅延を検知
- アラームをもとにインシデントが作成
- runbookでインシデント対応
- 自動実行、手動実行を組み合わせられる
- チャットチャネル連携することで他のチームが状況を確認できる
- case2：セキュリティインシデント
- GuardDutyなどをSecurity Hubで集約するようなケースでSecurity HubのイベントをEventBridgeで拾ってインシデント起票
- 例えばクリティカルなものだけインシデントとして起票したり
- case3:インシデントの連絡、対応のみにIncidentManagerを利用
- CloudWatchじゃない別のモニタリングツールを使っているケースでIncidentManagerの電話の連絡機能だけ、またはインシデント対応の機能だけを使いたいといったとき
- モニタリングツール側でwebhookを持っていれば、API Gateway+LambdaでIncidentManagerのインシデント起票APIを叩くことも可能
- case4：ユーザ問い合わせで発覚したインシデント
- システム的に検知できず、ユーザからの問い合わせで発覚するパターン
- モニタリング上異常を示してないので対応がバタつきがちだが、こういった場合でもいつものエスカレーションフローを使うことで冷静に対応できる
- slackからインシデント起票APIを実行できる
- インシデント報告用Webページを作って裏でインシデント起票APIを叩くのもあり
- 番外編：とにかくなにかあったら電話連絡だけ受けたい
- 一人情シスで全部自分でやるしかないケースなど
- インシデントごとに対応手順や自動処理をつくる時間がない
- runbookを作る必要なし（runbookの使用は任意）
- エスカレーションプランの設定だけをして、アラームだけ紐付ける
- これで電話連絡を受けることが可能
セッションの後、Q&Aがありました。印象に残ったものを記載しておきます。
Q&A
- 連絡先の登録はCSVなどでまとめてアップロードできる？
- 大量の担当を一気に登録する機能は現時点ではないはず
- IncidentManagerから外部のチケット管理システムに連携可能か？
- チケット管理じゃないが、jira等の一部連携には対応
- ドキュメント上にも対応サービスの一覧あり
- EventBridge,CloudWatchアラーム以外に、OS障害などをトリガーにインシデント起票することは可能か
- CloudWatchLogsにフィルターを設定しカスタムメトリクス及びCloudWatchアラームを作りそれをトリガーとすることは可能
- 短い間に複数アラートを検知した場合の挙動はどうなる？
- IncidentManagerというよりCloudWatchアラームの挙動に依存する。
インシデント対応の成熟度とベストプラクティス
PagerDuty株式会社 Solutions Consultant 山田さんのセッションです。 PagerDutyの紹介を交えつつ、インシデント対応の成熟度やベストプラクティスの紹介がありました。
資料
インシデント対応の成熟度とベストプラクティス - Speaker Deck
pagerDuty概要
インシデント対応ソリューションという分野を作ったのがPagerDutyとのことです。
PagerDutyは以下の課題を解決するソリューションになっています。
- インシデントをより早く少ないリソースで解決する。将来のインシデントを未然に防ぐ
- 人をアサインするだけでは対応工数へのインパクトは少ない。そのため、AIを使って原因を絞り込んだり、自動復旧をするソリューションとなっている
インシデント対応の成熟度
インシデント対応の成熟度についての説明です。
成熟度は以下の４つの段階があり、成熟度が上がるとシステムの信頼性、可用性が上がるとのことでした。
- リアクティブ＝監視を使ってない、ユーザからの連絡等によりインシデントが発覚している状態
- レスポンシブ＝通知は自動化されているが、対応は手動
- プロアクティブ＝通知の自動化だけでなく対応も自動化され、かつインシデントの振り返りをしている
- プリベンティブ＝組織全体にベストプラクティスがいきわたっている。
成熟度をあげるためにPagerDutyは以下のものを提供しています。
- PDでは２つの方法で成熟度向上を支援
- リアルタイム運用のベストプラクティスを公開している
- opsGuidesとして１２のガイドを公開している
- Ops Guides | PagerDuty
- リアルタイム運用のためのソリューション（PagerDuty）の提供
OpsGuideインシデント対応のベストプラクティス
またインシデント対応のベストプラクティスについていくつか紹介がありました。
私もシステム障害時の当番要員として入っていた期間があったので、どれもうなずいてしまう内容ばかりでした。
- オンコール文化をつくる
- 暗黙の原則：エンジニアは一番貴重なリソース。大事に扱う
- 最初に通知するときに通知をチーム全員にするのはアンチパターン、エンジニアに負担をかけている
- チーム全員に通知することで、結果としてMTTA（インシデント発生から人がアサインされるまでの時間）が長くなる
- 最初に通知する人は一人にするのがベストプラクティス
- 通知のエスカレーションは３階層を用意する
- ３階層目までにエスカレーションされるのが極稀なら３階層目にチーム全員を入れるというパターンもある
- 最初に通知するときに通知をチーム全員にするのはアンチパターン、エンジニアに負担をかけている
- 責めない文化・共感・心理的安全性
- 全てのアラートに対応するのは義務ではない
- システムとして通知を受け取れなかった時のためのバックアップの体制をとって、組織的に対応する
- 暗黙の原則：エンジニアは一番貴重なリソース。大事に扱う
- はじめに：これからプロセスを作成する方向け
- インシデントと重大インシデントを定義する
- 重大インシデントの定義を明確にする
- インシデント対応中にこの議論をすると時間がかかり、解決までの時間が長くなる
- 対応者を動員する方法を決める
- 手動でトリガーする方法も用意しておく、顧客やエンジニア自身がインシデントに気づくケースもあるので
- インシデント専用のweb会議とチャットルームを準備しておく
- インシデント対応の役割を定義する
- インシデントコマンダー：決断をする人がいないと解決が進まない。PM等。関係者の同意を取って前に進める
- 記録係：振り返りをしないと良くならないので、各アクションをした際の判断理由などを記録
- ポストモーテムテンプレート
- なぜインシデントがおきたか等の振り返りをする
- 練習＆運用開始
- インシデントと重大インシデントを定義する
インシデント対応のアンチパターンについても紹介がありました。
- アンチパターン
- チーム全員をインシデント対応に呼び出す
- 無駄が多くなるのでローテーションを組んでやる
- エスカレーションをためらう
- インシデント対応中にプロセスについて話し合う
- 原因調査をはじめてしまい、インシデント対応をおろそかにしてしまう
- 事後調査、フォローアップを怠る
- ポストモーテムをするルールを決めておく
- 複数の役割を担おうとする
- 役割を分担してやるべきことをやる
- インシデントコマンダーに深い技術知識を要求する
- システム全体像を把握していればよい
AI/自動化の活用例
PagerDutyではAIを以下のように利用することでユーザの利便性を上げていました。
- 大量のアラート発生時
- AIが一つのインシデントにまとめてくれる
- どこで何がおこっているのか分からない
- 過去の類似インシデントをAIが提示してくれたりする
- 手作業による無駄な時間
- ポストモーテムを自動で作成する機能あり
- 繰り返し発生する作業を自動化する
- AIによる支援機能
- 解決のヒントの提示
- 過去対応した履歴からヒントをAIが提供
- 最近どういう更新をシステムにしたかをAIが提示
- 他のサービスでおこったインシデントの提示
- サービス間で依存関係を設定できる
- 大本の原因と思われる箇所をAIが提示
LT みんなが幸せなインシデント管理
運営の吉井亮さんのLTです。LTなのですが、短い時間の中に学びが詰まったセッションになっていました。
私は特に（待機当番の）持ち回りの公平さの話や報酬の話がとても良いなと思いました。
冒頭で（このLTは）どっちかというと現場の人より偉いひとに聞いてほしい話という風に話されていましたが、聞き終わると確かに納得でした。
資料
OpsJAWS MEETUP25_みんなが幸せなインシデント管理 - Speaker Deck
インシデントとは
- インシデント：ユーザに影響をあたえるもの
- インシデント管理：早期にサービスを復旧させるプロセス
PagerDutyのベストプラクティスに沿った話
PagerDutyのベストプラクティスに沿って運用の心得を話されていました。
- アラート疲れ
- 重要度、緊急度で通知先を変える
- アラート本文に意味をもたせる
- SLOと見比べる
- 月間99.5ならオンコールでもいい
- 月間99.9だとオンコール無理なのでサポートセンターのような体制をつくる
- 手順書がない
- まず回復の手順書
- 証拠保全の手順書
- エスカレーションも手順書のうち
- 分からないときにこの人にエスカレーションする、とか
- 引継ぎしよう
- ライブインシデントドキュメント
- 対面、webMTGで引継ぎ
- つよつよエンジニアに頼らない
- みんなが対応できる体制、手順書つくりをする
- インシデントを繰り返さないようにする
- 一回鳴ったら繰り返さないように根本対策する
- エンジニアも人間
- 肉体的、精神的負担が増えてきたらインシデント対応をはなれてもいい
- 持ち回りの公平さが必要
- 運が悪くて同じ人ばかりが対応してたら変わってあげるなど
- 訓練大事
- 最初はシャドーから
- 適切な研修を受けさせる
- 報酬で報いる
- オンコール対応したら報酬
- 当番になったら対応しなくても報酬
- これが公平性を生み出す
まとめ
個人的に最近、運用をよく考える機会があったので、どの話もとても参考になり、すぐにでも実戦に取り入れられる内容ばかりだなと思いました。 とても勉強になったので、次回のOpsJAWSも期待してます。
以上、とーちでした。
0
