The DevOps ハンドブック 理論・原則・実践のすべて

著者 : ジーン・キム ジェズ・ハンブル パトリック・ボア ジョン・ウィリス 長尾高弘

• 日経BP (2017年6月22日発売)

作品紹介・あらすじ

システムの開発と運用を一体化するDevOpsの理論と実践を徹底解説。
ビジネス成果に結びつく考え方・導入・実践・事例を網羅した決定版です。
事例については、Google、Facebook、Twitter、LinkedIn、Netflix、Target、Etsy、Pivotalなどの実例を当事者のコメントやポイントともに紹介しています。

(本書で詳述する)「3つの道」はDevOpsの大原則であり、DevOpsを理解・実践するための大きな着眼点であるととらえればよい。第1の道はITバリューストリームのスピードアップであり、開発から運用を経て顧客接点のビジネスまでのスムーズな展開、第2の道はその逆方向でのフィードバックプロセスの有効化と迅速化、第3の道はこうした展開の安定と継続のなかで組織的に学習していくプロセスを表している。第1章の図5に示されているシンプルな矢印の重ね合わせこそが大原則なのである。
本書の構成はこの「3つの道」を中心の部として配置し、そのなかにトピックごとの章立てがなされている。まずは「3つの道」の概念をしっかりと理解、頭に入れた上で読み進めるのがよいだろう。
(監修者あとがきより)

感想・レビュー・書評

[hmk404さんの感想 · 2021年3月7日]

出版された年から数年経っているので少し内容が古いかと思っていたが、そういったことを感じさせない内容だった。

間でところどころに事例も入っていて、AgileとDevOpsとCI/CDの関係性もこの本を通じてクリアになった。

職場においてDevOpsは部分的には実践されているが、この書籍の内容をベースに改めて改善可能な点を探したくなるような一冊だった。
チームで共通の理解にしたいと思える。

[JG1PVDさんの感想 · 2019年7月15日]

会社で「研修を受けませんか？この本を読了することが条件になりますけど」と言われながら渡された本。3連休が雨続きだったので、予定よりも早く読了。
ITシステムの開発や運用の世界で重要なワード“DevOps”について、理論から事例まで1冊にまとめられている。私はエンジニアではないが、とても興味深く読むことができた。普段仕事をしている中で思い当たるところがいくつもあったので、研修があろうがなかろうが読んでよかったと思う。エンジニアやプロダクト開発の人と会話する時の予備知識として読んでもいいと思う。
余談だが、DevOpsの概念の中に、トヨタのカンバン方式があるとはこの本を読むまで知らなかった。英訳された本を読んでいく中で「アンドン」という言葉が出てくると意外な気もするが、トヨタが編み出した生産管理は他の業界・業種にも応用できるほど普遍性を持っている証左なのだろう。

[snow222さんの感想 · 2018年3月11日]

読みにくい本だ…。それほど目からウロコでもないような話題をタラタラタラタラ、翻訳書独特のの長ったらしい文章で説明し、「章タイトルは【最初に手をつけるバリューストリームの選択方法】なんだけど、バリューストリームのカテゴリの話ばかりして選択方法の話が出てこないぞ…」こんなのばっかりで、「これ何の話だったっけ？」と戻り読みすることが多くなかなか先へ進まない。

理想はそうなんだけどさー、どうやって実現にこぎつけりゃいいのよ？ケーススタディとやらも「日常業務の一部として問題を見つけ、修正していくことで、技術的に負債をマネジメントしていった」みたいな抽象的記述ばっかりで、いやいやクソ忙してくてそれどころじゃない職場で具体的にどうやってそれ進めたのか知りたいんだけど、という気持ちになりイライラして読むのが止まる。全然先に進まない。

