DevOpsハンドブックつまみ読み

真面目にDevOpsを学びたくなりバイブルとして知人に紹介してもらったDevOpsハンドブックと、その概念を具体的なストーリーに当てはめたフェニックスプロジェクトを読んで感銘を受けたのでここで紹介したいと思います。

全体的には何か目新しいことがあるわけではない（2016年8月に書かれた本なのでそりゃそうだ）のですが、体系的にまとまっているし、事例も多数あって網羅的な内容になっています。しかし、読みやすくはないのでじっくり腰を据えて読む必要がある本です。ということで自身の理解を深めるためにかいつまんでまとめてみたという動機もあります。

補足

• 🐮マークは私が腑に落ちていなかったり、勝手な解釈をしたところ
• 章見出しのセンテンスは適当に省略しているところもあります

第一部 3つの道

この第一部ではDevOpsの骨子である3つの道の触りを紹介して導入しています。

第1章 アジャイル、継続的デリバリー、そして第3の道

• ITバリューストリーム = ビジネス仮設の立案からそれが本番にリリースされるまでのプロセス
• DevOpsはデプロイリードタイムを短くすることにこだわる
  • リードタイム、プロセスタイム
    • 工程の開始から終了までがリードタイム
    • プロセスタイムは正味の作業時間
• %C/A率 = 手戻りの指標。高ければ高いほど後ろの工程に迷惑をかけていない

第2章　第1の道：フローの原則

• カンバンによるユーザーストーリーの状況の見える化
  • 列を「ワークセンター」と表現している
  • 左（上流）から右（下流）へ流れて右端に到着したら完了
• WIP制限
  • 同時にいろいろなやりかけ（仕掛り）を抱えてはいけない
  • マルチタスク数を制限する（🐮理想は１個流し）
    • 仕掛りが増えるということはワークセンター間でのキュー滞留時間が増える
      • 極端な話30分の作業時間のものが1週間待ちキューで滞留する
• バッチサイズの縮小
  • ユーザーストーリーのサイズが大きいほどWIPが増える
  • 小さなバッチサイズはリードタイムが短く、エラーの発見が早い
    • １週間かけてようやく出てきたものにエラーが見つかるよりも10分の作業でエラーが見つかるほうがいい
• 受け渡し数の制限
  • チームをまたぐと色々面倒
    • チームごとに待ちキューに入れられてリードタイムが延びる
    • 受け渡し時のコミュニケーションロス、勘違いが発生しがち
  • 🐮いわゆる多能工を推奨
• ボトルネックを見つける
  • ボトルネックの手前を効率化してもボトルネックで待たされるものが増えるだけ
  • ボトルネックの後ろを効率化しても詰まってなかなか流れてこないだけ
  • よくあるボトルネック集
    • テスト環境をつくったりするのに環境準備に時間がかかる
    • デプロイするのにやたらと時間がかかる
    • テストの下準備にやたらと時間がかかる
    • アーキテクチャが密結合でちょっとした修正に周辺の承認が必要
• ITバリューストリーム中の無駄
  • 仕掛り仕事
  • 下流で全く使われないドキュメント、誰にも使われない処理
  • 作業者のコンテキストスイッチ
  • 手待ち
  • 受け渡しによるコミュニケーションロス
  • 不良作業による手戻り
  • 非標準的なアドホック作業
  • 個人やチームが無理しければできない努力

第3章 第2の道：フィードバックの原則

• 複雑なシステムを見通して設計するのは無理
  • 🐮ウォーターフォールに対するアンチ？
• そんなものを安全に扱っていくには、
  • 設計や運用の問題が見つかるような管理の仕方（見つけるのが大事）
    • 素早くフィードバックを得る => 何ヶ月も何年もあとにフィードバックを得ても対処が難しい
    • モニタリングしてエラーを見つけられる仕組み
  • 問題が発生したときに組織一丸で新しい学びを得る
    • トヨタのアンドン
      • 問題が起きたらラインを止めて組織を挙げて問題解決に取り組む
      • 問題が起きているまま下流に流すと余計に被害が大きくなる
        • だから早い段階でフィードバックを得たい
  • 組織の一部が獲得した学びを全体に波及させる
  • これらを継続的に成長させる、そんなことができるリーダーを育てる
• 下流に品質の悪いものを流さない
  • ITの世界では下流は運用を指す
  • 運用できない・しづらいものはあとからしっぺ返しがくる
    • それならばアンドンの紐を引いて流すのを止めるべき

第4章 第3の道:継続的な学習と実験の原則

• 変化する環境に素早く自動的に適応する能力を身につけるのが目的
• 日常的な予防策に頼らず日常業務を改善する
  • 🐮ちょっとよくわからない 。一人ひとりが注意します的なやり方はだめだということ？
  • 作業システムを「安全」にせよ、ともある
• 個人の発見や経験を集合知に変える
  • 🐮形式化ということか？
• アンチフラジャイル
  • たまにあえて高負荷にしてどこが破綻するかを見つける
• リーダーの役割は「メンバーたちが日常業務で発見すること」を手伝う、そんな環境を整える
  • 問題発見、解決はメンバー主体
  • リーダーはそれを支える

第2部 スタートのための糸口

第2部では手をつけるためのアクションを説明しています。

第5章 最初に何に手を付けるか

• これといった定石はないが、考え方が紹介されている
  • グリーンフィールド、ブラウンフィールド
    • グリーンは新規案件、ブラウンは保守案件といったところ
    • グリーンはしがらみがないので適用しやすいが、実際に効果が上がりやすいのはブラウン
  • SoEとSoR
    • 「正しく実行すること」「早く実行すること」は二律背反
    • だが、DevOpsは両立する -> 🐮まじか
  • アーリーアダプターを巻き込む
  • サイレントマジョリティを増やす

