book

サイトリライアビリティワークブック ―SREの実践方法

Name: サイトリライアビリティワークブック ―SREの実践方法
ISBN: 9784873119137

by Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara, Stephen Thorne, 澤田武男, 関根達夫, 細川一茂, 矢吹大輔, 玉川竜司

June 2020

Intermediate to advanced

516 pages

7h 4m

Japanese

O'Reilly Japan, Inc.

Read now

Unlock full access

　大扉
　原書大扉
　クレジット
　本書への推薦の言葉
　序文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　ポストモーテム分析の結果
　編者・訳者紹介
　　編者紹介　　監訳者紹介　　訳者紹介　　カバーの説明
　奥付

Content preview from サイトリライアビリティワークブック ―SREの実践方法

付録Bエラーバジェットポリシーの例

ステータス	公開
作者	Steven Thurgood
日付	2018-02-19
レビューアー	David Ferguson
承認者	Betsy Beyer
承認日	2018-02-20
再訪日	2019-02-01

サービスの概要

サンプルゲームサービスは、Android及びiPhoneのユーザーがお互いにゲームを遊べるようにする。バックエンドコードの新リリースは日次でプッシュされる。クライアントの新リリースは週次でプッシュされる。このポリシーは、バックエンドとクライアントのどちらのリリースにも適用される。

目標

このポリシーの目標は以下のとおり。

反復的なSLO違反から顧客を保護する
信頼性とその他の機能とのバランスを取るための動機付けを提供する

目標ではないこと

このポリシーは、SLO違反に対する処罰として働くことを意図していない。変更を止めることは望ましくない。このポリシーは、信頼性がプロダクトの他の機能よりも重要であることをデータが示している場合に、チームが信頼性にのみ集中する権限を与えるものである。

SLO違反のポリシー

サービスがSLOに沿って、あるいはそれ以内で動作しているなら、リリース（データ変更を含む）はリリースポリシーに従って進められる。

サービスが直近の4週間のウィンドウでエラーバジェットを超過したら、P0†1の問題あるいはセキュリティの修正を除くすべての変更とリリースを、サービスがSLO内に回復するまで停止する。

SLO違反の原因によって、チームは機能の作業の代わりに信頼性に関する作業に追加のリソースを割くことがある。

以下の場合、チームは信頼性に関する作業をしなければならない。

コードのバグあるいは手続き的なエラーがサービスそのもののエラーバジェット超過を引き起こした。 ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9784873119137Other

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills