サービスの危機に立ち向かうリーダーシップ～インシデントコマンダーの役割と戦略～

by Kazuto Kusama

Slide 1

Slide 1 text

サービスの危機に立ち向かうリーダーシップ～インシデントコマンダーの役割と戦略～ PagerDuty Kazuto Kusama @jacopen

Slide 2

Slide 2 text

Kazuto Kusama @jacopen Product Evangelist @PagerDuty Japan Organizer @Platform Engineering Meetup Founder @Cloud Native Innovators Association

Slide 3

Slide 3 text

みなさんってご存じでしたか？

Slide 4

Slide 4 text

1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防ライフサイクル全体を通して、インシデントの状況をリアルタイムで可視化インシデントを特定⾃動処理運⽤改善のための知⾒を提供最適な担当者に通知迅速な解決を⽀援あらゆるツールからイベントを受信架電、 SMS、メール Appプッシュ通知、チャット⾃動エスカレーションスケジュール管理診断‧修復作業の⾃動化チーム内外と円滑に連携クラウドコンテナマイクロサービスネットワークアプリ‧サービスセキュリティデータベースサーバーソーシャル PagerDuty Operations Cloud インシデントをより早く‧少ないリソースで解決 / 将来のインシデントを未然に防ぐ担当者が最適な通知⽅法を選択対応履歴 MTTA/MTTR 分析担当者の負荷状況ポストモーテム解決のヒントを提⽰ ● 過去の類似インシデント ● 直近の構成/コード変更 ...etc. 80%-99% ノイズ削減 700+ Integrations

Slide 5

Slide 5 text

今日覚えて帰ってほしいこと① インシデント対応には

Slide 6

Slide 6 text

今日覚えて帰ってほしいこと② これからはインシデントコマンダーの時代

Slide 7

Slide 7 text

突然ですが皆さんはエンジニアとしてどうやって育ちましたか？

Slide 8

Slide 8 text

自分は障害対応で育ちました!

Slide 9

Slide 9 text

これまで何をやってきたか • 某会計システムの会社でカスタマーエンジニア • スタートアップ企業で何でも屋・ひとり情シス • 某通信事業者でPaaSの開発・運用リードエンジニア • Pivotal / VMwareでプロフェッショナルサービス • HashiCorpでプリセールスエンジニア • PagerDutyでプロダクトエバンジェリスト (Now)

Slide 10

Slide 10 text

クラウドサービスを作っていたとき Cloud Foundryを活用したPaaSの開発。コアの構築および周辺機能の開発。 IaaSは社内の別部隊が運用。その上にPaaSをデプロイする形。そのPaaSの上にユーザーのアプリがデプロイされる。機能の開発だけでなく運用も全て担当 IaaS(別チーム) PaaS(うち) 認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) canary app User app User app User app

Slide 11

Slide 11 text

クラウドサービスを作っていたとき Scrumで普段のイテレーションを回しつつも運用をしているので常に臨戦態勢。 IaaS(別チーム) PaaS(うち) 認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) User app User app User app canary app IRC / Slack チーム全員でウォッチさまざまなアラート

Slide 12

Slide 12 text

24時間体制深夜であっても休日であっても1チームで運用していた。会社としてNOCはあったが、複雑なアーキテクチャを理解してもらうことは出来ず、10分後に電話かけるくらいしかしてもらえなかった。どのチームよりも洗練された運用体制を作ったため、どのチームよりも早くインフラの障害に気づくという状態になった当時出たばかりの Philips Hueでアラートが起きると家中の照明をパカパカさせてた NOCにこれを理解して貰うの無理 ※注これはNOCを責めているわけじゃなくて、複雑なものの運用だけを他のチームに押しつけるってのは無理だよねと。オーナーシップは作った人が持つべきだと個人的には思います

Slide 13

Slide 13 text

障害発生!

Slide 14

Slide 14 text

障害だ！認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) User app User app User app canary app アラート IRC / Slack そんな中、深夜に障害が発生します。大量のSlackアラートで叩き起こされ、その瞬間頭フル回転。アドレナリンどばー。現象の確認と影響範囲の確認を進めて状況の把握に努めます

Slide 15

Slide 15 text

障害だ！認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) User app User app User app canary app アラート IRC / Slack 原因をつきとめるべく切り分けを実施。でも、色々複雑なシステムなのでひたすら試行錯誤。 LBか？･･･でもメトリクスは問題無いように見える。 GSLB?いや、そこが原因ならもっと他の影響が出るはず･･･アプリをホストしているインスタンスがおかしい？･･･いや、問題無さそうだ。 IaaSも問題無い。モニタリング側の問題？いや、実際に影響は起きてるからそっちは問題じゃないじゃあ何なんだ、どこが問題なんだ。頭フル回転で対応するがなかなか原因が見つからない。ちょっとこれは手詰まりか･･･と空を見上げ、フゥとため息をついた瞬間、ハッと気づく。あぁ、アレが原因なんじゃないか。調べてみるとビンゴ。暫定対処を行って無事障害解消。

