『全員インシデントコマンダー』の体制構築から 1年経った現在地

16.8K Views

December 17, 24

スライド概要

障害対応の属人化から脱却。全員を巻き込む仕組みづくりの方法
https://levtechlab.connpass.com/event/336442/

profile-image

経済ニュースアプリのSREの仕事をしています。

シェア

またはPlayer版

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

『全員インシデントコマンダー』の体制構築から 1年経った現在地 株式会社ユーザベース 安藤裕紀 2024/12/17 障害対応の属人化から脱却。全員を巻き込む仕組みづくりの方法

2.

00 自己紹介 安藤裕紀 / Yuki Ando 株式会社ユーザベース NewsPicks事業 VP of Platform Engineering SREチームのチームリーダー(プレイングマネージャー) 兼 Platform Engineering グループのエンジニアリングマネージャー 特技:AWSコスト削減や障害対応を愚直に100本ノックすること 好きなSREのプラクティス:非難なきポストモーテム文化 Incident Response Meetupという障害対応のイベントを運営しています ©Uzabase, Inc. All Rights Reserved.

3.

00 インシデントコマンダーをSREくらい有名にしたいと思ってます Incident Response Meetup #1 ☝ここから1年経ちました! ©Uzabase, Inc. All Rights Reserved. レバテックLABさんのインタビュー記事

4.

00 本日のアジェンダ 1. NewsPicksの開発体制 2. 障害対応への課題意識 3. 障害対応プロセスの整備(インシデントコマンドシステム) 4. ポストモーテムの改善(生成AIの活用) 5. 運用して1年経った現在地 ©Uzabase, Inc. All Rights Reserved.

5.

01 NewsPicksの開発体制 ©Uzabase, Inc. All Rights Reserved.

6.

01 ソーシャル経済メディア NewsPicksについて ©Uzabase, Inc. All Rights Reserved.

7.

01 サービス開始から11年を迎え、1,000万ユーザーを突破 https://corp.newspicks.com/info/20240802 ©Uzabase, Inc. All Rights Reserved.

8.

01 NewsPicksのプロダクト開発組織とエンジニアの体制 ユーザベースグループ内にNewsPicks独自のプロダクト開発組織があり、70名ほどのエンジニアが在籍しています ユーザベースグループ(約1,200名※業務委託含む) NewsPicks事業 プロダクトチーム (約100名) プロダクト開発エンジニア (約70名) XXX事業 開発チーム YYY事業 開発チーム ZZZ事業 開発チーム プロダクト マネージャー デザイナー カスタマー サポート ©Uzabase, Inc. All Rights Reserved. Platform Engineering チーム Web基盤チーム データ基盤チーム モバイルチーム SREチーム 発表者はSREチームのリーダー兼 Platform Engineering 4チームの エンジニアリングマネージャーとして 開発組織全体の障害対応の改善を推進

9.

02 障害対応への課題意識 ©Uzabase, Inc. All Rights Reserved.

10.

02 継続的な「最高の開発者体験」への投資によりデプロイ頻度は増加 リアーキテクチャやCI/CD整備など3年間以上に渡り開発者体験の向上へ投資 デプロイ頻度は2倍以上になり、開発者体験を示すDX Criteriaも大幅に改善 DX Criteria改善の取り組み https://tech.uzabase.com/entry/newspicks-dx-criteria-2023-08 開発生産性可視化SaaSのFindy Team+で 組織全体のデプロイ頻度は「Elite」に! 毎月2〜300回のデプロイが行われる ©Uzabase, Inc. All Rights Reserved.

11.

02 継続的な「最高の開発者体験」への投資によりデプロイ頻度は増加 リアーキテクチャやCI/CD整備など3年間以上に渡り開発者体験の向上へ投資 Elite(非凡)なデプロイ頻度に対して、DevOpsのFour Keysのうち デプロイ頻度は2倍以上になり、開発者体験を示すDX Criteriaも大幅に改善 守りのTwo Keys(変更障害率・平均修復時間)は平凡なDevOpsチーム DX Criteria改善の取り組み https://tech.uzabase.com/entry/newspicks-dx-criteria-2023-08 変更障害率 開発生産性可視化SaaSのFindy Team+で 組織全体のデプロイ頻度は「Elite」に! 毎月2〜300回のデプロイが行われる ©Uzabase, Inc. All Rights Reserved. 平均修復時間

12.