p. 167 【第9章 デプロイパイプラインの基礎の構築】ほとんどすべての場合において、コードよりも環境のほうが帰られる設定が何桁分も多いからである。そのため、もっともバージョン管理システムが必要なのは環境なのだ。
→「修理するよりも再構築するほうが簡単なインフラストラクチャを作る」につながる。
“イミュータブルインフラストラクチャ”＝本番環境に対する手作業の変更はもはや認められない。本番環境に変更を加えるときは、変更をバージョン管理システムに格納し、ゼロからコードと環境を作り直す以外の方法は許されない。そうすれば、本番環境に差異が紛れ込むことは絶対になくなる。

p.181 【第9章 デプロイパイプラインの基礎の構築】継続的インテグレーションの実践に必要な3つ
・デプロイできる状態になっていることをチェックする包括的で信頼性の高い自動テストセット
・チェックのためのテストが失敗したときには「生産ラインを全面ストップする」文化（＝アンドン）
・寿命の長い機能ブランチではなく、トランクに小規模な変更を加えていくデベロッパー

p.185 【第10章 高速で信頼性の高い自動テストの実現】理想的な自動テストピラミッドは、大半のエラーをユニットテストで見つけられることである。インテグレーションテストや受入テストでエラーを見つけた場合、デベロッパーに返すフィードバックは桁違いに遅くなる。そして、インテグレーションテストは希少で複雑なインテグレーションテスト環境を使うため、この環境を同時に使えるチームは1つだけに限られたりして、フィードバックはさらに遅くなってしまう。
しかし、多くのテストプログラムは、マニュアルテストやインテグレーションテストに重点を置いており、これとは逆になっている。

p.237 【第12章 自動化とローリスクリリースの実現】「継続的インテグレーション ⊃ 継続的デリバリー ⊃ 継続的デプロイメント」
・継続的インテグレーション： ビルドが成功したら自動的にインテグレーションテストが実行される状態
・継続的デリバリー： トランクがいつでもオンデマンドでデプロイ可能な状態
・継続的デプロイメント： 以上に加え、最後のステップ（本番環境へのデプロイ）まで定期的に行っている状態

p.309 【第16章 フィードバックループおｗ実現して開発と運用が安全にコードをデプロイできるようにする】最初の段階では本番サービスをデベロッパーに管理させる。運用エンジニアに移管後、本番サービスが十分脆弱になってきたら、運用は本番サポートの職務を開発に返上（サービスハンドバック）できるようにする。
こうしたフィードバックループを作ると、本番環境へのデプロイが安全になり、開発が作るコードが本番環境により適したものになる。そして、共通の目標や責任を強化し、共感を強めるように仕向けていけば、開発と運用の間により協力的な関係を築くことができる。

p.336 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】テストが失敗すると、私たちはとかくもっとテストをしようとする。しかし、プロジェクトの終わりの時期にただテストを増やすようなことをすると、かえって結果が悪くなることがある。特に、増やしたのがマニュアルテストだと弊害が起きやすい。デプロイのバッチサイズが大きくなり、変更の成功率が下がり、インシデントの数が増え、MTTRが長くなる。つまり望んでいるのと逆の結果になるということは、理論からも実践からもわかっていることである。
変更凍結期間を設定してバッチサイズの大きい変更をじっくりテストするよりも、スムースで継続出来な本番デプロイのフローの一部としてテストを日常業務に完全に組み込み、デプロイの頻度を上げるようにしよう。そうすれば、作業に品質を組み込み、もっとバッチサイズの小さい変更をテスト、デプロイ、リリースできる。


p.333 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】ピアレビューでもバッチサイズは小さく保つ。変更のサイズが大きくなると、変更に対して意味のある批評を加える能力は下がっていく。「プログラマーに10行のコードのレビューを頼むと10個の問題点を見つけてきますが、500行のコードのレビューを頼むと、まあいいんじゃないと言われるでしょう」

p.342 【第18章 レビューと調整プロセスによって現在の仕事の品質を上げる】官僚主義的なプロセスを大胆に取り除く。終わるまで何ヶ月もかかる承認プロセス＝ウォーターフォールのこと。

