サイトリライアビリティエンジニアリング：第1章
第1章：イントロダクション
- SREとは何か。SREがIT業界における従来型の実践方法とは異なるのか？
- Googleのプロダクション環境の紹介
1.1 サービス管理へのシステム管理者のアプローチ
- シスアドのシステム管理のアプローチ
- devとopsが分離
| メリット | デメリット |
|---|---|
| ・実践しやすい ・人を集めやすい |
・間接的/直接的なコストが生じる |
- 直接的
- コストがかさむ
- システム運用の負荷の増大に伴って、シスアドチームを大きくする必要があるため
- コストがかさむ
- 間接的
- バッググランド/スキルセット/動機づけが異なることから生じるコスト
- devとopeが対立する
- dev：新機能のリリース
- ope：システムの安定稼働
1.2 サービス管理へのGoogleのアプローチ：サイトリライアビリティエンジニアリング
Googleのサイトリライアビリティエンジニアリングチーム
- シスアドが手作業で実施する作業をシステム化
- コードを書かなければならない
- サービス管理に対するGoogleのアプローチの主要な構成要素はSREの各チームのチーム編成
- 運用ではなくエンジニアリングに注力する
- 「運用」業務は、全体の50％以下にする上限がある
- どのように時間を使っているか計測する
- 開発作業の時間の確保
- 「運用」業務は、全体の50％以下にする上限がある
- シスアドが手作業で実施する作業をシステム化
SREのチーム構成
すべてのSREに共通するものは、複雑な問題を解決するソフトウェアシステムの開発に対する信念と適正
- Googleが求めているシステムは、自動的に動作するシステム
- SREはエンジニアリングが重要
- そうでなければ運用に関する負荷が増大し続ける
| メリット | デメリット |
|---|---|
| ・素早いイノベーションと変更の両立 | ・SREの採用が難しい |
| ・エンジニアリングと運用の両立が可能 | ・SREチームの構築と管理に関する情報が少ない |
| ・SREの人数はシステム規模に比例しない | ・マネージメント層の強力なサポートが必要 |
| ・プロダクト開発とSREチームの異動が容易で開発者のスキルを育成できる |
1.3 SREの信条
SREは以下の責任を負う
- サービスの可用性
- レイテンシ
- パフォーマンス
- 効率性
- 変更管理
- モニタリング
- 緊急対応
- キャパシティプランニング
1.3.1 エンジニアリングへの継続的な注力の保証
- 運用業務が50%にするようにマネージメントすることで手作業による介入を必要としないシステムへの効果的なフィードバックになる
- イベントに忙殺されてはイベントから学ぶことができない
- インシデントに対するポストモーテムを重要視
1.3.2 サービスのSLOを下回ることなく、変更の速度の最大化を追求する
devとopsの対立をエラーバジェットの導入で解決した
エラーバジェット：100%の信頼性の目標にすることは、基本的にいかなる場合も間違っている
プロダクト開発で以下を考慮に入れる
- ユーザーが満足する可用性のレベルはどの程度か
- プロダクトの可用性に満足できなかったユーザーにとって、どのような代替案があるか
- 可用性のレベルを変更したとして、ユーザーのプロダクトの利用の仕方になにか起こるか
サービス障害は悪いことではなく、イノベーションのプロセスにおいて予想済の部分である。障害を恐れるのではなく、コントロールする。
1.3.3 モニタリング
モニタリングは、サービスの所有者がシステムの健全性と可用性を追求するための主要な手段の一つ。モニタリングの方針は十分に検討して構築する必要がある。人間がメールを読み、アクションの必要性を判断しなければならないようなシステムは根本的に欠陥を抱えている。人間の解釈の必要性があってはならない。
効果的なモニタリングの出力は以下の3つ
| 項目 | 説明 |
|---|---|
| アラート | 人間が即座にアクションを起こして対応し、状況を改善しなければならないことが生じている、生じようとしている |
| チケット | 人間がアクションを起こさなければならないことを知らせる。ただし即座でなくてよい |
| ロギング | 人間が見る必要はない。診断もしくはフォレンジックのための記録されるもの |
1.3.4 緊急対応
緊急対応の効率を評価する上では、MTTRが最も関係があるメトリクス。ページャーの連絡に対応する際には、手順書が役に立つ。
1.3.5 変更管理
70%のサービス障害は動作中のシステムの変更によるものによって生じている。自動化によって以下を実現することがベストプラクティス。人手を除外することで繰り返しのタスクに対する一般的な問題を回避できる。結果としてリリースの速度と安全性が高まる。
- 漸進的なロールアウトの実装
- 高速かつ正確な問題の検出
- 問題が生じた際の安全なロールバック
1.3.6 需要の予測とキャパシティプランニング
キャパシティプランニングにはいくつかのステップが必要
- 自然な需要の正確な予測
- 需要予測に突発的な需要の発生源を正確に織り込む
- 計算リソースのキャパシティとサービスのキャパシティの関連を把握するための定期的なシステムの負荷テスト
1.3.7 プロビジョニング
プロビジョニングは、変更管理とキャパシティプランニングの双方の組み合わせ。キャパシティは高価なので、プロビジョニングは素早くかつ必要な場合のみに正確に行うべき。
1.3.8 効率とパフォーマンス
SREはプロビジョニングを最終的にコントロールすることになるので、利用率に関係する仕事にも関わらなければならない。
1.4 始まりの終わり
サイトリライアビリティエンジニアリングは、従来のベストプラクティスを逸脱している。指針・プラクティス・動機づけ・ソフトウェアエンジニアリングの領域の注力分野になった。