02 デプロイ頻度が高く、変更障害率が普通だとどうなるか ● 毎月200〜300回のデプロイに対して変更障害率が5〜10%なら毎日障害対応でもおかしくない ● 修復時間が伸びたり、ユーザー影響が発生すると毎週2〜3件のポストモーテムが行われる (ポストモーテム好きには福利厚生かもしれない) Eliteなデプロイ頻度 🌟 毎月200〜300回のデプロイ ©Uzabase, Inc. All Rights Reserved. 変更障害率 5%〜10% 毎月10〜30件 revert/hotfix ロールバック・ 障害対応 修復時間 数h〜24h 毎週2〜3件のポストモーテム ユーザー影響 が3割程度

13.

02 『障害のほとんどはデプロイによって引き起こされる』の通り 書籍『エレガントパズル』より ❝障害のほとんどはデプロイによって引き起こされる。❞ したがって、デプロイが増えると障害も増え、結果として インシデント管理、軽減策、ポストモーテムが必要となる ©Uzabase, Inc. All Rights Reserved.

14.

02 毎週2〜3件のポストモーテムはユーザーへの価値提供を阻害する ● ユーザー影響のある障害については、影響の大きさ(時間帯・影響時間)や主要機能の提供可否 など実施基準を定めてポストモーテム(障害撲滅委員会と呼んでいる)を実施している ● デプロイ頻度を高めた結果、障害が増え、障害対応やポストモーテムで開発に使う時間が減って しまうことが開発生産性を損ない、ユーザーへの価値提供を阻害していると考えた ポストモーテムは3〜8名でミーティング開催されており、ある2週間では延べ27名が会議参加 各回3〜8名の 会議出席者 のアイコン ©Uzabase, Inc. All Rights Reserved.

15.

02 障害対応を改善して、プロダクト開発の価値を高めたいと考えた デプロイ頻度だけじゃないエリートDevOpsチームとして、守りのTwo Keysを強化 ● 修復時間の短縮:障害を早期に復旧させ、ユーザー影響を最小化したい 👉 障害対応プロセスの整備(インシデント管理とインシデントコマンダー文化の醸成) ● 変更障害率の低減:障害の発生数を減らしたい 👉 ポストモーテムの改善(一部で生成AIの活用) ©Uzabase, Inc. All Rights Reserved.

16.

03 障害対応プロセスの整備 (インシデントコマンドシステム) ©Uzabase, Inc. All Rights Reserved.

17.

03 NewsPicksの障害対応体制は「全員プライマリオンコール」 チームに関係なくNewsPicksサービス全体のプライマリオンコールを24x7で交代する ● モバイル1名、サーバー2名の3人一組がPagerDutyのオンコールシフトに入る3.5日交代制 ● 2ヶ月に1回程度、「運用当番」としてオンコール担当・プロダクトへの問い合わせ担当になる プロダクト開発エンジニア (約70名) XXX事業 開発チーム YYY事業 開発チーム ZZZ事業 開発チーム Platform Engineering チーム ©Uzabase, Inc. All Rights Reserved. Web基盤チーム データ基盤チーム モバイルチーム SREチーム

18.

03 NewsPicksの障害対応の流れ ? 運用当番がアラートを受けて、暫定復旧までは対応するという「よしなに」な役割 システムのアラート (Bugsnag->PagerDuty, New Relic,CloudWatch) 📟 ビジネスサイドからの 緊急呼び出し (Slack->PagerDuty) ©Uzabase, Inc. All Rights Reserved. 運用当番 (オンコール担当) が一次切り分け・ 担当チームアサイン・ 暫定復旧作業 障害撲滅委員会 開催 (ポストモーテム) 担当チームで開発の バックログとして対応

19.

03 運用当番の障害対応スキルとオーナーシップが人によってばらばら ? 運用当番がアラートを受けて、暫定復旧までは対応するという「よしなに」な役割 システムのアラート (Bugsnag->PagerDuty, New Relic,CloudWatch) 📟 ビジネスサイドからの 緊急呼び出し (Slack->PagerDuty) ©Uzabase, Inc. All Rights Reserved. 運用当番 (オンコール担当) が一次切り分け・ 担当チームアサイン・ 暫定復旧作業 「担当チームがどこなのかわからない… 自分でログを見ようとしたけど時間がかかってわ からずエスカレーションもできなかった…」 「担当チームにエスカレーションしたから、 後のことは任せよう」 「俺が問題を解決する!→解決した!!」 「ビジネスサイドへの状況報告をせずに解散」 障害撲滅委員会 開催 (ポストモーテム) 担当チームで開発の バックログとして対応

20.

03 障害の修正に取り掛かるまでの時間は、プロセスの整備で最小化 書籍『SREの探求』より サービス障害の軽減に要する時間の内訳 障害を検出してから適切なエンジニアが対応を開始するまでの時間の改善 ©Uzabase, Inc. All Rights Reserved.

21.