Slide 16

Slide 16 text

解決！

Slide 17

Slide 17 text

本当にこれで良かったのか？ 🤔

Slide 18

Slide 18 text

めちゃくちゃ知識と経験はつく認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) User app User app User app canary app アラート IRC / Slack 一エンジニアとしてはめちゃくちゃ知識と経験がついた。インフラレイヤーからミドルウェア、アプリまで幅広く知識を持って対処する。苦戦したとしても、それを解消した瞬間の気持ちよさは最高

Slide 19

Slide 19 text

何もいい話じゃない認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) User app User app User app canary app IRC / Slack ● 体制を組んで取り組めばもっと早く解消したのでは？ ● 思い込みで明後日の方向を切り分けてしまった可能性は？ ● もし全員が起きなかったらどうなった？ ● 眠たい頭でミスオペして二次災害が起こる可能性があったのでは？ ● このノウハウは組織に受け継がれたか？自分が抜けた後にも役に立つ内容となったか？様々な組織で同じことが起きているただ、個人としてではなく組織として見た場合はどうだろうか。

Slide 20

Slide 20 text

今日の講演の目的インシデント対応を進化させて、世の中に少しでも貢献したいその中で、PagerDutyが貢献出来るところを紹介したい

Slide 21

Slide 21 text

おや？ • 主語が変わってる？ • 障害対応→インシデント対応

Slide 22

Slide 22 text

言葉の整理 • インシデント→「何らかの原因でユーザーがサービスを正常に利用できない状態」 • システム障害 • ネットワークトラブル • 人的ミス • 等々 • インシデントは「状態」 • システム障害はインシデントを起こしうる原因のひとつ • インシデントに対応することが重要 (Incident Response) • 障害を完全に解消しないこともありうる

Slide 23

Slide 23 text

なぜインシデント対応が重要なのか • 世の中におけるサービスの重要性が高まった • APIで連携し合うのはごく普通になってきた。 1つのインシデントがさまざまな場所に波及する確率も高まってきた • 構成要素の複雑化、障害対応の難化 • クラウド、オンプレなどさまざまな選択肢 • コンテナをはじめとしたクラウドネイティブ技術 • マイクロサービス化の流れ • コミュニケーション要素の増大 • 上記の要素により組織が拡大し、コミュニケーションパスが複雑化

Slide 24

Slide 24 text

体系的な取り組みが必要不可欠に • 一人(ないしは少数)が単騎で動くことの危うさ • システムの複雑化にともなう対応の長期化 • 暗黙知 • 二次災害の危険性 • 恒久対応や再発防止策が後回しに • 組織として対応能力を高めていかないといけない • 体系だった指揮系統 • 組織としてのノウハウの継承 • サステナブルな組織作り

Slide 25

Slide 25 text

価値の総量の最大化事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering https://speakerdeck.com/recruitengineers/business-value-and-engineering-2022 より引用リクルートさんが出している資料からの引用です。グラフの面積が生み出した価値の総量とすると、インシデント中の価値はぽっかりと空いてしまうといえます。

Slide 26

Slide 26 text

価値の総量の最大化事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering https://speakerdeck.com/recruitengineers/business-value-and-engineering-2022 より引用素早く気づく素早く直す将来起きる問題の防止インシデントに素早く対応することで、価値の総量を最大化できます。インシデント対応は守りのイメージがありますが、実際は開発と同じ「価値を最大化する行動」なのです。

Slide 27

Slide 27 text

ヒーローを目指してはいけない正義の味方悪の組織自分自身の具体的な目標がない大きな夢、野望を抱いている相手の夢を阻止するのが生き甲斐目標達成のための研究開発を怠らない常に何かが起こってから行動日々努力を重ね、夢に向かって手を尽くしている受け身の姿勢失敗してもへこたれない単独〜少人数での行動組織で行動いつも怒っているよく笑う場当たり的なインシデント対応は「正義の味方」的な行動です。解決したときの気持ちよさもまさにヒーロー。ですが、目指す先はそこではありません。悪の組織になるべきとは言いませんが、あるべき心持ちは右側です

Slide 28

Slide 28 text

インシデントコマンダーそこで重要になってくるのが、インシデントコマンダーです。

Slide 29

Slide 29 text

インシデントコマンダーのもと、体系的な対応をするインシデントコマンダーは、インシデント対応の指揮者。重大インシデントを解決に導くことを目的とし、意思決定を行う。日々の地位に関係なく、重大インシデントでは最も位の高い人インシデントコマンダー作業担当