p.355 【第19章 日常業務での学習の実現と日常業務への学習の注入】 避難なしのポストモーテムイーティングにおいて「もっと注意する」「もっと愚かでないようにする」という対応策は認められない。この種のエラーが再び起きるのを妨げる本物の対応策を生み出さなければならないのである。
そのような対応策として考えられるのは、デプロイパイプラインの危険な条件を検出する新しい自動テストの導入、遠隔測定の追加、ピアレビューを追加しなければならない変更タイプの確定、定期的に設定されたGame Dayに実施される同じタイプのエラーのリハーサルなどがある。

[bob-taniさんの感想 · 2022年5月28日]

様々に語られるIT要素と互換性のある文化側面を説明。

悪循環を断ち生産性向上とビジネス価値をもたらすのに、もっといいやり方がある論。
当たり前化の話であり、現在のITの先端をいく企業に限らず
デプロイ・リリースをするために必要なことをまとめると、ここ十数年の動きの集大成の語りで、結果そうなるよねという話。
できているなと思えるのであればそれほど目新しさはない。

[japapizzaさんの感想 · 2022年3月5日]

序章 DevとOpsがDevOpsになる世界を想像してみよう
0.1 問題：組織の何かを改善しなければならない
　　(でなければ、あなただろうね)
0.2 DevOpsの倫理：もっとよい方法がある
0.3 The DevOps Handbook: 基本ガイド

第1部 3つの道
第1章　アジャイル、 継続的デリバリー、 そして3つの道
1.1 生産のバリューストリーム
1.2 ITバリューストリーム
1.3.3つの道：DevOpsを支える原則
1.4 まとめ

第2章 第1の道：フローの原則
2.1 作業の可視化
2.2 WIP(仕掛り)の制限
2.3 バッチサイズの縮小
2.4 受け渡しの数の削減
2.5 条件を見つけ出して尊重する
2.6 バリューストリームからムダと苦痛を取り除く
2.7 まとめ

第3章 第2の道：フィードバックの原則
3.1 複雑なシステムにおける安全な作業
3.2 発生と同時に問題を知る
3.3 新しい知識を作り上げるために組が一丸となって問題解決に当たる
3.4 上での品質確保を追求する
3.5 下流のワークセンターのために最適な出力
3.6 まとめ

第4章 第3の道：継続的な学習と実験の原則
4.1 組織的な学習と安全重の文化を生み出す
4.2 日常業務の改善を制度化する
4.3 ローカルな発見をグローバルな改善に転化する
4.4 日常業務に力を鍛えるパターンを注入する
4.5 リーダーが学習する文化を奨する
4.6 まとめ
4.7 第1部のまとめ

第2部 スタートのための糸口
第5章 最初に手を付けるバリューストリームの選択方法
5.1 グリーンフィールドサービスとブラウンフィールドサービス
5.2 記録システムと参加システムの両方を考慮に入れる
5.3 もっとも関心を持ちイノベーティブなグループから始める
5.4 DevOpsの組織全体への展開
5.5 まとめ

第6章 バリューストリーム内の作業を理解し、それを可視化して、組織全体に広げる
6.1 バリューストリームを支えるチームを明らかにする
6.2 バリューストリームマップを作成して作業を可視化する
6.3 専任の変革チームを編成する
ケーススタディ Linkedin-Operation InVersion (2011年)
6.4 ツールを使って望ましい行動を促す
6.5 まとめ

第7章 Conwayの法則を念頭に置いた組織とアーキテクチャの設計
7.1 組織の原型
7.2 過度に職能指向(「コストのために最適化｣)になったときによく起きる問題
7.3 市場指向 (｢スピードのために最適化｣)のチームの実現
7.4 職能指向の組織を機能させる方法
7.5 全員の日常業務としてのテスト、運用、セキュリティ
7.6 すべてのチームメンバーがジェネラリストになれるようにする
7.7 プロジェクトではなく、サービスと製品に投資する
7.8 Conwayの法則に従ってチームの境界線を引く
7.9 疎結合なアーキテクチャによりデベロッパーの生産性と安全を向上させる
ケーススタディ Target API Enablement (2015年)
7.10 まとめ

