SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

34章まとめ

執筆：Benjamin Lutch†1

編集：Betsy Beyer

私は本書を強い誇りを持って読み通しました。1990年代の初めにExciteで働き始めたときから、私のグループは「ソフトウェアオペレーションズ」と呼ばれる原始的なSREグループのようなものであり、私はシステムの構築のプロセスを通じて自分のキャリアを模索してきました。IT業界での何年にもわたる私の経験に照らしてみれば、SREという考え方がこれほどの速度でGoogleに根付き、進化してきたのは驚くべきことです。私はGoogleのインフラストラクチャはこの地球上で最も興味深いコンピューティングインフラストラクチャだと信じていますが、私がGoogleに加わった時点では数百人のエンジニアの集団だったSREは、今では1,000人を超えて10箇所以上のサイトに広がり、そのGoogleのインフラストラクチャを動かしています。

それでは、10年ほどの間にGoogleのSREの組織が進化し、この巨大なインフラストラクチャを知的で効率的、そしてスケーラブルな方法でメンテナンスできるほどになれたのはなぜなのでしょうか？　私としては、SREの圧倒的な成功をもたらした鍵はSREが礎とする原理にあると考えています。

SREチームは、エンジニアが自分の時間を等しく重要な2種類の仕事に分けるように構築されています。SREが人を割り当てるオンコールシフトでは、エンジニアはシステムに触れ、それらのシステムがどこでどのように壊れるのかを観察し、それらを最もうまくスケールさせるにはどうしたらよいか、といった課題を理解します。しかし私たちには、それらのシステムを管理しやすくするためには何を構築すればよいか、振り返って決断するための時間もあります。根本的には、私たちはパイロットとエンジニア/設計者の ...