Open5
SRE について考えてみる
ピン留めされたアイテム
Tomonori HayashiTomonori HayashiSite Reliability Engineer
- 職務（ロール）としての SRE
- SRE の How
フォーカスポイント
- Embracing Risk（リスク許容）
- SLO（サービスレベル目標）
- Eliminating Toil（トイルの撲滅）
- Monitoring Distributed Systems（分散システムの監視）
- The Evolution of Automation（自動化の促進）
- Relese Engineering
- Simplicity
Site Reliability Engineering
- 方法論としての SRE = 考え方・文化
- SRE の Why
フォーカスポイント
SRE の重要な価値は 4 つ
- サイトの稼働の維持
- 開発チームが「正しいことを行う」環境の整備 / 意思決定の分散化
- エンジニアリングの問題としての運用へのアプローチ
- 約束の表明、計測、実現を通じたビジネスの成功の達成
⇒ SRE が最も高い生産性と価値を示すのは、障害の防止や軽減に集中するときではなく、ビジネスにおける成功の実現に集中するとき。部分を見ることから全体を見ることへ…現在に対応することから将来を創造することへという気持ちの変化 by “SRE の探求”
Tomonori HayashiDevOps or SRE
- システムの設計と開発の各フェーズにおける IT 部門の関与、自動化への大きな依存と人的努力、エンジニアリングのプラクティスとツールの運用タスクへの適用、といった基本原則は、SRE の原則とプラクティスの多くと一致
- DevOps は、SRE の中核となるいくつかの原則を、より広範な組織、管理構造、および要員に一般化したものとみなすこともできる
- また、SRE を、DevOps にいくつかの特異な拡張を加えた特定の実装とみなすこともできる
⇒ class SRE implements interface DevOps
- 組織の壁を減らす ⇒ 同じツール、同じ手法を使う
- 失敗を普通のこととして受け入れる ⇒ エラー予算
- 段階的に変更を加える ⇒ 失敗のコストを下げる
- ツールと自動化を活用する ⇒ 手動作業を自動化することを推奨する
- すべて測る ⇒ トイルも信頼性も定量化する
原則
- いかなるシステムにおいて最も重要な機能は信頼性である。
- 「ユーザーに使って貰える」状態にする
- 目指すのは「それなり」
- 魅力的な機能の追加・実装とのバランスが重要
- 監視が信頼性を決めるのではない。ユーザーが決めるのだ。
- 監視システムの設定値を下回っているからといって、それが信頼性の高さを示しているわけではない
- ex) CPU値が100%でもサービスが使えていればユーザーは満足、逆に余裕があっても使えなければ不満
- 巧妙に設計されたソフトウェアは 99.9%,
巧妙に設計された運用は 99.99%,
巧妙に設計されたビジネスは 99.999%- 99.9% はソフトウェアの設計で達成出来る
- 99.99% （4分+/30日）を達成するには、しっかりした運用設計と熟練、自動化が必要
- 99.999% のためには投資やリリース計画など、経営(ビジネス)判断が必要
用語
- CUJ：クリティカルユーザージャーニー
- ユーザーが目的を完遂するために行う特定の動作
- SLI：サービスレベル指標
- サービスが必要十分に機能していることを示す指標
- SLO：サービスレベル目標
- 成功したインタラクションの割合に対して設定された目標
- SLA：サービスレベル保証
- ビジネスへの影響
- エラーバジェット
- 許容できる不具合の割合
Tomonori Hayashi考える上でのストーリー
Site Reliability Engineering（Why）
物が壊れるのは、雨が降るのと同じ自然現象
- 雨を止めるのではなく、「雨が降ったらどうするか」を考えるほうが現実的
- = 失敗・故障・障害を前提として設計する
極端に高い信頼性を実現しようとすると？
- ユーザーに価値を届ける速度が制限される
- にもかかわらずコストは大幅増
SREが最大化するのは信頼性ではなくてユーザーの幸せ
- リスク、イノベーション速度、運用効率のバランス
- サービスの機能を最適化
信頼性とは？
- ユーザーが満足するのは、(システムが) その期待に応えているから
- ユーザーは何をもって「そのシステムが信頼できる」と判断するのか？
-
SLI（サービスレベル指標）
-
- そのSLIにおいて、ユーザーがギリギリ「満足」出来るライン
-
SLO (サービスレベル目標)
-
クリティカルユーザージャーニー (CUJ)
- ユーザーが(最終的に)目的を達成するためにサービスと(何回か)行うやり取りのこと
- SLIとして、このCUJを使うのがよさそう
- CUJを測定するために使えるSLI
- リクエスト・レスポンス（可用性、遅延、品質）
- データ処理（カバレッジ、正確性、鮮度、スループット）
- ストレージ（スループット、遅延）
エラー予算（※エラーバジェット）
- 信頼性を保つ上で許容できる不具合の量のこと
- どれくらいシステムを止められるか？
-
1 - SLO- SLO 99.95%であれば、エラー予算 = 0.05%
- 30日間で 21.6分
- エラーの発生率が全体のトラフィックの 1%であれば -> 36時間/30日
-
カナリアリリースが有効
- エラー予算の使い方
- エラーが多いシステムならリリースを遅らす
- エラーが少なければ（予算が残っていれば）計画通りのリリースを
- データに基づいて判断を
- Cloud Operation Suiteを使うと計測できる
- エラー予算のメリット
- 開発とSREの共有のインセンティブ
- 開発チームが自分でリスクを管理出来る
- 非現実的な信頼性の目標は魅力的でなくなる（イノベーションの速度を遅くすることが可視化される）
- 信頼性に対する責任をチーム全体（開発・運用）で共有できる
リスク
- 人間の脳は、リスクの比較と評価において、信頼できないということが知られている
- 間違った評価・分類をしてしまう
- リスクを客観的に分析できるフレームワークが必要
Tomonori HayashiSite Reliability Engineer（How）
クリティカル ユーザー ジャーニー を検討する
- まずはここを検討したい