2025/06/12 日本経済新聞社 SRE チーム 山田 悠右 SRE ガイドマップを用いたイネーブルメントの実践 NIKKEI TECH TALK #34 1 

About me 山田 悠右 (Yu Yamada) 2024 年に日本経済新聞社に中途入社。 SRE チームにて、社内プラットフォームの開発や SRE イネーブルメントに従事。 2 

本日話すこと ● SRE 実践のためのガイドラインの整備 ○ SRE Trail Map (ガイドマップ) ○ SRE Trail Map Criteria (チェックシート) ● ガイドラインを活用した SRE 支援 ● 実例: CMS チームの SRE 支援 ● 今後の展望 3 

日経 SRE の活動 ● Platform SRE ○ 共通アプリケーション基盤の提供 ○ 共通負荷試験基盤の提供 ○ 共通監視・オブザーバビリティ基盤の提供 ● Enablement SRE ○ 社内への SRE 実践の方法論の普及 (社内ブログ等) ○ SRE 実践のためのガイドラインの整備 ■ SRE Trail Map (ガイドマップ) ■ SRE Trail Map Criteria (チェックシート) Platform SRE と Enablement SRE の両軸で組織横断的に活動 4 

● Platform SRE ○ 共通アプリケーション基盤の提供 ○ 共通負荷試験基盤の提供 ○ 共通監視・オブザーバビリティ基盤の提供 ● Enablement SRE ○ 社内への SRE 実践の方法論の普及 (社内ブログ等) ○ SRE 実践のためのガイドラインの整備 ■ SRE Trail Map (ガイドマップ) ■ SRE Trail Map Criteria (チェックシート) 日経 SRE の活動 Platform SRE と Enablement SRE の両軸で組織横断的に活動 今日お話するのは こっち 5 

SRE 実践のためのガイドラインの整備 6 

SRE ガイドラインの整備の背景 ● どこまで浸透しているか？ ○ 多数のサービス・開発チームが存在する ○ 組織全体でどこまで浸透しているかの計測が困難 ● どこから着手すべきか？ ○ SRE プラクティスは多数ある (ポストモーテム、SLI/SLO etc.) ○ どのプラクティスから取り組むべきかの明確な指針がない ● どこに問題があるのか？ ○ サービスの信頼性上の重要な問題を把握するための目安がない ○ 信頼性上の問題が把握されずに軽視されてしまう SRE プラクティスを社内に普及させる上での課題感 7 

SRE Trail Map + Criteria 7 項目の SRE プラクティスの解説や社内ノウハウ＋チェックリスト 日経において重視すべき SRE プラクティスを実践するためのガイドラインを整備 1. モニタリング 2. SLI/SLO 3. CI/CD 4. 障害対応フローと手順 5. ポストモーテム 6. オブザーバビリティ 7. 障害対応訓練の実施 8 

SRE Trail Map（ガイドマップ） ● どのような取り組みが必要か ● 得られるメリット ● 社内での実践例 ● 社内基盤・ツール プラクティスの解説や社内ノウハウ 具体例:「障害対応フローと手順」の項目 社内での取り組みを 蓄積・共有 9 

チェッ ク 実践 Lv. Criteria ✅ 1 障害発生時に連絡・連携等コミュニケーションが必要な連絡先が明らかになっている。 1 障害発生時にコミュニケーションを取るツール・手段について、チーム内で合意が取れている。また、それらが万が一利用できな い場合の代替手段が決められている。 2 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照することでチームメンバの 誰もが障害対応できる状態になっている。 ✅ 1 障害の深刻度 (Severity Level) を定義し、それに応じてコミュニケーションパスや対応方法などを整理している。 2 典型的な障害に対する対応手順がドキュメントにまとめてある。チーム内の誰もがそのドキュメントに従えば対応できる。 3 障害対応に関するドキュメントが継続的に見直され、サービスの実状に合った状態が維持されている。 SRE Trail Map Criteria（チェックリスト） Yes / No で答えられる基準 (Criteria) に落とし込んだもの 各項目の Criteria に ✅ をつけることで ● SRE の実践度合いを測ることができる ● 次に取るべきアクションがわかる 実践レベル ＝ 取り組みやすさの目安 (Lv.1~5) 具体例:「障害対応フローと手順」の Criteria 10 

