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

序章 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のメリットを享受できる。デスマーチを減らして、優れた製品を開発する喜びを復活させてくれる。愛する人たちと過ごせない週末や休日を減らして、人間らしい勤務条件を作り出してくれる。生き残り、学び、繫栄し、顧客を喜ばせ、会社の成功を支えるために、チームが力を合わせられるようにしてくれる。続きを読む

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

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

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

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

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

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