AI x インシデント管理で拡げるサービスオーナーシップ

Slide 1

Slide 1 text

AI x インシデント管理で拡げるサービスオーナーシップ 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

PagerDutyって知ってますか？

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

Slide 7

Slide 7 text

ノイズ削減: ⼤量のアラートから”インシデント”を特定 1000s of events Suppression, basic deduplication & ﬁltering Event Orchestration Service routing Machine learning alert correlation 80-99% noise reduced Event (= Alert, Signal): 監視ツール等か送られる雑多な情報 Incident: サービスに影響を及ぼしかねない課題。何らかの対応が必要なもの。 7

Slide 8

Slide 8 text

Slide 9

Slide 9 text

オンコール必要なアラートだけに絞り込み電話やSMS、プッシュ通知、Slack など、人それぞれ適した通知一次対応者 (応答がなければ) 二次対応者オンコールのローテーション

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

おれたちDeveloperなんだけど何か関係があるの？

Slide 15

Slide 15 text

製品開発ライフサイクル Build Test Ship Run Dev Ops

Slide 16

Slide 16 text

製品開発ライフサイクル Build Test Ship Run Dev Ops

Slide 17

Slide 17 text

障害のほとんどはデプロイによって引き起こされる “障害のほとんどはデプロイによって引き起こされる。したがって、デプロイが増えると障害も増え、結果としてインシデント管理、軽減策、ポストモーテムが必要となる” エレガントパズル　エンジニアのマネジメントという難問にあなたはどう立ち向かうのかより引用

Slide 18

Slide 18 text

フルサービスオーナーシップ Build Test Ship Run

Slide 19

Slide 19 text

フルサービスオーナーシップとは「コードを書いた者が、その責任を負う」 • 設計と実装の点から見て、テクノロジーに最も精通した人が製品開発ライフサイクル全体の責任を引き受ける運用モデル • 本番環境において自分が書いたコードの責任を負うよう、最もシンプルな形でエンジニアに権限を与える • “You build it, you run it.” Werner Vogels - VP & CTO of Amazon

Slide 20

Slide 20 text

Team Topologies https://martinfowler.com/bliki/TeamTopologies.html より引用

Slide 21

Slide 21 text

“コードに責任を持つ ” メリット • 自分のコードに責任を持つ開発者は、エンドユーザーエクスペリエンスにより大きな影響を及ぼす • 開発者は自分の仕事が顧客だけでなく、ビジネスにも与える影響をよりよく知ることができる • 開発者にとってモチベーションを高めるだけでなく、修正やアップデートのスピードアップにもつながる。 • 二次情報やサポートチケットに頼るのではなく、自分自身で問題を確認できる

Slide 22

Slide 22 text

“コードに責任を持つ ” メリット • 品質管理のループが生まれる • 夜中3時に好んで叩き起こされたい人はいない • 本番環境での責任を果たすため、運用品質を向上させようというモチベーションに繋がる • 組織構造ではなく、提供するものに集中できる • 責任者が誰なのかが明確となる • 組織の変化に対応していく仕組みが出来る

Slide 23

Slide 23 text

“コードに責任を持つ ” メリット • MTTR（平均修復時間）削減につながる • 開発者は不具合の修正に最も適した人材 • 不具合の際には、開発者がラインの先頭に立つ • コードの責任者が明確なら、より少ないメンバーで問題のトラブルシューティングに対応できる • 300人規模のオンライン会議で、コードを最後に修正したのは誰かをトラブルシューティングするような状況から決別できる

Slide 24

Slide 24 text

理想現実

Slide 25

Slide 25 text

そんな簡単にできるものじゃない • 『作った本人が全部やった方が早い』 • それはそう • これだけだと、単に分業を否定しているだけになる • 「専門分野」を活かすことにメリットがあるから、分業が存在する

Slide 26

Slide 26 text

だからAI

Slide 27

Slide 27 text

Slide 28

Slide 28 text

Recent Changes Related Incidents Past Incidents Probable Origins

Slide 29

Slide 29 text

インシデント発生中ってこんな感じ CIO 一体どうなってるんだ! 現状を教えてください！今何が起きてるの！スココンスココンアラート動かない！ユーザー担当別チームユーザー

Slide 30

Slide 30 text

忙しいインシデント対応を助ける生成AI

Slide 31

Slide 31 text

直近で⾏ったシステム変更が障害の原因か？ - Assistant for Slack - サーバーにパッチを当てるランブックを⽣成して - AI Generated Runbooks - Automationの実⾏結果はどうだった？ - Automation Digest - 診断と修復の改善状況報告⽤の Status Updateを作成して - Status Updates - 31

Slide 32

Slide 32 text

インシデント解決と学習の改善最新の情報は？ - Assistant for Slack - ポストモーテムを作成して - Postmortems - このインシデントは以前にも起きた？ - Assistant for Slack - 顧客への影響範囲は？ - Assistant for Slack - 32