第6章 バリューストリームを可視化

• バリューストリームの登場人物を明らかにする
• バリューストリームマップで可視化する
• 専任の変革チーム
• 6ヶ月〜2年の間に達成する目標をつくる
• 変革も2週間程度のイテレーションで進めていく
  • 中長期目標を短期目標に置き換え
  • フィードバックループ
• チームは改革のために20%程度を費やす
  • 負債の返済である。返済をしないと負債はどんどん膨らんでいくばかり。
• 目標に向かって前進しているか見える化する
• 運用と開発で共通のツールを使う

第7章 Conwayの法則を念頭に置いた組織とアーキテクチャ

• 組織の形は3種類の基本タイプ
  • 職能指向（開発、運用、企画、営業）
    • コスト重視
    • 専門性を育てるには良い
    • 過度に職能指向になると上述の「受け渡し」が増える問題
      • スペシャリストが乱立し、それぞれの部門が主権国家になる（サイロ化）
      • 国家間での「受け渡し」問題
    • しかしトヨタは職能指向組織
      • 組織構造よりも人の行動様式のほうが大切
      • 高信頼マネジメントの企業文化
      • 社員の能力と習慣を鍛えて育てた
  • 市場指向（サービスA,サービスB,...)
    • 職能横断的
    • 「受け渡し」が少ないメリット
    • スピード重視
  • マトリクス指向
    • 二兎を追うものは…的な
    • 上司が複数になって困ることも
• ITアウトソーシングはコストを固定化する管理戦略だが、変化するビジネスとITのニーズに反応できなくなる
• ジェネラリストを増やす
  • スペシャリストばかりだと独立国家間「受け渡し」ロス
  • 複数の分野を学ぶことは社員の成長にとっても良いこと
  • 新しいスキルを獲得して活かしていくことを評価すべき
• プロジェクト->出来上がったら解散 はマズイ
  • 開発者は長期的な結果のフィードバックを得ることができない
    • 🐮できた気になっているが受け取った運用が人知れず苦労しているパターン
  • ソフトウェアの長いライフサイクルからすると開発は最も金がかからない最初のステージ
    • 新規アプリケーションはただでもらった子犬の・ようなもの -> もらったあとの方がカネがかかる
• 開発プロジェクト単体で評価するのもマズイ
  • 納期、開発範囲だけを評価しても不十分
  • その後の運用コストや、顧客から得た収益などトータルで評価すべき
• コミュニケーションコストが最小になるようにチームを分ける
  • 変なところで線を引くと「受け渡し」問題に悩む
• 疎結合なアーキテクチャ
  • 密結合は変更影響がお隣に波及しやすい => お隣さんとの調整がいちいち必要
    • 🐮現場では疎結合であってもなんか不安になってインテグレーションテストせざるを得ないことは多い
    • 🐮真なる疎結合じゃないのかな？
  • お隣を気にせずに独立してガンガンデプロイできるのが理想
    • 🐮マイクロサービスへの導線だろう
    • DDDのBounded Contextに示されるうまい線の引き方
      • 🐮これが難しいんだよ！
• うまく分割された独立単位に小さなチーム(2ピザチーム）

第8章 開発の日常業務に運用を統合して成果を出す

• 運用部門は開発チームのための共通プラットフォームを作る
  • 依頼ベースではなく開発者たちがオンデマンドで使えるようなものであるべき
    • 「セルフでプラットフォームを利用できなければクラウドはただのホスティング2.0」
      • 🐮日本のベンダーが提供したクラウドはだいたいコレ（インスタンス増減に申請書出す的なヤツ）だったな
  • 🐮好き勝手にやられたものをあとから受け取るよりも先手を打って自分の土俵に乗せろということか
  • とはいえプラットフォームチームは開発者たちのニーズを掴んでプラットフォームというプロダクトを開発する必要がある
    • 🐮独りよがりのクソプラットフォームは嫌がられるだけ
    • 🐮フレームワーク全盛期にオレオレフレームワークを作るも誰にも使ってもらえない現場をよく見た
    • 🐮片手間でやると開発者たちのニーズに追従するスピードが出ないので、やるならフルコミットでやらんと成立しないだろう
    • プラットフォームチームは競合分析と対策をすべし
      • 🐮行き着く先が車輪の再開発になったりしないのか？
• ゼロから作るよりも成功している現場から育てる
  • うまく行っているところのツールチェーンを持ち上げる
  • 絶えずチーム横断でどんなツールチェーンが使われているかに目を光らせる
    • 🐮警察として取り締まるわけではない
    • 良さげなものがあったら持ち上げて、洗練させ、全社に展開する
• サービスチームに運用を配置する
  • （運用者が）顧客との接点が増えビジネス目標を意識するようになる
  • 従来の運用部門は人が作った列車を運行するだけ
  • DevOpsの運用は列車作りを助けたり、必要なら列車が通過する橋を作ったりもする
  • 運用の知識をサービスチームに伝播させ、それを自動化コードにする
  • 人数的にアサインできないときはコンサルタント的にアサインする
    • 運用もサービスのコンテキストを知る必要がある
      • どんな機能を何故作っているのか
      • 非機能要件（可用性、スケーラビリティ、可観測性など）
      • ビジネスメトリクス
  • スタンドアップミーティングに参加してリリース時期などの計画を頭に入れる
  • レトロスペクティブに参加して運用観点で意見する
  • 運用の仕事もカンバンで共有する

思ったよりも長くなった

このあと第3部〜第5部でそれぞれの道の実践方法について述べられています。
そして最後はITILとの関連を整理しています。

それらについてはまた次回別のエントリとして書きたいと思いますので今回はこの辺りで。