SRE Trail Map Criteria（チェックリスト） 説明 この Criteria は、過去に発生したインシデントや、発生する可能性が高い典型的な障害シナリオについて、具体的な対応手順が文 書化されており、そのドキュメントがチームの経験や知識レベルに関わらず、誰もが参照して実際に対応を遂行できるレベルで整備 されている状態を求めています。 推奨事項 ● インシデントの検知から解決、事後対応までの主要なフェーズ（例 : 検知、初期評価・トリアージ、エスカレーション、対応役割の 割り当て、インシデント通知・コミュニケーション、原因調査・対応策検討、解決策の実施・確認、復旧、クローズ、ポストモーテ ム準備）を明確に定義する。 ⋮ Criteria: 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照する ことでチームメンバの誰もが障害対応できる状態になっている。 実タスクに落とし込めるように Criteria ごとに補足説明、推奨事項を記載 11 

ガイドラインを活用した SRE 支援 12 

ガイドラインを活用した SRE 支援 プロダクトチームへの SRE 支援の流れ ① チェックリストで SRE の実践度合いを確認する ② SRE 支援の計画を策定する ③ SRE 支援の計画を実行する SRE チームによる能動的な支援活動に SRE ガイドマップ＋チェックリストを活用 13 

① チェックリストで SRE の実践度合いを確認する プロダクトチームにヒアリングしながら、 Criteria にチェックをつけていく 達成 実践 Lv. Criteria ✅ 1 障害発生時に連絡・連携等コミュニケーションが必要な連絡先が明らかになっている。 1 障害発生時にコミュニケーションを取るツール・手段について、チーム内で合意が取れている。また、それらが万が一利用できない 場合の代替手段が決められている。 2 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照することでチームメンバの誰もが 障害対応できる状態になっている。 ✅ 1 障害の深刻度 (Severity Level) を定義し、それに応じてコミュニケーションパスや対応方法などを整理している。 2 典型的な障害に対する対応手順がドキュメントにまとめてある。チーム内の誰もがそのドキュメントに従えば対応できる。 3 障害対応に関するドキュメントが継続的に見直され、サービスの実状に合った状態が維持されている。 「障害対応フローと手順」の Criteria Criteria に沿って、システムの運用体制や課題感をヒアリング ● プロダクトチームへの理解を深める ● 支援計画を立てる際の参考にする 14 

① チェックリストで SRE の実践度合いを確認する 項目ごとのチェックの数を見て、実践度が低い箇所を洗い出す 15 

① チェックリストで SRE の実践度合いを確認する 項目ごとのチェックの数を見て、実践度が低い箇所を洗い出す 16 チェック数が少ない項目に課題を 抱えている可能性が高い SLI/SLO 障害対応フローと手順 ポストモーテム オブザーバビリティ 

② SRE 支援の計画を策定する ● 最初期 (数週間) ○ SRE とはなにか、何のためにやるのか、共通認識の形成 ● 初期 (数ヶ月) ○ 基礎的な項目、優先度の高い項目 (実践レベル低〜) ● 中期 (数ヶ月) ○ 基礎を前提とする項目、SRE のコアとなる項目 (実践レベル中〜) ● 後期 (数ヶ月) ○ 残りの項目、プロダクトチームの自走を目指す (実践レベル高) 期間を区切り、達成目標を設定する プロダクトチームが割ける 工数を確認しつつ調整 17 

③ SRE 支援計画を実行に移す ● Criteria の内容を読み合わせる ○ 何が必要なのか、なぜやるのか ● 両チームでアクションを決定し、進める ○ ゴール地点を合意 ○ 作業は各チームで実施、定例で進捗確認 ● マイルストーン達成ごとにチェックリストを確認する ○ Criteria が達成されたか ○ リグレッションしていないか 両チームで実施内容を合意しつつ、 Criteria の達成を目指す 18 

実例: CMS チームの SRE 支援 19 

実例: CMS チームの SRE 支援 ● CMS: 日経電子版を支える重要なシステム群 ○ 毎日3000本の記事を公開する新聞社の屋台骨で、安定稼働と信頼性が重要 ○ 記事の入稿・編集、画像等の素材の管理、公開スケジュールの管理 etc. ● 開発と運用が分離された体制 ○ 日経・ベンダーが開発、協力会社が運用・保守 ○ サービスの信頼性と開発のアジリティを両立したい CMS チーム: 日経電子版に掲載されるコンテンツ編集を担う CMS の開発チーム SRE 支援のきっかけ Contents Management System 20 

実例: CMS チームの SRE 支援 プラクティスごとのチェックの数を見て、実践度が低い箇所を洗い出す 21 チェック数が少ない項目に課題を 抱えている可能性が高い SLI/SLO 障害対応フローと手順 ポストモーテム オブザーバビリティ 

実例: CMS チームの SRE 支援 ● 最初期 (数週間) ○ SRE の基礎に関する講義 ● 初期 (数ヶ月) ○ 障害対応フローと手順、ポストモーテム ● 中期 (数ヶ月) ○ SLI/SLO、オブザーバビリティ ● 後期 (数ヶ月) ○ その他、実践度高の Criteria SRE 支援の計画を策定 22 

