はじめに
- SRE(サイトリライアビリティエンジニアリング)とは何か?→エンジニア、システムの信頼性を向上させる者、運用について考慮する者
第Ⅰ部 イントロダクション
- 第Ⅰ部では、SREとは何か、そしてSREがIT業界における従来型手法と何が異なるかをみていく。
第1章 イントロダクション
1.1 サービス管理へのシステム管理者のアプローチ
- シスアドを用意することと、開発と運用を分断することの利点と欠点について
- 基本的に、開発は新しい機能を早くリリースしたい、運用は変更をしたくない、と考えているので対立する
1.2 サービス管理へのGoogleのアプローチ:サイトリライアビリティエンジニアリング
- SREチームにとってスキルセットの多様性は重要
- GoogleのSREチームでは運用にあてる作業時間を50%以下に抑えるように定めた
- SREチームのメンバー採用は、求めるものが高いため難しい
1.3 SREの信条
- 各SREチームの持つべき信条は同じ
- SREチームは、サービスの可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニングに責任を持つ
1.3.1 エンジニアリングへの継続的な注力の保証
- SREが行う運用作業の量が50%を超過した場合、超過分を開発チームに差し戻す
- インシデント後にはポストモーテム(障害報告書みたいな)を書く
- SREチームと開発チームの関わりは https://qiita.com/san-tak/items/1e8a6aae062c5f6c4c64 の下のほうの図が分かりやすい
1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する
- 100%を信頼性の目標とすることは、基本的にいかなる場合にも間違っているという所見のもと、サービス障害を悪とみなさず、開発とSREの対立構造を解消する
1.3.3 モニタリング
- 人間に判断、解釈させるようなアラートを出してはならない
- 効果的なモニタリング出力には3種類ある
- アラート:人間が即座にアクションを起こして対応し、状況を改善しなければならないことが生じていることを知らせる
- チケット:人間がアクションを起こさねばならないことを知らせる(即座でなくてもよい)
- ロギング:人間が見る必要がないもの。診断やフォレンジックに使用
1.3.4 緊急対応
- 緊急対応の評価にはMTTRを使う
- 人間の作業を介さないシステムが良い
- オンコールエンジニアの出番となった場合に備え、事前に十分な手順書を用意しておく
1.3.5 変更管理
- 70%のサービス障害は、動作中のシステム変更によっておこる
- 自動化で以下を実現することを目指すべき
- 漸進的なロールアウトの実装
- 高速かつ正確な問題の検出
- 問題が生じた際の安全なロールバック
1.3.6 需要の予測とキャパシティプランニング
- 以下のステップでキャパシティプランニングを実施する
- 自然な需要の正確な予測。この予測は、キャパシティのリソース確保に必要なリードタイムも踏まえる
- 需要予測に突発的な需要の発生源を正確に織り込む
- 計算リソースのキャパシティ(サーバー、ディスク等)とサービスのキャパシティの関連を把握するための、定期的なシステム負荷テスト
1.3.7 プロビジョニング
- プロビジョニングは変更管理とキャパシティプランニングの組み合わせ(?)
- プロビジョニングは素早くかつ必要な場合に、正確に行う
- プロビジョニングによって追加されたキャパシティが、正しく動作することも検証する
1.3.7 効率とパフォーマンス
- リソースの効率的な活用が、サービスのトータルコストに大きな影響を与える
- 特定のパフォーマンスを維持できるように、プロビジョニングを行うため、パフォーマンスの改善は大事
1.4 始まりの終わり
- これ以降、SREの詳細を見ていく