第8章 開発の日常業務に運用を統合してすばらしい成果を生み出す方法
8.1 デベロッパーの生産性を上げるために共有サービスを作る
8.2 サービスチームに運用エンジニアを配置する
8.3 運用のなかで個々のサービスチームに対する連絡担当を指名する
8.4 開発の儀式に運用を参加させる
8.5 共有カンバンボードで関連する運用の仕事を可視化する
8.6 まとめ
8.7 第2部のまとめ

第3部 第1の道：フロー改善の技術的実践
第9章 デプロイパイプラインの基礎の構築
9.1 開発、テスト、本番環境をオンデマンドで作成できるようにする
9.2 システム全体で唯一の真正なリポジトリーを作る
9.3 修理するよりも再構築する方が簡単なインフラストラクチャを作る
9.4 本番に近い環境で動作することの確認も含めて「完成」と言うように開発の「完成｣の定義を変える
9.5 まとめ

第10章 高速で信頼性の高い自動テストの実現
　GWSチームを率いるBharat Medirattaは、自動テストが役に立つはずだと考えていた。また、Blandの話を聞いてみよう。「非常に厳しい線が引かれました。―自動テストがついていない変更は、GWSには受け入れないということになったのです。彼らは継続的ビルドをセットアップし、律儀にそれを実行し続けました。また、テストカバレッジのモニタリングをセットアップし、時間とともに必要とされるテストカバレッジのレベルは上がり続けました。また、テストの方針とガイドが作られ、社内外のコントリビューターはそれに従うよう強く求められました。」
10.1 コードと環境を継続的にビルド、テスト、インテグレートする
10.2 高速で信頼性の高い自動確認テストスイート
10.3 デプロイパイプラインが壊れたときにはアンドンの紐を引く
10.4 まとめ

第11章 継続的インテグレーションの実現と実践
11.1 小さなバッチによる開発についてとトランクへのコードのコミットが頻繁に行われない場合に何が起きるかについて
11.2 トランクベースの開発という実践手法
ケーススタディ Bazaarvoiceの継続的インテグレーション(2012年)
11.3 まとめ

第12章 自動化とローリスクリリースの実現
12.1 デプロイプロセスの自動化
ケーススタディ CSG International 一日次デプロイ(2013年)
ケーススタディ Etsy-デベロッパーによるセルフサービスのデプロイ(継続的デプロイの事例 2014年)
12.2 リリースからデプロイを切り離す
ケーススタディ Dixons Retail POSシステムの青-緑デプロイ(2008年)
ケーススタディ Facebook Chatーダークローンチ(2008年)
12.3 まとめ

第13章 ローリスクリリースのアーキテクチャ
　eBayのShoupのチームが行ったことは、絞め殺しアプリケーション(stangler application)パターンと呼ばれるテクニックを使った、発展的な設計の教科書的なサンプルである。組織の目標をサポートできなくなったアーキテクチャの古いサービスをちぎっては交換するような乱暴なことをせず、既存の機能をAPIの背後に置き、それ以上その機能に手を付けないようにする。そして、新しい機能は、新しいアーキテクチャを使った新しいサービスのなかで実装し、必要に応じて古いシステムを呼び出す。
　絞め殺しアプリケーションパターンは、モノリシックなアプリケーションや蜜結合のサービスをもっと疎結合なものにマイグレートするときに特に役立つ。何年(または何十年)も前から作られてきているアプリケーションでは、アーキテクチャのなかに蜜結合になってしまった部分や、相互の結び付きが密接になりすぎてしまった部分が見つかることが多い。
13.1 生産性、テスト可能性、安全性を実現するアーキテクチャ
13.2 アーキテクチャの原型：モノリシックとマイクロサービス
ケーススタディ Amazon発展的アーキテクチャ(2002年)
13.3 絞め殺しアプリケーションパターンを使って安全に全社のアーキテクチャを発展させる
ケーススタディ Blackboard Learn 絞め殺しアプリケーションパターン(2011年)
13.4 まとめ
13.5 第3部のまとめ

