以下の本を読みました。メルカリが2015年に組織に導入したSREに関して、生みの親のGooglerが詳細な説明をしていてためになります。

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム
- 作者: 澤田武男,関根達夫,細川一茂,矢吹大輔,Betsy Beyer,Chris Jones,Jennifer Petoff,Niall Richard Murphy,Sky株式会社玉川竜司
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/08/12
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (1件) を見る
- SREは、従来のシスアドではなくソフトウェアエンジニアが運用を構成するという立ち位置。開発/運用の分断による必然的な対立関係をインセンティブ設計で統合し、サービスの成長と運用コストが比例しないように切り離すべく生まれた。シスアドとしての技術要件はソフトウェアエンジニアからは遠いものだったが、それをGoogleは再定義してて、こんなに良くなったんだぜ、オレたちのやり方はこうだぜ、と説明している
- エラーバジェットとは、サービスレベル目標で設定する許容可能なエラー率(時間、範囲、レベル)を指す。サービスを早期にリリースしてユーザーを獲得したいソフトウェア開発チームは、この予算内で品質レベルを作り込めた時点でデリバリーできるので、これを超過するまでは機能開発に集中できるという点でメリットがあり、SREと開発チームの密なやりとりをする必要がない。
- 過度の信頼性はコストに跳ね返る。100%の信頼性を持つサービスを目指すべきではない。ユーザは高い信頼性と極度に高い信頼性の差異に気づかない。ユーザ体験を決定づけているのは、ワイアレスネットワークやモバイル端末などもっと信頼性が低い要素。
- ソフトウェアベースの自動化は多くの環境において手作業による運用よりも優れているとGoogleは信じている。もちろん自動化が必ずしも万能薬になるのではなく能力を増幅するもの。最も優れているのは、自動化も手作業も必要としない自律的なシステム。
- 高いスループットと低いレイテンシの両方が求められるシステムの多くにとって、合意アルゴリズムは低速であり、コストがかかりすぎるということが一般通念となっていた。Multi-Paxosが安定したリーダーを選択することによってパフォーマンスを改善する。
本筋ではないが、Googleの分散合意の運用方法は面白かった。ブロックチェーンの文脈でしか知らなかったが、Googleのような環境でタイトな合意プロセスを導入するとこうなるというのがわかった。ブロックチェーンの合意をめぐる価値の算定を精緻にできる気がする。一部には大きな可能性があり、ハイプされているその他大部分は、砂上の楼閣だろう。今の下げ相場でその大半が退場するはずで、本物だけ残ればいいと思う。
まとめ
ここに記されたGoogleのベストプラクティスの一部はGoogle Cloud Platformを使うことで、巨人の肩に乗れる。Snapchatの中身はGoogleなんて形容されていて、Googleが買収を提案したくらい。ゼロから考えて、SREなどの概念群とその運用方法などを作る姿勢が重要だと感じられるし、毎度毎度Googleには本当に驚かされる。広告取引のセカンドプライスオークションの導入もそうだし、IPOもダッチオークションでやるなどソフトウェアとは異なる分野でも自分たちの叡智を信じているわけね。
マネなんかしないぜと言っているわけではなく、マネだけしていて何も考えてないカルチャーが出来てくるとキケンだし、そういうハスッこいだけで味のない会社作ってもワクワクしないよね。検索サービス作るためにハードウェアから始めるという、ゼロから自分で考えて自分でやってみるというカルチャーを作ろうと強く感じさせられた。
https://yoshidashingo.hatenablog.com/entry/2017/08/08/200306
http://tech.mti.co.jp/entry/2017/11/25/000316
http://www.slideshare.net/GoogleCloudPlatformJP/managing-risk-with-error-budgets?from_m_app=android