03 Googleも採用するインシデントコマンドシステムを参考にする 書籍『サイトリライアビリティワークブック』より インシデントコマンドシステム における3Cs ● 対応作業の調整(Coordinate) ● インシデント対応者間、組織内、外 界とのコミュニケーション (Communicate) ● インシデント対応に対するコント ロール(Control)の保持 Coordinate インシデントコマンダーは 3Csに集中する Incident Commander(IC) Communicate Control Communication Lead(CL) Ops Lead(OL) インシデントコマンドシステムは山火事を管理する方法として1968年に消防士によって確立されたフレームワーク https://en.wikipedia.org/wiki/Incident_Command_System ©Uzabase, Inc. All Rights Reserved.

22.

03 ● インシデントコマンダー文化の導入で解決できるのではと考えた 検知から適切なエンジニアのアサインまでの時間がかかるとダウンタイムが伸びる 👉基本的に運用当番が手を動かそうとすることはしない 担当をアサインし、障害の状況をレポートし、関係者を巻き込むことに集中する ● 担当アサインから暫定復旧までの時間がかかるとダウンタイムが伸びる 👉「集合知」と「同期コミュニケーション」を活用する Slackでのやりとりから通話(Gatherの障害対応スペース)にすみやかに切り替えて インシデントコマンダーとしてファシリテーションと意思決定に集中する ©Uzabase, Inc. All Rights Reserved.

23.

03 参考:インシデントコマンダーの動き方についてのドキュメント PagerDutyのドキュメントがとても参考になります(URLは有志の和訳版) https://ueokande.github.io/incident-response-docs-ja/training/incident_commander/ インシデントコマンダーとしての仕事は、他の背景情報や詳細情報を集約して明確な調整をするために、 通話を聞きインシデントのSlackルームを見ます。 インシデントコマンダーは、任意のアクションの実行 や修正をしたり、グラフやログの調査をすべきではないです。 それらのタスクは委譲すべきです。 オンコールのインシデントコマンダーとして通話に参加した場合はアナウンスしてください。 議論を手放さないでください。会話は短くするようにしてください。 他の人からの意見に注意しつつ、あなたの判断が最終決定となります。 もし議論の妨げになる人が通話に参加してきたら追い出してください。 通話の終了をアナウンスしてください。 ©Uzabase, Inc. All Rights Reserved.

24.

03 NewsPicksのインシデントコマンダーの動き(1/2) 障害対応が始まったら、運用当番がSlackの障害チャンネルにスレッドを作り、 関係者をGatherの障害対応スペース(枯山水と呼んでいます)に集める ©Uzabase, Inc. All Rights Reserved.

25.

03 NewsPicksのインシデントコマンダーの動き(2/2) 運用当番がSlackの障害チャンネルに関係者の対応状況を常に更新する(障害状況ボード) ビジネスサイドとの連絡担当がいなければビジネス担当者との業務影響確認・復旧確認も行う 障害対応体制の解散を宣言し、必要なら障害撲滅委員会(ポストモーテム)を招集する ©Uzabase, Inc. All Rights Reserved.

26.

03 インシデントコマンダーの動き方について周知・ドキュメント化 インシデントコマンダーの動きを取り入れた運用当番の障害対応プロセス改善を プロダクト開発組織全体に周知し、ドキュメント化 プロダクト月例会で 発表し、呼びかけ ©Uzabase, Inc. All Rights Reserved.

27.

03 運用当番としてオンコールに入った時の自動Slack通知にも反映 運用当番がインシデントコマンダーとして動くことを期待するメッセージと共に 必要なドキュメント、担当チームの運用体制、事業部の連絡先などの資料を案内 運用当番になると、こんなSlack通知がきます ©Uzabase, Inc. All Rights Reserved.

28.

03 エスカレーション用のドキュメントも整備 オンコールシフト中の専用Slackグループにメンションされると同時に、 システムの運用担当と事業部との対応表が自動で案内 例えば「ニュース記事入稿・配信」の システムで問題が発生し、広告事業の 顧客に影響が発生した場合、インシデ Aチーム ニュース記事入稿・配信 個人課金事業 障害発生箇所 ントコマンダーは作業担当にAチーム Bチーム 法人管理機能 法人事業 を、コミュニケーション担当にCチー Cチーム 広告管理・配信機能 広告事業 ムのメンバーをアサインして対応作業 影響する事業部門 を調整することになる システムの運用と事業部の対応表のイメージ チーム 運用担当システム ©Uzabase, Inc. All Rights Reserved. 担当事業部門

29.

04 ポストモーテムの改善(生成AIの活用) ©Uzabase, Inc. All Rights Reserved.

30.