第4部　第2の道 : フィードバックの技術的実践
第14章 問題の可視化と解決のための基礎となる遠隔測定データを作り出す
14.1 一元的な遠隔測定インフラストラクチャの作り方
14.2 本番システムの運用を助けるためにアプリケーションにログ作成機能を追加する
14.3 問題解決の道案内として遠隔測定データを利用する
14.4 日常業務の一部として指標を生み出せるようにする
14.5 遠隔測定データと情報ラジエーターにセルフサービスでアクセスできるようにする
ケーススタディ LinkedIn セルフサービスによる指標作成
14.6 遠隔測定の穴を見つけて埋める
14.7 まとめ

第15章　遠隔測定データを分析して問題の予測と目標の達成に活かす
15.1 平均と標準偏差を使って問題となり得るものを検出する
15.2 望ましくない結果を測定してアラートを送る
15.3 遠隔測定データが正規分布に従っていないときの問題
ケーススタディ Netflix-オートスケーリング機能 (2012年)
15.4 異常値検出テクニックの使い方
　ユーザーデータに関する遠隔測定の大部分は、周期的／季節的な類似性を示すと予想することができる。ウェブトラフィック、小売取引、映画鑑賞といったユーザーの行動の多くは、非常に規則的であり、驚くほど予測が当たる毎日、毎週、毎年のパターンがある。これを利用すれば、たとえば火曜日の午後には発注のトランザクション速度が週の基準値の50％まで落ちるといった履歴に現れた基準から大きく外れる状況を検出することができる。
ケーススタディ 高度な異常値検出(2014年)
15.5 まとめ

第16章　フィードバックループを実現して開発と運用が安全にコードをデプロイできるようにする
16.1 遠隔測定データを使ってデプロイをより安全なものにする
16.2 開発と運用でオンコールを共有する
16.3 デベロッパーに下流の仕事を観察させる
16.4 最初の段階では本番サービスをデベロッパーに管理させる
ケーススタディ Google-ローンチ/引き継ぎ準備調査(2010年)
16.5 まとめ

第17章 日常業務に仮説駆動開発とA/Bテストを組み込む
17.1 A/Bテスト小史
17.2 機能テストにA/Bテストを組み込む
17.3 リリースにA/Bテストを組み込む
17.4 機能のプランニングにA/Bテストを組み込む
ケーススタディ Yahoo! Answers (Yahoo!知恵袋のアメリカ版)収益を倍増させたリリースサイクル高速化実験(2010年)
17.5 まとめ

