SREにおけるコンテキストの話

gch

これは SRE Advent Calendar 2021 6日目の記事です。

こんにちは、岩崎です。突然ですが、皆さんはSREの探求は読まれましたでしょうか？

SREの探求は、様々な企業における SRE の実例に触れることができるとても良い本です。まるでカンファレンスの廊下で優秀な SRE たちの会話に耳をそばだてている気分を味わうことができます。

この本の各章はどれも魅力的なのですが、その中でも特に私の目を引いたのが、第1章の「SREにおけるコンテキストとコントロール」の話です。

コンテキストとコントロール

SREの探求の冒頭を飾る第1章は 現 Microsoft、元 Netflix の Coburn Watson 氏のコンテキストとコントロールの話で始まります。

少し長いですが、書き出しの部分を引用します。

David: あなたとはこれまで、さまざまなことについて語り合う機会を楽しんできました。あなたからお聞きした中で私が最も興味を引かれた点の一つは、SRE を実践する方法についてです。つまり、コントロールを中心とするプロセス（これが SRE の実践では一般的な方法ですが）を用いるのではなく、コンテキストの提供を重視するという主張です。本日は、この点を掘り下げていきたいと思います。まず、コンテキストとコントロールの対比が何を意味するのかと、それぞれの優れた例を説明していただけるでしょうか。

Coburn: 私は、コンテキストとは追加の関連情報を提供することだと考えています。それによって誰かが、与えられたリクエストや表明の背後にある論理的根拠をより的確に理解できるようになるわけです。最も高いレベルで見ると、Netflix では可用性に関連するコンテキストがエンジニアリングチームと共有されますが、これは提供するマイクロサービスに関する可用性の傾向と、それが望ましい目標とどのように関連しているかを示す情報となるでしょう。ここには下流に対する依存関係も含まれます。こうしたドメイン固有のコンテキストが与えられることで、エンジニアリングチームは可用性の改善に必要なステップを取るための責任（とコンテキスト）を手にすることになります。
　コントロールベースのモデルでは、チームとしてマイクロサービスの可用性目標を把握しているでしょうが、その目標を達成できない場合には罰則の対象となるかもしれません。例えば、プロダクションにコードをプッシュする権限を取り上げることなどが考えられます。Netflix では試行錯誤を経て、先ほど説明したモデルにたどり着きました。つまり、マイクロサービスレベルの可用性に関するコンテキストを共有した上で、必要に応じて担当チームとの共同作業を通じ、可用性の改善を支援するようにしています。

ここでは SRE におけるコンテキストが何を意味するのかが簡潔な言葉で語られています。つまり、コンテキストとはコントロールと対比されるものであり、エンジニアリングチームが自らの手で可用性を改善できるように追加の関連情報を提供することを指します。

コンテキストベースのアプローチと対になる、コントロールベースの代表的なモデルは Google のエラーバジェットです。エラーバジェットは SLO に基づき算出される、損失可能な信頼性を意味します。そしてエラーバジェットが底をついた時、開発チームは強制的にプロダクションへのプッシュ権限を取り上げられることになります。

このコントロールベースのエラーバジェットモデルは、一見非常に合理的に見えます。実際にSRE本が世に出た時、このエラーバジェットモデルは大いなる賞賛を持って受け入れられました。しかし、それと同時に、多くの組織が Google のようなエラーバジェットモデルを導入しようとして失敗したのも事実です。今でもエラーバジェットモデルが有益なことに変わりはありませんが、時間が経つにつれ、よりそれぞれの組織にあったアプローチが求められるようになりました。

私の所属する組織でもエラーバジェットを少し形を変えて部分的に導入したり、設定したバジェットを上回った時に調整できるように組織構造を見直したりといった取り組みを行ってきました。詳細は以下の記事に譲りますが、これらの取り組みは一定の成果を上げつつも、やはりどこか腑に落ちない思いがありました。

そんな時に出会ったのがこのコンテキストの話だったのです。

コンテキストの背後にあるもの

コンテキストベースのアプローチは、私が感じていたモヤモヤや、行ってきた取り組みを見事に言語化してくれました。エラーバジェットを設定して、仮にバジェットを上回ったとしても、多くの組織では開発を止めることをできないばかりか、それによって組織内の対立はより深まってしまうでしょう。それは合理性ばかりに気を取られ、本来大切にしなければいけないはずの人間同士のコラボレーションが忘れられているからなのです。私はこのコンテキストの背後にあるのは DevOps の考え方だと思いました。

class SRE implements DevOps と言われるように、DevOps は SRE の元になった考え方です。この DevOps はよく CI / CDなどのツール の文脈で語られがちですが、本来 SRE より遥かに抽象的な概念であり、アジャイルや、リーン、組織論などから幅広い影響を受けています。いわば DevOpsは、IT開発、運用、ネットワーキング、セキュリティのサイロを壊すために設計されたプラクティス、ガイドライン、文化の緩やかな集合なのです。

DevOps において、ツールと同じくらい重要なのが文化です。開発チームと運用チームがコラボレーションし、組織としてのデリバリスピードを上げること、サイロをなくし幅広く情報を共有することなどは DevOps の基本といえます。また、変化は徐々に起こすべきものというのも DevOps の重要な考え方です（これはリーンソフトウェア開発から影響を受けていると思われます）。

つまり DevOps とは人間同士のコミュニケーションを大切にし、強い文化を作ることでボトムアップで改善活動を推し進める取り組みなのです。これはそのままコンテキストベースのアプローチではないでしょうか。

DevOps と SRE のこれから

最近は SRE ばかりが持て囃され、DevOps はもはや過去の遺物であるというイメージがあるかもしれませんが、 DevOps は今でも有効な考え方です。実際に、SRE は DevOps の一実装に過ぎません。そしてもちろん、 SRE と DevOps は対立するものではありません。

温故知新とは古いものをたずね求めて新しい事柄を知るという意味の言葉ですが、SRE のこれからを考えるときに、古き良き DevOps に立ち返ってみるのは案外役に立つかもしれません。DevOps はきっと良いヒントを与えてくれるでしょう。今回このコンテキストとコントロールの話を読んで、私はそんなことを思いました。皆さんはどう思いましたか？

この記事が気に入ったらサポートをしてみませんか？