書籍概要

知識地図

SREの知識地図
——基礎知識から現場での実践まで

著者
発売日
更新日

概要

2004年にGoogleが提唱したシステム運用の方法論「SRE(Site Reliability Engineering)」。ソフトウェア開発現場におけるアジャイル型への転換の中で,システムの利便性や安定性を「価値」ととらえ,その向上を目指すSREに注目が集まっています。大きなミッションである「システムの安定的な運用」のために,SREを担当するエンジニアには開発と運用,双方のスキルが必要です。

本書では,これからSREを学びたい,開発に取り入れたいというエンジニアを対象に,全体像を解説しつつ,今後の学習のための情報源を多く紹介します。基本的な知識だけでなく,代表的なプラクティスや組織の運用など,実践的な内容まで解説します。

こんな方におすすめ

  • SREをこれから学びたいエンジニア

目次

第1章 SREとは

  • 1.1 SREの概要
    • 1.1.1 サイトとは何か
    • 1.1.2 信頼性とは何か
    • 1.1.3 信頼性を制御するとはどういうことか
    • 1.1.4 ソフトウェアエンジニアリングの原則と手法を運用に応用するとはどういうことか
  • 1.2 なぜSREが重要なのか
    • 1.2.1 信頼性が失われるとどうなるか
    • 1.2.2 過剰な信頼性を追い求めるとどうなるか
  • 1.3 SREの価値観
    • 1.3.1 信頼性は機能の一部である
    • 1.3.2 100%の信頼性を目指すわけではない
    • 1.3.3 運用をエンジニアリングする
    • 1.3.4 データにもとづく意思決定を行う
    • 1.3.5 失敗から学ぶ,非難なき文化を構築する
  • 1.4 SREに必要なスキル
    • 1.4.1 どのSREにも求められる単一のスキルセットはない
    • 1.4.2 中核となるスキル
  • 1.5 本書の歩き方
    • 1.5.1 信頼性を定義し組織で運用する
    • 1.5.2 システムの状態を観測する
    • 1.5.3 障害への向き合い方
    • 1.5.4 手作業を自動化し効率化する
    • 1.5.5 サービスのリリースを事前にレビューする
    • 1.5.6 組織構造
    • 1.5.7 今後の手引き
  • 1.6 まとめ

第2章 信頼性を定義して組織で運用する

  • 2.1 SLOを理解するための4つの要素
    • 2.1.1 SLA
    • 2.1.2 SLO
    • 2.1.3 SLI
    • 2.1.4 エラーバジェット
  • 2.2 なぜSLOが重要なのか
  • 2.3 エラーバジェットの理解と活用
    • 2.3.1 エラーバジェットの基本的な考え方
    • 2.3.2 エラーバジェットの目的と意義
    • 2.3.3 エラーバジェットの管理と監視
  • 2.4 SLO導入ステップ
    • 2.4.1 1.クリティカルユーザージャーニーの特定
    • 2.4.2 2.適切な目標値の設定
    • 2.4.3 3.組織的な合意・運用体制
    • 2.4.4 4.継続的改善のしくみ作り
  • 2.5 まとめ

