Book description
『SRE サイトリライアビリティエンジニアリング』で、サイトリライアビリティエンジニアリング（SRE）はプロダクションサービスの稼働と信頼性の維持がサービス設計の基本であるとし、行動の基礎となる原則と理論を述べました。その実践編であり副読本でもある本書は、SREを組織やプロジェクトで導入するにあたり、必要となる具体的な方法や手順を解説します。またこれまでGoogle内部で得た技術的ノウハウを解説し、さらにEvernote、The Home Depot、New York Timesなどさまざまな企業での事例を紹介します。
Table of contents
- 大扉
- 原書大扉
- クレジット
- 本書への推薦の言葉
- 序文1
- 序文2
- はじめに
- 本書の読み方
- 日本語版について
- 表記
- コードサンプル
- お問い合わせ先
- 謝辞
- 1章 SREとDevOpsとの関係
- 1.1 DevOpsの背景
- 1.1.1 サイロの抑制
- 1.1.2 アクシデントは普通のこと
- 1.1.3 変化は徐々に起こすべきもの
- 1.1.4 ツールと文化は相互に関係する
- 1.1.5 計測は必須
- 1.2 SREの背景
- 1.2.1 運用はソフトウェアの問題
- 1.2.2 サービスレベル目標（SLO）による管理
- 1.2.3 トイルの最小化のための作業
- プロダクションの知恵
- 1.2.4 今年のジョブの自動化
- 1.2.5 失敗のコストの削減による速度の向上
- 1.2.6 開発者との共有オーナーシップ
- 1.2.7 役割や仕事の肩書きに関わらず同じツールを使うこと
- 1.3 比較と対照
- 1.4 組織のコンテキストと成功する採用の促進
- 1.4.1 狭く硬直したインセンティブは成功を狭める
- 1.4.2 修正は自分で行う。他の誰かを責めない
- 1.4.3 信頼性に関する作業を特化した役割として考える
- 1.4.4 「やるかどうか」は「いつやるか」に置き換えられる
- 1.4.5 評価の同等性のための努力：キャリアと金銭
- 1.5 まとめ
- 第Ⅰ部 基礎
- 2章 SLOの実装
- 2.1 SREにSLOが必要な理由
- 2.2 始めてみよう
- 2.2.1 信頼性のターゲットとエラーバジェット
- 2.2.2 何を計測するか：SLIの利用
- 2.3 うまく行った例
- 2.3.1 SLIの仕様からSLIの実装への移行
- 2.3.2 SLIの計測
- 2.3.3 SLIを使った最初のSLOの計算
- 2.4 適切な時間ウィンドウの選択
- 2.5 ステークホルダーの同意を得る
- 2.5.1 エラーバジェットポリシーの確立
- 2.5.2 SLOとエラーバジェットポリシーのドキュメント化
- 2.5.3 ダッシュボードとレポート
- 2.6 SLOターゲットの継続的改善
- 2.6.1 SLOの品質の改善
- 2.7 SLOとエラーバジェットを使った意思決定
- 2.8 高度なトピック
- 2.8.1 ユーザージャーニーのモデリング
- 2.8.2 インタラクションの重要性の段階付け
- 2.8.3 依存関係のモデル化
- 2.8.4 SLOを緩めてみる
- 2.9 まとめ
- 3章 SLOエンジニアリングのケーススタディ
- 3.1 EvernoteにおけるSLOの物語
- 3.1.1 EvernoteがSREモデルを採用した理由
- 3.1.2 SLOの導入：進行中の旅路
- 3.1.3 顧客とクラウドプロバイダーの間にあるSLOの壁を壊す
- 3.1.4 現状
- 3.2 Home DepotのSLOの物語
- 3.2.1 SLO文化プロジェクト
- 3.2.2 最初のSLO群
- 3.2.3 SLOの普及
- 3.2.4 VALETデータ収集の自動化
- 3.2.5 SLOの急増
- 3.2.6 バッチアプリケーションへのVALETの適用
- 3.2.7 テストでのVALETの利用
- 3.2.8 将来的な野望
- 3.2.9 まとめ
- 3.3 結論
- 4章 モニタリング
- 4.1 モニタリング戦略における望ましい機能
- 4.1.1 速度
- 4.1.2 計算
- 4.1.3 インターフェース
- 4.1.4 アラート
- 4.2 モニタリングデータのソース
- 4.2.1 例
- 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.4.5 目的を持ったメトリクスの実装
- 4.5 アラートのロジックのテスト
- 4.6 まとめ
- 5章 SLOに基づくアラート
- 5.1 アラートについて考慮すべきこと
- 5.2 重大なイベントに対するアラートの方法
- 5.2.1 1：ターゲットのエラーレート ≥ SLOの閾値
- 5.2.2 2：より長いアラートウィンドウ
- 5.2.3 3：アラートの期間のインクリメント
- 5.2.4 4：バーンレートに対するアラート
- 5.2.5 5：複数バーンレートのアラート
- 5.2.6 6：複数ウィンドウ、複数バーンレートのアラート
- 5.3 低トラフィックのサービスとエラーバジェットによるアラート
- 5.3.1 人工的なトラフィックの生成
- 5.3.2 サービスの組み合わせ
- 5.3.3 サービスとインフラストラクチャに対する変更の実施
- 5.3.4 SLOの引き下げあるいはウィンドウの拡大
- 5.4 極端な可用性のゴール
- 5.5 大規模環境におけるアラート
- 5.6 まとめ
- 6章 トイルの撲滅
- 6.1 トイルとは何か？
- 事例：トイルに対する手作業でのレスポンス
- 6.2 トイルの計測
- 6.3 トイルの分類学
- 6.3.1 ビジネスプロセス
- 6.3.2 プロダクションへの割り込み
- 6.3.3 リリースの世話
- 6.3.4 マイグレーション
- 6.3.5 コストエンジニアリングとキャパシティプランニング
- 6.3.6 不明瞭なアーキテクチャのトラブルシューティング
- 6.4 トイル管理の戦略
- 6.4.1 トイルの特定と計測
- 6.4.2 システムから発生するトイルに対するエンジニアリング
- 6.4.3 トイルの拒否
- 6.4.4 SLOを使ったトイルの削減
- 6.4.5 人が背後に控えるインターフェースから始める
- 6.4.6 セルフサービスメソッドの提供
- 6.4.7 上司及び同僚から支援を得る
- 6.4.8 トイルの削減を機能に格上げする
- 6.4.9 小さく始めて改善する
- 6.4.10 一様性の増加
- 6.4.11 自動化に内在するリスクの評価
- 6.4.12 トイルへのレスポンスの自動化
- 6.4.13 オープンソース及びサードパーティツールの利用
- 6.4.14 改善のためのフィードバックの利用
- レガシーシステム
- 6.5 ケーススタディ
- 6.6 ケーススタディ1：自動化によるデータセンター内のトイルの削減
- 6.6.1 背景
- 6.6.2 問題の内容
- 6.6.3 実行すると決めたこと
- 6.6.4 最初の活動の設計：Saturnラインカードの修理
- 6.6.5 実装
- 6.6.6 2番目の活動の設計：Saturnラインカードの修理対Jupiterラインカードの修理
- 6.6.7 実装
- 6.6.8 学んだこと
- 6.7 ケーススタディ2：ファイラーを背後に持つホームディレクトリの廃止
- 6.7.1 背景
- 6.7.2 問題の内容
- 6.7.3 実行すると決めたこと
- 6.7.4 設計と実装
- 6.7.5 主要なコンポーネント
- 6.7.6 学んだこと
- 6.8 まとめ
- 7章 単純さ
- 7.1 複雑さの計測
- 7.2 単純さはあらゆる場面で目指すべきことであり、SREはその追求に適している
- 7.2.1 ケーススタディ1：エンドツーエンドのAPIの単純さ
- 7.2.2 ケーススタディ2：プロジェクトのライフサイクルの複雑さ
- 7.3 単純さの再獲得
- 7.3.1 ケーススタディ3：Display Ads Spiderwebの単純化
- 7.3.2 ケーススタディ4：共有プラットフォーム上での数百のマイクロサービスの実行
- 7.3.3 ケーススタディ5：pDNSはもう自分自身に依存しない
- 7.4 まとめ
- 第Ⅱ部 実践
- 運用作業の定義（プロジェクトの作業とオーバーヘッドとの対比）
- 8章 オンコール
- 8.1 『SRE サイトリライアビリティエンジニアリング』の「オンコール対応」の章の振り返り
- 8.2 Google内外でのオンコールの構成例
- 8.2.1 Google：新しいチームの形成
- プレイブックのメンテナンス
- 8.2.2 Evernote：クラウドへの順応
- 8.3 実用的な実装の詳細
- 8.3.1 ページャーの負荷の解剖学
- 適切なレスポンスタイム
- 8.3.2 オンコールの柔軟性
- シフトの長さ
- 8.3.3 オンコールチームの力学
- 8.4 まとめ
- 9章 インシデント対応
- 9.1 Googleにおけるインシデント管理
- 9.1.1 インシデントコマンドシステム
- 9.1.2 インシデント対応における主な役割
- 9.2 ケーススタディ
- 9.2.1 ケーススタディ1：ソフトウェアのバグ――ライトはついているのに誰も（Googleの）ホームにいない
- 9.2.2 ケーススタディ2：サービスの障害――できるものなら捕まえて
- 9.2.3 ケーススタディ3：電源喪失 ―― 雷に2回打たれるなどということは起こらない……それが起こるまでは
- 9.2.4 ケーススタディ4：PagerDutyにおけるインシデント対応
- 9.3 ベストプラクティスの実践
- 9.3.1 インシデント対応のトレーニング
- 9.3.2 事前準備
- 9.3.3 練習
- 9.4 まとめ
- 10章 ポストモーテムの文化：失敗からの学び
- 10.1 ケーススタディ
- 10.2 良くないポストモーテム
- ポストモーテム：すべてのサテライトマシンのdiskeraseへの送出
- 10.2.1 このポストモーテムが良くない理由
- 10.3 良いポストモーテム
- ポストモーテム：すべてのサテライトマシンのdiskeraseへの送出
- 10.3.1 このポストモーテムが良い理由
- 10.4 組織的なインセンティブ
- 10.4.1 非難のない振る舞いのモデル化と実施
- 10.4.2 ポストモーテムの成果に対する報酬
- 10.4.3 ポストモーテムのオープンな共有
- 10.4.4 ポストモーテム文化の失敗への対応
- 10.5 ツールとテンプレート
- 10.5.1 ポストモーテムのテンプレート
- 10.5.2 ポストモーテムのツール
- 10.6 まとめ
- 11章 負荷の管理
- 11.1 Google Cloudのロードバランシング
- 11.1.1 anycast
- 11.1.2 Maglev
- 11.1.3 Global Software Load Balancer
- 11.1.4 Google Front End
- 11.1.5 GCLB：低レイテンシー
- 11.1.6 GCLB：高可用性
- 11.1.7 ケーススタディ1：GCLB上でのPokémon GO
- 11.2 オートスケーリング
- 11.2.1 不健全なマシンの処理
- 11.2.2 ステートフルなシステムの扱い
- 11.2.3 保守的な設定
- 11.2.4 設定の制約
- 11.2.5 キルスイッチと手動オーバーライドの取り込み
- 11.2.6 バックエンドの過負荷の回避
- 11.2.7 トラフィックの不均衡の回避
- 11.3 負荷の管理のための戦略を組み合わせる
- 11.3.1 ケーススタディ2：ロードシェディングが自らの首を絞める
- 11.4 まとめ
- 12章 非抽象的な大規模システム設計の紹介
- 12.1 NALSDとは何か？
- 12.2 なぜ「非抽象的」なのか？
- 12.3 AdWordsの例
- 12.3.1 設計プロセス
- 12.3.2 初期の要件
- 12.3.3 1台のマシン
- 12.3.4 分散システム
- 12.4 まとめ
- 13章 データ処理パイプライン
- 13.1 パイプラインアプリケーション
- 13.1.1 データの並び替えあるいは構造化のためのイベント処理/データ変換
- 13.1.2 データ分析
- 13.1.3 機械学習
- 13.2 パイプラインのベストプラクティス
- 13.2.1 サービスレベル目標の定義と計測
- 13.2.2 依存性障害のための計画
- 13.2.3 パイプラインのドキュメンテーションの作成と管理
- 13.2.4 開発ライフサイクルのマッピング
- 13.2.5 ホットスポットの低減とワークロードパターン
- 13.2.6 オートスケーリングの実装とリソース計画
- 13.2.7 アクセス制御とセキュリティポリシーの遵守
- 13.2.8 プランのエスカレーションパス
- 13.3 パイプラインの要求と設計
- 13.3.1 必要な機能は？
- 13.3.2 冪等と2フェーズの変換
- 13.3.3 チェックポイント処理
- 13.3.4 コードのパターン
- 13.3.5 パイプラインのプロダクションレディネス
- 13.4 パイプラインの障害：回避と対応
- 13.4.1 潜在的な障害の形態
- 13.4.2 潜在的な原因
- 13.5 ケーススタディ：Spotify
- 13.5.1 イベント配信
- 13.5.2 イベント配信システムの設計とアーキテクチャ
- 13.5.3 イベント配信システムの運用
- 13.5.4 顧客の統合とサポート
- 13.5.5 まとめ
- 13.6 結論
- 14章 設定の設計とベストプラクティス
- 14.1 設定とは何か？
- 14.1.1 設定と信頼性
- 14.1.2 哲学と仕組みの分離
- 14.2 設定の哲学
- 14.2.1 ユーザーに質問する設定
- 14.2.2 質問はユーザーの目標に近いものであるべき
- 14.2.3 必須の質問とオプションの質問
- 14.2.4 単純さからの脱却
- 14.3 設定の仕組み
- 14.3.1 設定と結果データの分離
- 14.3.2 ツールの重要性
- 14.3.3 所有権と変更追跡
- 14.3.4 安全な設定変更の適用
- 14.4 まとめ
- 15章 設定の詳細
- 15.1 設定が引き起こすトイル
- 15.2 設定が引き起こすトイルの削減
- 15.3 設定システムの重要な属性と落とし穴
- 15.3.1 落とし穴1：設定をプログラミング言語の問題と認識しない
- 15.3.2 落とし穴2：偶然あるいはアドホックな言語機能の設計
- 15.3.3 落とし穴3：過剰なドメイン固有の最適化
- 15.3.4 落とし穴4：「設定の評価」への「副作用」の混入
- 15.3.5 落とし穴5：Python、Ruby、Luaのような既存の汎用スクリプティング言語の利用
- とても短いJsonnetの紹介
- 15.4 設定言語の統合
- 15.4.1 特定のフォーマットでの設定の生成
- 15.4.2 複数のアプリケーションの駆動
- 15.5 既存のアプリケーションの統合：Kubernetes
- 15.5.1 Kubernetesが提供するもの
- 15.5.2 Kubernetesの設定の例
- 15.5.3 設定言語の統合
- 15.6 カスタムアプリケーション（インハウスソフトウェア）の統合
- 15.7 効果的な設定システムの運用
- 15.7.1 バージョニング
- 15.7.2 ソース管理
- 15.7.3 ツール
- 15.7.4 テスト
- 15.8 いつ設定を評価するか
- 15.8.1 非常に早い段階：JSONのチェックイン
- 15.8.2 途中の段階：ビルド時点での評価
- 15.8.3 終盤：実行時の評価
- 15.9 不正な設定に対するガード
- 15.10 まとめ
- 16章 カナリアリリース
- 16.1 リリースエンジニアリングの原則
- 16.2 リリースの速度と信頼性のバランス
- 異なるレートで変更されるコンポーネントの分離
- 16.3 カナリアとはなにか？
- 16.4 リリースエンジニアリングとカナリア
- 16.4.1 カナリアプロセスの要求
- 16.4.2 サンプルのセットアップ
- 16.5 ロールフォワードデプロイメント対シンプルなカナリアデプロイメント
- 16.6 カナリアの実装
- 16.6.1 SLOとエラーバジェットに対するリスクの最小化
- 16.6.2 カナリアの対象数と期間の選択
- 16.7 メトリクスの選択と評価
- 16.7.1 メトリクスは問題を示すものであるべき
- 16.7.2 メトリクスは代表的で起因を示すものであるべき
- 16.7.3 事前/事後の評価はリスクを含む
- 16.7.4 より優れたメトリクス選択のための段階的なカナリアの利用
- 16.8 依存関係と隔離
- 16.9 非インタラクティブなシステムでのカナリア
- 16.10 モニタリングデータに対する要求
- 16.11 関連する概念
- 16.11.1 ブルー/グリーンデプロイメント
- 16.11.2 人工的な負荷生成
- 16.11.3 トラフィックティーイング
- 16.12 まとめ
- 第Ⅲ部 プロセス
- 17章 過負荷の特定と回復
- 17.1 負荷から過負荷へ
- 17.2 ケーススタディ1：チームの半分が去った時点での作業過負荷
- 17.2.1 背景
- 17.2.2 問題の表明
- 17.2.3 実行すると決めたこと
- 17.2.4 実装
- 17.2.5 学んだこと
- 17.3 ケーススタディ2：組織及び作業負荷の変更後の認知過負荷
- 17.3.1 背景
- 17.3.2 問題の表明
- 17.3.3 実行すると決めたこと
- 17.3.4 実施
- 17.3.5 効果
- 17.3.6 学んだこと
- 17.4 過負荷の緩和のための戦略
- 17.4.1 過負荷の症状の認識
- 17.4.2 過負荷の低減とチームの健全性の回復
- 17.5 まとめ
- 18章 SREのエンゲージメントモデル
- 18.1 サービスのライフサイクル
- 18.1.1 フェーズ1：アーキテクチャと設計
- 18.1.2 フェーズ2：活発な開発
- 18.1.3 フェーズ3：限定公開
- 18.1.4 フェーズ4：一般公開（GA）
- 18.1.5 フェーズ5：非推奨化
- 18.1.6 フェーズ6：放棄
- 18.1.7 フェーズ7：サポート終了
- 18.2 関係性のセットアップ
- 18.2.1 ビジネスとプロダクションの優先順位のコミュニケーション
- 18.2.2 リスクの特定
- 18.2.3 目標を揃える
- 共有の目標：New York TimesにおけるSREのエンゲージメント
- 18.2.4 基本原則の設定
- 18.2.5 計画と実行
- 18.3 効率的な継続的関係性の維持
- 18.3.1 よりうまく共同で働けるようになることへの時間の投資
- 18.3.2 オープンなコミュニケーション経路の維持
- 18.3.3 定期的なサービスレビューの実施
- 18.3.4 基本原則がずれ始めた時点での再評価
- 18.3.5 SLOとエラーバジェットに基づく優先順位の調整
- 18.3.6 適切なミスの処理
- 18.4 より大規模な環境へのSREのスケール
- 18.4.1 単一のSREチームでの複数サービスのサポート
- 18.4.2 複数のSREチーム環境の構造化
- 18.4.3 変化する環境へのSREチームの構造の適応
- 18.4.4 まとまりのある分散SREチームの運営
- 18.5 関係性の終了
- 18.5.1 ケーススタディ1：Ares
- 18.5.2 ケーススタディ2：データ分析パイプライン
- 18.6 まとめ
- 19章 SRE：壁の向こうへの到達
- 19.1 我々が自明だと考える真実
- 19.1.1 信頼性は最も重要な機能
- 19.1.2 モニタリングではなくユーザーが信頼性を決める
- 19.1.3 プラットフォームを動作させるなら、信頼性はパートナーシップである
- 19.1.4 重要なものはすべていつかプラットフォーム化する
- 19.1.5 顧客が苦労しているなら、速度を落とさなければならない
- 19.1.6 SREは顧客と共に実践しなければならなくなる
- 19.2 ハウツー： 顧客とのSRE
- 19.2.1 ステップ1：SLOとSLIが会話の手段
- 19.2.2 ステップ2：モニタリングの監査と共有ダッシュボードの構築
- 19.2.3 ステップ3：計測と再交渉
- 19.2.4 ステップ4：設計レビューとリスク分析
- 19.2.5 ステップ5：実践、実践、実践
- 19.2.6 思慮深く規律を守る
- 19.3 まとめ
- 20章 SREチームのライフサイクル
- 20.1 SREなしでのSREの実践
- 20.2 SREロールの開始
- 20.2.1 最初のSREを見つける
- 20.2.2 最初のSREの配置
- 20.2.3 最初のSREの立ち上げ
- 20.2.4 分散SRE
- 20.3 最初のSREチーム
- 20.3.1 形成期
- 20.3.2 混乱期
- 20.3.3 統一期
- 既存のチームのSREチームへの転換
- 20.3.4 機能期
- 20.4 さらなるSREチームの形成
- 20.4.1 サービスの複雑さ
- 20.4.2 SREの展開
- 20.4.3 地理的な分割
- 20.5 多数のチームの運営のための推奨プラクティス
- 20.5.1 ミッションコントロール
- 20.5.2 SRE Exchange
- 20.5.3 トレーニング
- 20.5.4 横断的プロジェクト
- 20.5.5 SREの流動性
- 20.5.6 出張
- 20.5.7 ローンチ調整エンジニアリングチーム
- 20.5.8 プロダクションエクセレンス
- 20.5.9 SREへの投資と雇用
- 20.6 まとめ
- 21章 SREにおけるIT変更管理
- 21.1 SREは変化を抱擁する
- 21.2 変更管理の紹介
- 21.2.1 Lewinの3ステージモデル
- 21.2.2 マッキンゼーの7-Sモデル
- 21.2.3 Kotterの変更をリードするための8ステッププロセス
- 21.2.4 ProsciのADKARモデル
- 21.2.5 感情ベースのモデル
- 21.2.6 デミングのサイクル
- 21.2.7 これらの理論のSREへの適用
- 21.3 ケーススタディ1：Wazeのスケーリング――アドホックな変更から計画された変更へ
- 21.3.1 背景
- 21.3.2 メッセージキュー：信頼性をメンテナンスしながらのシステムの置き換え
- 21.3.3 変更の次のサイクル：デプロイメントプロセスの改善
- 21.3.4 学んだこと
- 21.4 ケーススタディ2：SREにおける共通ツールの採用
- 21.4.1 背景
- 21.4.2 問題の状況
- 21.4.3 実行すると決めたこと
- 21.4.4 設計
- 21.4.5 実装：モニタリング
- 21.4.6 学んだこと
- 21.5 まとめ
- まとめ
- この先……
- 将来は過去に属する
- SRE + ＜他の分野＞
- しずく、細流、そして奔流
- SREは私たち全員のもの
- 謝意
- 付録A SLOドキュメントの例
- サービスの概要
- SLIとSLO
- 根拠となる事項
- エラーバジェット
- 補足・留意点
- 付録B エラーバジェットポリシーの例
- サービスの概要
- 目標
- 目標ではないこと
- SLO違反のポリシー
- 障害のポリシー
- エスカレーションポリシー
- 背景
- 付録C ポストモーテム分析の結果
- 編者・訳者紹介
- 編者紹介
- 監訳者紹介
- 訳者紹介
- カバーの説明
- 奥付
Product information
- Title: サイトリライアビリティワークブック ―SREの実践方法
- Author(s):
- Release date: June 2020
- Publisher(s): O'Reilly Japan, Inc.
- ISBN: 9784873119137
You might also like
book
進化的アーキテクチャ ―絶え間ない変化を支える
現代におけるエンタープライズアーキテクチャは、もはや静的な計画をあてにすることはできなくなっています。そしてソフトウェア開発エコシステムは、ツールやフレームワーク、技術イノベーションの流れと共に絶え間なく変化しています。こうした状況の中で、いったん構築したシステムを成長させていくには、さまざまな変化に適応しながら進化するアーキテクチャをシステムに組み込む必要があります。本書は、そうしたアーキテクチャを「進化的アーキテクチャ」と名付け、その構築に必要な考え方や技術、実践方法などについて解説するものです。
book
リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり
新規事業を生み出し、顧客にすばやく価値を届けるには、それを支援する体制が必要です。本書は、あらゆるムダを省き、継続的に仮説検証を繰り返しながら、プロダクトやサービスを構築する「リーンスタートアップ」の手法を既存の企業に適用するための方法を説明します。市場環境や顧客ニーズの変化に対応し、イノベーションを加速させ、組織文化、ガバナンス、財務管理を最適化し続けるハイパフォーマンス組織になるための原則とパターンを、さまざまな成功企業のケーススタディとともに詳述します。
book
Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセス
Googleの現役ソフトウェアエンジニアたちが、超大規模ソフトウェアの開発と保守を長期的に支えてきたGoogle社内の多様なベストプラクティスを、文化、プロセス、ツールの側面からこの一冊に凝縮。時間と変化、規模と成長、トレードオフとコストという3つの基本原理に沿って、コードを持続可能にする方法論を紐解きます。「謙虚、尊敬、信頼」、心理的安全性、ダイバーシティとインクルージョンなど公正を重んじる文化から、コードレビューやテスト構成法など人間の行動を規定するプロセス、継続的インテグレーションや大規模変更システムなど変化への対応を支援する自動化ツールの基盤技術まで、Googleが試行錯誤を経て獲得した教訓を余すところなく紹介しています。経済学、心理学、マネジメント論などを背景にした人間への深い洞察をふまえ、データ駆動かつトレードオフから導かれる、定量的かつ定性的な決定プロセスも解説。Googleの成長力の源泉を理解でき、得られる知見は、学生から組織の意思決定者、小規模スタートアップからデジタルトランスフォーメーション（DX）を目指す大企業まで、幅広く活用できます。
book
入門 監視 ―モダンなモニタリングのためのデザインパターン
本書は、システムのどの部分をどのように監視すべきか、また監視をどのように改善していくべきかについて解説する書籍です。前半で監視のベストプラクティス、デザインパターン／アンチパターンを示して、監視の基本原則を詳しく説明し、後半でフロントエンド、アプリケーション、サーバ、ネットワーク、セキュリティの各テーマで強力な監視の基盤を設計して実装するための方法を示します。監視対象が変化し、システムアーキテクチャが進化する中で、従来から変わらない監視の基本を示しながら、時代に合った監視の実践を解説する本書は、監視についての理解を深めたいエンジニア必携の一冊です。
