SRE ガイドマップを用いたイネーブルメントの実践/nikkei-tech-talk-34

2025/06/12開催のNIKKEI Tech Talkで日本経済新聞社のSRE 山田 悠右さんが発表しました。#nikkei_tech_talk
https://nikkei.connpass.com/event/355303/

Transcript

1. 2025/06/12 日本経済新聞社 SRE チーム 山田 悠右 SRE ガイドマップを用いたイネーブルメントの実践 NIKKEI TECH TALK #34 1
2. About me 山田 悠右 (Yu Yamada) 2024 年に日本経済新聞社に中途入社。 SRE チームにて、社内プラットフォームの開発や SRE イネーブルメントに従事。 2
3. 本日話すこと • SRE 実践のためのガイドラインの整備 ◦ SRE Trail Map (ガイドマップ) ◦ SRE Trail Map Criteria (チェックシート) • ガイドラインを活用した SRE 支援 • 実例: CMS チームの SRE 支援 • 今後の展望 3
4. 日経 SRE の活動 • Platform SRE ◦ 共通アプリケーション基盤の提供 ◦ 共通負荷試験基盤の提供 ◦ 共通監視・オブザーバビリティ基盤の提供 • Enablement SRE ◦ 社内への SRE 実践の方法論の普及 (社内ブログ等) ◦ SRE 実践のためのガイドラインの整備 ▪ SRE Trail Map (ガイドマップ) ▪ SRE Trail Map Criteria (チェックシート) Platform SRE と Enablement SRE の両軸で組織横断的に活動 4
5. • Platform SRE ◦ 共通アプリケーション基盤の提供 ◦ 共通負荷試験基盤の提供 ◦ 共通監視・オブザーバビリティ基盤の提供 • Enablement SRE ◦ 社内への SRE 実践の方法論の普及 (社内ブログ等) ◦ SRE 実践のためのガイドラインの整備 ▪ SRE Trail Map (ガイドマップ) ▪ SRE Trail Map Criteria (チェックシート) 日経 SRE の活動 Platform SRE と Enablement SRE の両軸で組織横断的に活動 今日お話するのは こっち 5
6. SRE 実践のためのガイドラインの整備 6
7. SRE ガイドラインの整備の背景 • どこまで浸透しているか？ ◦ 多数のサービス・開発チームが存在する ◦ 組織全体でどこまで浸透しているかの計測が困難 • どこから着手すべきか？ ◦ SRE プラクティスは多数ある (ポストモーテム、SLI/SLO etc.) ◦ どのプラクティスから取り組むべきかの明確な指針がない • どこに問題があるのか？ ◦ サービスの信頼性上の重要な問題を把握するための目安がない ◦ 信頼性上の問題が把握されずに軽視されてしまう SRE プラクティスを社内に普及させる上での課題感 7
8. SRE Trail Map + Criteria 7 項目の SRE プラクティスの解説や社内ノウハウ＋チェックリスト 日経において重視すべき SRE プラクティスを実践するためのガイドラインを整備 1. モニタリング 2. SLI/SLO 3. CI/CD 4. 障害対応フローと手順 5. ポストモーテム 6. オブザーバビリティ 7. 障害対応訓練の実施 8
9. SRE Trail Map（ガイドマップ） • どのような取り組みが必要か • 得られるメリット • 社内での実践例 • 社内基盤・ツール プラクティスの解説や社内ノウハウ 具体例:「障害対応フローと手順」の項目 社内での取り組みを 蓄積・共有 9
10. チェッ ク 実践 Lv. Criteria ✅ 1 障害発生時に連絡・連携等コミュニケーションが必要な連絡先が明らかになっている。 1 障害発生時にコミュニケーションを取るツール・手段について、チーム内で合意が取れている。また、それらが万が一利用できな い場合の代替手段が決められている。 2 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照することでチームメンバの 誰もが障害対応できる状態になっている。 ✅ 1 障害の深刻度 (Severity Level) を定義し、それに応じてコミュニケーションパスや対応方法などを整理している。 2 典型的な障害に対する対応手順がドキュメントにまとめてある。チーム内の誰もがそのドキュメントに従えば対応できる。 3 障害対応に関するドキュメントが継続的に見直され、サービスの実状に合った状態が維持されている。 SRE Trail Map Criteria（チェックリスト） Yes / No で答えられる基準 (Criteria) に落とし込んだもの 各項目の Criteria に ✅ をつけることで • SRE の実践度合いを測ることができる • 次に取るべきアクションがわかる 実践レベル ＝ 取り組みやすさの目安 (Lv.1~5) 具体例:「障害対応フローと手順」の Criteria 10
11. SRE Trail Map Criteria（チェックリスト） 説明 この Criteria は、過去に発生したインシデントや、発生する可能性が高い典型的な障害シナリオについて、具体的な対応手順が文 書化されており、そのドキュメントがチームの経験や知識レベルに関わらず、誰もが参照して実際に対応を遂行できるレベルで整備 されている状態を求めています。 推奨事項 • インシデントの検知から解決、事後対応までの主要なフェーズ（例 : 検知、初期評価・トリアージ、エスカレーション、対応役割の 割り当て、インシデント通知・コミュニケーション、原因調査・対応策検討、解決策の実施・確認、復旧、クローズ、ポストモーテ ム準備）を明確に定義する。 ⋮ Criteria: 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照する ことでチームメンバの誰もが障害対応できる状態になっている。 実タスクに落とし込めるように Criteria ごとに補足説明、推奨事項を記載 11
12. ガイドラインを活用した SRE 支援 12
13. ガイドラインを活用した SRE 支援 プロダクトチームへの SRE 支援の流れ ① チェックリストで SRE の実践度合いを確認する ② SRE 支援の計画を策定する ③ SRE 支援の計画を実行する SRE チームによる能動的な支援活動に SRE ガイドマップ＋チェックリストを活用 13
14. ① チェックリストで SRE の実践度合いを確認する プロダクトチームにヒアリングしながら、 Criteria にチェックをつけていく 達成 実践 Lv. Criteria ✅ 1 障害発生時に連絡・連携等コミュニケーションが必要な連絡先が明らかになっている。 1 障害発生時にコミュニケーションを取るツール・手段について、チーム内で合意が取れている。また、それらが万が一利用できない 場合の代替手段が決められている。 2 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照することでチームメンバの誰もが 障害対応できる状態になっている。 ✅ 1 障害の深刻度 (Severity Level) を定義し、それに応じてコミュニケーションパスや対応方法などを整理している。 2 典型的な障害に対する対応手順がドキュメントにまとめてある。チーム内の誰もがそのドキュメントに従えば対応できる。 3 障害対応に関するドキュメントが継続的に見直され、サービスの実状に合った状態が維持されている。 「障害対応フローと手順」の Criteria Criteria に沿って、システムの運用体制や課題感をヒアリング • プロダクトチームへの理解を深める • 支援計画を立てる際の参考にする 14
15. ① チェックリストで SRE の実践度合いを確認する 項目ごとのチェックの数を見て、実践度が低い箇所を洗い出す 15
16. ① チェックリストで SRE の実践度合いを確認する 項目ごとのチェックの数を見て、実践度が低い箇所を洗い出す 16 チェック数が少ない項目に課題を 抱えている可能性が高い SLI/SLO 障害対応フローと手順 ポストモーテム オブザーバビリティ
17. ② SRE 支援の計画を策定する • 最初期 (数週間) ◦ SRE とはなにか、何のためにやるのか、共通認識の形成 • 初期 (数ヶ月) ◦ 基礎的な項目、優先度の高い項目 (実践レベル低〜) • 中期 (数ヶ月) ◦ 基礎を前提とする項目、SRE のコアとなる項目 (実践レベル中〜) • 後期 (数ヶ月) ◦ 残りの項目、プロダクトチームの自走を目指す (実践レベル高) 期間を区切り、達成目標を設定する プロダクトチームが割ける 工数を確認しつつ調整 17
18. ③ SRE 支援計画を実行に移す • Criteria の内容を読み合わせる ◦ 何が必要なのか、なぜやるのか • 両チームでアクションを決定し、進める ◦ ゴール地点を合意 ◦ 作業は各チームで実施、定例で進捗確認 • マイルストーン達成ごとにチェックリストを確認する ◦ Criteria が達成されたか ◦ リグレッションしていないか 両チームで実施内容を合意しつつ、 Criteria の達成を目指す 18
19. 実例: CMS チームの SRE 支援 19
20. 実例: CMS チームの SRE 支援 • CMS: 日経電子版を支える重要なシステム群 ◦ 毎日3000本の記事を公開する新聞社の屋台骨で、安定稼働と信頼性が重要 ◦ 記事の入稿・編集、画像等の素材の管理、公開スケジュールの管理 etc. • 開発と運用が分離された体制 ◦ 日経・ベンダーが開発、協力会社が運用・保守 ◦ サービスの信頼性と開発のアジリティを両立したい CMS チーム: 日経電子版に掲載されるコンテンツ編集を担う CMS の開発チーム SRE 支援のきっかけ Contents Management System 20
21. 実例: CMS チームの SRE 支援 プラクティスごとのチェックの数を見て、実践度が低い箇所を洗い出す 21 チェック数が少ない項目に課題を 抱えている可能性が高い SLI/SLO 障害対応フローと手順 ポストモーテム オブザーバビリティ
22. 実例: CMS チームの SRE 支援 • 最初期 (数週間) ◦ SRE の基礎に関する講義 • 初期 (数ヶ月) ◦ 障害対応フローと手順、ポストモーテム • 中期 (数ヶ月) ◦ SLI/SLO、オブザーバビリティ • 後期 (数ヶ月) ◦ その他、実践度高の Criteria SRE 支援の計画を策定 22
23. 実例: CMS チームの SRE 支援 • 最初期 (数週間) ◦ SRE の基礎に関する講義 • 初期 (数ヶ月) ◦ 障害対応フローと手順、ポストモーテム • 中期 (数ヶ月) ◦ SLI/SLO、オブザーバビリティ • 後期 (数ヶ月) ◦ その他、実践度高の Criteria 今日紹介する内容 23
24. SRE の基礎に関する講義 SRE 本*1 から抜粋した内容を 1時間 x 2回の講義で説明・議論 *1. Niall Richard Murphy, Betsy Beyer, Chris Jones, Jennifer Petoff. “Site Reliability Engineering”. 2016. O’REILLY • 講義①: SRE の原則 ◦ 第二部 「原則」から抜粋 ◦ SRE の基本的な考え方 • 講義②: サービスの信頼性階層 ◦ 第三部 「プラクティス」から抜粋 ◦ SRE の実践的な側面 25
25. SRE の基礎に関する講義 SRE の基本的な考え方 • リスクの受容 • サービスレベル目標 • トイルの撲滅 • 分散システムのモニタリング • リリースエンジニアリング • 単純さ 講義①: SRE の原則 26
26. SRE の基礎に関する講義 講義②: サービスの信頼性の階層 SRE の実践的な側面 • モニタリング • インシデント対応 • ポストモーテム • テスト及びリリース手順 • キャパシティプランニング • 開発 • プロダクト 28
27. 「障害対応フローと手順」の改善支援 今回取り組んだ Criteria 達成 実践 Lv. Criteria ✅ 1 障害発生時に連絡・連携等コミュニケーションが必要な連絡先が明らかになっている。 1 障害発生時にコミュニケーションを取るツール・手段について、チーム内で合意が取れている。また、それらが万が一利用できな い場合の代替手段が決められている。 2 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照することでチームメンバの誰 もが障害対応できる状態になっている。 ✅ 1 障害の深刻度 (Severity Level) を定義し、それに応じてコミュニケーションパスや対応方法などを整理している。 2 典型的な障害に対する対応手順がドキュメントにまとめてある。チーム内の誰もがそのドキュメントに従えば対応できる。 3 障害対応に関するドキュメントが継続的に見直され、サービスの実状に合った状態が維持されている。 「障害対応フローと手順」の Criteria 29
28. 「障害対応フローと手順」の改善支援 障害対応ドキュメントのテンプレートを作成 • テンプレートを埋めることで障害対応ド キュメントが完成 • 読みながら作業することを想定し、障害 対応の時系列に沿った章立て • SRE Trail Map に蓄積されていた別の チームでの取り組みを元に作成 30
29. 障害対応ドキュメントのテンプレート Severity Level ごとの状況例や対応方針を 記載するテーブル 31
30. 障害対応ドキュメントのテンプレート Severity Level ごとの連絡先のテーブル コピペで使える報告例のテンプレ 32
31. 障害対応ドキュメントのテンプレート 障害の影響を緩和するための典型的な手順書は別途整備し、 ここから辿れるように リンクを集約 する 33
32. これまでの活動を振り返って 支援先チームからのフィードバックは良好 経験則に基づいた改善をしてきたことが多かったが、Criteria があるので基準がわかりやすい 👍 SRE の講義や Criteria チェックを通して信頼性について考える機会を得られて有意義 だった 👍 開発・運用で協力 して課題に取り組むことができてよい 👍 34
33. これまでの活動を振り返って • Criteria があることでゴールや次のアクションが明確になる ◦ SRE チームは、支援計画を立てやすい ◦ プロダクトチームは、やることをイメージをやすい • Criteria のチェック数によって SRE 実践度を定量的に評価できる ◦ 優先して取り組むべき項目がわかる ◦ チェック数の変化を追うことで改善幅がわかる 成果: ガイドマップとチェックリストを軸とした SRE 支援の有効性を確認できた 35
34. 今後の展望 • 進行中の SRE 支援プロジェクトを完遂する • 得られた知見をもとに SRE Trail Map を軸とした支援のプロセスを確立する ◦ 汎用的なソリューションを蓄積してスケール可能にする • 他チームにも展開し、最終的には全社的な SRE の実践を目指す SRE Trail Map を軸とした SRE 支援のプロセスを確立し、全社に展開 36
35. まとめ • SRE 実践のためのガイドラインの整備 ◦ SRE ガイドマップ、チェックシート • ガイドラインを活用した SRE 支援 ◦ チェックリスト→支援計画→実行 • 実例: CMS チームの SRE 支援 ◦ SRE 講義、障害対応ドキュメントテンプレート • 成果と展望 ◦ ガイドラインを活用した SRE 支援の有効性を確認 ◦ この SRE 支援のプロセスを確立し、全社に展開 37
36. We are Hiring!! 🔍 HACK The Nikkei 日経では、 SRE をはじめ、 各種エンジニアを募集中です！ hack.nikkei.com/jobs/sre 38