組織横断的なSRE活動を始めようとしています

この記事は株式会社エス・エム・エス Advent Calendar 2024 vol.1の12月9日の記事です。

エス・エム・エスで全社SREというロールで活動しているSecurity Hub芸人1の山口(@yamaguchi_tk)です。 おすすめのAWSサービスは営業です(いつもお世話になっています)。

はじめに

SRE(Site Reliability Engineering)は、運用の効率化とシステムの信頼性向上を目指すアプローチです。 私たち全社SREチームでは、組織横断的にSRE活動を開発チームにEnablingしていく取り組みを開始します。本記事では、その背景や目的、具体的に活動を予定している内容をご紹介します。

背景

現在、事業部に専属のSRE(Embedded SRE的な立ち位置のSRE)がいないサービスでは、主に全社SREがインフラの構築・運用を担っています。しかし、システムの運用については受動的な対応が多く、「組織の信頼性のマインドセット:Google SRE の知見」に記載のある組織の信頼性のマインドセットではAbsentな段階でした。

そのため運用負荷が集中し、信頼性向上や運用の効率化のための活動になかなか手が回らない状況でした。

エス・エム・エスは事業活動の性質としてサービスの数が多く、事業部に専属のSREがいない全てのサービスの運用の効率化、信頼性の向上を全社SREチームだけで行うことは現実的ではないため、新たなアプローチを策定しました。

SRE活動を開発チームにEnablingしていく目的

私たちのチームが目指すのは以下です。

  1. 開発チームの自律性を高める
    1. 開発チームがSRE活動を主体的に実施し、信頼性のあるシステムを構築・運用できる体制になることを支援します。
  2. 運用の効率化と信頼性の向上
    1. 運用負荷を軽減し、システムがより高い信頼性を保つ状態を維持します。

具体的な活動内容

以下のような手順で活動内容を決定しました。

  1. 全社SREチームが開発チームにEnablingするSRE活動を定義
  2. 定義した活動を開発チームに委譲する目標レベルを定義
  3. 定義した活動で成熟度レベルを評価するものを決定

開発チームにEnablingする活動は以下のようになりました。

活動 Enable対象 目指す委譲レベル 成熟度評価
SLI/SLO ⭕️ 尋ねる ⭕️
監視 ⭕️ 尋ねる ⭕️
インシデント対応 ⭕️ 尋ねる ⭕️
ポストモーテム ⭕️ 尋ねる ⭕️
ドキュメント管理 ⭕️ 尋ねる
トイルの撲滅 ⭕️ 尋ねる ⭕️
コスト管理 ⭕️ 尋ねる ⭕️
脆弱性対応 ⭕️ 尋ねる ⭕️
インフラ設計 ⭕️ 同意する
開発効率の向上 ⭕️ 尋ねる ⭕️
セキュリティ対応 伝える
Admin業務 伝える
知識共有とトレーニング 伝える
ログの管理 伝える

委譲レベルはManegement3.02を採用しました。

  1. 伝える:私が決定し、チームに伝える
  2. 説得する:私が決定し、チームを納得させる
  3. 相談する:チームに相談してから、私が決定する
  4. 同意する:チームと一緒に決定する
  5. 助言する:助言はするが、チームが決定をする
  6. 尋ねる:チームが決定し、後で私を納得させてもらう
  7. 委ねる:チームが決定し、私は気にしない

成熟度評価

サイバーエージェントさんの資料3を参考にさせていただきLevel1からLevel3までの成熟度を設定しました。

SLI/SLO

  • Level1
    • SLI/SLOが設定されていない
  • Level2
    • SLOが計測され、信頼性の数値としてチーム内で認知されている
  • Level3
    • ベストプラクティスに基づいたSLO運用ができている

監視

  • Level1
    • 監視についてのルールや要件がなく、場当たり的な監視になっている
  • Level2
    • 監視ルールが整備され、プロダクトの異常が適切に検知できる状態になっている
  • Level3
    • ベストプラクティスに基づいた監視項目の設定、通知が行われている

インシデント対応

  • Level1
    • 対応フローが定義されておらず、対応が属人化している
  • Level2
    • 対応フローが定義され、チーム全体で反復可能な状態になっている
  • Level3
    • ベストプラクティスに基づいた対応フローが行われている

ポストモーテム

  • Level1
    • 障害報告書は書いているが、障害から学習できる状況になっていない
  • Level2
    • 障害をふりかえり、対応プロセスやプロダクトの改善につながっている
  • Level3
    • ベストプラクティスに基づいてポストモーテムの導入、ふりかえりが行われている

ドキュメント管理

  • Level1
    • 必要なドキュメントが整備されていない
  • Level2
    • 必要なドキュメントが整備されている
  • Level3
    • ベストプラクティスに基づいてドキュメントの維持や整備が行われている

トイルの撲滅

  • Level1
    • 運用作業と開発タスクが分断しており、運用作業の改善は場当たり的に行われている
  • Level2
    • 運用作業の見直しや改善が計画性を持って行われている
  • Level3
    • ベストプラクティスに基づいてトイルの計測や改善が行われている

コスト管理

  • Level1
    • コストの削減は場当たり的に行われている
  • Level2
    • コストの評価や削減が計画性を持って行われている
  • Level3
    • ベストプラクティスに基づいてコストの評価や対応が行われている

脆弱性対応

  • Level1
    • 脆弱性対応は場当たり的に行われている
  • Level2
    • 脆弱性対応が計画性を持って行われている
  • Level3
    • ベストプラクティスに基づいて脆弱性の評価や対応が行われている

開発効率の向上

  • Level1
    • プロセスは定義されているが自動化は行われていない
  • Level2
    • CI/CDが構築され、一部で自動化が行われている
  • Level3
    • ベストプラクティスに基づいて開発効率の評価や向上への対応が行われている

開発チームとのコラボレーション

開発チームとのコラボレーションについても、「開発チームが自律的に全てのフェーズを実施できている状態」を理想形と定義し、以下のように役割分担を整理しました。

フェーズ 事業部 開発チーム 全社SRE 備考
企画・要件定義 ⭕️ ⭕️
設計 ⭕️ 全社SREが可用性、セキュリティの観点でレビューを行う
インフラ初期構築 ⭕️ admin的な業務は全社SREが実施
その他は開発チームで構築
開発 ⭕️
インフラ変更等 ⭕️ 全て開発チームで実施
必要に応じて全社SREが支援、レビューを行う
アラート対応 ⭕️ 営業時間内外問わず開発チームが実施
インフラ作業 ⭕️ Admin業務以外は開発チームが実施
メンテナンス対応 ⭕️ 開発チームが通知を確認して開発チームが実施
脆弱性対応 ⭕️ ⭕️ 基本的に開発チームが自律的に実施
緊急性の高いものに関しては全社SREが脆弱性を確認し開発チームに対応を依頼

今後の展望

全社SREチームでは、この取り組みを通じて「組織全体で信頼性を高める文化」を醸成していきます。 開発チームと密に連携しながら、組織横断的なSRE活動の推進に取り組んでいきます。

本取り組みに関する最新情報や進捗は、随時Blogで共有していく予定です。


  1. SRE界隈でもAWS界隈でも「山口」だとレピュテーションがなかなか上がらないので、レピュテーションは「Security Hub芸人」で確保しています
  2. 「Management 3.0 デレゲーションと エンパワーメント」
  3. 「SRE Technology Map 2023」