ビジネスと技術の交差点：SREの哲学と実践

表現の校正に一部ChatGPTを利用しています

はじめに

SRE本が世に出てから５年以上たち、多くの企業が導入してきている。
そのため、そのプラクティスや他組織との関わり方などは、すでに多くの良書や良記事があり、今更無名の私が語るまでもないだろう。
つまり、年月を経るにしたがって「インフラ部隊をSREにアップデートする」「運用を技術者としてハックし続けることがSRE」といった理解で進められるような土壌はすでに整ってきていると考えて良さそうだ。そして、当然のようにSLOを考え、エラーバジェットを運用し、トイルを削減するという取り組みの好ましい面も広く知られているだろう。
しかしながら、私が最初にSREを知ったころの目から鱗が落ちる思いは、本当にそんなものだっただろうか。
この記事は、20年来のGoogle信者を自認している私が、GoogleでなぜSREが生まれたのか、どのように世界の人々に響いたのかをウォッチしてきたことを吐き出すポエムである。
また、私がSRE活動に取り組むときの姿勢を示すものである。

ここで述べることは私の見解であり、特定の企業や組織が公式に断定しているものではありません

想定読者

• これからSREを始める人
• SREとは何かを知りたい人
• エンジニアからSREと聞いてもピンとこないビジネス職の人
• SREのプラクティスはわかっていてもしっくりきていない人

ここで書くこと

• SREのバックグラウンド
• SREが目指すこと
• SREのビジネスへの関わり方

ここで書かないこと

• 各プラクティスの詳細
• 技術的な取り組み方
• 各主張の正しいリファレンス

概論

まず最初に、この記事で言いたいことをまとめて言ってしまおう。

• SREは功利主義的な取り組みである
• SREは実利主義的な取り組みである
• SREは現実的・人間的なプラクティスの集合である
• 結論：SREはビジネスと融合してこそ真価を発揮する

SREは功利主義的な取り組みである

「最大多数の最大幸福」（ベンサム）という言葉をどこかで聞いたことがあるだろうか。
SREが目指していることはそれである。

SREは実利主義的な取り組みである

この実利主義と前項の功利主義はラップする部分が多いが、こちらはどちらかと言えばSREを抱える企業に利することを目的としているものとして区別している。
多くの場合SREはサイト信頼性を謳っているが、究極的には継続的に利用者の維持拡大を目指す取り組みである。

SREは現実的・人間的なプラクティスの集合である

SRE以前の運用業務は誰でも常に同じ結果がでることを最上としていたが、SREではそれを最良としていない。
むしろ、綿密に計画しても常に問題はあり続けることを起点として、専門性を活かしたエンジニアが解決しつづけることを目指すような、ソフト的アプローチが強い。

結論：SREはビジネスと融合してこそ真価を発揮する

SREはその名前にエンジニアリングとついているが、非常にビジネスに寄り添った取り組みである。
したがって、SREの提唱するプラクティスを実践することはあくまで一つの方法であり、SREそのものではないことを理解してほしい。

SREの根付く土壌とは何か

人間と人間の作るものは不完全であること

システムや運用者が不完全であることを前提としてプラクティスが組み立てられているSREは、この前提を受け入れてもらわなければサボる口実としか受け取られかねない。
今は不完全であるが、明日はよりましな状態にするような漸進的改善を許容できることが必須条件である。

したがって、航空システムや医療システムなどの命に直結する仕組みに適用する場合には慎重を期さなければならない。

要求は常にアップデートされること

完璧なシステムを作りきって、それを長く（少なくとも5年10年などのスパン）利用し続けるようなことにはSREは適合しない。
そのような場合にはすべてのケースを想定して綿密にテストをやりきることで、高品質なシステムを提供することが重要である。
市場や利用者の要求は常にアップデートされ、それに追従する意志があるシステムの課題に対応し続けることが、SREの本懐である。

データが意志を支える

何らかの決定をする際に、当事者の思いだけではなくデータによる補強が重要である。
システムのエラーに対する態度は人それぞれである。
何らかの背景を持っていて最重要課題と考える人もいれば、数あるエラーの一つであると捉える人もいる。
そのために、客観的なデータを元にチームとして同じ方向を見続けることが、チームの総力を有効的に利用する方法である。

SREの哲学

SREの功利主義的側面

ユーザ体験の最大化

よく知られているSLOやSLIを例に考えてみよう。
典型的なSLOとしては「xパーセンタイルのユーザがエラーなくシステムを利用できること」のように設定されているだろう。
これをかみ砕いて、露悪的に表現するとこのようになる。

全体のxパーセントのユーザがこのシステムを正常利用できていれば問題ないと考える。こぼれ落ちたユーザに関しては関知しない

仮に既存システムがユーザにとって100%正しく稼働しているときの満足度を100としてみよう。
また、その満足度を維持するために必要な人員が常時5人（エラー解消やオペレータ等）であるとする。
この際、1年間すべてのユーザがエラーなく利用し続ける為には、120人月必要で、満足度の総量は1200である。