第18章　レビューと調整プロセスによって現在の仕事の品質を上げる
18.1 変更承認プロセスの危険性
　…人を信頼せず、命令と服従の文化が浸透している環境では、変更管理やテストといった予防策の改善を試みたところで、問題が再発する確率を上げるだけになることが多い。しかももっとひどい結果が起きることがある。
　Gene Kimは、次のように語っている。「〔変更とテストの管理は、〕プロとしてのキャリアのなかでもっとも重要な瞬間の１つで、意図とは逆の効果を持つことがあります。…
　…そこから、これからの10年でもっとも大きな経営課題は、高信頼マネジメントの文化を築くことになりそうだという認識を強める驚くべき発見が得られたのです」
18.2 「過度に管理された変更」が秘める危険
　トヨタ生産方式の中心的な考え方の１つは、「問題にもっとも近い人間が問題をもっともよく知っている」ということだ。これはDevOpsバリューストリームのように、行う仕事と仕事を進めるためのシステムが複雑でダイナミックなものになればなるほど、強調されなければならないことである。そういった場合、仕事の現場から遠く離れた人の承認を新たに要求すれば、成功の可能性は低くなる。仕事をする人(つまり、変更の実装者)と仕事をすることを決定する人(つまり、変更の承認者)の距離が離れれば離れるほど、結果が悪くなることは、繰り返し実証されてきたことだ。
18.3 変更の調整と日程管理の実現
18.4 ピアレビューの実現
ケーススタディ Google-コードレビュー(2010年)
18.5 マニュアルテストを増やして変更の凍結期間を延ばすことの危険性
18.6 変更の品質を上げるためにペアプログラミングを実現する
ケーススタディ Pivotal Labs一破綻したコードレビュープロセスに代わるペアプログラミング(2011年) 18.7 プルリクエストプロセスの有効性の評価方法
18.8 官僚主義的なプロセスを大胆に取り除く
ケーススタディ Target-冗長な承認プロセスの廃止(2012年)
18.9 まとめ
18.10 第4部のまとめ

第5部 第3の道：継続的な学習と実験の技術的実践
第19章　日常業務での学習の実現と日常業務への学習の注入
19.1 公正なラーニングカルチャーを確立する
19.2 事故が起きたあとに非難なしのポストモーテムを開く
　ジャストカルチャーの実現を助けるために、事故や重大なインシデント(たとえば、デプロイ失敗、顧客に影響を及ぼした本番環境の問題)が起きたときには、事態を解決したあとで非難なしのポストモーテムを開くべきである。
・誤りを犯した人を罰しないようにしながら、さまざまな視点から障害の詳細な事実を集めてタイムラインを描く。
・自分が障害の発生にどのように関わったかについて詳細に説明できる場を設けて、すべてのエンジニアに安全性向上のための意欲を与える。
・将来同じ過ちを繰り返さないための方法を社内のほかの人々に教えるエキスパートになるように、誤りを犯した人々を励ます。
・人にはアクションを起こすか否かを判断する裁量の余地がかならずあり、その判断のよしあしの判定はあと知恵だということだと認める。
・将来、同じような事故が起きないようにするための対応策を提案し、期限とフォローアップ責任者を決めて、その対応策の実施記録をかならず作る。
…
Estyのエンジニア、Ian Malpassは、次のように指摘する。「サイト全体が落ちるような何かをしてしまったときには、『背筋が凍りつく』思いがして、まず『なんてことだ、自分が何をしたのかまったくわからない』という考えが頭のなかを駆けめぐることになるでしょう。しかし、この考えは錯乱、絶望、自分がじぶんではないような感覚に陥る道です。優れたエンジニアはそのような状態に陥ってはなりません。そのような考えは止めて、『あの行動をとったとき、なぜそれが正しいと思ったのだろうか』ということをじっくり考えるようにすべきです」
19.3 できる限り広い範囲にポストモーテムを公表する
19.4 従来よりも弱い失敗の兆候を見つけるためにインシデントの境界線を引き下げる
19.5 失敗の意味を捉え直して計算されたリスクテイクを奨励する
19.6 回復力と学習を生み出すために本番環境にエラーを注入する
19.7 エラーのリハーサルのために試合日を設ける
19.8 まとめ

第20章 一部門の発見を全社的な進歩につなげる
20.1 チャットルームとチャットポットで組織的な知識を自動的にキャッチする
20.2 標準化されたプロセスを再利用のためにソフトウェアにまとめて自動化する
20.3 組織全体で1つの共有ソースコードリポジトリーを作る
20.4 ドキュメントとしての自動テストとコミュニティを使って知識を拡散する
20.5 非機能要件を体系化して運用にやさしい設計を実現する
20.6 再利用可能な運用ユーザーストーリーを開発に組み込む
20.7 組織の目標を達成するために役立つ技術を選ぶ
ケーススタディ Etsy 新しいテクノロジースタックによる標準化(2010年)
20.8 まとめ

