10年モノの24x7サービスにおける障害対応と生成AIの活用

10年モノの24x7サービスにおける 障害対応と生成AIの活用 株式会社ユーザベース 安藤裕紀 2024/9/6 Cloud Operator Days 2024 CLOSING EVENT

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

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

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

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

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

• https://corp.newspicks.com/info/20240802

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チームの エンジニアリングマネージャーとして 開発組織全体の障害対応の改善を推進

01 「全員プロダクト開発エンジニア」という文化 エンジニアが開発から運用までオーナーシップを持ち、常に改善を続ける エンジニアはフルサイクルの問題解決を自走する過程で何度もデプロイを繰り返すことになり、 リリース後にはオンコールで自ら障害対応も行い、サービスを継続的に改善する。 安全かつ高速に開発・リリースでき、問題が発生してもトラブルシューティングできる状態を 追求することが、NewsPicksのユーザーに価値を届けることにつながると考えている。 ©Uzabase, Inc. All Rights Reserved.

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

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.

• https://tech.uzabase.com/entry/newspicks-dx-criteria-2023-08

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. 平均修復時間

• https://tech.uzabase.com/entry/newspicks-dx-criteria-2023-08

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割程度

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

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

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

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

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チーム

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

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

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

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.

• https://en.wikipedia.org/wiki/Incident_Command_System

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

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

• https://ueokande.github.io/incident-response-docs-ja/training/incident_commander/

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

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

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

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

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

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

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

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

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

04 日常の壁打ちに利用したり、チャンネル固有のプロンプトも指定可 基調講演のタイトルの考案は微妙でした ©Uzabase, Inc. All Rights Reserved. カスタム指示でプロンプト可能

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

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

05 まとめ ©Uzabase, Inc. All Rights Reserved.

04 ● 10年モノの24x7サービスにおける障害対応と生成AIの活用状況についてお話しました 障害対応プロセスを改善するためにインシデントコマンドシステムを参考に インシデントコマンダーの役割を明文化し導入した ○ すでに運用当番の何名かがやってみて、「障害対応勉強になる、面白い、自分にもできた」 など好意的なフィードバックをプロダクト開発組織に共有してくれている ● インシデントコマンダーの技芸を、誰でも再現できるように 生成AIによる障害状況の要約をSlackから簡単にできるようにした ○ 要約の精度などは改善の余��があるが、 Slackから誰でもプロンプトを修正できるので、障害対応 にあたって課題を感じたエンジニアが自主的に工夫するなど改善がはじまっている ● 変更障害率・平均修復時間は長期の遅効指標なので、まだ改善の兆候は見られていない ○ デプロイ頻度だけではないエリート DevOpsチームを目指して障害対応も改善していきたい ©Uzabase, Inc. All Rights Reserved.

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