SREとは、ソフトウェアエンジニアに運用チームの設計を依頼したときに起こること

SRE誕生の経緯

歴史的に、企業は複雑なコンピューティングシステムを実行するためにシステム管理者を雇用してきました。シスアドとも呼ばれるこの役職は、サービスを運用し、イベントが発生したり、イベントに応じてアップデートが必要になるたびに対処します。

システム管理者の役割には、製品の開発者に求められるスキルセットとは著しく異なるスキルセットが求められるため、開発者とシステム管理者は「開発」と「運用」または「ops」という別々のチームに分割されている状態です。

しかし、この開発者とシステム管理者という役割分担は、大きな問題があります。

一つは、システム管理者は手作業が中心となっていたため、システムが大きくなるにつれて、必要となる人数も増えていたということです。もう一つは、開発者とシステム管理者の間に発生する心理的/技術的な溝です。

ほとんどの障害は、新しい構成、新機能のリリース、新しいタイプのユーザートラフィックなど、何らかの変更によって発生するため、2 つのチームの目標は根本的に対立してしまうのです。

SRE とは、ソフトウェアエンジニアに運用チームの設計を依頼したときに起こることです。

GOogleの運用チームは、以下の割合で構成されていました。

50～60% は Google ソフトウェアエンジニア、より正確には Google ソフトウェアエンジニアの標準手順で採用された人々です。
40～50% は、Google ソフトウェアエンジニアリングの資格 (必要なスキルセットの 85～99%) に非常に近い候補者であり、さらにSRE には役立つもののほとんどのソフトウェアエンジニアには珍しい技術スキルセットも持っています。(UNIXシステムの内部とネットワークの詳細)

SRE に共通するのは、複雑な問題を解決するソフトウェアシステムを開発するという信念と適性です。

SRE の採用に対する当社のアプローチの結果、(a) 手作業でタスクを実行することにすぐに飽きてしまい、(b) 複雑なソリューションであっても、以前の手作業に代わるソフトウェアを作成するために必要なスキルセットを持つ人々で構成されるチームが誕生しました。