オンコール担当がインシデントコマンダーを担う仕組みづくり

オンコール担当が インシデントコマンダーを担う仕組みづくり 株式会社ユーザベース 安藤 裕紀 Incident Response Meetup vol.1 - 2024.1.16(Tue)

00 自己紹介 安藤裕紀 / あんどぅ 株式会社ユーザベース NewsPicks事業 SRE Unit Leader SREチームのマネージャー 兼 テックリード 好きなSREのプラクティス：非難なきポストモーテム文化 特技：AWSコスト削減、障害対応を愚直に100本ノックすること 座右の銘：「質は量から生まれる。逆はない」 ©Uzabase, Inc. All Rights Reserved.

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

00 目次 1. 障害対応の体制など 2. NewsPicksの障害対応とインシデントコマンダーの動き 3. まとめ ©Uzabase, Inc. All Rights Reserved.

01 障害対応の体制など ©Uzabase, Inc. All Rights Reserved.

01 NewsPicksのプロダクト開発組織、エンジニア体制 ユーザベースグループ内にNewsPicks独自のプロダクト開発組織があり、70名ほどのエンジニアが在籍しています ユーザベースグループ(約1,200名※業務委託含む) NewsPicks Product Domain (15Unit 約100名) プロダクト マネージャー NewsPicks Product Engineering Division(11Unit 約70名) Media Experience Unit Media Infrastructure Unit Subscription Product Unit NPEx Product Unit SBD Product Unit BDD Product Unit Stage Product Unit Web Platform Unit デザイナー カスタマーサポート ©Uzabase, Inc. All Rights Reserved. Mobile App Unit Analytics and Data Lab Unit SRE Unit 私はこのチームのリー ダーをやりつつ、運用や 障害対応の仕組みの改善 に取り組んでいます

01 障害対応に関わる役割：運用当番 ● NewsPicksのエンジニアは全員がプロダクト志向で開発から運用までフルサイクルに関わる ● 経済ニュースのサービスなので、24h/365dのオンコールシフトを組んでいる (PagerDutyで管理) ● 運用当番は、障害が発生した際の一次切り分けとエスカレーション、状況報告を推進する モバイルアプリ担当1名、 サーバー担当2名の3名が『運用当番』 ©Uzabase, Inc. All Rights Reserved.

01 障害対応に関わる役割：運用当番 ● 運用当番（オンコール担当）が、インシデントコマンダーとして障害を解決に導くことを期待 ● 障害に伴うコミュニケーションのとりまとめを行い、ポストモーテム（障害撲滅委員会）の 開催判断をする 運用当番になると、こんなSlack通知がきます ©Uzabase, Inc. All Rights Reserved.

01 ● 余談：障害対応に関わる単語の呼称 NewsPicksでは障害発生時に記者・編集者などビジネスサイドとのやりとりが発生するため、 意味が通じやすい日本語の呼称になっている気がします。(ビジネス職メンバーは数百名在籍) ● 障害対応に関わる単語の呼称 ○ オンコール担当：『運用当番』 ○ ポストモーテム：『障害撲滅委員会』 ○ War Room：『障害対応優先スペース』 障害報告・問い合わせチャンネルのリマインダー ©Uzabase, Inc. All Rights Reserved.

01 NewsPicksの障害対応と インシデントコマンダーの動き ©Uzabase, Inc. All Rights Reserved.

02 ● NewsPicksの障害対応の流れ ? 運用当番がアラートを受けて、暫定復旧までは対応する システムのアラート (bugsnag->PagerDuty, New Relic) BizメンバーのSOS (Slack->PagerDuty) ©Uzabase, Inc. All Rights Reserved. 運用当番 （オンコール担当） が一次切り分け・ 担当チームアサイン・ 暫定復旧作業 障害撲滅委員会 開催 （ポストモーテム） 担当チームで開発の バックログとして対応

02 ● 運用当番のスキルとオーナーシップが人によって違っていた ? 運用当番がアラートを受けて、暫定復旧までは対応する システムのアラート (bugsnag->PagerDuty, New Relic) BizメンバーのSOS (Slack->PagerDuty) ©Uzabase, Inc. All Rights Reserved. 運用当番 （オンコール担当） が一次切り分け・ 担当チームアサイン・ 暫定復旧作業 運用当番 「担当チームがどこなのかわからない… 自分でログを見ようとしたけど時間が かかってわからなかった…」 「担当チームにエスカレーションしたから 後のことは任せよう」 「俺が問題を解決する！→解決した！！」 障害撲滅委員会 開催 （ポストモーテム） 担当チームで開発の バックログとして対応

02 障害対応は信頼性の要なので、「人による」をなくしたい SRE Bookの信頼性の階層 「ユーザーがサービスを使えない時間」の内訳 ● 障害の検知までの時間がかかるとダウンタイムが伸び る（監視） ● 検知から適切なエンジニアのアサインまでの時間がか かるとダウンタイムが伸びる（障害対応） ● エンジニアのアサインから暫定復旧までの時間がかか るとダウンタイムが伸びる（障害対応） ©Uzabase, Inc. All Rights Reserved.

• https://sre.google/sre-book/part-III-practices/

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

02 参考：インシデントコマンダーについてのドキュメント PagerDutyのドキュメントがめちゃくちゃ参考になります 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/

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

02 NewsPicksのインシデントコマンダーの動き（２／２） 運用当番がSlackの障害チャンネルに関係者の対応状況を常に更新します Bizメンバーとの連絡担当がいなければBizメンバーとの業務影響確認・復旧確認も行います 障害対応体制の解散を宣言します ©Uzabase, Inc. All Rights Reserved.

02 インシデントコマンダー難しくありません。誰でもできるはず 実はシステムの深いドメイン知識や技術力やログ調査は必要なかったです 関係者とのコミュニケーションを取りまとめて、障害を解決するように推進するだけ そのために『運用当番のお知らせ』のSlack通知に必要な心構えや対応を書くようにしました オンコールを運用するSlack通知の実装の詳細は記事に書きました 「PagerDutyのオンコールシフトをSlackでリマインドする〜TypeScriptとAWS CDKで実装〜」 ©Uzabase, Inc. All Rights Reserved.

• https://qiita.com/yuki549/items/3a2a6beeb78a43401b97

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

03 ● インシデントコマンダーを、SREくらい有名にしたい 運用当番（オンコール担当）にインシデントコマンダーの役割を担ってもらう期待を明文化した ○ プロダクト開発組織で運用当番がやるべき仕事についての解像度が上がってきた ■ ログ調査はメインの責務ではないので自分で手を動かしはじめない ■ とにかくGatherの障害対応優先スペース（枯山水）に人を集める ■ Slackの障害対応スレッドに状況をアップデートして、 関係者とのコミュニケーションを取りまとめて障害対応を推進する ■ ● 障害撲滅委員会（ポストモーテム）の開催判断と、積極的な運営をする まずは「インシデントコマンダーは何をするの」に対して、「SREってなんとなくこういう役割だ よね」というイメージのように、期待される役割のイメージを普及していきたい ○ その上で、必要なドキュメント・ツール・トレーニングを整備していきたい（これから） ©Uzabase, Inc. All Rights Reserved.

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