SRE本を買いました！せっかく分厚い本を読み始めたので、簡単にまとめていこうと思います。

今回のセクション

第一部イントロダクション
1章イントロダクション

それではさっそく↓

サービス管理者へのシステム管理者へのアプローチ

もともとのシステムの運用では、システム管理者といわれる人が存在していた。
ただし、大きく異なるスキルセットが求められるので、多くの組織ではチームが別れてしまう。
（いわゆるdevチームとopsチーム）
しかし、その分断には大きなデメリットがあった...

直接的
変更管理やイベントを手作業でやっていると、サービスやトラフィックの増大に伴い、そのシステムの運用負荷は増大、よってコストも上がるのは明白
間接的
両チームの動機付け、コミュニケーション、用語、プロダクトの安定性のターゲットレベル、リスクの考えかたの違い

その結果、両チームは衝突することも多々。
特にリリースにおいて、2つのチームの目標は基本的に対立関係にある。

devチーム：新しい機能をリリースし早く使ってほしい
opsチーム：新しいことすると、トラブル起きがち、やめてほしい、安定を守りたい

サービス管理へのGoogleのアプローチ；SRE

そこでGoogleは、ソフトウェアエンジニアを採用し、その人達にサービスを運用させ、
opsの人が手作業で行ってきたことを遂行するシステムを構築させました。それが後にSREチームとなった。
（手作業に飽きる→その手作業を代替するシステム）

Googleのサービス管理に対するアプローチの要素は、チーム編成に表れていて、
このバックグラウンドの多少の多様性（複数のスキルセットの融合）は良いシステムを生み出すことに繋がっているらしい。
主に2つの人たちに別れる。

Googleのスキルセットを満たしたソフトウェアエンジニア
↑のスキルセットをほぼ満たしている、かつ多くのソフトウェアエンジニアが持っていない技術（特にインフラ）を持っているエンジニア
すべてのSREに共通するのは、複雑な問題を解決するソフトウェアの開発に対する信念と適正。

すべてのSREに対して、チケット・オンコール・手作業といった運用作業を業務の50％以下にするよう上限を設けていて、
この上限によって、サービスを安定して運用するための開発をする十分な時間を確保している。
結果、
運用と開発の作業のバランスを意識して維持することで、クリエイティブかつ自律性を確保しながら、運用面から収集した知見も持つ
チームとなった。

SREの信条

SREは、サービスの可用性、レイテンシー、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を持つ。
では、どのように環境（実働環境、devチーム、Testチーム、ユーザなど）とやり取りすべきか？

エンジジニアリングへの継続的な注力の保証
運用作業に割く時間を50％と決める。それをdev側も理解し、そういうシステム作りを目標とする
サービスのSLOを下回ることなく、変更の速度の最大化を追及する。
「サービス障害を0にする」ではなく、機能のリリース速度を最大化するためにエラーバジェットを使う
モニタリングする
これまでの閾値や条件でメール通知＋アクションの必要性を判断という、人間の解釈が必要な運用はダメ
その代わり、ソフトウェアが解釈し、人間はアクションが必要なときのみ通知を受けるような環境を用意する
緊急対応
人間を介入させず復旧させる。それができないならベストプラクティスを考え手順を作っておく
変更管理
リリースの速度と安全性を高めるために、漸進的なロールアウト、高速かつ正確な問題検出、問題発生時の安全なロールバックを用意しておく。さらにこれらのプラクティスを人手でやらないことで、よくある不注意などの問題を回避する。
需要の予測とキャパシティプランニング
未来の需要（自然的なものと突発的なもの）に対して必要な可用性を確保できるよう、キャパシティと冗長性を確保しておく
プロビジョニング
必要な時にのみ、素早く、かつ正確にシステムを利用可能な状態にする
効率とパフォーマンス
利用率に注意を払い、リソースの効率的な活用を行う