1 SRE NEXT 2024 株式会社日本経済新聞社 清水 赳 Enabling SRE by Guide Maps

2 自己紹介 清水 赳 (Takeru Shimizu) ● 株式会社日本経済新聞社 ○ 技術戦略ユニット 基盤第二グループ ○ ソフトウェアエンジニア ● SRE, Observability, Cloud Security ○ 社内での SRE 実践の推進 (SRE Enablement) ○ 社内共通アプリケーション基盤の開発 ○ Google Cloud 利活用に関するセキュリティ強化

3 今日話すこと ● SRE 活動の推進 (SRE Enablement) を効率的に行うための実践を紹介 ● 重要な SRE プラクティスを段階的に示すマップを社内提供 ● 細分化したチェックリスト やベストプラクティス を提供 ○ 現在地の把握 や行動変容に役立てている ● ドキュメントに関するガイドライン なども提供

4 日経のエンジニア組織 多様なサービスと技術基盤 ● プロダクト ○ 日経電子版、NIKKEI Prime、日経テレコン、NIKKEI COMPASS など ● コンテンツ ○ コンテンツ基盤、データビジュアライゼーションなど ● 技術基盤 ○ ID 基盤、課金・決済基盤、データ基盤、アプリケーション基盤など ● 技術研究 ○ イノベーションラボ

5 NIKKEI SRE の役割 Platform SRE と Enablement SRE の両軸で組織横断に活動 ● Platform SRE ○ 共通 Kubernetes アプリケーション基盤の開発・運用 ○ 共通 Terraform モジュールの提供 ○ 共通監視・オブザーバビリティ基盤の開発 (OpenTelemetry) ● Enablement SRE ○ 社内への SRE 実践の方法論の普及 ○ SRE 実践のための基本指針の策定やガイドラインの発行

6 日経における Enablement SRE 文化的側面から SRE 実践を支援 ● 社内への SRE 実践の方法論の普及 ○ オフィスアワーの開催 (週 1 回) ○ 社内ブログ・ポータルサイトの公開 (月 1 回程度) ○ サービス開発チームとのスポット相談 ● SRE 実践のための基本指針の策定やガイドラインの発行 ○ SRE Trail Map の開発・発行 ○ ドキュメント管理・テクニカルライティングガイドラインの開発

7 NIKKEI SRE が直面した課題 SRE プラクティスを普及させるにあたり課題に直面 ● どこまで浸透しているか？ ○ 多数のサービス・開発チームが存在する ○ 組織全体でどこまで浸透しているか計測が困難 ● どこから着手すべきか？ ○ SRE プラクティスは多数ある ○ どのプラクティスから取り組むべきか明確な指針がない ● どこに問題があるか？ ○ サービス・開発チームにとっての信頼性上の最重要問題を把握する目安がない ○ そもそも既存の信頼性上の問題が把握されず軽視 されてしまう

8 SRE プラクティスのガイダンス・ガイドラインの必要性 ガイドラインは開発チームにも SRE チームにもメリット ● サービス開発チームにとって ○ SRE プラクティスを自律的に実践できるためのツールセット ○ 開発・運用効率を改善し、付加価値の高いサービスを提供するための手段 ● SRE チームにとって ○ 効率的に SRE プラクティスを組織に展開するための手段 ○ チームの仕事を (量的にも、質的にも) スケールさせるための手段

9 SRE Trail Map SRE プラクティスの各ステップを Trail Map (登山マップ ) にたとえて提示 ● SRE プラクティスを実装するきっかけ ○ 数ある SRE プラクティスを網羅的に知る手段 ● ステップを一つずつ達成していくことで自然と SRE を実践 ○ どこからプラクティスを実装するか、どこまでできているか現在地を知る ● 組織全体の SRE プラクティスの集積場 ○ ひとつの Trail Map に組織全体の知見を集約して共有

10

11 SRE Trail Map: 8 つのステップ ステップ Trail Map で の採用 理由 モニタリング 採用 ● SRE プラクティスでも最も基本的項目である ● 社内でいくつかプラクティスが蓄積されている ● 社内でも実践できている場合とそうでない場合がまばら サービスレベル指標 障害対応フローと手順 ポストモーテム 継続的インテグレーション 継続的デリバリ オブザーバビリティ 障害対応訓練の実施 SLO 見送り ● 達成に至るチームが少ないと思われる ● 実践まで相当の時間を要する可能性が高い Severity Level の定義

12 SRE Trail Map: ステップの具体例 ● Trail Map の各ステップの解説 ● アクションを取るべき理由、どのような取り組みが必要か ● アクションの実行の前提となる資料を提示

13 SRE Trail Map: ステップの具体例 ● 社内チームでの実践例を蓄積 (ナレッジベースとして機能) ● 他チームでの実践にリファレンスしてもらう

14 SRE Trail Map: ステップの具体例 ● 社内に共通で提供されている共通基盤・モジュール・テンプレートを紹介 ● SRE チームが導入をサポートする

15 SRE Trail Map: ステップの具体例 ● SRE Trail Map がどこまで実施できているか確認できるチェックリスト ● のちで説明

