DevOps プラクティスを強化したい場合、調査結果は「SRE を試す」

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

信頼性は重要です。アプリケーションにアクセスできない場合、アプリケーションの反応が遅い場合、またはアプリケーションが期待どおりに動作しない場合、ユーザーはアプリケーション提供者が意図した価値を得られません。そのため、Google では、信頼性はどのようなシステムにおいても最も重要な特性であると考えています。信頼性の影響は、最終的な利益に至るまでのあらゆる過程で見られます。ひとたびダウンタイムが発生すると、収益は大幅に低下し、評判やユーザー ロイヤルティは損なわれます。

DevOps Research and Assessment（DORA）プロジェクトの開始当初から、私たちは一貫したエクスペリエンスをユーザーに提供することの重要性を認識していました。その測定には Four Key 指標が使われています。そのうち 2 つは新規リリースのデプロイ速度を追跡します。残り 2 つはそれらのリリースの初期の安定性を捕捉するもので、前者とバランスがとれています。これら 4 つの指標がすべて高いチームは、コードの配布に長けているだけでなく、配布するコード自体も優れています。

ただし、これら 4 つのシグナルは、デプロイへの道とその即時的な効果に焦点を当てたものであり、その後のリリースの寿命全体で見た成功の診断には向いていません。2018 年に DORA は、技術的なオペレーションが組織のパフォーマンスに及ぼす影響を明らかにするため、（ウェブ アプリケーションに代表される）サービスとして提供されたソフトウェアの継続的な安定性に関する研究を開始しました。この安定性はこれまで、可用性を測定する追加指標で捉えられてきました。今年 Google は調査範囲をこの領域に広げ、「可用性」という言葉を「信頼性」に置き換えました。信頼性（「r9y」と略されることもあります）は、可用性に加えてレスポンスのレイテンシやコンテンツの妥当性などの側面も包含する、より広い意味を持つ用語です。

2021 年の State of DevOps Report のクラスタ分析では、ソフトウェア デリバリーの Four Key 指標に基づいてチームが 4 つのグループに分けられました。一見したところ、信頼性の実践は、ソフトウェア デリバリーのパフォーマンスとは直接相関していませんでした。つまり、デリバリー指標のスコアが高いチームと最新のオペレーションを一貫して実践しているチームは必ずしも一致していません。しかし、両者を組み合わせて見ると、ソフトウェア デリバリーのパフォーマンスと信頼性エンジニアリングは組織の成果に大きな影響を及ぼしていることがわかります。ソフトウェア デリバリーに優れたチームのうち、信頼性の目標も達成しているチームでは、ビジネスの成果が向上したという回答が 1.8 倍多くなっています。

Google は信頼性をどのようにして達成しているか: SRE

初期の Google では、技術的オペレーションに対して従来のアプローチをとっていました。つまり、ほとんどの業務において、個々の問題に手動で介入していました。しかし、Google のプロダクトを利用するユーザーが世界中に急速に広がるにつれて、このアプローチでは持ちこたえられないと悟りました。システムの規模や複雑さの増大に合わせて拡張することができず、維持するだけでもオペレーション部門に受け入れがたいほどの投資が必要でした。そのため、過去 15 年以上にわたり、Google ではサイト信頼性エンジニアリング（SRE）と呼ばれるアプローチを実践し、これを反復しています。

SRE は、測定、優先順位付け、情報共有のフレームワークを提供するもので、機能リリースの速度とデプロイされたサービスの予測可能な動作とのバランスをとるために役立ちます。このアプローチは、リスクの軽減や、エンジニアの時間を解放して戦略的な業務に回すために、自動化を使用することを重視しています。これは DevOps の説明とよく似ていると思われるかもしれません。実際、これらの手法では多くの価値が共通しています。このような類似性から、2016 年に Google がサイト信頼性エンジニアリングに関する初めての書籍を出版したとき、そこから共通の考え方を読み取った DevOps 実践者のコミュニティで議論が巻き起こりました。これは一部に混乱をもたらし、DevOps と SRE は互いに対立または競合するものとして定義する人もいました。

Google は、同じような課題から生じ、同じような目的を共有する DevOps と SRE は、互いに共存できると考えています。例えて言えば、SRE と DevOps の関係は class SRE implements DevOps のようなもので、SRE は DevOps の目的を実現する手段を提供します。これらのコミュニティが成長し続けているという背景と、継続的な意見交換から、両者の関係を詳しく調査することには意味があると思われたため、今年の調査ではデータ収集の範囲を拡大しました。この狙いは、業界全体での SRE の採用の程度を評価し、このような最新のオペレーションの実践が DORA のソフトウェア デリバリー パフォーマンスのモデルとどのように相互作用しているかを明らかにすることです。

SRE に関する書籍を始めとして、私たちはこのフレームワークの主要な要素を実務担当者向けアンケートの項目として追加しました。その際、できるだけ専門用語を避け、最新のオペレーションを実践するチームがどのように業務に取り組むかをわかりやすい言葉で説明することに注意を払いました。その結果、「ユーザーの目に見える行動という観点で信頼性を定義する」、「エンジニアが戦略的な業務に専念できるように自動化を使用する」、「インシデント対応のために、明確に定義された広く実施されているプロトコルを用意する」といったプラクティスについて回答が収集されました。

この調査でわかったのは、DevOps を実施するために SRE を使用することは、私たちが考えているよりもはるかに広く実践されているということでした。SRE や、これに関連する Facebook のプロダクション エンジニアリングのような手法は、一握りの大手テクノロジー企業のみが取り入れているニッチな手法というイメージがあります。しかしそれに反して、DORA の調査によると大部分のチームがなんらかの仕事で SRE を使用しており、回答者の 52% が 1 つ以上の SRE プラクティスを使用していると回答しました。

SRE はソフトウェア デリバリーのパフォーマンスを増強する

ただし、SRE は幅広く使用され、明白なメリットをもたらしてはいますが、調査の対象としたすべての SRE 手法を実践していると回答した人はごく少数でした。SRE をより広範囲に適用することは、あらゆるレベルでメリットがあります。ソフトウェア デリバリー パフォーマンスのすべてのクラスタにおいて、信頼性の目標も達成しているチームは、同じクラスタに属する他のメンバーよりもビジネス成果という点で秀でています。

卓越した DevOps に向けた SRE の道のり

SRE は単なるツールセットではなく、オペレーション スタッフの役割に関する企業文化的な考え方でもあります。SRE は、情報の把握や問題対応時の継続的な反復を狙いとした学習の規律です。したがって、SRE の導入には時間がかかります。また、成功を収めるには、まず小規模に開始し、SRE 自体に反復的なアプローチを適用する必要があります。

SRE に着手するには、次のような方法があります。

• sre.google で無料の書籍や記事を探す

• bit.ly/reliability-discuss で、さまざまな SRE 実施段階にいる実務担当者との会話に参加する

• Google が提供しているプロフェッショナル サービスについて GCP アカウント マネージャーに問い合わせる

Google では、DevOps アワードへのお申し込みを受け付けています。皆様の職場で DORA の原則とともに実践している SRE プラクティスをご紹介ください。