第3章 システムの状態を観測する

  • 3.1 システムを観測するための基本概念
    • 3.1.1 モニタリングとは
    • 3.1.2 オブザーバビリティとは
    • 3.1.3 モニタリングとオブザーバビリティのちがい
  • 3.2 モニタリングの基本
    • 3.2.1 The Four Golden Signals
    • 3.2.2 USEメソッドによるリソースモニタリング
    • 3.2.3 REDメソッドによるサービスモニタリング
    • 3.2.4 各メソッドの活用シーン
  • 3.3 アラート通知の基本と運用
    • 3.3.1 アラート通知とはなにか
    • 3.3.2 効果的な通知の原則
    • 3.3.3 通知強度に応じたSlack活用例
    • 3.3.4 システム運用でよくある課題と工夫
  • 3.4 オブザーバビリティツールの構成
    • 3.4.1 オブザーバビリティツールの全体像
    • 3.4.2 収集
    • 3.4.3 保存
    • 3.4.4 活用
  • 3.5 オブザーバビリティにおける5つの重要なシグナル
    • 3.5.1 CNCFが提唱する5つのシグナル
    • 3.5.2 ログ
    • 3.5.3 メトリクス
    • 3.5.4 トレース
    • 3.5.5 プロファイル
    • 3.5.6 ダンプ
    • 3.5.7 シグナルは組み合わせて使うことが重要
  • 3.6 オブザーバビリティツールの選定と実装
    • 3.6.1 ツールの選択肢
    • 3.6.2 ツール選定の基準
    • 3.6.3 実装の基本プロセス
    • 3.6.4 社内での継続的な取り組み
    • 3.6.5 オブザーバビリティはどこを目指すべきなのか
  • 3.7 まとめ

第4章 障害を学びにつなげる

  • 4.1 ポストモーテム
    • 4.1.1 ポストモーテムの目的と意義
    • 4.1.2 ポストモーテムはいつやるのか
  • 4.2 ポストモーテムのフレームワーク
    • 4.2.1 ポストモーテムの準備
    • 4.2.2 ポストモーテムの実施
    • 4.2.3 ポストモーテムの共有
    • 4.2.4 ポストモーテムのまとめ
  • 4.3 ポストモーテムの実践
    • 4.3.1 具体的なポストモーテムの例
    • 4.3.2 よくないポストモーテムの具体例
    • 4.3.3 よいポストモーテムの具体例
  • 4.4 再発防止策の重要性と効果的な実施方法
    • 4.4.1 再発防止策の目的
    • 4.4.2 よくある失敗例
    • 4.4.3 効果的な再発防止策のポイント
    • 4.4.4 再発防止策のまとめ
  • 4.5 ポストモーテムの運用と文化
    • 4.5.1 ポストモーテムの運用
    • 4.5.2 ポストモーテムを成功させる文化作り
  • 4.6 複数チームにまたがるポストモーテムの実施
    • 4.6.1 ポストモーテムの課題
    • 4.6.2 課題を克服するためのアプローチ
    • 4.6.3 部門横断ポストモーテムのまとめ
  • 4.7 ポストモーテムをテーマにしたワークショップの提案
    • 4.7.1 ワークショップの目的
    • 4.7.2 ワークショップの構成
    • 4.7.3 ワークショップの進行
    • 4.7.4 ワークショップのポイント
  • 4.8 まとめ

第5章 障害対応のプロセスや体制を作る

  • 5.1 オンコール
  • 5.2 オンコール担当者の役割
    • 5.2.1 障害の検知と初期対応
    • 5.2.2 適切なエスカレーション判断
    • 5.2.3 関係者とのコミュニケーション
  • 5.3 オンコール体制の設計
    • 5.3.1 オンコールの必要性の評価
    • 5.3.2 オンコール体制設計のポイント
    • 5.3.3 オンコールシフトの設計
    • 5.3.4 オンコールシフトのまとめ
  • 5.4 オンコールトレーニング
    • 5.4.1 オンコールトレーニングのポイント
    • 5.4.2 実践的なシミュレーション
    • 5.4.3 チーム連携を強化するロールプレイ
    • 5.4.4 ポストモーテムの実施
    • 5.4.5 トレーニングの定期実施
    • 5.4.6 トレーニングの評価とフィードバック
  • 5.5 オンコールに対する手当て
    • 5.5.1 オンコール手当ての考え方
    • 5.5.2 オンコール手当ての種類
    • 5.5.3 手当ての設計と運用のポイント
  • 5.6 Runbookの作成と活用
    • 5.6.1 Runbookの作成と運用
    • 5.6.2 Runbookの例
  • 5.7 燃え尽き
    • 5.7.1 燃え尽き症候群が生じる要因
    • 5.7.2 燃え尽き症候群の兆候
    • 5.7.3 燃え尽き症候群を防ぐために
    • 5.7.4 ポジティブな文化の醸成
  • 5.8 SEVレベル
    • 5.8.1 SEVレベルの定義
    • 5.8.2 SEVレベルの運用
  • 5.9 心理的・身体的ケア
    • 5.9.1 心理的ケア
    • 5.9.2 身体的ケア
    • 5.9.3 自己ケア
    • 5.9.4 組織のサポート
  • 5.10 まとめ

