それでも、SRE の銀の弾丸を求めて

著者：木村健人(AoTo)
目次

自己紹介

こんにちは。Datadog Japan で Sales Engineer をしている 木村健人(AoTo)です。

Sales Engineer という職種は、Datadog の導入を検討されているお客様にプリセールスの段階で専任のスペシャリストとして導入支援を行う役割を担うことが主な業務です。そうした中で、システムに Datadog / Observability の導入を検討されている様々なエンジニアの方々の悩みを伺ってきました。

本記事では、こうした悩みを元に「SRE(Site Reliability Engineering) の銀の弾丸」を求めていくというシナリオでの考察を行います。

銀の弾丸とは

そもそも、「銀の弾丸」とはフィクションの世界で不死身や強靭な生命力を持つ狼男・魔女・魔物に対抗する一撃必殺の手段として説明され、転じて万能な解決手段としての比喩表現として用いられます。

この言葉は特に、エンジニアリング・ソフトウェアに携わる IT 技術者の間では、1987年に Fred Brooks が発表したソフトウェア工学の論文『No Silver Bullet - essence and accidents of software engineering』によって広く知られています。一般的には、上述の論文タイトルの通り、「銀の弾丸」という言葉に続いて「そんなものはないので泥臭く頑張ろう」という結論に導かれます。

しかし、ここからは SRE の銀の弾丸があると仮定して、それはどのようなもので、どのようにすればきちんと扱えるかを考えていきます。

SRE の銀の弾丸

まず初めに、SRE の銀の弾丸にはどのような要素が必要でしょうか。『Site Reliability Engineering』 で述べられている様々な SRE の基礎・原則・実践を元に紐解いていきます。

SRE の原則では7つの原則が説明されています。この中でも、最も重要とされるリスクの受容(Embracing Risk)で述べられている通り、SRE のプラクティスを全て実践しても、システムに100%の信頼性を適用することは現実的ではありません。このことからも、SRE の銀の弾丸に求められる要素は100%の信頼性などではなく、SRE のプラクティスを実現するための土壌であるはずです。

この SRE のプラクティスには、監視(Monitoring)・インシデント対応(Incident Response)・事後検証/分析(Postmortem/Root Cause Analysis)・テストと製品リリース(Test + Release product)・キャパシティ計画(Capacity planning)・開発(Development)・製品(Product)といったサービス信頼性階層(Service Reliability Hierarchy)で説明される要素が挙げられています。

サービス信頼性階層

これらのプラクティスには、共通してツール・文化・ノウハウに大別できる要素が重要であるように思います。(もちろんその他にも分類方法があるかもしれません)

SRE 3 things

ツール

実践的なアラートでも紹介されている Borg における Borgmon のように、システム(特に分散システム)の状態を正しく理解するためにも監視・オブザーバビリティのツールは欠かせません。さらに、オンコール対応・効果的なトラブルシューティング・インシデント管理・停止の追跡など、それぞれのプラクティスを実現するためにも適切なツールを選択することがコスト最適なアプローチと言えるでしょう。

これらのツールを利用することが、SRE の第一歩となります。

ツールは、弾丸を発砲するための拳銃です。しかし、この拳銃が発砲されることに理解がなければ、未知の標的を打ち破ることは賞賛されません。

文化

事後検証文化: 失敗から学ぶの例のように、SRE のプラクティスにおいて文化は非常に重要です。事後検証で個人やチームに対する非難が発生すれば、誰も SRE を実践したいと考えることはないでしょう。つまり、銀の弾丸があっても誰も扱いたがらないということです。

文化が醸成されれば、SRE のプラクティスが根付きより効率化されていきます。

文化は、拳銃を発砲することを許容する法律です。しかし、この拳銃の扱い方を知らなければ、未知の標的を打ち破ることはできません。

ノウハウ

無知な状態で SRE の文化や関連するツールの利用を促進しても、コストの増加に対する費用対効果を十分に見込むことはできません。ノウハウを蓄積し共有していくことで、組織に適合したプラクティスを把握し、適切なリソースに投資することができます。フロントエンドにおける負荷分散やCron による分散定期スケジューリングはまさにこうしたノウハウの一例です。

ノウハウによって、適切・効率的にツールを利用し文化の醸成を促進できます。

ノウハウは、拳銃の扱い方を説明できるマニュアルです。これによって銀の弾丸を拳銃に込め、未知の標的を打ち破るための方法を知り、周りの協力のもと打ち倒すことができます。

ですが、銀の弾丸は一体どこにあるのでしょうか？

SREs と銀の弾丸

これまで、ツール・文化・ノウハウで銀の弾丸を扱うための拳銃・法律・マニュアルのようなものと説明してきました。

システムのことを一番に理解しているのは、そのシステムを開発したエンジニアです。つまり、銀の弾丸があるとすれば、それはまさにエンジニア自身(もしくはその知識・技能・経験)が銀の弾丸たり得るのではないでしょうか。

そして、こうした「銀の弾丸」を体現するエンジニアこそが SREs(Site Reliability Engineers) です。昨今は SREs が様々な分類で整理されていますが、ここでは Platform SREs・Enabling SREs・Product SREs について考えてみましょう。

先ほどの考察の3要素のうち、それぞれの SREs が主に担うのは以下のようになります。

  • Platform SREs: ツール・文化 複数の製品・サービスにまたがる共通基盤を整備し、横断的な方針の策定や仕組みの整備を行う。
  • Enabling SREs: 文化・ノウハウ 各製品・サービスチームに対して、SRE のプラクティスや文化を組織へ浸透させ、自立支援を行う。
  • Product SREs: ノウハウ・ツール 各製品・サービスに所属し、そのチームにおいて高い生産性と信頼性の向上に責務を持つ。

このように、全ての要素を併せ持つ SREs は存在せず、それぞれの要素が合わさって初めて「SRE の銀の弾丸」を実現できるのではないでしょうか。

おわりに

以上のように、SRE の基本に立ち返りながら「銀の弾丸」というキーワードを起点に SRE に何が必要かを考えてきました。結論として、(私個人としては) SRE の銀の弾丸があるとするならばそれは SRE を実践するエンジニアであり、それこそが SREs である、と考えています。

SREs には様々な分類や役割がありますが、特に大きな組織においてツール・文化・ノウハウの全てを担うことは現実的ではありません。これらのうちいくつかの要素を、システムの信頼性を向上させる SREs が SRE の銀の弾丸となるよう、個々が意識して SRE を実践することが重要です。