AWS Summit Japan 2024のPagerDuty株式会社様によるセッションに参加してきました！

セッションタイトルは、、、

「インシデント対応を 10 倍速くする方法、教えます – PagerDuty と AWS で爆速障害対応」

普段からAWSの運用業務に関わっている方なら、かなり気になるタイトルではないでしょうか？

私はこのタイトルを見た瞬間、セッション予約をしました。笑

私なりの解釈も交えながら感想を書いていきたいと思います。

インシデントコマンダー

今日はこれだけは覚えて帰ってください！！

「インシデントコマンダー」

なんだか可愛いキャラクターと共に紹介されたこの言葉皆さんはご存知でしょうか？

インシデントコマンダーとは

・インシデント対応の指揮者

・重大インシデントを解決に導くことを目的とし、意思決定を行う

・日々の地位に関係なく、重大インシデントでは最も位の高い人

私が特に注目したのが、「日々の地位に関係なく、重大インシデントでは最も位の高い人」です。

重大インシデントに限っては、インシデントコマンダーが絶対です。

たとえCTOが横から指示を出そうとも、最も位の高い人はインシデントコマンダーです。

手を動かすな

インシデントコマンダーに任命されたら直接手を動かしてはいけません。

コマンドを実行したり、ログの調査をするような手を動かすことは作業担当に委譲しましょう。

なぜ手を動かしてはいけないのか？

インシデントを解消していくには、たくさんの関係者と連携する必要があります。

お客様から「いつ復旧するんだ！」別チームから「何が起きてるんだ？」CTOから「一体どうなってるんだ！！」

こんな問い合わせがインシデントコマンダーに集中します。

（経験者ならわかる胃が痛くなるやつ）

そんな問い合わせに回答しながら、手を動かせるでしょうか？

答えはNOだと思います。

手を動かしたくなる気持ちをぐっと抑えて、全体の指揮者となり交通整理を行いましょう。

インシデントコマンダーを助けるPagerDuty

手を動かさなくてもインシデントコマンダーは大変です。

そこで登場するのがPagerDutyです。

インシデント対応の交通整理を行う上で、PagerDutyは強力なツールとなるようです。

機能別に説明を見ていきましょう。

情報の集約

インシデント対応をするとき見るべき情報は大量にあります。

New Relic、Datadog、AWSなどなど

現在では多くのサービスがあるので情報が分散され、全体を俯瞰して見ることができません。

そんな時はPagerDutyにすべてを集約しましょう。

PagerDutyはあらゆるツールと連携できるため、状況把握が楽になります。

トリアージ

情報を集約しても大量にアラートが出ていたらどれを対処すればいいかわかりません。

そんな時はPagerDutyに自動処理してもらいましょう。

これによって必要なアラートのみに集中して対応することができます。

また、様々な連絡ツール、手段を利用してオンコールをすることができます。

影響範囲の把握

近年のシステムは複雑かつ、様々なサービスが連携されています。

インシデントが発生すると影響範囲を把握するのがとても大変です。

そんな時はService Graph機能を使えば影響範囲を可視化することができます。

ステークホルダーとのコミュニケーション

インシデント対応時は多くのステークホルダーに対して、適切なコミュニケーションを取る必要があります。

1人1人に対して、都度連絡を行っていては追いつきません。

そこでPagerDutyのステータスページ機能を使ってブロードキャストで状況を連絡しましょう。

このページを見ればインシデント対応の状況を必要な粒度で把握することができます。

ステークホルダーの立場を考えれば、今どんな状況なのかわからないことはとてもストレスです。

この機能を使えばインシデントコマンダーもステークホルダーも楽になりそうです。

ポストモーテム

皆さんインシデント対応後のポストモーテム書いてますか？？

対応後は後処理に追われて書いてる暇ないよ。という声が聞こえてきそうです。

ポストモーテムを書くことは根本解決や再発防止、組織の成長に欠かせないと思っています。

PagerDutyを使えばめんどk…大変なポストモーテム作成を支援してくれます。

作成のための情報がPagerDutyに集約されているので、とても楽ですね。

まとめ

普段からPagerDutyを使用していますが、今回の説明にあった機能は全然使えていませんでした。

まずは自チームで使えそうな機能から試してみて、今回学んだことを現場で活かせればと思います。