16 SRE Trail Map: モニタリングの例 ログやメトリクスなどもとにしたアラートルールを定め、サービスの監視を実施している ● なぜアクションを取るべきか？ ○ モニタリングなしでは、サービスが正しく動作しているかわからない ○ 問題が起きたときは、ユーザより先に事象に気づく必要がある ○ 誰かが常にサービスの動作を確認し続ける体制は、現実的ではない ● どのように解決するべきか？ ○ 例: 社内共通 Terraform モジュール ● 参考事例 ○ 例: 社内開発チームで 5xx 系レスポンスに対する過剰なアラートを抑制

17 SRE Trail Map: ポストモーテムの例 サービス障害のたび非難のないポストモーテムが迅速に実施されている ● なぜアクションを取るべきか？ ○ 生じたインシデントからは教訓を得るべきである ○ 建設的な議論を行うためにも、非難ではなく根本的な原因を議論の中心に ● どのようにアクションを取るべきか？ ○ 内製開発したインシデントレスポンス管理ツール (IRM) があるので利用する ● 参考事例 ○ IRM に蓄積されたポストモーテムを参考にする ○ Trail Map 内で書法に関するベストプラクティスを示している

18 SRE Trail Map: ポストモーテムの例 良いポストモーテムのためのチェックリストも提供 概要が記載されている 継続時間がわかる 根本原因がわかる きっかけがわかる 暫定対応と恒久対応がそれぞれ記載されている 特定の個人やチームを非難する表現がない 再発防止のアクションアイテムが検討されている 用語集が添付されている

19 SRE Trail Map Criteria SRE プラクティスの実装度合いを計測するチェックリスト ● Trail Map の各ステップの充足度合いを確認する観点 (Criterion) ○ 実践のための準備、実践、学習と改善、メトリクスと計測 ● 各ステップの具体的な実装のガイドラインを提供 ○ 観点を満たせるように具体的な実装方法のベストプラクティスを提示 ○ すなわち未達事項に基づいた「SRE 実装のガイドライン」 ● チームにとって優先すべき SRE プラクティスを明確化 ○ どの SRE プラクティスが充足・未達かが一目でわかる ○ 状況に応じて、ガイドラインや SRE チームを活用してチーム強化を図る

20

21 SRE Trail Map Criteria モニタリング 実践のための準備 システム監視に用いるツールが選定されている モニタリング 実践のための準備 ログやメトリクスを収集し、アラートルールが定められる モニタリング 実践 ユーザに近い視点で異常を検知できるアラートルールがある モニタリング 学習と改善 アラートのルールやしきい値が定期的に見直し・改善される モニタリング メトリクスの計測 平均検出時間が計測され、可視化されている

22 SRE Trail Map Criteria で提供されるガイドラインの例 ポストモーテムの実践 : 用語集や補足を設けて誰が読んでもわかる内容にまとめる ● 説明 ○ ポストモーテムは誰が読んでもわかることが推奨されます ○ 用語集や補足を設けてチームの内外の誰でもわかる内容を作成しましょう ● 理由 ○ ポストモーテムは障害で得られた教訓を広く共有するドキュメントである ○ 教訓を広く共有するためには、誰が読んでもわかるドキュメントである必要がある ● 推奨事項 ○ 曖昧さやわかりづらい表現を避けて、数値や定量的な表現を用いる ○ グラフや図を用いる、固有名詞に関する単語集・用語集を作成する

23 ドキュメント管理・テクニカルライティングガイドライン SRE プラクティスの実践を包括的にサポートする ● SRE Trail Map に含まれるステップには適正なドキュメント管理が必要 ○ 障害対応、ポストモーテムなど ● ドキュメントの品質確保は信頼性の担保につながる ○ ドキュメントの誤認によるミスオペレーションの防止 ○ 誰もが読めば正しく関われる「SRE のスケール」 ● 内部ドキュメンテーションは DevOps に関わる技術的能力を向上させる ○ DORA Capabilities “Documentation quality”も参考 “DORA | Capabilities: Documentation Quality.” dora.dev, dora.dev/capabilities/documentation-quality/. Accessed 23 July 2024.

24 ガイドライン整備において重視していること ● 組織に不足している能力・組織が特に必要としている能力を分析する ○ 組織の事業領域やミッションクリティカルから検討する ○ 弊社では DORA Quick Check などの活用も検討 ● 確認後・達成後の改善ができることを念頭にする ○ チェックリスト形式等は、達成度の計測のみが目的化する場合がある ○ 具体的な改善策も同時に提示して、実際の行動変容につなげる必要がある “DORA | DORA Quick Check.” dora.dev, dora.dev/quickcheck/. Accessed 25 July 2024.

25 まとめ ● 重要な SRE プラクティスを 8 つのステップで示すマップ を提供 ○ 細分化したチェックリスト 、各項目へのベストプラクティス ○ 現在地の把握 だけではなく、行動変容も同時に行う ● 活動を支えるドキュメントに関するガイドライン ● 社内組織への広範な浸透 ○ 重要項目の入れ替え・知見の集約・社内標準仕様の策定 ● 内発的動機付けに基づく SRE Enablement ○ 一環の活動が SRE チームではない全員によって行われる ○ SRE Trail Map はそのきっかけ (外発的動機づけ )