Luupの開発組織におけるインシデントマネジメントの変遷

Transcript

1. 機密・専有情報 株式会社Luupによる個別の明示的な承諾を得ることなく、この資料を使用することを固く禁じます。 Wataru Tsuda / gr1m0h 2024.6.4 Waroom Meetup #1 Luupの開発組織における インシデントマネジメントの変遷
2. Luup, Inc. - Confidential and Proprietary 2 whoami Wataru Tsuda / gr1m0h Reliability Engineer @Luup,inc. SRE Lounge / SRE NEXT Organizar Platform Engineering Meetup Organizar Lives in Hiroshima
3. Luup, Inc. - Confidential and Proprietary 3 0. 事業説明 1. インシデントマネジメントの変遷 2. Notionでのインシデントマネジメント 3. Waroomでのインシデントマネジメント 4. まとめ
4. Luup, Inc. - Confidential and Proprietary 4 0. 事業説明 1. インシデントマネジメントの変遷 2. Notionでのインシデントマネジメント 3. Waroomでのインシデントマネジメント 4. まとめ
5. Luup, Inc. - Confidential and Proprietary 5 LUUPとは 街じゅうの電動マイクロモビリティに、 どこからでも乗れて好きな場所に返せる シェアリングサービス LUUPは電動キックボードと電動アシスト自転車のシェアリングサービスで す。 LUUPのポートは街じゅうに広がっています。駅前や繁華街、住宅街やコン ビニなど、近くのポートから好きなタイミングで借りて、好きな場所に返すこと ができます。 毎日の最寄り駅までの移動や、「歩くには少し遠いな」と感じる場所へ向か うこと、できれば避けたい坂道をのぼることも、 “早く・ラクに・気持ちのよい “ライドに変えることができます。 現在は、東京・大阪・横浜・京都・神戸・名古屋などで展開しており、さらに拡 大を目指しています。
6. Luup, Inc. - Confidential and Proprietary 6 0. 事業説明 1. インシデントマネジメントの変遷 2. Notionでのインシデントマネジメント 3. Waroomでのインシデントマネジメント 4. まとめ
7. Luup, Inc. - Confidential and Proprietary 7 インシデントマネジメントの変遷
8. Luup, Inc. - Confidential and Proprietary 8 インシデントマネジメントの変遷
9. Luup, Inc. - Confidential and Proprietary 9 0. 事業説明 1. インシデントマネジメントの変遷 2. Notionでのインシデントマネジメント 3. Waroomでのインシデントマネジメント 4. まとめ
10. Luup, Inc. - Confidential and Proprietary 10 Notionでのインシデントマネジメント ２０２２年１０月からNotionを利用してインシデントマネジメントを開始 全社的にNotionでドキュメント管理しているのでNotionを選択 以下を実施 - インシデントマネジメントテーブルの用意 - ポストモーテムチェックリストの用意
11. Luup, Inc. - Confidential and Proprietary 11 インシデントマネジメントテーブルの用意 発生したインシデント情報を記録していくテーブル SRE本に記載のポストモーテムの項目を一部Luup用にカスタマイズした情報が記載されている https://sre.google/sre-book/example-postmortem/
12. Luup, Inc. - Confidential and Proprietary 12 ポストモーテムチェックリストの用意 ポストモーテム会議でインシデントを振り返る際に利用するチェックリスト 必要なインシデント情報が適切に入力されているかを確認する役割がある
13. Luup, Inc. - Confidential and Proprietary 13 https://www.pagerduty.com/resources/learn/what-is-a-war-room/ 運用上の課題 - インシデント履歴が記録されない - 担当者がインシデントに対する適切な対応がわからない - 担当者の対応状況やインシデントの状況が第三者から見えない - 対応専用チャンネル（War roomチャンネル）を手動で作成する手間がある インシデント対応 ポストモーテム会議 - 会議中にインシデント情報を記載する ”War roomは、対応者と関係者が大規模インシデントに対処するために集まることができる（対 面または仮想の）場所です。” 　　　　　　　　- PagerDuty: What is a war room?
14. Luup, Inc. - Confidential and Proprietary 14 0. 事業説明 1. インシデントマネジメントの変遷 2. Slackでの報告、コミュニケーション 3. Notionでのインシデントマネジメント 4. Waroomでのインシデントマネジメント 5. まとめ
15. Luup, Inc. - Confidential and Proprietary 15 Waroomでのインシデントマネジメント ２０２３年１１月から Waroomの利用を開始 コスト・サポート・機能の適合性の観点からWaroomを選択
16. Luup, Inc. - Confidential and Proprietary 16 https://www.pagerduty.com/resources/learn/what-is-a-war-room/ 運用上の課題 - インシデント履歴が記録されない - 担当者がインシデントに対する適切な対応がわからない - 担当者の対応状況やインシデントの状況が第三者から見えない - 対応専用チャンネル（War roomチャンネル）を手動で作成する手間がある インシデント対応 ポストモーテム会議 - 会議中にインシデント情報を記載する ”War roomは、対応者と関係者が大規模インシデントに対処するために集まることができる（対 面または仮想の）場所です。” 　　　　　　　　- PagerDuty: What is a war room?
17. Luup, Inc. - Confidential and Proprietary 17 Waroomによる課題解決 UserToken版SlackApp 対応専用チャンネル（War roomチャンネル）を手動で作成する手間がある ランブック インシデント履歴が記録されない 担当者がインシデントに対する適切な対応がわからない 担当者の対応状況やインシデントの状況が第三者から見えない ポストモーテム 会議中にインシデント対応情報を記載する これらの機能を使って運用上の課題を解決 1 2 3
18. Luup, Inc. - Confidential and Proprietary 18 課題解決１：UserToken版SlackApp Slack Member（正社員） Slack Multi-Channel Guest（業務委託） チャンネルを簡単に作成、Memberから招待 を受けることができる チャンネルの作成、Memberからの招待を受 けることはできない Workspace Owner/Adminしかチャンネルに 招待できない Luupでは、業務委託メンバーのSlack権限はMulti-Channel Guestになっている 一部の業務委託メンバーはオンコール対応をしているので、Member同様の動きができない とインシデント対応に影響がある 課題の掘り下げ 課題：対応専用チャンネル（War roomチャンネル）を手動で作成する手間がある
19. Luup, Inc. - Confidential and Proprietary 19 課題解決１：UserToken版SlackApp https://docs.waroom.com/user_token_slack_app Waroom Slack App（Bot Token） Waroom Slack App（User Token） Memberに対して、対応専用チャンネルの 作成、招待ができる Multi-Channel Guestに対して、対応専用 チャンネル の作成、招待ができない Member, Multi-Channel Guest両方とも対 応専用チャンネルの作成、招待ができる Workspace Owner/AdminがSlack連携を する必要がある （LuupではWaroom用に別途Slackユー ザーを作成している） UserToken版SlackAppを使うことで解決！
20. Luup, Inc. - Confidential and Proprietary 20 課題解決１：UserToken版SlackApp https://docs.waroom.com/user_token_slack_app UserToken版SlackApp運用上の注意点 - Member（WorkspaceOwner/Admin以外）でSlackAppをインストールしないこと - 利用するUser Tokenが一般アカウントのものに変わってしまう - 事故が起きないように、Waroom側で権限管理できるようにして、ここを塞ぎたい - SlackApp用のSlackユーザー（Workspace Admin）を作成すること - これをしないと、SlackAppの動き（対応専用チャンネルに通知するなど）が特定のユー ザーによる動きに見えるので健全ではない - Slackコマンドを実行するチャンネルを固定すること - Waroom用のWorkspace Adminが招待されているSlackチャンネル以外でSlackコマンドを 実行しようとすると失敗する - どのチャンネルでコマンドを実行できるのか周知する必要がある
21. Luup, Inc. - Confidential and Proprietary 21 課題解決２：ランブック 課題の掘り下げ 課題： - インシデント履歴が記録されない - 担当者がインシデントに対する適切な対応がわからない - 担当者の対応状況やインシデントの状況が第三者から見えない インシデント履歴が（リアルタイムに）記録されないことで、分析ができない - TTA, TTRなど計測したい インシデントのステータスを把握し、インシデント対応に参加しやすくしたい 既知のインシデントに対しては対応を明確にすることでインシデント対応への心理的負担を（で きる限り）減らしたい
22. Luup, Inc. - Confidential and Proprietary 22 課題解決２：ランブック https://docs.waroom.com/create_runbook ランブックを使うことで解決！
23. Luup, Inc. - Confidential and Proprietary 23 課題解決２：ランブック インシデント対応時にランブックの手順に沿って対応を進められる 対応者に対して対応をガイドできる 対応状況・ステータスが第三者から見てわかりやすい Waroom - インシデントページ Slack - 対応専用チャンネル
24. Luup, Inc. - Confidential and Proprietary 24 課題解決３：ポストモーテム 課題の掘り下げ 課題：会議中にポストモーテムを記載する つまり、会議前の準備が不十分であるということ ポストモーテム会議で行うはずの以下の時間を失い、会議が長時間化する - 事象の確認、暫定対応の評価、恒久対応（Follow-up Action） 準備が不十分なので、課題の把握が不完全であったり、Follow-up Actionが不明瞭になり、 会議のゴールである “ステークホルダーからと合意する” が達成できない
25. Luup, Inc. - Confidential and Proprietary 25 課題解決３：ポストモーテム https://docs.waroom.com/create_runbook ポストモーテムを使うことで解決！
26. Luup, Inc. - Confidential and Proprietary 26 課題解決３：ポストモーテム AIによって自動で項目を埋めてくれる - ポストモーテムの初版をAIが作成してくれるので、人間が情報を更新する際の心理的障壁が低 くなる ポストモーテムの記載が完了してからポストモーテム会議を開始できる - 「下書き」というステータスがある - 「下書き」を終えていること = 記入が完了していること を確認した上でポストモーテム会議を 実施できる https://docs.waroom.com/create_runbook
27. Luup, Inc. - Confidential and Proprietary 27 今現在の運用状況 利用範囲 SREチームのみ → 開発組織全体へ拡大！ コミュニケーション 他部署（開発組織以外）のメンバーとのやり取りも対応専用チャンネルで行っている！ 共有・振り返り 開発組織、SREチームでそれぞれ週１回程度実施している プロセス改善 Severity（SEV）の定義は検討中 その他コミュニケーションに関するプロセスも整理中
28. Luup, Inc. - Confidential and Proprietary 28 今現在の運用状況 - 利用範囲 SREチームのみ → 開発組織全体へ拡大！ なぜ、Notionのときは拡大できず、Waroomでは拡大できたのか？？ SREチームが普及活動を積極的に行った - オンコール対応、呼びかけ、実際にインシデント対応に巻き込む を行った - 推進していける人がSREチームにいなかったが、正社員が入ったことによって進められた 潜在的なニーズがあった？ - 他のチームではこれまでインシデントマネジメントがそんなに行われていなかった - リリース時のインシデントを管理できていなかった Waroomの利便性によって「楽かも？→使おう！」になった？ - Notionだと最初から膨大な項目を埋めなければならないが、Waroomのランブックを使うと対 話形式で入力していけば良いので心理的障壁が低い
29. Luup, Inc. - Confidential and Proprietary 29 今現在の運用状況 - コミュニケーション 他部署（開発組織以外）のメンバーとのやり取りも対応専用チャンネルで行っている！ なぜ、他部署のメンバーがWaroomの対応専用チャンネルでやりとりできているの か？？ Waroomを意識していない？ - Slack自体はLuup内の標準コミュニケーションツール - 対応専用チャンネルもSlackチャンネルなので、単にインシデント対応のための緊急チャンネル という認識？ - Waroomを意識しなくてもコミュニケーションはできる
30. Luup, Inc. - Confidential and Proprietary 30 今現在の運用状況 - 共有・振り返り 開発組織での共有・振り返り - 週１の開発組織全体の部会内で実施 - 各チームから報告の時間があり、SREチームからの報告の時間で実施 - SLOの報告の後インシデントの報告を行い、そこで何かあれば議論するという形 - インシデントの報告時にWaroomのインシデント一覧のスクショを共有する - 規模が大きいインシデントがあった際には、そのインシデントやポストモーテムのURLを共 有する SREチームでの共有・振り返り - SREチームの週１回のSyncMTG内で実施 - パフォーマンス確認（定点観測）の前にインシデント確認を行う - Waroomのインシデント一覧とインサイトを確認する
31. Luup, Inc. - Confidential and Proprietary 31 今現在の運用状況 - プロセス Severity定義 - SLOアラートの状態 - CSの問い合わせ件数 - 法律遵守 - 個人情報保護、道路交通法、道路運送車両法、etc.... - 車両数、ユーザー数 コミュニケーション - 事業規模の割にCS、サービスオペレーションなどステークホルダーが多い - “車両” があるので、エンジニアだけで完結できる世界ではない
32. Luup, Inc. - Confidential and Proprietary 32 今現在の課題 (一部抜粋) APIの公開（waroom-roadmap #29） - 入力データをバリデーションできるようにユーザーが入力したデータをGETできるAPIがほしい - 過去のインシデント情報をWaroomへインポートしたい - インシデントにAPIを使ってコメントをつけたい ポストモーテムテンプレートのカスタマイズ （waroom-roadmap #52） - Notion管理時代のポストモーテムの項目をWaroomのポストモーテムでも使いたい アクションアイテムの登録（waroom-roadmap #47） - アクションアイテムをWaroomから一律で管理できるようにしたい インシデントメトリクスの編集（waroom-roadmap #60） - Waroomの運用を始める段階では、インシデントが起きて時間が経った後・インシデントが収 束した後にWaroomにインシデントを起票するというパターンが起きるので後からインシデン トメトリクスを更新したい
33. Luup, Inc. - Confidential and Proprietary 33 0. 事業説明 1. インシデントマネジメントの変遷 2. NotionDBでのインシデントマネジメント 3. Waroomでのインシデントマネジメント 4. まとめ
34. Luup, Inc. - Confidential and Proprietary 34 まとめ - Luupの開発組織でのインシデントマネジメントの変遷について紹介しました - Waroomを利用することで多くの課題を解決できる - インシデント対応時のフローを一気通貫でサポートできる - ランブックの効果は大きい - インシデントマネジメント上の課題やプラクティスについて語りましょう！ - #Waroom , @gr1m0h , 懇親会で！
35. 一緒に、街じゅうを「駅前化」する インフラをつくりませんか？ 詳細は採用ページをご覧ください https://recruit.luup.sc/