Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Kazuto Kusama
February 15, 2024

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

Developers Summit 2024で発表した資料です

Kazuto Kusama

February 15, 2024
Tweet

More Decks by Kazuto Kusama

Other Decks in Technology

Transcript

  1. 1. 検知 2. トリアージ 3. 動員 4. 協⼒/解決 5. 学習/予防

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

    Dashboard Buildpack Support(Tier2/Tier3) User app User app User app canary app IRC / Slack チーム全員でウォッチ さまざまな アラート
  3. 24時間体制 深夜であっても休日であっても1チームで運用して いた。 会社としてNOCはあったが、複雑な アーキテクチャを理解してもらうことは 出来ず、10分後に電話かけるくらいしかしてもらえ なかった。 どのチームよりも洗練された運用体制を 作ったため、どのチームよりも早くインフラの障害 に気づくという状態になった

    当時出たばかりの Philips Hueでアラートが起 きると家中の照明をパカパカさせてた NOCにこれを理解して貰うの無理 ※注 これはNOCを責めているわけじゃなく て、複雑なものの運用だけを他のチームに 押しつけるってのは無理だよねと。オー ナーシップは作った人が持つべきだと個人 的には思います
  4. 障害だ! 認証・認可 LB GSLB Monitoring Dashboard Buildpack Support(Tier2/Tier3) User app

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

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

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

    User app User app canary app IRC / Slack • 体制を組んで取り組めばもっと早く解消したのでは? • 思い込みで明後日の方向を切り分けてしまった可能性は? • もし全員が起きなかったらどうなった? • 眠たい頭でミスオペして二次災害が起こる可能性があったのでは? • このノウハウは組織に受け継がれたか? 自分が抜けた後にも役に立つ内容となったか? 様々な組織で同じことが起きている ただ、個人としてではなく組織として見た場 合はどうだろうか。
  8. 言葉の整理 • インシデント→「何らかの原因でユーザーがサービスを正常に利用できない状態」 • システム障害 • ネットワークトラブル • 人的ミス •

    等々 • インシデントは「状態」 • システム障害はインシデントを起こしうる原因のひとつ • インシデントに対応することが重要 (Incident Response) • 障害を完全に解消しないこともありうる
  9. なぜインシデント対応が重要なのか • 世の中におけるサービスの重要性が高まった • APIで連携し合うのはごく普通になってきた。 1つのインシデントがさまざまな場所に波及する 確率も高まってきた • 構成要素の複雑化、障害対応の難化 •

    クラウド、オンプレなどさまざまな選択肢 • コンテナをはじめとしたクラウドネイティブ技術 • マイクロサービス化の流れ • コミュニケーション要素の増大 • 上記の要素により組織が拡大し、コミュニケーションパスが複雑化
  10. 体系的な取り組みが必要不可欠に • 一人(ないしは少数)が単騎で動くことの危うさ • システムの複雑化にともなう対応の長期化 • 暗黙知 • 二次災害の危険性 •

    恒久対応や再発防止策が後回しに • 組織として対応能力を高めていかないといけない • 体系だった指揮系統 • 組織としてのノウハウの継承 • サステナブルな組織作り
  11. 価値の総量の最大化 事業価値とエンジニアリング・リソース効率性とフロー効率性 / Business Value and Engineering https://speakerdeck.com/recruitengineers/business-value-and-engineering-2022 より引用 素早く

    気づく 素早く 直す 将来起きる 問題の防止 インシデントに素早く対応することで、価値の 総量を最大化できます。インシデント対応は 守りのイメージがありますが、実際は開発と同 じ「価値を最大化する行動」なのです。
  12. ヒーローを目指してはいけない 正義の味方 悪の組織 自分自身の具体的な目標がない 大きな夢、野望を抱いている 相手の夢を阻止するのが生き甲斐 目標達成のための研究開発を怠らない 常に何かが起こってから行動 日々努力を重ね、夢に向かって手を尽くして いる

    受け身の姿勢 失敗してもへこたれない 単独〜少人数での行動 組織で行動 いつも怒っている よく笑う 場当たり的なインシデント対応は「正義の味方」的な行動です。解決したときの気 持ちよさもまさにヒーロー。ですが、目指す先はそこではありません。悪の組織に なるべきとは言いませんが、あるべき心持ちは右側です
  13. インシデントコマンダーの役割分担 インシデントコマンダーは、直接手を動かさない。 コマンドを実行したり、修正したり、メトリクスやログを調査したり しない それらの行動は作業担当に委譲する インシデントコマンダー 作業担当 指示 報告 指示

    報告 指示 報告 ◦◦さんはログの 調査 XXさんは影響 範囲の確認 ▲▲さんはサー バーの稼働状況 を見てください ▲ ◦◦出来る人居ますか?じゃなくて、タスクを明示的に アサインする。傍観者効果を防ぐため。
  14. + だと Teams 通話 (ZoomもOK) Slack チャンネル (TeamsもOK) JIRAや ServiceNow

    と連携 必要な環境を自動生成 手作業は少なければ少ないほど良い!
  15. ステークホルダーとのコミュニケーション インシデントコマンダーは、ステークホルダーに対して 適切なコミュニケーションを取る 適切な粒度 = 詳細ではなく、 適切なタイミング = ステータス変化時 +

    定期的 適切な方法 = ブロードキャスト型 インシデントコマンダー CIO ユーザー担当 他チーム ブロード キャスト ブロードキャストすることにより、 関係者が増えても対応工数が増えずに済む。 連絡漏れを防げる
  16. インシデントコマンダーの権限 インシデントコマンダーは、ステークホルダーに対して 適切なコミュニケーションを取る インシデントコマンダー CEO / CIO あなたはインシデント対応に あたって不適切なので、通話 から退出いただきます

    インシデントコマンダーは、重大インシデント の最中においてはCEOやCIOよりも偉い人 です。現場をかき回す人は、 CEOであっても 強制的に退出させる厳格さを持つべきで す。
  17. + だと Process Automation Process Automation (On-Prem版) またはRunbook Automation (SaaS版)

    により、 複数のステップや各ステップの実行結果によって後続の処理を 分岐させるような複雑なワークフローの Jobの作成・実行が可能。 1. Jobを整備: SME • スクリプト • API • コマンド実⾏ サポート 契約社員 AIOps SRE Dev 2. Jobの実⾏指⽰ (PagerDutyまたは API経由) 3. Jobを実⾏ 4. 実⾏結果を通知
  18. ポストモーテム SREのプラクティスでおなじみ • インシデントのインパクト • 緩和や解消のために行われたアクション • 根本原因 • インシデントの再発を避けるためのフォローアップ

    きちんと纏めておくことで、組織としての成長に繋がる。スタンドプレーだとこのあたりの取り組みが 行われないことが多い
  19. インシデントコマンダーになれる人はどんな人か システムの深い技術知識は必要なし。 インシデントコマンダーの役割はインシデント対応を調整することであって、 技術的な変更を行うことではない • コミュニケーションスキル • サービスがどのように連携しているかの理解 • 状況を判断して、行動方針に対する迅速な意思決定ができる

    • フィードバックに耳を傾け、必要に応じてその場で計画を変更できる柔軟性がある • 直近の2つの重大インシデントに、見学または対応者として関わっている • 指揮を執り、CEOであっても通話の妨げとなる人を通話から追い出すことのできる厳格さがあ る
  20. 教育・育成 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
  21. PagerDuty Copilot https://www.pagerduty.co.jp/copilot/ • AWS re:Invent 2023にて発表 • 生成AIによる自動化支援の機能群 ◦

    AIアシスタント ◦ 自動化ジョブ構築 ◦ ステータスアップデート ◦ ポストモーテム