第6章 手作業を自動化し効率化する

  • 6.1 トイルとは
    • 6.1.1 トイルの定義
    • 6.1.2 トイルの分類
  • 6.2 トイルを管理する
    • 6.2.1 トイルの分類と計測
    • 6.2.2 トイル削減の計画と目標設定
    • 6.2.3 トイル削減の実施
    • 6.2.4 効果の測定と改善
  • 6.3 まとめ

第7章 サービスのリリースを事前にレビューする

  • 7.1 PRR
    • 7.1.1 PRRとは
    • 7.1.2 PRRの目的
    • 7.1.3 PRRの重要な要素
    • 7.1.4 PRRのチェックリスト
    • 7.1.5 PRRをはじめるためのステップ
    • 7.1.6 よくある失敗例
  • 7.2 GitLabのPRR事例
    • 7.2.1 PRR実施の基準
    • 7.2.2 PRRプロセス
    • 7.2.3 PRRのチェックリスト
    • 7.2.4 PRRの進め方
  • 7.3 PRRとほかのプラクティスの関係
    • 7.3.1 CI/CDパイプラインとの統合
    • 7.3.2 Platform Engineeringで担保すること
  • 7.4 まとめ

第8章 SREの組織構造

  • 8.1 SREにおける組織構造の重要性
    • 8.1.1 組織的なサポートが欠如した環境でSREチームが直面した課題
    • 8.1.2 コンウェイの法則と逆コンウェイ戦略
    • 8.1.3 SREにおける組織構造の重要性のまとめ
  • 8.2 SREの組織構造を考えるヒント
    • 8.2.1 チームトポロジー
    • 8.2.2 SREのチームトポロジーにおける位置づけ
    • 8.2.3 SREとチームトポロジー
    • 8.2.4 SREの組織構造を考えるヒントのまとめ
  • 8.3 SREの組織パターン
    • 8.3.1 3つの組織パターン
    • 8.3.2 SRE組織の配置
    • 8.3.3 SREの組織パターンのまとめ
  • 8.4 SREの実装モデルとパターン
    • 8.4.1 3つのSREの実装モデル
    • 8.4.2 埋め込み型
    • 8.4.3 中央集中型
    • 8.4.4 ハイブリッド型
    • 8.4.5 SREの実装モデルとパターンのまとめ
  • 8.5 SREの実装モデルとパターンの選び方
    • 8.5.1 SREが必要となるパターンを整理する
    • 8.5.2 組織にあったSREの実装モデルとパターンを選択する
    • 8.5.3 SREの実装モデルとパターンの選び方のまとめ
  • 8.6 まとめ

第9章 SREの実践

  • 9.1 とある組織におけるSREの実践事例
    • 9.1.1 はじめに
    • 9.1.2 過去:2つのSRE
    • 9.1.3 現在:SREの統合と役割の定義
    • 9.1.4 未来:まだまだ続く改善の旅
  • 9.2 SREの実践のコツ
    • 9.2.1 短期的成果の重視
    • 9.2.2 現場のニーズへの対応
    • 9.2.3 積極的なコミュニケーション
    • 9.2.4 SLI / SLOの段階的な導入
    • 9.2.5 効果測定の重要性
  • 9.3 広がるSREの世界
    • 9.3.1 技術領域
    • 9.3.2 対象システム
  • 9.4 SREと???
    • 9.4.1 SREとPlatform Engineering
    • 9.4.2 SREとDevOps
  • 9.5 まとめ

サポート

現在サポート情報はありません。

商品一覧