1章イントロダクション

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

歴史的に企業はサービスを動作させるために既存のソフトウェアコンポーネントを組合わあせて動かせるシステム管理者を雇用してきた。「シスアド」とも呼ばれるこの役割は開発者とは異なるスキルセットを持つので、「dev」と「ops」という別々のチームで分けられてきた。シスアドという役割の利点はあり、業界では馴染みのあるパラダイムであり導入しやすいことである。

一方で「シスアド」とも呼ばれる役割を作ることで「dev」と「ops」の分断によりデメリットも生まれた

直接的には手動運用が中心の「ops」チームはサービスの成長やトラフィックの増大によるシステムの運用負荷が増えるに連れてチームを拡大せざるを得なくなる
間接的には「dev」と「ops」が異なるバックグラウンド、スキルセット、動機づけが異なるためプロダクト開発において安定性やリスクの捉え方について異なる解釈をして衝突が生まれる
- 「好きなものを好きな時にローンチしたい」vs「いったん動いたシステムは一切変更したくない」

開発者は衝突を迂回する方法を学び、レビューの実効性が失われていく。

1.2 サービス管理者へのgoogleのアプローチ：サイトリライアビリティエンジニアリング

「dev」と「ops」の衝突に対して、Googleはサイトリライアビリティエンジニアリング(以降、SRE)チームはソフトウェアエンジニアを採用した SREはシスアドによって手作業で行われたであろう作業を自動化するシステムを構築する

SREのうち、60％はGoogleの標準的なソフトウェアエンジニア採用を経て雇用されたメンバである
残り40％はソフトウェアエンジニアリングの必須条件を85%-99%満たす候補者である
後者のほぼ必須条件を満たすメンバは、ソフトウェアエンジニア採用よりもエンジニアリングやUNIXシステム、ネットワーキングに関する専門知識をもつ

SREを採用していった結果、(a)手作業でタスクをこなすことにすぐ飽きる、(b)複雑でも手作業のシステムを自動化できるスキルをもつ、エンジニアのチームができた GoogleではすべてのSREに対してチケット、オンコール、手作業といった「運用」業務の合計を50％以下にする上限を設けた上限を超えた場合、開発チームに差し戻したり新たな人員をチームに加えることができるシステムの稼働、メンテンナンス、改善に必要なSREの人数はシステムのサイズに対して比例しない

1.3 SREの信条

サポートするサービスに対する一連の基本的な責任と、中核となる信条の尊重はすべてのSREチームに共通する。 SREチームはサービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を負う。

信条
- SREが運用作業に書ける時間は50％
- 「エラーバジェット」を導入して、サービスのSLOを下回らずに変更速度の最大化を追求する
  - 「サービス障害をゼロに」する目標から「エラーバジェット」に目標を変えることで、開発とSREの間で起きる構造的な競合を解決する
- モニタリングは人間がメールを読んでアクションの必要性を判断するシステムは根本的な欠点を持つと考える
  - 効果的なモニタリングとして人間に即座のアクションを促すアラート、人間に日次のアクションを促すチケット、フォレンジックのっために記録するロギングの3要素を持つ
- SREは70%のサービス障害は動作中のシステムへの変更によって生じることを発見し、自動化で以下を実現するベストプラクティスを得た
  - 漸進的なロールアウト
  - 高速かつ正確な問題の検出
  - 問題が生じたときの安全なロールバック