1200（満足度総量） = 100（満足度） \times 12（ヶ月）

一方、1%のユーザがエラー発生した場合には単純計算で満足度99（100*99%）となる。
その上で常時張り付きは不要で、5人を月間1%の満足度向上の開発に回した場合はどうなるだろうか。

この場合複利計算となる為、kヶ月後の満足度S(k)は以下の数式で表される。

S(k) = 99 \times (\frac{101}{100})^k

これで12ヶ月後の満足度総量はこうなる

\begin{align}
\sum_{k=1}^{12}S(k) &= \sum_{k=1}^{12}(99 \times (\frac{101}{100})^k) \\
&= 99(1.01)+99(1.01)^2+99(1.01)^3+⋯+99(1.01)^{12} \\
&= 99+99.99+100.98+⋯+110.09 \\
&= 1272.8
\end{align}

つまり、1%のユーザをあえて度外視することで、一定期間後の総量としては高くなる。
このように一部のユーザの負担に目をつぶることで、資源を有効に活用し、その結果として可能な限り多くのユーザにとって良好な体験を提供することが可能になる。

開発者体験の最大化

80:20の法則のように言われるが、システム開発を完璧にする最後のピースを埋めることの困難さは、それ以前の労力総量に匹敵することがある。
ということは、必然そこに携わる人たちのプレッシャーや労力は多大なものとなるが、それに対して得られるリターンは軽微であることが多い。
他方、機能拡張に携わることで新規性の高いものが生まれていくプロセスに喜びを覚える人は多いだろう。
更に、３交代で目を皿のようにして監視し続けるオペレータ業務も過酷なものである。
議論の先取りになるが、失敗を前提としたSREは開発者や関わる人々の体験の最大化も目指している。

SREの実利主義的側面：ビジネス価値の最大化

次にエラーバジェットに代表される実利主義的側面を見てみよう。

SREでは、システムの拡張がユーザの維持拡大につながるという前提のもと、SLOを違反するリスクを許容しつつ、ビジネスを拡大していく。
例えば、SLO設定値に違反する状態に達する7割までは、該当エラーの早期解決を目指さず、機能開発を優先するという手法である。

SLOを作ることでどれくらいのユーザの機会損失や解約を許容して、ビジネスを拡大していくかを考えていくのだ。

以下、枝葉ではあるが各プラクティスのビジネスへの関わり方を敷衍しよう。

SLO設定におけるビジネス的意志決定

SLO設定は、エンジニアリングの判断だけでなくビジネス的な意志決定の一部であり、企業全体の戦略に密接に関連している。簡潔な言葉で言えば、「このシステムがどれだけエラーとなったときの機会損失を許容できるか」「このシステムが遅いことの不満による解約をどれだけ許容できるか」というビジネス上の戦略的判断を反映するものである。

エラーバジェット管理とビジネス戦略

すでに述べたように、システムの安定性と新機能を天秤にかけたときの、ビジネス戦略を反映したものがエラーバジェットである。
どこまでアグレッシブな開発がビジネスにとって良いものであるかを考えることと同義である。

障害対応やポストモーテムのビジネス的意義

障害対応やポストモーテムは、ビジネス継続性とリスク管理の観点から重要なビジネス的意志決定となる。障害発生時の迅速な対応は、ビジネスのダウンタイムを最小限に抑え、顧客への影響を軽減する。また、同様の障害を減らして次なる失敗に備えるポストモーテムは、一時的に出血を塞ぐだけではなく、繰り返される機会損失を減らす重要な行為である。

トイルの撲滅とビジネス価値

トイルの撲滅は、効率的なリソースの活用とエンジニアの創造的な能力を最大限に引き出すためのビジネス的意志決定である。エンジニアが手作業のルーチンから解放されることで、より高度なタスクや新機能の開発に専念できることがビジネス上のコンピテンシーにつながるからである。

SREの現実的・人間的な側面：人間の限界、Embracing Failure

SREは人間の限界を理解し、それを前提としたアプローチを採用している。これは、24時間365日の運用を要求する従来の方法とは対照的である。SREは、「人間や人間の作ったシステムは失敗を含むものである」という前提のもと、適切なエラーハンドリングや対応策を考える。

具体的には、エラーバジェットの管理や障害時の対応方針、ポストモーテムの取り組みなどがある。これらの取り組みは、システムの持つエラーを前提とし、それを適切に管理することで、システムの安定性を維持しつつ、開発者の作業負荷を軽減する。

従来の思想では、システムの安定性や性能を追求するあまり、失敗の許されない運用や開発といったストレスを抱えることになっていた。
しかし、失敗はあるものだという前提で作られる運用の中では、心の余裕から生まれる障害時対応の適切な対処やシステムの多重化などで、逆説的に安定性を高めることにつながると考えられる。