実例: CMS チームの SRE 支援 ● 最初期 (数週間) ○ SRE の基礎に関する講義 ● 初期 (数ヶ月) ○ 障害対応フローと手順、ポストモーテム ● 中期 (数ヶ月) ○ SLI/SLO、オブザーバビリティ ● 後期 (数ヶ月) ○ その他、実践度高の Criteria 今日紹介する内容 23 

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 

SRE の基礎に関する講義 SRE の基本的な考え方 ● リスクの受容 ● サービスレベル目標 ● トイルの撲滅 ● 分散システムのモニタリング ● リリースエンジニアリング ● 単純さ 講義①: SRE の原則 26 

SRE の基礎に関する講義 講義②: サービスの信頼性の階層 SRE の実践的な側面 ● モニタリング ● インシデント対応 ● ポストモーテム ● テスト及びリリース手順 ● キャパシティプランニング ● 開発 ● プロダクト 28 

「障害対応フローと手順」の改善支援 今回取り組んだ Criteria 達成 実践 Lv. Criteria ✅ 1 障害発生時に連絡・連携等コミュニケーションが必要な連絡先が明らかになっている。 1 障害発生時にコミュニケーションを取るツール・手段について、チーム内で合意が取れている。また、それらが万が一利用できな い場合の代替手段が決められている。 2 障害発生時に取るべき対応フローが策定され、ドキュメントに明文化されている。ドキュメントを参照することでチームメンバの誰 もが障害対応できる状態になっている。 ✅ 1 障害の深刻度 (Severity Level) を定義し、それに応じてコミュニケーションパスや対応方法などを整理している。 2 典型的な障害に対する対応手順がドキュメントにまとめてある。チーム内の誰もがそのドキュメントに従えば対応できる。 3 障害対応に関するドキュメントが継続的に見直され、サービスの実状に合った状態が維持されている。 「障害対応フローと手順」の Criteria 29 

「障害対応フローと手順」の改善支援 障害対応ドキュメントのテンプレートを作成 ● テンプレートを埋めることで障害対応ド キュメントが完成 ● 読みながら作業することを想定し、障害 対応の時系列に沿った章立て ● SRE Trail Map に蓄積されていた別の チームでの取り組みを元に作成 30 

障害対応ドキュメントのテンプレート Severity Level ごとの状況例や対応方針を 記載するテーブル 31 

障害対応ドキュメントのテンプレート Severity Level ごとの連絡先のテーブル コピペで使える報告例のテンプレ 32 

障害対応ドキュメントのテンプレート 障害の影響を緩和するための典型的な手順書は別途整備し、 ここから辿れるように リンクを集約 する 33 

これまでの活動を振り返って 支援先チームからのフィードバックは良好 経験則に基づいた改善をしてきたことが多かったが、Criteria があるので基準がわかりやすい 👍 SRE の講義や Criteria チェックを通して信頼性について考える機会を得られて有意義 だった 👍 開発・運用で協力 して課題に取り組むことができてよい 👍 34 

これまでの活動を振り返って ● Criteria があることでゴールや次のアクションが明確になる ○ SRE チームは、支援計画を立てやすい ○ プロダクトチームは、やることをイメージをやすい ● Criteria のチェック数によって SRE 実践度を定量的に評価できる ○ 優先して取り組むべき項目がわかる ○ チェック数の変化を追うことで改善幅がわかる 成果: ガイドマップとチェックリストを軸とした SRE 支援の有効性を確認できた 35 

今後の展望 ● 進行中の SRE 支援プロジェクトを完遂する ● 得られた知見をもとに SRE Trail Map を軸とした支援のプロセスを確立する ○ 汎用的なソリューションを蓄積してスケール可能にする ● 他チームにも展開し、最終的には全社的な SRE の実践を目指す SRE Trail Map を軸とした SRE 支援のプロセスを確立し、全社に展開 36 

まとめ ● SRE 実践のためのガイドラインの整備 ○ SRE ガイドマップ、チェックシート ● ガイドラインを活用した SRE 支援 ○ チェックリスト→支援計画→実行 ● 実例: CMS チームの SRE 支援 ○ SRE 講義、障害対応ドキュメントテンプレート ● 成果と展望 ○ ガイドラインを活用した SRE 支援の有効性を確認 ○ この SRE 支援のプロセスを確立し、全社に展開 37 

We are Hiring!! 🔍 HACK The Nikkei 日経では、 SRE をはじめ、 各種エンジニアを募集中です！ hack.nikkei.com/jobs/sre 38