1. なぜSREか？
1.1. スケールするサービスを高い信頼性で、かつ低コストで運用したいから
1.2. DevとOpsを対立させず、ユーザーに新機能をすばやく提供したいから
2. 本日の内容
2.1. 6章 分散システムのモニタリング
2.1.1. 非効果的なソリューション： 特定の条件を監視、条件が満たされたらアラート（ページ）
2.1.1.1. 人間が次のアクションを考える
2.1.1.1.1. 貴重な従業員の時間を消費
2.1.2. 代わりに
2.1.2.1. ソフトウェアが解析を行い、人間はアクションを取るのみ
2.1.2.1.1. 予め決めたシグナルに問題が生じたときに人間にページ
2.1.3. 4大シグナル
2.1.3.1. レイテンシ：リクエストを処理してレスポンスを返すまでにかかる時間
2.1.3.2. トラフィック：リクエストの量
2.1.3.3. エラー：失敗したリクエストのレート
2.1.3.4. サチュレーション
2.1.3.4.1. サービスの「手一杯」具合
2.1.3.4.2. 予測も可能 例：「DBがディスクの空き容量を圧迫し、4時間後にハードディスクの空きがなくなりそうです」
2.1.4. モニタリングやアラートのルール決め
2.1.4.1. 誤検知、ページャーによる燃え尽き症候群を避けるための問いかけ
2.1.4.1.1. 緊急で、対応が可能で、現時点（あるいは近い将来）ユーザーに影響を及ぼすものか？
2.1.4.1.2. 無害なものと判断して、対応せずにそのままにしておけるか？（その理由は？）
2.1.4.1.3. 間違いなくユーザーに悪影響があるか？除外すべきケースはないか？
2.1.4.1.4. 緊急か、翌朝まで待てるか？
2.1.4.1.5. 次アクションを取ることができるか？
2.1.4.1.6. そのアクションは安全に自動化できないものか？
2.2. 7章 Googleにおける自動化の進化
2.2.1. 自動化の価値
2.2.1.1. 一貫性：人では不可避
2.2.1.2. プラットフォーム：１つ自動化の仕組みをつくってしまえば多数に適用、拡張可能
2.2.1.3. 高速な修復：MTTRの短縮
2.2.1.4. 素早いアクション：フェイルオーバーのスイッチングなど、定義済みの動作であればシステムにやらせるほうが速い
2.2.1.5. 時間の節約：誰にでも実行できる仕組みをつくる＝1人分以上の時間の節約
2.2.2. システムを直接扱わなくなることによる運用者の経験不足の懸念
2.2.2.1. システムを”自律的”で弾力を持つ動作にする
2.2.2.1.1. そういったことはGoogleも乗り越えてきた
2.3. 8章 リリースエンジニアリング
2.3.1. ソフトウェアエンジニアリングで新しい分野
2.3.2. 簡単に言うなら、ソフトウェアをビルドしリリースすること
2.3.3. リリースエンジニアの守備範囲
2.3.3.1. ソースコード管理
2.3.3.2. コンパイラ、ビルド設定言語
2.3.3.3. 自動ビルドツール
2.3.3.3.1. 集計するメトリクス
2.3.3.4. パッケージマネージャー、インストーラー
2.3.4. 哲学
2.3.4.1. セルフサービスモデル
2.3.4.1.1. 自給自足のリリース環境
2.3.4.2. 高速性
2.3.4.2.1. リリース頻度を高めることでVersion間の変更を少なくする
2.3.4.3. 密封ビルド
2.3.4.3.1. ビルドプロセスは自己完結：誰がどのマシン上で行っても正常に動作
2.3.4.4. ポリシーと手順の強制
2.3.4.4.1. ソースコード変更の承認
2.3.4.4.2. リリースプロセスの間にある各手順の指定
2.3.4.4.3. 新リリースの作成
2.3.4.4.4. 新リリースのデプロイ
2.3.4.4.5. プロジェクトのビルド設定の変更
2.3.5. リリースで心配しないために…
2.3.5.1. 適切なツール、自動化、しっかりと定義されたポリシー
2.3.5.1.1. これらがあればあとはボタンを押すだけ
2.3.5.2. Googleは自分たちのポリシーを構えるツールがないので、自作した
2.3.5.2.1. ポリシー第一にすべき
2.3.5.2.2. 開発サイクルの初期に リリースエンジニアリングのための リソースを割り当てておくべき