book

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

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.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.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.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.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.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.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.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.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.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.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.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.1　NALSDとは何か？　　12.2　なぜ「非抽象的」なのか？　　12.3　AdWordsの例　　　12.3.1　設計プロセス　　　12.3.2　初期の要件　　　12.3.3　1台のマシン　　　12.3.4　分散システム　　12.4　まとめ
　　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.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.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.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.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.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.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.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.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は私たち全員のもの　　謝意
　　サービスの概要　　SLIとSLO　　根拠となる事項　　エラーバジェット　　補足・留意点
　　サービスの概要　　目標　　目標ではないこと　　SLO違反のポリシー　　障害のポリシー　　エスカレーションポリシー　　背景
　　編者紹介　　監訳者紹介　　訳者紹介　　カバーの説明

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

3章SLOエンジニアリングのケーススタディ

執筆：Ben McCormack（Evernote）、William Bonnell（The Home Depot）

協力：Garrett Plasky（Evernote）、Alex Hidalgo、Betsy Beyer、Dave Rensin

SREの教義の多くはGoogleの壁の中で形作られたものですが、その原理は私たちの門の外で長く息づいていたものです。Google SREの標準的なプラクティスの多くは、業界の中の多くの他の組織で独自に発見され、あるいは採用されてきました。

SLOはSREモデルの基礎になる考え方です。私たちは、Google Cloud Platform（GCP）の顧客がより信頼性の高いサービスを構築するのを支援する経験豊富なSREのグループである、カスタマーリライアビリティエンジニアリング（Customer Reliability Engineering = CRE）チームを発足させました。このチームと顧客とのやりとりには終始SLOが使われます。

ここでは2つの非常に異なる企業によって語られる2つの物語を紹介します。これは、Google CREチームと共に働くにあたってSLOとエラーバジェットベースのアプローチを採用するにいたった彼らの旅路（ジャーニー）の概要です。SLOとエラーバジェットに関するより一般的な議論については本書2章と『SRE サイトリライアビリティエンジニアリング』の「3章　リスクの受容」をご覧ください。

3.1　EvernoteにおけるSLOの物語

執筆：Ben McCormack（Evernote）

Evernoteは、個人やチームが情報を生み出し、整理し、共有するのを支援するクロスプラットフォームアプリケーションです。世界中で2.2億人以上のユーザーを持ち、テキストベースのノート、ファイル、添付ファイルや画像などからなる120億以上の情報をこのプラットフォーム内に保存しています。舞台裏では、Evernoteのサービスは750以上のMySQLインスタンスによってサポートされています。 ...

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.

Start your free trial

Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

Publisher Resources

ISBN: 9784873119137Other

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

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

3章SLOエンジニアリングのケーススタディ

3.1　Evernoteにおける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.

You might also like

Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

プログラミングRust

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

Publisher Resources

3章SLOエンジニアリングのケーススタディ

3.1 Evernoteにおける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.

You might also like

Pythonではじめる機械学習 ―scikit-learnで学ぶ特徴量エンジニアリングと機械学習の基礎

プログラミングRust

初めてのGraphQL ―Webサービスを作って学ぶ新世代API

ルールズ・オブ・プログラミング ―より良いコードを書くための21のルール

Publisher Resources

3.1　Evernoteにおける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.