殆どのサービス障害は何らかの変更や機能のローンチによるユーザトラフィック増によって引き起こされるものなので、これらのチームの目標は基本的に対立関係となります。このような対立する問題にGoogleは下記のようなアプローチを取る。Googleのサイトリライアビリティエンジニアリングチームは、ソフトウェアエンジニアを採用することを注力し、採用したエンジニアにサービスを運用させ、従来であればシスアドによってしばしば手作業で行われていたであろう作業を遂行するシステムを構築させています。監視・デプロイ専門家ではなくソフトウェアエンジニアにその作業をさせることで、システム化・自動化も実現することを狙っているのでしょう。するよう、上限を求めているようです。この上限により、SREが本来行うべきシステム化・自動化の時間を十分に確保できているということ。本にこのことはさらっと書いているが、これが実現されている組織がすごい。ついて話されています。ここまで読んでみると、なんとなくSREを設置していく目的と理由が見えてきました。開発側が開発プロセスを改善していく方向ととても良く似た方法で、運用側がプロダクションサービスの安定性も効率化していくようなイメージができますが、これは組織的にサポートして初めて実現できるようなものであるようにも思えます。次章からは本格的にどう実践していくかが書かれている模様ですね。通信・インフラによって最適化が実現されている、という説明の章。基本的にこの章は以降のgoogleがどのようにサービスを効率的に運用しているかの説明のために、同社の社内事情や前提知識を説明している章のように見える。よって、わからなかった場合に適宜見るくらいで読み飛ばしても良い気がしました。リスクの受容」は「SREの仕事とはどういうものか」、そして「なぜこのような仕事をするのか」について幅広い検知を得たい方にとっては、最重要となる必読の章です。この章がSREのKPIを決める上で一番重要な内容であると思われます。システムの可用性は最重要。99%の可用性のシステムを99.9%にするコストが現在の100倍かかるなら取り組むべきでない。99%の可用性のスマートフォンで動作するWebサービスに99.99%の可用性は必要ない。グローバルに展開しているサービスにおいては時間的な可用性のメトリクス化にはあまり意味がないので、サービスのリクエストの成功率を指標とすべき。エラーレスポンスの数をリアルタイムに計測しているだけだと、相対的にエラーが増加したときに問題修正に当たるということしか行われないため、ここで書かれている計測が達成できているとは言えないです。仕事柄として「コンシューマーサービス」を前提として考えてみる。リスク許容度によってコストも変動してくるので、かなり開発・運用の深いところまでプロダクトマネージャーと相談するということになります。バジェット(予算)として使い切ることができるという考えです。これをSREは開発成果物のリリース判定に用いることができます。