SRE を成功させるには、まず計画を立てることが大事

※この投稿は米国時間 2021 年 2 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

サイト信頼性エンジニアリング（または DevOps）を実装すると、魔法のようにすべてが改善されると思う人もいるでしょう。組織に SRE のおまじないをかけるだけで、サービスの信頼性と収益性が向上し、IT やプロダクト、エンジニアリングの各チームの誰もが満足すると。

このような勘違いが起こる理由は明らかです。世界屈指の信頼性と拡張性を誇るサービスのいくつかは、SRE チームの支援を得て稼働しているからです。Google がその代表的な例です。

私は、大規模な本番環境システムの稼働に明け暮れる生活を 20 年近く続けてきました。トレードオフ、信頼性、コスト、制約や要件が異なる多様なアーキテクチャの実装といったことで頭を悩ませ、深夜に呼び出されることもよくありました。最近では、その経験と知識を活かして、SRE プラクティスの実装など、Google Cloud のお客様がインフラストラクチャやアプリケーションをモダナイズするお手伝いをさせていただいています。経験から学べることは組織ごとに異なるように見えますが、実はどの組織にも共通する、デプロイの成否を左右する教訓があります。

問題が発生する原因は、技術面ではないことが一般的です。SRE 文化の行き詰まりは、目標が事前に明確になっていない、関係者が適切に関与していないといった、ビジネス プロセスでの失敗が原因となっていることがほとんどです。このような展開を何度も目の当たりにした経験から得られた教訓をもとに、SRE プラクティスの実装を成功させる方法について、テクノロジー リーダー向けのアドバイスを提供したいと思います。

始める前に

SRE 実装の道のりは、1 つ目のマニュアルを読む前、あるいは SRE アドバイザーに初めての電話をかけるはるか前から始まっています。組織内のテクノロジー リーダーとして初めにやらなくてはいけないのは、いくつかの重要な質問に答え、基本的な情報を収集することです。

解決しようとしている問題は何か

ほとんどの組織は、組織に改善すべき点があることを認識しています。作業負担の軽減、組織の創造性の向上、ソフトウェアのリリースに要する時間の短縮といった課題を抱えているかもしれません。大規模システムを確実に運用するためのフレームワークである SRE は、こうした目標の達成に役立てることができます。そのためには、そうした目標を達成したいと考える理由を明確にし、組織内に存在するギャップやニーズを把握することが重要です。

組織が変革によって何を達成しようとしているのか、自問してみましょう。また、信頼性に関する懸念事項は何でしょうか。SRE を成功させて効果を上げるには、最初に問題を自覚することが重要です。解決すべき問題を特定することから始めると、解決策を見出せるだけでなく、組織がフォーカスを定めやすくなる、共通の目標に向かって関係者の足並みを揃えられる、意思決定者の賛同を得やすくなるなど、さまざまなメリットがあります。

解決すべき問題を把握したら、次にどのような状態になれば「解決した」とみなせるのかを決める必要があります（つまり、「成功」の定義を決めておくということです）。目標を定めることは重要です。目標を定めておかないと、改善したかどうかを判断できません。自己評価に役立つ指標を定める方法については、今後の投稿でご紹介します。

組織の主要な意思決定者は誰か

SRE の原則を実装する際に中心となる要素はエンジニアリングですが、実際には SRE は技術的な挑戦というよりも、組織を変革するプロセスであるといえるでしょう。そのため、業務の進め方や企業文化を変えなければならなくなることがほとんどです。

他のビジネスの変革と同様に、このプロセスに関与する意思決定者を事前に特定しておく必要があります。具体的に誰であるかは組織によって異なりますが、製造や運用に関わる部門の関係者や、技術部門のリーダーなどが一般的です。ただしその役職名は組織ごとに異なり、複数の組織に分かれていることもあります。意思決定者を特定する作業は、縦割りの組織では特に困難になりがちです。時間をかけてさまざまな部署に連絡を取り、主要な関係者と有力者を特定することが重要です（この作業を行うことで、後でかなりの時間を節約できます）。少しでも関係のありそうな部署には必ず連絡を取りましょう。要件（セキュリティなど）の異なるさまざまな部署から情報を入手してください。

同時に、柔軟に作業を進めるよう心がけてください。この作業の途中で、意思決定者のリストが改訂されたり、手直しされたりしても問題ありません。他のエンジニアリング分野と同じように、単純な手順を繰り返して、複雑なものを完成させましょう。

賛同を得て信頼を築く

関与する意思決定者を特定したら、同僚や組織の他のリーダーからの支援を取り付けます。権限移譲を積極的に行う企業文化を構築することは、SRE の中核原則である学習できる文化（失敗を受け入れ、非難せず、精神的な安心感をもたらし、漸進的な変化と自主自律に重きを置く文化）の実現に不可欠です。

私の経験では、リーダーや意思決定者からの幅広いサポートと賛同がなければ、組織に真の変化をもたらすことはできません。このことは、SRE に特に当てはまります。DevOps と同様に、SRE を実装するには、組織内のさまざまな機能（製品、運用、開発）間での共同作業が必要です。ほとんどの組織では、こうした機能は指揮系統が分かれており、それぞれに独自のプロセスがあります。各機能の目標や手順を一致させるためには、リーダーが変革を優先する姿勢を示さなければなりません。同時に、文化の変容をボトムアップで推進するのは、トップダウンの指示によって進めるよりも困難で時間がかかることがあり、企業文化によっては不可能なことさえあります。つまり、変化を推進して「正しい」文化を育むためには、まずリーダーが模範を示したうえで、組織の人々に権限を委譲することが重要なのです。

短距離ではなくマラソンである

SRE への道のりには、技術的な面からの課題と人間的な面（文化やプロセスなど）からの課題がいくつも折り重なっています。成功するためには、リーダーが組織の変革を優先する姿勢を示し、エンジニアリングの卓越性（品質と信頼性）を実現するためにリソースを割り当てるとともに、自部門中心的な考え方を脱し、失敗を非難せずに受け入れるといった文化的原則を育む必要があります。

期待値を一致させる製品やエンジニアリングから経営陣まで、SRE の実装に関与するすべての関係者は、変化には時間と労力がかかること、そして短期的にはリソースが必要であることを認識する必要があります。手ごわい挑戦のように思えるかもしれませんが、SRE の目標は、困難な問題を克服してより良い明日を築くことです。

SRE の原則の詳細については、リーダー向けのこちらの Coursera コース、Developing a Google SRE Culture（Google SREのための企業文化の構築）をご覧ください。次の投稿では、適切なチームの作り方、権限移譲、コミュニティの構築など、SRE の第一歩を踏み出したチームが検討するべき戦術的な事柄をご紹介します。