あらすじ
DevOps改革を「迅速に・確実に・安全に」実践するための必読書です。
システムの開発と運用を一体化するDevOpsの理論と実践を徹底解説。
ビジネス成果に結びつく考え方・導入・実践・事例を網羅した決定版です。
事例については、Google、Facebook、Twitter、LinkedIn、Netflix、Target、Etsy、Pivotalなどの実例を当事者のコメントやポイントともに紹介しています。
本書の目的は、DevOps導入の取り組みを成功させ、目指した目標を達成するために必要な理論、原則、実践を読者に伝えることだ。このガイドは、経営理論の数十年の蓄積、高い業績を上げているIT企業の研究、組織改革を手伝うために私たちが行ってきたこと、処方されたDevOps実践の有効性の検証を基礎としている。また、関連する分野の専門家たちに対するインタビューや、DevOps Enterprise Summitで発表された100件近いケーススタディの分析も織り込まれている。
本書は6部構成になっており、「3つの道」を使ってDevOpsの理論と実践を説明していく。ITバリューストリーム(一般に、製品管理、開発、品質保証、IT 運用、情報セキュリティから構成されている)の仕事を行っているか影響を与えているすべての人々のための本であり、ほとんどのITプロジェクトを生み出すもととなっている経営者、販売推進(マーケティング)リーダーのための本でもある。
(序章より)
感情タグBEST3
Posted by ブクログ
読むまでは「開発（Dev）と運用（Ops）の対立」からの『一緒にやりましょうね』ってだけの話だと思って舐めてました。
DevOpsをやらなくても生きてる企業はある。けど、今をトップで生きている（生き残っている）企業がこうなのだ、という事を知っておくと良いかもしれない。
Posted by ブクログ
出版された年から数年経っているので少し内容が古いかと思っていたが、そういったことを感じさせない内容だった。
間でところどころに事例も入っていて、AgileとDevOpsとCI/CDの関係性もこの本を通じてクリアになった。
職場においてDevOpsは部分的には実践されているが、この書籍の内容をベースに改めて改善可能な点を探したくなるような一冊だった。
チームで共通の理解にしたいと思える。
Posted by ブクログ
2017年発行だけど、既に少し古くなってきている。
アジャイルが前提なのか、関連をもっと書いて欲しいなぁ。
第1の道、フローの原則（可視化、WIP、バッチサイズ…）
第2の道、フィードバックの原則（行燈？）
第3の道、継続的な学習と実験の原則（レトロスペクティブ、ポストモーテム…）
をベースに全体を構成。
最後の部で、セキュリティや変更管理、コンプライアンスに触れている、これら重要そうだけど大きな企業しか関係ない？やるとなるとアジャイルやDevOpsのやり方的に大変そう。
Posted by ブクログ
読みにくい本だ…。それほど目からウロコでもないような話題をタラタラタラタラ、翻訳書独特のの長ったらしい文章で説明し、「章タイトルは【最初に手をつけるバリューストリームの選択方法】なんだけど、バリューストリームのカテゴリの話ばかりして選択方法の話が出てこないぞ…」こんなのばっかりで、「これ何の話だったっけ？」と戻り読みすることが多くなかなか先へ進まない。
理想はそうなんだけどさー、どうやって実現にこぎつけりゃいいのよ？ケーススタディとやらも「日常業務の一部として問題を見つけ、修正していくことで、技術的に負債をマネジメントしていった」みたいな抽象的記述ばっかりで、いやいやクソ忙してくてそれどころじゃない職場で具体的にどうやってそれ進めたのか知りたいんだけど、という気持ちになりイライラして読むのが止まる。全然先に進まない。
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に実施される同じタイプのエラーのリハーサルなどがある。
