* この投稿は米国時間 7 月 11 日、Mission Controller である Paul Newson によって投稿されたもの（投稿はこちら）の抄訳です。

ちょっと待て。これは Google じゃない、ヒューストンだ！
上の写真は NASA の Christopher C. Kraft Jr. Mission Control Center ですが、私たち Google にも、これにちなんで Mission Control と名付けられたものがあります。
ただし、私たちの Mission Control は場所ではありません。製品開発に携わるエンジニアに SRE（Site Reliability Engineer : サイト信頼性エンジニア）の仕事を体験させる 6 か月のローテーション プログラムです。その目的は、Google のような大規模環境で信頼性の高いサービスを構築、運用することの難しさを理解しているエンジニアを増やすことです。
Mission Control が受けた刺激はまだあります。Gene Kranz 氏がヒューストンのミッション コントローラーたちのために作らせたフライト パッチ *1 を参考に、私たちもフライト パッチを作りました。Google の SRE には、このフライト パッチ付きのジャケットが支給されます。
私たちのフライト パッチには、Kranz 氏の名言 “Tough and Competent”（タフで有能であれ）のラテン語表記 “Duri et Periti” が記されています。このフライト パッチが付いたレザー ジャケットを着た人を見かけたら、その人は Google の SRE ということです。


では、SRE とは具体的に何なのでしょうか。SRE という言葉を生み出した Google のエンジニアリング担当 VP、Ben Treynor Sloss は「SRE とは、操作機能を作ってくれとソフトウェア エンジニアに頼んだときに起こることだ」と述べています。
Ben は 2003 年、Google の “Production Team” のリーダーに任命されました。メンバーは 7 人のソフトウェア エンジニアで、チームはソフトウェア エンジニアリング チームとして発足しました。以来、Ben はこのチームを、自身がソフトウェア エンジニアとしてかかわり続けたいと思える集団に育ててきました。
13 年後、Ben が率いるチームは約 2,000 人の SRE を擁するまでになりましたが、以前と変わることなく、ソフトウェア エンジニアがかかわりたいと思うチームであり続けています。ちなみに、Mission Control ローテーションに参加したエンジニアの約半分は、ローテーションが期間満了になっても SRE のポジションを選択しています。
Google は、2～3 年ほど前から SRE に関する対外的な情報発信を行っています。たとえば、Ben は SREcon14 の講演で、Google でチームを育ててきた 11 年間に学んだ SRE の原則を紹介しました。また GCP NEXT 2016 では、Google で使われているテクニックの一部を、顧客のクラウドで実行されているワークロードに応用する方法について Melissa Binde が説明しました。
もっと深く掘り下げたいという方には、現在販売中の書籍『Site Reliability Engineering』をお勧めします。おかげさまで、この書籍は読むべき本として高く評価されています。
実は、私はこれから 6 か月間、エキサイティングな Mission Control ローテーションの冒険に旅立つことになっています。Google Compute Engine の面倒を見ているシアトルの SRE チームに合流するのです。
これから始まる冒険で学んだことの一部は、このブログでシェアするつもりです。SRE の詳細や、サイト信頼性エンジニアリングが Google のクラウド サービスに与えている影響について知りたい方は、続報を楽しみにお待ちください。
*1 http://genedorr.com/patches/Ground.html
- Posted by Paul Newson, Mission Controller