04 ポストモーテムによる再発防止を機能させて変更障害率を下げたい インシデントコマンダーの導入によってポストモーテムの活性化を期待したが・・・ ● インシデントコマンダーが大変 👉 障害の緊張感の中、会話とテキスト両方のコミュニケーションで情報を集めて障害の状況を 記録しながら、障害対応の調整・判断を行うのはかなり負荷が高い ● ポストモーテムの開催が正直億劫 👉 障害の暫定復旧が終わったことで安堵・疲弊している中で、ポストモーテムを開催するため にチャットの対応記録から議事録に文書化する手間があり、意思の強さが必要 ● ポストモーテムの実施基準の認識が人によってばらばら 👉 ユーザー影響の有無や影響する機能など、大枠の実施基準はあるが、担当者のさじ加減で 開催されないこともあった ©Uzabase, Inc. All Rights Reserved.

31.

04 インシデントコマンダーの当意即妙な技芸の再現性を高めたい 運用当番がSlackの障害チャンネルに関係者の対応状況を常に更新する(障害状況ボード) ビジネスサイドとの連絡担当がいなければビジネス担当者との業務影響確認・復旧確認も行う 障害対応体制の解散を宣言し、必要なら障害撲滅委員会(ポストモーテム)を招集する 障害対応の中、リアルタイムに情報収集と判断をし、コミュニケーションと記録を行 い、収束後に「ポストモーテムやるぞ!」となるには経験と余裕が必要 ©Uzabase, Inc. All Rights Reserved.

32.

生成AIでなんとかできないものか🤔

33.

04 ユーザベースではSlack環境にChatGPT Botが統合されている Azure OpenAI Serviceのプライベート環境で稼働し、 Slackチャンネルから呼び出して利用できる社内ツール ©Uzabase, Inc. All Rights Reserved.

34.

04 障害の状況やポストモーテムに記録する内容をスレッドから要約 カスタム指示で、特定のemoji メンションで要約 障害対応スレッド内からemojiメンション メンションするだけで障害状況フォーマットに スレッドから情報を収集してテキストが埋まる ©Uzabase, Inc. All Rights Reserved.

35.

04 インシデントコマンダーの補佐役としての生成AI インシデントコマンダーがポストモーテムの開催判断をする余力を作り判断を助ける ● インシデントコマンダーが大変 👉 障害の緊張感の中、会話とテキスト両方のコミュニケーションで情報を集めて障害の状況を 記録することを助け、障害対応の調整・判断に集中できるようになる ● ポストモーテム開催が正直億劫 👉 ポストモーテムを開催するためにチャットの対応記録から議事録に文書化する手間を省き、 ポストモーテム開催のハードルを下げインシデントコマンダーの余裕ができる ● ポストモーテムの実施基準の認識が人によってばらばら 👉 ユーザー影響の有無や影響する機能など、実施基準が障害の要約時にリマインドされるので 担当者の認識や記憶によらずポストモーテム開催できるようになる ©Uzabase, Inc. All Rights Reserved.

36.

05 運用して1年経った現在地 ©Uzabase, Inc. All Rights Reserved.

37.

02 障害対応が難しいのは変わらない。高速な仮説検証の繰り返し 書籍『サイトリライアビリティエンジニアリング』より ❝形式的には、トラブルシューティングのプロセスは、❞ 仮説演繹法の応用と考えることができます。 システムに関する一連の観察結果と、システムの挙動を把握 する理論的な基盤を基に、障害の原因についての仮説を立 て、その仮説を検証するというプロセスを繰り返します。 ©Uzabase, Inc. All Rights Reserved.

38.

04 障害対応の仮説検証の繰り返しの中で、インシデントコマンダーを担うことで 対応できることが増えていき、エンジニアの問題解決力が高まっている トラブルシューティングのプロセス(SRE本より) ● 問題の報告 トリアージ ● 検証 ● 診断 回復 ©Uzabase, Inc. All Rights Reserved. テスト/対処 ● トリアージ:どこで問題が発生しているかを特定する ○ スマホアプリ・ Web・バックエンド・ DB・データ基盤 まで一気通貫で切り分け、特定していくやり方を覚える 検証:コンポーネントの動作を検証する ○ 広告や検索バックエンドなど、普段の開発チームでは触らな いシステムの箇所の動作検証の方法を覚える 診断:正常に動作しているかを判断する ○ ユーザー視点で QA方法・動作確認手段について、 担当チームに依頼しなくてもできるようになる テスト/対処:可能性が高い順番に、復旧作業を実行する ○ 実際の復旧作業は担当チームに任せるが、 ワークアラウンドのパターンを覚えることで 暫定復旧策を立案できるようになる

39.

ご清聴ありがとうございました! ©Uzabase, Inc. All Rights Reserved.