第21章 組織的な学習と改善を生み出すための時間を確保する
21.1 技術的負債を返済するための儀式を制度化する
21.2 全員が教え、学べるようにする
21.3 DevOpsカンファレンスで自分の経験を共有する
ケーススタディ Nationwide Insurance、Capital One、
Target-社内テクノロジーカンファレンス(2014年)
21.4 実践を広めるために社内にコンサルティングとコーチングの組織を作る
21.5 まとめ
21.6 第5部のまとめ

第6部 情報セキュリティ、変更管理、コンプライアンスを統合するための技術的実践
第22章 すべてのエンジニアの毎日の職務として情報セキュリティを位置づける
22.1 開発イテレーションのデモに情報セキュリティを組み込む
22.2 欠陥の追跡とポストモーテムに情報セキュリティを組み込む
22.3 共有ソースコードリポジトリーと共有サービスにセキュリティリスク予防ツールを組み込む
22.4 デプロイパイプラインにセキュリティを統合する
22.5 アプリケーションのセキュリティを確保する
ケーススタディ Twitter-静的セキュリティテスト(2009年)
22.6 ソフトウェアサプライチェーンのセキュリティを確保する
22.7 環境のセキュリティを確保する
ケーススタディ 18F-Compliance Masonryで連邦政府のコンプライアンス需要を自動化する
22.8 遠隔測定に情報セキュリティを統合する
22.9 アプリケーションのなかにセキュリティ遠隔測定を作り込む
22.10 環境のなかにセキュリティ遠隔測定を作り込む
ケーススタディ Etsy一環境のインストルメンテーション(2010年)
22.11 デプロイパイプラインを防御する
22.12 まとめ 421

第23章 デプロイパイプラインを防御する
23.1 変更承認プロセスにセキュリティとコンプライアンスを組み込む
23.2 比較的リスクが低い変更を標準変更に分類し直す
23.3 変更が通常の変更に分類されたときに何をすべきか
ケーススタディ Salesforce.com-自動化されたインフラストラクチャによる変更を標準的な変更に
23.4 職務の分離に対する依存度を下げる
ケーススタディ Etsy-PCIコンプライアンスと職務の分離についての教訓(2014年)
23.5 監査人とコンプライアンス責任者のためのドキュメントと証拠を残す
ケーススタディ 規制を受けている環境でのコンプライアンスの証明(2015年)
ケーススタディ ATMシステムの遠隔測定の効果
23.6 まとめ
23.7 第6部のまとめ

行動提起 : DevOps ハンドブックの締めくくりに
　最後に、ここまで読み通したあなただけに、知りたくない秘密をお教えしよう。私たちのケーススタディの多くでは、画期的な結果を達成した多くの改革の旗手たちが昇進していった。しかし、その後トップが代わって改革に関わった多くの人々が会社を離れ、彼らが生み出した組織改革がもとに戻ってしまった例もある。
　私たちは、このような可能性があることに悲観的にならないことが大切だと思っている。改革に関わった人々は、最初の時点で自分たちは失敗する可能性がかなり高いことを承知の上で、行動に出た。おそらくもっとも重要なのは、彼らがそうすることによって何ができるかを私たちに示し、私たちをインスパイアしてくれたことである。イノベーションは、リスクを負うことなしには不可能であり、少なくとも上にいる何人かを当惑させなければ、おそらく頑張りが足りないということだ。会社の免疫システムによってビジョンの実現を妨げられたり、注意をそらされたりしてはならない。Amazonの「災難の主」と言われたJesse Robbinsは次のように好んで言う。「バカとケンカしていないで、もっとすごいことをやれ」
　ITバリューストリームに属する人間なら、開発、運用、品質保証、情報セキュリティ、製品オーナーのどの立場であれ、DevOpsのメリットを享受できる。デスマーチを減らして、優れた製品を開発する喜びを復活させてくれる。愛する人たちと過ごせない週末や休日を減らして、人間らしい勤務条件を作り出してくれる。生き残り、学び、繫栄し、顧客を喜ばせ、会社の成功を支えるために、チームが力を合わせられるようにしてくれる。

