はじめに

このスクラップではSRE サイトリライアビリティエンジニアリング本を購入し、読書会をしていくにあたり章ごとのメモをまとめていきます。
https://www.oreilly.co.jp/books/9784873117911/

やり方

• 章ごとに内容を整理する
• 章ごとにメンバーが返信する形で読書したメモを返信する
• 関連の技術トピックを調べたことをまとめる

一章

ただめも

• Google の中でのSREチームはソフトウェアエンジニアの採用をし、そのエンジニアにサービスを運用させた
  • SRE とはソフトウェアエンジニア理に運用チームの設計を依頼した時にできあがるもの
    • SREで求められる技術はソフトウェアエンジニアリング+UNIX,1~3層のネットワークに関する専門知識
    • SRE の業務の50%以下に手作業系を抑えるように指示(それ以外は開発にあてて改善とかプロジェクトに当てる）
  • 全体的にはメリットが多いSREのモデルには課題もある
    • 採用
    • チームの
    • チームの組成
• SRE の共通事項はサポートするサービスに対する責任(可用性、レイテンシ、パフォーマンス、効率性、変更管理、モニタリング、緊急対応、キャパシティプランニング）と信条の尊重
  • Google ではポストモーテムで非難せず問題を回避し、最小化したりするのではなく問題を明らかにしてエンジニアリングで問題を解決することを目標にした
• 可用性：SRE チームとプロダクトチームとの対立はエラーバジェットの導入で解決した(システムの障害を許容できるのかをチーム間で話さないと許容範囲がわからない)
  • 100%を信頼性の目標にしないという考え方でここでいう信頼性で考えるべきはプロダクトの以下の問題
    • ユーザー が満足する可用性のレベルは？
    • ユーザー が満足しない場合代替策は？
    • 可用性を変更したらプロダクトの利用の仕方に何が起こる？
• モニタリング：効果的なモニタリングの出力はアラート/チケット/ロギングがある(いずれも人が介さないといけないことだから通知が必要)
• 緊急対応：人で解さないようなオペレーションは避けるようにして人手が必要なら手順書を作っておく
• 変更管理：自動化して運用上の一般的な問題を回避する
• キャパシティプランニング：自然な成長と突発的な成長を考慮に入れる
  • プロビジョニングも考慮し必要な時に必要なだけ素早く作れるようにする
• 効率性：SREは需要を予測しキャパシティをプロビジョニングし、ソフトウェアを変更する

二章

ただめも

• Google のハードウェアはスケーラビリティが極めて高いソフトウェアによってコントロールされているのが特徴
  • データセンターではハードウェアをAPIで制御
• 用語
  • Borg
  • Global Software-Load Balancer(GSLB)
  • Borgmon
  • Stubby
  • protocol buffers
  • BigTable
• 3章以降でのSRE 原則(=SREオペレーション全般に影響を及ぼすパターン、振る舞い、関心事項）で扱うテーマ
  • SREの仕事とは？なぜそのような仕事をするのか？（リスクの受容）
  • サービスレベル（サービスレベル目標）
  • 価値が低く、サービスの成長に比例して増える、反復作業を撲滅する（トイルの撲滅）
  • モニタリングの方法と対照、実装に依存しないベストプラクティス（分散システムのモニタリング）
  • 自動化に対するSREアプローチとして成功事例と失敗事例（Googleにおける自動化の進化）
  • システムの品質としての単純さ（単純さ）

3章 リスクの受容

ただメモ

3.1 リスクの管理

• コストは2つある
  • 冗長なマシン/コンピュートリソースのコスト
  • 機会のコスト
• サービスのリスクとビジネスが許容できる範囲を意識的に合わせることがSREのミッション
  • ただ必要以上に信頼性を高める必要はない

3.2 サービスリスクの計測

• リスクの許容度を表すの方法あ計画外の停止時間の許容から見ていく
  • 計画外の停止時間はサービスの可用性に求められるレベルによって把握できる
  • Google はリクエスト成功率を可用性の観点に定義している
    • 可用性 = 成功したリクエスト数/総リクエスト数

3.3 サービスのリスク許容度

• サービスリスクの強要度はSREとプロダクトマネージャーと共同でビジネスゴールをエンジニアリング可能な明確な目標に変換する
• toC サービスにおける可用性のレベル
  • ユーザーが期待するサービスレベル
  • サービスが直接的に収入につながっているか
  • サービスが有料か、無料か
  • 市場に競合がある場合、その競合が提供しているサービスレベル
  • サービスがtoC向け、toB向けか
    • GSuiteの可用性のターゲットは99.9%にして内部の目標これより高いものにした
    • YoutubeはGSuiteとは対照的で低めの可溶性を設定し、機能開発に重点を置きたかった

3.4 エラーバジェットの活用

• 開発チームとSREチームは協力してSLOに基づくエラーバジェットを作成する
• エラーバジェットを作ることで一定期間内で信頼性がどの程度損なわれても許容さえれるかを示すメトリクス
  • PDMがSLOを作り、一定期間内に期待されるサービスの稼働時間を作る
  • 稼働時間はモニタリングシステムで計測する
  • 稼働時間とダウンの時間の差分がエラーバジェットの残分
  • 計測された稼働時間がSLOを超えている、エラーバジェットがまだ残っているなら新しいリリースをプッシュできる
• エラーバジェットのメリットはプロダクト開発者とSREに共通のインセンティブを提供し、両者がイノベーションと信頼性の適切なバランスを見出すことに注力する

4章 サービスレベル目標

ただメモ

• サービスを適切に管理するにはサービスの中で振る舞いとその計測、評価方法を定義する必要がある
  • ユーザーへのサービスレベルがそれにあたる
  • SLI(サービスレベル指標）、SLO(サービスレベル目標)、SLA(サービスレベルアグリーメント)

4.1 サービスリスクの用語

• SLI としてはリクエストのレイテンシを考慮する
  • 他のSLIとしてエラー率、スループット
• SLOはSLIで計測されるサービスレベルのターゲット値を指す
  • SLI ≦ ターゲット、下限 ≦ SLI ≦ 上限

4.2 指標の実際

• メトリクスのすべてをSLIにしないでユーザーがシステムに求めていることを理解して指標を作る
• SLI の標準化を行い、1から作らないようにする
  • テンプレート定義を作ると良さそう

4.3 目標の実際

• ユーザーが気にすることが何かを考えて、目標を設定する
• SLOを常に満たし続けるのは現実的ではないのでSLOを満たせない比率を示すエラーバジェットを認めて定期的に追跡した方がよい
• SLOにはユーザーの関心事が反映されるから開発チームにとって有益で理にかなった構造である必要がある
• SLIとSLOはシステム管理のサイクルにおいて欠かせないため段階がある
  • 1.システムのSLIのモニタリングと計測を行う
  • 2. SLOに対してSLIを比較し、アクションが必要かを判断する
  • 3. 目標を満たすために実現しなければならないことを明らかにする
  • 4. アクションをとる

4.4 アグリーメントの実際

• SREの役割はSLAに含まれるSLOを満たせる可能性や難易度を他のチームが理解するための支援をすること