Slide 30

Slide 30 text

価値を最大化する人 = インシデントコマンダー事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering https://speakerdeck.com/recruitengineers/business-value-and-engineering-2022 より引用素早く気づく素早く直す将来起きる問題の防止なぜ位が高いかというと、価値の最大化をする人だから

Slide 31

Slide 31 text

インシデントコマンダーの役割分担インシデントコマンダーは、直接手を動かさない。コマンドを実行したり、修正したり、メトリクスやログを調査したりしないそれらの行動は作業担当に委譲するインシデントコマンダー作業担当指示報告指示報告指示報告 ○○さんはログの調査 XXさんは影響範囲の確認 ▲▲さんはサーバーの稼働状況を見てください ▲ ○○出来る人居ますか？じゃなくて、タスクを明示的にアサインする。傍観者効果を防ぐため。

Slide 32

Slide 32 text

何故直接手を動かさないのかインシデントを解消していくには、たくさんの人たちと連携していく必要がある。一人で作業をしながら、他の人の対応をするのは無謀。どちらかが犠牲になる CIO 一体どうなってるんだ! 現状を教えてください！今何が起きてるの！スココンスココンアラート動かない！ユーザー担当別チームユーザー

Slide 33

Slide 33 text

インシデントコマンダーは意思決定と交通整理インシデントコマンダーがインシデント対応の最高責任者として、全体の交通整理を行う。作業担当には作業に専念してもらう。作業したくなるICも居ると思うが、そこはぐっとこらえる。それが最速への道インシデントコマンダー作業担当 CIO ユーザー担当別チームユーザー

Slide 34

Slide 34 text

インシデントコマンダーは意思決定と交通整理インシデントコマンダーがインシデント対応の最高責任者として、全体の交通整理を行う。作業担当には作業に専念してもらう。作業したくなるICも居ると思うが、そこはぐっとこらえる。それが最速への道インシデントコマンダー作業担当 CIO ユーザー担当別チームユーザーここがボトルネックにならないか？なります

Slide 35

Slide 35 text

インシデントコマンダーを助けるPagerDuty インシデントコマンダーがインシデント対応の最高責任者として、全体の交通整理を行う。作業担当には作業に専念してもらう。作業したくなるICも居ると思うが、そこはぐっとこらえる。それが最速への道インシデントコマンダー作業担当 CIO ユーザー担当別チームユーザー PagerDutyがあることによって、とても楽になる

Slide 36

Slide 36 text

影響範囲の把握インシデントが他のサービスに影響を及ぼしている可能性もある。その場合、影響が起きているサービスとも連携しながら対応を行う必要がある。インシデントコマンダーが状況を取りまとめて、必要に応じて外部と連携するインシデントコマンダー作業担当別チーム

Slide 37

Slide 37 text

+ だと Service Graph機能で影響範囲の可視化

Slide 38

Slide 38 text

War room インシデント発生時に迅速な意思決定を行っていくために関係者が招集される部屋を作る。物理的な部屋がある場合はホワイトボードとマーカー、スクリーン。加えて会議ブリッジやチャットツールの War roomが作られることもある作業担当 CIO ユーザー担当その他関係者インシデントコマンダー

Slide 39

Slide 39 text

+ だと Teams 通話 (ZoomもOK) Slack チャンネル (TeamsもOK) JIRAや ServiceNow と連携必要な環境を自動生成手作業は少なければ少ないほど良い！

Slide 40

Slide 40 text

ステークホルダーとのコミュニケーションインシデントコマンダーは、ステークホルダーに対して適切なコミュニケーションを取る適切な粒度 = 詳細ではなく、適切なタイミング = ステータス変化時 + 定期的適切な方法 = ブロードキャスト型インシデントコマンダー CIO ユーザー担当他チームブロードキャストブロードキャストすることにより、関係者が増えても対応工数が増えずに済む。連絡漏れを防げる

Slide 41

Slide 41 text

+ だとステータスアップデート機能とステータスページ機能でブロードキャスト

Slide 42

Slide 42 text

インシデントコマンダーの権限インシデントコマンダーは、ステークホルダーに対して適切なコミュニケーションを取るインシデントコマンダー CEO / CIO 一体いつ治るんだまずは再起動しろ XXXは調べたのか誰のせいなんだ

Slide 43

Slide 43 text

インシデントコマンダーの権限インシデントコマンダーは、ステークホルダーに対して適切なコミュニケーションを取るインシデントコマンダー CEO / CIO あなたはインシデント対応にあたって不適切なので、通話から退出いただきますインシデントコマンダーは、重大インシデントの最中においてはCEOやCIOよりも偉い人です。現場をかき回す人は、 CEOであっても強制的に退出させる厳格さを持つべきです。

