「SREをはじめよう」を読んで正解がないことを知った
はじめに
私は現在、ある会社でSREチームのマネージャーを務めています。SREに関する目標、戦略、戦術を考え、実践する立場にあると言えるでしょう。最近、私にとって非常にぴったりな本が出版されたので、その感想を共有したいと思います。
この本を一言で説明すると、 「正解がないこと（=自分で考える必要があること）とその向き合い方をやさしく教えてくれる本」 です。
SREが行うこと
SREについて学ぼうとした際、多くの人が最初に手に取るのが「SRE本」だと思います。私もその一人で、最初に出会った時、この図を見て「これを実践すればSREができるんだ！」とワクワクしたのを覚えています。
「14章 Dickersonの信頼性の階層構造（良い出発点）」のコラム「Dickersonの信頼性の階層構造では不十分」では、この図を素晴らしいものだと褒め称えつつ、これがSREの全てではないと述べられています。
Dickersonの信頼性の階層構造は、多くの点ですぐれていて、素敵で、見事で、素晴らしいものです。SREを始めるための素晴らしい地図であり、そうでなければ本書には載せていません。しかし、これはSREのすべてでも、SREが行うこと、SREが注力することでも、SREのするべきこと/プロジェクトの総体でも、組織にとっての価値でもありません。
この階層構造がSREの始まりであり終わりであるかのような印象を読者に与えてしまいます。
「トイル」についても、SREの取り組みがそれをどのように軽減できるのかについても、この階層では言及されていません
通常と少し異なる、そしておそらくあまり目にしないようなアイデアは、多くのSREが持っている、組織内のすべての本番環境を横断している独特の視点に由来します。この視点から、組織環境における一貫性の構築や維持の支援など、多くのことができるようになります。あるいは、一貫性の保持が最優先事項でない場合は、少なくとも、ある本番環境で発見された優れたアイデアを他の本番環境に広める手助けができます。
これが不完全なリストであることは確かであり、ある程度はそこがポイントです。Dickersonの信頼性の階層構造は、SREの表現においても不完全です。
最近ではDBRE（Database Reliability Engineering）やPlatform Engineeringなどの新しい役割も登場していますが、SREが元々それらの役割を暗黙的に担っていることも多いのではないでしょうか。私のチームでもそうした役割を果たしています。重要なのは、どんな方法であれ、大きなインパクトを出すことであり、それがSREであるかどうかは重要ではないと考えています。
14章では、SREを始めるための良い出発点を紹介する一方で、進むべき方向を誤らないための警告もあり、非常に読み応えがありました。
SREの評価指標
「15章 SREを組織に組み込む」の中で、「15.4 成功の兆し」では、SREが成功しているかを確認するためのシンプルな質問が提示されています。
- 人々はあなた（集団）に会えてよろこんでいますか？
- ゲートキーパーの役割を乗り越えたか、あるいは完全に回避することに成功しましたか
- 関係はプッシュ（状況に自分自身を売り込む）からプル（人々はあなたがそこにいるように頼む）に変わりましたか
- SREチームや組織は、あたりまえのようにロードマップ計画に参加していますか
- プロジェクト作業と受動的作業の比率は正しい方向に向かっていますか
- あなたはトイルを増やすのではなく、取り除く存在として見られますか？
このリストを読んだSREは、これは測定可能な目標の一覧というよりは、「雰囲気チェック」のようなものだと（正しく）指摘するかもしれません。私は「読者任せの演習」はあまり好きではないですが、この場合、あなたやあなたのチームがこれらの質問をSLI/SLO的な指標や目標に変換することで、自分たちの組織に特化した多大な価値が生まれると信じています。多くのSLI/SLO演習と同様、この演習は組織適合とSRE適用の一隅を照らすと確信しています。
このリストの後に続く説明が非常に良いと思いました。目標やあるべき姿は、業界やプロダクト、組織のフェーズによって変わるものであり、正解はその状況の数だけ存在します。設定した数値が本当に正解かどうかは、何度も試してみないとわからないことが多いです。
「15.3 適切なフィードバックループの構築と育成」では、改善サイクルを回すための具体的なヒントが紹介されており、非常に参考になります。
SRE成熟度モデル
本書では、元LinkedInのBenjamin Purgason氏が提唱した「SREの進化における5つの段階」を紹介しています。このモデルは「SRE成熟度段階」と呼ばれることもあります。
- 段階1：消防士
- 段階2：ゲートキーパー
- 段階3：提唱者（アドボケイト）
- 段階4：パートナー
- 段階5：エンジニア
興味深いのは、段階が1→5にまっすぐ進むわけではないという点です。
人々はこの章を、最終状態に到達することをゴールとする有限状態機械として扱う傾向があるからです。あなたのチームがパートナー段階に深く入っていても、そのチームがやっていることの一部が真っ当なゲートキーピングであることに気づいて冷や汗をかくことは十分にあり得ます。あるいは、パートナーシップの変化に応じて段階を出たり入ったりするようなこともあるでしょう。そして、口に出したくはありませんが、消防士を必要とするような火事が常に潜んでいるのです…。
自分が通過する、あるいは通過しないかもしれないさまざまな段階があるという考えを捨てれば、それはきっと役に立つことでしょう。
この章では、進化の過程において段階を行き来することがあるという現実的な視点が強調されています。SREチームがどの段階にいるか、どの段階を目指すべきかを自分たちで考えることが重要であり、ここでも「正解がないこと（=自分で考える必要があること）」が強調されている点が印象的でした。
さいごに
正解があることに時間をかけるのは無駄ですし、逆に「正解がない」と言われることで、色々考える気持ちが湧いてきます。この本はまさに「正解がない」ことを教えてくれる内容であり、チームで輪読会を開いたら非常に盛り上がるだろうと思いました。
Discussion