[got4416さんの感想 · 2022年1月25日]

読むまでは「開発（Dev）と運用（Ops）の対立」からの『一緒にやりましょうね』ってだけの話だと思って舐めてました。
DevOpsをやらなくても生きてる企業はある。けど、今をトップで生きている（生き残っている）企業がこうなのだ、という事を知っておくと良いかもしれない。

[QAZさんの感想 · 2020年9月12日]

DevOpsの教科書として読むべき1冊だとは思いますが、現場レベルのHowには落とし込まれていないので、これを読んでDevOpsを始めるのは難しいのではないかと思います。どのようなプロジェクトが始めやすいかまでで、プロジェクトのどの部分からというのはありませんし、参考に出てくる事例はキラキラ成功話なのでどこか遠い世界に感じてしまいます。
DevOpsでイメージしやすい開発→運用、運用→開発の時間短縮で半分、残りの半分の大半がこのフィードバックを生み出す検知の仕組みだったのは意外でしたが、この仕組みがないとDevOpsを続けることができない重要な部分なのだと思いました。
ただ、そのためのグラフが読み取り辛いものだったのが残念でした。元ネタはきっとカラーだったと思われ、それがモノクロの本になると絶望的なほど分かり辛いものになってしまっています。

[ayatsuguさんの感想 · 2019年9月10日]

やっとこさ読み終えた。自社とのギャップがすごい、、

[波瀬龍さんの感想 · 2019年2月9日]

　自分が所属しているようなIT関連スタッフが1〜2名しかいないNPOでDevOpsもないのだが、そもそもDevOpsって何だっけ？ツールの総称？という程度の理解しかなかったのでザッと読んでみた。考え方なりで何か参考になるところはないか、また、外部の委託業者さんとうまく連携するために参考になるところはないかという期待もあった。
　結果、DevOpsとは、対立しがちな開発部隊と運用部隊が今日的なツールをうまく活用しながら連携していこうという「方法論」「規範」のようなもので、まぁ、開発現場での作法だったxpやアジャイルの進化系という感じ。
　経営リソースの活用という視点から「べき論」を組み立てて展開する辺りは、ちょっと思考遊戯的な香りがするし、スマートにリスクを回避するためには、（余計な）人員がどんどん必要になっていき、これはITという分野の自己増殖本能が為せる技か？と思ったりしたが、参考になる箇所がないでもない。デプロイとリリースを混同してはいけない、というくだりなんかにはハッとさせられた。しかし、IT、特にOSSという分野がすごいのは、本書で紹介されている自動化のツールが、小さなNPOでも活用できるという点だと再認識した。

[speakingchickenさんの感想 · 2018年6月20日]

DevOps についてこれほど広く深く解説されている日本語書籍は2018年現在どこにもない。最高。

著者プロフィール

『ウォールストリート・ジャーナル』ベストセラーの著者、研究者で多くの賞を受賞している。1999年以来、大きな成果を収めている技術組織を研究しており、1998年にトリップワイヤを創設してから13年間CTOを務めた。2014年に大規模で複雑な技術組織のITトランスフォーメーションを研究するDevOps Enterprise Summitを創設し、オーガナイザーを務めている。コンピューター業界における優れた業績とリーダーシップから、2007年にはコンピュータワールド誌で「40歳未満のイノベーティブなITプロフエツショナル40名」に選出され、パーデュ一大学からコンピューター科学科の傑出した卒業生として表彰された。

「2020年 『The DevOps 勝利をつかめ！　技術的負債を一掃せよ』 で使われていた紹介文から引用しています。」