1.2.1 サービスレベル指標
1.2.2 サービスレベル目標
1.2.3 エラーバジェット
1.3.1 サービスの例
1.4.1 SLOは単なるデータである
1.4.2 SLOはプロセスでありプロジェクトではない
1.4.3 すべてを反復する
1.4.4 世界は変化する
1.4.5 すべて人に関わる
2.2.1 暗黙の合意
2.2.2 合意の形成
2.2.3 信頼性のうまくいった例
2.3.1 100%は不要である
2.3.2 信頼性にはコストがかかる
2.3.3 信頼性についての考え方
3.1.1 ユーザーの満足
3.1.2 満足するエンジニア
3.1.3 満足するビジネス
3.2.1 リクエスト/レスポンスサービス
3.2.2 少数の計測のみによる多数の計測
3.2.3 文章で書かれた例
3.3.1 複雑なサービスにおけるユーザーの信頼性の計測
3.3.2 他の記述例
3.3.3 社内の連携とSLI
4.1.1 ユーザーの満足
4.1.2 信頼性が高すぎることの問題
4.1.3 9という数の問題
4.1.4 多すぎるSLOの問題
4.2.1 サービスの依存対象
4.2.2 サービスコンポーネント
4.3.1 オープンソースまたはホストされているサービス
4.3.2 ハードウェアの計測
4.4.1 過去のパフォーマンス
4.4.2 統計の基本
4.4.3 メトリクスの属性
4.4.4 パーセンタイルの閾値
4.4.5 履歴がない場合の対処
5.1.1 新機能をリリースするか否か
5.1.2 プロジェクトの焦点
5.1.3 リスク要因の検査
5.1.4 実験とカオスエンジニアリング
5.1.5 負荷テストおよびストレステスト
5.1.6 ブラックホール演習
5.1.7 バジェットの意図的な消費
5.1.8 人間に適用されるエラーバジェット
5.2.1 エラーバジェットの確立
5.2.2 意思決定
5.2.3 エラーバジェットポリシー
第II部 SLOの実装
6.2.1 開発
6.2.2 製品
6.2.3 運用
6.2.4 QA
6.2.5 法務
6.2.6 経営幹部
6.3.1 活動の順序
6.3.2 一般的な反対意見とその克服方法
6.3.3 初めてのエラーバジェットポリシー(および初めてのクリティカルテスト)
7.1.1 柔軟な目標値
7.1.2 テスト可能な目標値
7.1.3 鮮度
7.1.4 コスト
7.1.5 信頼性
7.1.6 組織の制約
7.2.1 集中型の時系列統計(メトリクス)
7.2.2 構造化イベントデータベース(ログ)
7.3.1 レイテンシー重視のリクエスト処理
7.3.2 低ラグ、高スループットのバッチ処理
7.3.3 モバイルクライアントとWebクライアント
7.5.1 分散トレーシングとの統合
7.5.2 SLIとSLOの発見可能性
8.1.1 単純な閾値アラートの短所
8.1.2 より良い方法
8.2.1 目標値の選択
8.2.2 エラーバジェットとレスポンスタイム
8.2.3 エラーバジェットのバーンレート
8.2.4 ローリングウィンドウ
8.2.5 すべてをまとめる
8.2.6 SLOのアラートによるトラブルシューティング
8.2.7 まれなケース
8.2.8 開発済みのセットアップにおけるSLOのアラート
9.1.1 SLIの例:可用性
9.1.2 SLIの例:低いQPS
9.2.1 最尤推定
9.2.2 最大事後確率
9.2.3 ベイズ推定
9.2.4 SLIの例:キューイングレイテンシー
9.2.5 バッチ処理のレイテンシー
10.1.1 アーキテクチャに関する検討事項:ハードウェア
10.1.2 アーキテクチャに関する検討事項:モノリスかマイクロサービスか
10.1.3 アーキテクチャに関する検討事項:障害の形態の予測
10.1.4 アーキテクチャに関する検討事項:3種類のリクエスト
10.1.5 システムおよび構成要素
10.1.6 システムの定量分析
10.1.7 計装!システムにも計装が必要である!
11.1.1 データアプリケーションの設計
11.3.1 データおよびデータアプリケーションの信頼性
11.3.2 データ属性
11.3.3 データアプリケーション属性
11.4.1 データアプリケーションの障害
11.4.2 その他の品質
12.1.1 サービスの成長過程
12.1.2 サービスの設計
12.2.1 顧客:製品の検索と閲覧
12.2.2 ユーザーとしてのその他のサービス:製品の購入
12.2.3 内部ユーザー
12.2.4 サービスとしてのプラットフォーム
第III部 SLOの文化
13.3.1 同意を得る
13.3.2 SLOの作業を最優先する
13.3.3 SLOを実装する
13.3.4 SLIはどうなるか
13.3.5 SLOはどうなるか
13.3.6 SLOを活用する
13.3.7 SLOの定義を繰り返す
13.3.8 SLOが十分に適切になった時を判断する
13.3.9 SLOの活用を他の人々に提唱する
14.1.1 最初のパス
14.1.2 ユーザーからの聞き取り
14.1.3 定期的な見直し
14.2.1 増加した利用率の変更
14.2.2 減少した利用率の変更
14.2.3 機能による利用率の変更
14.3.1 サービスの依存対象の変更
14.3.2 プラットフォームの変更
14.3.3 依存対象の導入または退役
14.5.1 ユーザーの期待の変更
14.5.2 ユーザーの要求の変化
14.6.1 計測の変更
14.6.2 計算の変更
14.9.1 ユーザーからの聞き取り(再検討)
14.9.2 障害への配慮
14.10.1 再検討のスケジュール
15.1.1 SLOの定義ドキュメント
15.1.2 表現法
15.2.1 ドキュメントのリポジトリ
15.2.2 発見可能性のためのツール
15.2.3 SLOのレポート
15.2.4 ダッシュボード
16.1.1 あなた自身による調査研究の実施
16.1.2 セールストークの準備
16.1.3 サポートする成果物の作成
16.1.4 最初のトレーニングとワークショップの実施
16.1.5 単一のサービスに関するSLOのパイロット版の実装
16.1.6 あなたのメッセージの拡散
16.1.7 課題の処理方法の学習
16.2.1 初期の採用者との連携によるより多くのサービスのSLOの実装
16.2.2 達成の祝福と自信の構築
16.2.3 ケーススタディのライブラリの作成
16.2.4 トレーナーの増員によるトレーニングプログラムの拡大
16.2.5 コミュニケーションの規模の拡大
16.3.1 SLOに関するケーススタディのライブラリの共有
16.3.2 SLOのエキスパートで構成されるコミュニティの創設
16.3.3 継続的な改善
17.1.1 インシデントのカウント
17.1.2 深刻度レベル
17.1.3 平均X時間の問題
17.1.4 基本的なレポートのためのSLO
17.2.1 SLOの状態
17.2.2 エラーバジェットの状態