Responsibility of SRE
最近改めて SRE とは一体何なのかについて考え直す機会があり、現状での自分の考えを整理したいと思います。
全体的に自分の主観を前提としているので、客観的に見ると違った考え方もあるかと思います。
インフラエンジニアと SRE の違い
インフラエンジニアから SRE へ
SRE という概念が世に出てきてから、元々社内にあったらインフラチームを、メンバーはそのままに SRE チームに転換させた会社は多くあると思います。
そして、それだけでは”上手く”行かないというのも皆さんご存知だと思います。これはインフラエンジニアと SRE とで発揮したい価値や責務に乖離があること、そもそも SRE という哲学の理解不足から生じていると考えています。
そういった背景から、改めて SRE と従来的なインフラエンジニアの比較から、違いを明らかにしていこうと思います。具体的な Migration Path については、これまた長い話になりそうなので、本記事ではスコープ外とします。
インフラエンジニアの責務
SRE が従来的なインフラエンジニアとどのように異なるのか整理するために、まずはインフラエンジニアの責務から整理したいと思います。
Software Service 事業者におけるインフラエンジニアの責務と認識されていそうなものを “主観” で申し訳ないですが、雑多に列挙します。
- ハードウェアの管理（e.g. サーバー機器の調達等）
- 構築業務（アプリケーション実装以外の全て）
- 構成管理
- 監視設定の管理
- デプロイパイプラインの管理
- ICT ツール管理
- ID 管理・権限管理
- 社内ネットワーク管理
- サービスの可用性対策
- サービスの対障害性対策
- サービスの性能対策
- オンコール対応
- セキュリティ対策
- ログ収集・分析基盤の構築
- 開発環境整備
- コスト管理
Software Service を提供していない企業においては、「インフラエンジニア = Network エンジニア」という定義も多いかもしれませんが、Software Service 事業者というスコープにおいてはそこまで違和感ないのではないでしょうか。例として、Software Service 事業者のインフラチームの業務紹介を載せておきます（私は部外者ですが、丁度いい記事だったのでお借りしました）。
続いて、インフラエンジニアと SRE との共通の責任領域を整理するために、多岐に渡るこれらの業務を分類してみます。会社によっては別々の組織なりチームが担当していることもあるでしょう。これまた主観で恐縮ですが、一旦以下の3つに分類してみました。
- 情シス業務（ハードウェアの管理、ID 管理・権限管理、社内ネットワーク管理、セキュリティ対策、コスト管理）
- IT 投資業務（ICT ツール管理、セキュリティ対策、コスト管理）
- サービスインフラ業務（ハードウェアの管理、構築業務、構成管理、監視設定の管理、デプロイパイプラインの管理、ID 管理・権限管理、サービスの可用性対策、サービスの対障害性対策、サービスの性能対策、オンコール対応、セキュリティ対策、ログ収集・分析基盤の構築、開発環境整備、コスト管理）
SRE はこれらのインフラエンジニアの業務の内、”サービスインフラ業務” の領域を主戦場とし、顧客から見て、信頼性の高いサービスを提供するための哲学・プラクティスだと理解しています。
Reliability Engineering は信頼性をどう担保していくかというのが目的なので、厳密には ”サービスインフラ業務” を超えて適用可能ですが、一旦典型的なユースケースにスコープを絞って話を進めさせてもらいます。
小規模な組織（特に新興企業）においては、PaaS や IaaS の利用により、（品質はさておき）SWE が ”サービスインフラ業務” と “開発業務” を兼務していることは少なくないと思います。つまりこの区分けはあくまで、顧客基盤の成長やサービスの複雑化に対応して、効率化や品質向上のために実行された分業の形態に過ぎません。
コアなソフトウェアやシステムを開発すること “以外” に、必要な業務を分業していく過程で、運用業務に類する業務がインフラエンジニアに委譲され、運用業務という概念が固まってきたのかなと推測しました。こちらの記事のハードウェアビジネス時代の区分けの名残ではないかとの話は興味深かったです。
インフラエンジニアのサービスインフラ業務
続いて、インフラエンジニアはどのようにサービスインフラ業務を進めているのか考えていきたいと思います。大体のケースでは、インフラチームが組織横断で社内の全サービスを中央管理するという方式ではないでしょうか。
この方式のメリットは、セキュリティや可用性のような、リスクの高い非機能要件の対応漏れが防げる（もしくは対応漏れがあっても責任の所在が明らかである）こと、ノウハウが集約されることで、運用業務自体の品質や生産性が上がることです。開発チーム側もコアとなるシステム開発に集中できるので、同様の効果が期待されます。典型的な分業の利点を享受できるモデルと言えます。
デメリットとしては、システム品質のクオリティコントロールが難しいという点でしょうか。サービス数の増加や、サービス自体の複雑性が増すにつれて、構成差異などの認知コストや、単純な作業量の増加がどうしても生じてきます。例えば可用性対策の機構が、システムAとシステムBの構成差異により、それぞれ別々に用意しなければならなくなるというケースです。特別対応が増えることで、対応のばらつきや、工数不足による妥協がシステムに現れてきます。
この状況を避けるためには、インフラチームが構成決定に関する強い権限を持ち、構成の標準化を維持できる必要があります。この前提があればサービス数が増えても生産性を高めていくことも可能でしょう。一方で標準構成に新しいオプションを追加する工数を捻出することは簡単なことではありません。インフラチームは事業価値の源泉ではなく、あくまでコストセンターであるという認識をされることが多く、余剰人員を獲得できないこともあるでしょう。
こういった背景から生じる構成の硬直化は、開発チーム側に新しい要件に対応できなくなったり、リリースサイクルが低下するなどの drawback を受け入れることを強要し、チーム間での衝突が発生します。
衝突の結果として、開発・運用どちらか（基本的に運用側）に妥協が発生し、品質や生産性の低下として現れます。その対策として、マンパワーによる場当たり的な解決が図られ、オーバーワークとなり、離職率が上がり、品質や生産性が下がるというネガティブスパイラルに入っていくというシナリオは想像に難くありません。
また開発起因での問題が起きた際に、その根本対応が取られるかどうかは開発チーム依存なので、基本的にインフラチームが自身の作業量をコントロールする術はありません。
成長と複雑化を続けるシステムにおいて、こういった組織横断のインフラチームによる一元管理は、品質と開発速度のバランスを上手く取るのが難しいという問題を抱えています。こういった背景を出発点とし、SRE の有用性が議論されます。
SRE の Principles
SRE とは何か、Google の SRE Book から引用すると、その主たる原則は以下4つだそうです。
- Embracing Risk (Error Budgets によるリスク管理)
- Service Level Objectives (顧客価値に基づいてサービス品質を評価)
- Eliminating Toil (運用業務の自動化)
- Monitoring (可観測性の重要視)
SRE が従来型のインフラチームと大きく異なるのは、SRE というチームをサービスとして見立てているところにあると思います。つまり全システムが必ずしも SRE チームによって管理される必要はなく、利用規約を守る限りは、SRE という運用代行サービスを利用することができ、各開発チームが、運用業務を SRE チームに委託できるという XaaS 型のメンタルモデルなのです。つまり、中央集権一括管理のインフラチームとは異なり、運用の基本責任はシステムを開発している開発チームが持つことになります。
システムはそれを生み出した開発チーム自身によって運用されますが、システムの SLO を定義し、一定期間安定して SLI やアラート発火率が SRE チームの許容できる範囲に収まっていることが確認できれば、開発チームはシステムの運用を SRE チームに委託することができるようになります。確からしい SLO を定義するためには、ある程度運用してみないとわからないため、通常ローンチ後、一定期間経ってから、この運用委託は行われます。
SRE に運用委託されたシステムは Error Budgets を守る限り、SRE チームによって保守運用してもらえることが保証されます。夜間にオンコール対応する必要がなくなるのです。逆に言えば、アプリケーションレイヤの品質が低いシステムは、SRE チームから開発チームへ運用を突き返したり、リリースを禁止され、改善作業にリソースを向けることが強制できます。SRE チーム起因で Error Budgets を消化してしまった場合はどうするのか等、実際の運用は会社ごとに異なると思いますが、基本的な枠組みとして、 開発チームに対して、SLO, Error Budgets に基づいて運用サービスを提供するという点では変わらないでしょう。
多くの場合、開発チームにとって好ましいオプションは、自らの工数で運用するよりも、SRE チームに運用してもらえる状態に改修して、運用を委託することです。そのため、自動的にシステムは単純で運用しやすい状態に収束し、結果としてシステムの信頼性は高めやすくなります。このインセンティブ構造による自主規制の促進こそが SRE のコアコンセプトであり、それをサポートするために SLO, Error Budgets などの各種プラクティスが存在します。
開発チームの視点から見ると、初期の試行錯誤の速度を確保できつつ、構成が固まったら、面倒な運用をSRE チームにお任せできるわけです。
SRE のサービスインフラ業務
それでは具体的に、SRE の導入によりサービスインフラ業務がどのように変わるかを整理します。
「SRE への運用委託サイクル外で必要となるサービスインフラ業務（ここでは、その他インフラ業務と呼びます）」が別チームの責務として分離されます。また、従来インフラエンジニアが行っていた標準化作業も、開発チームに委譲されるので、業務領域が小さくなっていることがわかります。どちらかというと元々の業務領域が広すぎただけという気はしますが。
代わりに、SLO, Error Budgets, ポストモーテムなどの運用業務が生じます。
SRE
- サービスの可用性対策
- サービスの対障害性対策
- サービスの性能対策
- 監視設定の管理
- セキュリティ対策
- ログ収集
- コスト管理
- オンコール対応
- SLO, Error Budgets の運用 (New)
- ポストモーテムの運用 (New)
- 運用業務の自動化 (New)
その他インフラ業務
- ハードウェアの管理
- デプロイパイプラインの管理
- ID 管理・権限管理
- コスト管理
- 分析基盤の構築
- 開発環境整備
SRE 導入により開発チームに委譲される業務
- 構築業務
- 構成管理
- サービスの可用性対策
- サービスの対障害性対策
- サービスの性能対策
- 監視設定の管理
- セキュリティ対策
- ログ収集
- コスト管理
- オンコール対応
新たに追加されたことからもわかるように、SRE の主要な責務は、こうしたインセンティブ構造を維持し、信頼性向上の改善サイクルがより高速に回るようにすることだと思います。つまり「運用代行サービス」を定着させ、その品質を高めることが最重要です。これによりシステムの複雑化が解消される力学が働き、運用がスケールします。
第二の責務は、これらの業務生産性を高めるための定型業務の自動化となるでしょう。これがないと、サービス数の増加に応じて人員増加が必要となってしまいます。これも目的は運用をスケールさせることです。
第三の責務として、SRE チームは品質の低いサービスの保守にリソースを奪われること無くなるので、その分のリソースを、より高い信頼性を実現するための仕組みの開発に回すことが可能になります。これの目的は運用のスケーラビリティではなく、より高い水準の信頼性を実現することです。
Embedded SRE と Production Engineering
Embedded SRE について
既に触れた Google による SRE のプラクティスとは異なる形式の SRE も存在します。
Spotify, Netflix, Facebook などの Tech Giant では “you build it, you run it” に則り、開発チームが運用まで全て行っているそうです。この開発チーム内に存在する SRE の機能は Embedded SRE と呼ばれたりします。わかりやすさのため、Embedded SRE と対称するために、Google 方式の SRE を Traditional SRE （私の造語です）と呼ぶこととします。
“you build it, you run it” が実践される開発チームには、SRE および他の機能別の役割が参加しており、サービス開始から廃止まで所有できる機能横断チームが作られています。開発チーム内に SRE 専任のメンバーを持つのか（このパターンは専任 SRE の過負荷で破綻することが多いそうです）、チーム全員が等しく責務を分担するのかは、会社によって方式が異なりそうですが、1チームで運用まで面倒を見るという意味では一致しています。
Traditional SRE と Embedded SRE を、所属するチームが異なるだけという組織構造の違いとして説明する議論を見かけたことがありますが、両者は明確に異なります。Traditional SRE が運用代行サービスの利用可否というインセンティブ構造から生じる自主規制により信頼性を高めようというアプローチであるのに対し、Embedded SRE においてそのようなインセンティブ構造は不要です。全ての機能が1チームに閉じているため、チーム運営を持続的にするために、運用工数の圧縮は必須です。そのため、自然と自主規制が働くというアプローチなのです。
Production Engineering
Embedded SRE において、特に開発チーム全メンバーで SRE の責務を分担する場合は、メンバーに運用のノウハウが不足していることが想定されます。以下のような SRE 業務遂行のサポートが追加で必要でしょう。
- サービスレベルの定義
- オンコール対応
- インシデント処理、RCA、ポストモーテムのガイダンス
- キャパシティプランニングに関するガイダンス
- モニタリング・アラートのセットアップベストプラクティスと、アラートの解釈方法
こうした背景から、運用業務を持たない Production Engineering チームという組織横断チームが作られます。Production Engineering チームは各開発チームに SRE プラクティスのコンサルティングを行ったり、デバッグ・トラブルシューティングのサポートといった技術支援を行います。これにより、各開発チーム内で完結したシステム運用を実現します。
会社によっては、チーム横断で必要となるソフトウェアやテンプレート開発などのプラットフォーム活動も Production Engineering チームの責務に含まれます。
Traditional SRE と Embedded SRE and Production Engineering での開発チームとの関わり方の違いを改めて整理すると、運用代行サービスを提供するのか、コンサルティングを提供するのかというコミットメントの違いがわかります。
共通点としては、開発チームが利用できる共通基盤を開発・提供している点でしょうか。こちらの共通基盤に関しては利用するかどうかは開発チームの自由意志（SRE の運用代行サービスを利用する際の利用条件に含まれる可能性はある）であることが、インフラエンジニア時代とのパラダイムの違いとなるでしょう。
まとめ
システムを単純化し、障害に強いものへ変化させていく自主規制構造を作り、その改善サイクルを高速化するための業務プロセス管理。そしてその先で、システムワイドなインシデントに向き合うための可観測性、可用性、対障害性の向上に向けた仕組み作りを行っていくというのが SRE の責務になるのかなと思いました。
従来型のインフラチームを分割すること、成長・複雑化するシステムを単純化していくインセンティブ構造を作るというのがコアになるので、上手く回すためには開発組織の在り方にメスを入れる必要があります。組織作りに関する権力を巻き込むことが必須になるでしょう。
参考資料
SRE の探求は色々な企業での実践例が載っており、考えを整理するのにとても参考になりました。