Slide 44

Slide 44 text

Slide 45

Slide 45 text

要員の管理インシデント対応は長時間にわたることもある。インシデントコマンダーは、要員の体調面に気を配り、適切に休ませる。申告が無くても休ませる。食事や宿泊などの兵站にも気を配ること (実際の手配は委譲したほうが良い ) インシデントコマンダー作業担当

Slide 46

Slide 46 text

+ だと Analytics Dashboard で状況の分析。特定の人に偏っていないかも分かる

Slide 47

Slide 47 text

+ だとオンコールのスケジュールを管理

Slide 48

Slide 48 text

判断を迅速化するための自動化インシデントコマンダーも作業担当も、インシデント発生時はとにかく忙しい。自動化できる定型作業は出来る限り自動化すべし。 (先ほどのWar roomの件もしかり) 一次切り分け類似事例の検索最近入った変更の調査 War room の作成ステータスアップデート

Slide 49

Slide 49 text

+ だと Recent Changes 最近入った変更のサマライズ

Slide 50

Slide 50 text

+ だと Past Incidents 過去の類似インシデント一覧と、発生時期・回数のヒートマップを表示。

Slide 51

Slide 51 text

+ だと Related Incidents 他サービスで現在発生している、関連性の高いインシデントを表示。

Slide 52

Slide 52 text

+ だと Automation Actions 診断や修復を行うスクリプトを定義しておくことで、 PagerDuty上から実行指示、ならびに結果の確認が可能。

Slide 53

Slide 53 text

+ だと Process Automation Process Automation (On-Prem版) またはRunbook Automation (SaaS版) により、複数のステップや各ステップの実行結果によって後続の処理を分岐させるような複雑なワークフローの Jobの作成・実行が可能。 1. Jobを整備: SME ● スクリプト ● API ● コマンド実⾏サポート契約社員 AIOps SRE Dev 2. Jobの実⾏指⽰ (PagerDutyまたは API経由) 3. Jobを実⾏ 4. 実⾏結果を通知

Slide 54

Slide 54 text

ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップきちんと纏めておくことで、組織としての成長に繋がる。スタンドプレーだとこのあたりの取り組みが行われないことが多い

Slide 55

Slide 55 text

+ だと Postmotems ポストモーテムの作成を支援。受信したイベント、ステータスアップデート、インシデントノート、Slackの会話などからタイムラインを作成

Slide 56

Slide 56 text

インシデントコマンダーになれる人はどんな人かシステムの深い技術知識は必要なし。インシデントコマンダーの役割はインシデント対応を調整することであって、技術的な変更を行うことではない • コミュニケーションスキル • サービスがどのように連携しているかの理解 • 状況を判断して、行動方針に対する迅速な意思決定ができる • フィードバックに耳を傾け、必要に応じてその場で計画を変更できる柔軟性がある • 直近の2つの重大インシデントに、見学または対応者として関わっている • 指揮を執り、CEOであっても通話の妨げとなる人を通話から追い出すことのできる厳格さがある

Slide 57

Slide 57 text

今日覚えて帰ってほしいこと① インシデント対応には

Slide 58

Slide 58 text

教育・育成 PagerDutyが出している、インシデントコマンダーのガイド (スクリーンショットは有志による翻訳 ) https://ueokande.github.io/incident-resp onse-docs-ja/training/incident_command er/

Slide 59

Slide 59 text

教育・育成 PagerDuty自身の経験に基づいた運用ガイド PagerDuty社内で使われているドキュメントの編集版 • Full Service Ownership • Incident Response • Customer Service Operations • DevSecOps • Best Practices for On Call Teams • Autoremediation • Postmortems • Operational Reviews • Retrospectives • Security Training • Internal Stakeholder Communications • Business Incident Response

Slide 60

Slide 60 text

教育・育成インシデントレスポンスについては有志による翻訳版がある https://ueokande.github.io/incident-response -docs-ja/

Slide 61

Slide 61 text

PagerDuty Copilot https://www.pagerduty.co.jp/copilot/ ● AWS re:Invent 2023にて発表 ● 生成AIによる自動化支援の機能群 ○ AIアシスタント ○ 自動化ジョブ構築 ○ ステータスアップデート ○ ポストモーテム

Slide 62

Slide 62 text

AIアシスタント ● Slackと連携 ● 会話ベースでAIがインシデント対応を支援 ○ システム影響範囲 ○ 問題の原因 ○ 対応策 ○ 業務影響

Slide 63

Slide 63 text

ステータスアップデート ● ワンクリックで要約作成 ● 連携する相手に合わせて適切な内容でドラフトを作る

Slide 64

Slide 64 text

ポストモーテム ● 報告書のドラフトを自動作成 ● データ収集不要