SREの生まれた背景

このセクションでは、GoogleがなぜSREを提唱し始めたのか、その背景と主な要因を探る。
これにより、SREの基礎となる哲学ががより鮮明に理解できることを期待している。

多くのユーザとステークホルダー

Googleは世界中の何十億ものユーザに対して24時間365日サービスを提供する巨大なIT企業であり、全体のユーザに対して一定以上の品質を維持し続けることが求められていた。
さらに、Googleのビジネスモデルは主に広告に基づいており、ユーザ体験とエンゲージメントがビジネスの成功にとって不可欠な要素である。そのため、システムのパフォーマンスや安定性がユーザ満足度に直接的に影響を及ぼすという認識があった。このことから、システムの改善や新機能の導入といった、ユーザ体験向上のための活動がビジネス価値を生み出す一方で、それらはシステムの変更や更新を伴い、一定のリスクをもたらすことが理解されていた。

営利企業として

言うまでもなくGoogleは世界随一の営利企業であり、その開発したものは利益を生むものであることが求められている。
その中でどのようなアプローチが利益を最大化するものかを考えなければならない。もちろん、10の事実で語られるように一方的な利益を求めていたとは考えていない。
しかし、よく知られるようにすべての人を満足させることはできないため、取捨選択をする基準に利益は重要な要素である。

Googleは合理的な企業である

Googleの理性主義はよく知られるところである¹。
そもそもPage Rankからして評価をデータとして手に入れる方法であるし、数式看板での人材募集やWORK RULES!を紐解けば、データを中心とした意志決定などのエピソードも数多くある。
そんなGoogleがSREを産んだことは合理的選択であることの裏付けでもある。

Googleの選択

全ユーザに対して100%の可用性を提供するという現実的に困難な目標を追求するよりも、全体のユーザに対して一定の品質を維持することを合理的な選択として採用できた裏には、表に出てきていない様々なデータが存在していたはずだ。
私が仮の数字として出した漸進的改善の効能を、更に正確な数字で検討していることだろう。
また、プロジェクトOxygenも同時進行していたため、効果的なチームの構成要素がSREとマッチしていることも影響しているかもしれない。

いずれにせよ、このような課題を解決するために、GoogleはSREの哲学とプラクティスを開発し、提唱することになった。SREは、全体的なユーザ体験の改善と運用の効率化を可能にする一方で、リスクを適切に管理する方法を提供した。それにより、Googleはビジネス価値を最大化し、エンジニアリングと運用の持続可能性を確保するための架け橋となる新たなプラクティスを提供することができた。SREの提唱は、結果としてビジネス価値と技術目標の最適なバランスを保つための合理的で効率的な選択となったのだ。

プラクティス実践へのヒント

長々とSREの哲学を語ってきたが、具体的なプラクティスの実践にどのように役立たせるかを考察したい。
改めてこれらの哲学や背景を振り返ってみることで、悩みがちな問題に一本筋を通す方法を見つける手助けになることを願う。

SLOをどのように設定するか

• このビジネスはどれくらいの規模なのか
• n時間の機会損失がどのように影響するか
• n%のユーザ離脱がどのように影響するか
• 試算した上でビジネスサイドと合意とれたか

エラーバジェット

• プロダクトバックログはシステムの価値をどれだけ向上させる期待があるか
• エラー対応にどれくらいの資産を投入する必要があるか
• 投資と運転の比率をどのようにするか

障害対応とポストモーテム

• 障害のMTBFとMTTRのビジネス影響はどれくらいか
• 障害対応時にどれだけの人員が必要か
• 初動はシンプルで失敗の少ない方法であるか
• ポストモーテムでどのように未来の出血を削減するか

トイルの撲滅

• 現状維持のためにどれだけの運転資金が必要か
• 現状をn%改善した際にどれだけのビジネス影響があるか
  • 単に削減効果だけではなく、先へ進めるための開発に再投資できる

プロアクティブなアクション

• 上記プラクティスを更に前に進めることでどのような影響があるか

おわりに

SREは、その手法や哲学がビジネスと深く結びつき、進化し続けていくことだろうと期待している。
というのも、プラクティスはすでに広く知れ渡り、多くの実践例が聞こえているだろう。
しかしながらそのプラクティスは必ずしも固着しておらず、技術の進歩や人々の成熟と共に一層進化しているものだと考えている。
例えば、SREが登場した頃には目新しかったSLOという概念も、今では一般的に使われることになり、Datadogなどのオブザーバビリティ製品で実装されることで、簡単に使えるようにもなっている。

しかし、私はプラクティスを実践していくだけでSREが成就するものではなく、今後の情勢にしたがって常に変化し続けるものだと考えている。
そのときにここで書いたSREの哲学は、技術の進歩やビジネスの変化に応じて新たなプラクティスを生み出す礎となれば幸いである。

1. Google信者の筆者から見て最近はなりを潜めている感があるので寂しい限りだが ↩