Skip to content

Instantly share code, notes, and snippets.

@miyajan
Last active October 16, 2017 15:59
Show Gist options
  • Save miyajan/65de57460355428f0fcc495e34eaf4f0 to your computer and use it in GitHub Desktop.
Save miyajan/65de57460355428f0fcc495e34eaf4f0 to your computer and use it in GitHub Desktop.
The DevOps ハンドブック

バリューストリーム

  • リーンの基本概念の1つ
  • 「企業が顧客の要求に応えるために着手する一連の活動」
  • 「顧客に届ける商品やサービスを設計、生産し、送り届けるために必要な一連の活動で、情報と素材の双方向的なフローを含む」
    • Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation
  • どのバリューストリームでも高速で予測可能なリードタイムを実現するためには、以下のテクニックが重要
    • 小さなバッチサイズ
    • WIPの削減
    • 下流のワークセンターに不良品を渡さないことによる手戻りの防止
    • 大きな目標に近づくためのシステムの絶え間ない改善

ITバリューストリーム

  • 「ビジネス上の仮説を立案してから、顧客に価値を送り届ける技術サービスを生み出すまでの間に必要なプロセス」
  • 価値が生み出されるのは、サービスが本番環境で実行されてからなので、ただ単に高速なフローを提供するだけでなく、以下のような混乱や停滞を引き起こさずにデプロイを実施できることが求められる
    • サービスのアウテージ(システム停止)
    • 部分的な障害
    • セキュリティエラー
    • コンプライアンス問題

デプロイリードタイム

  • バリューストリームのサブセット
  • 変更をバージョン管理システムにチェックインしたときに始まり、その変更が本番環境での稼働に成功し、顧客に価値を提供して役に立つフィードバックや遠隔測定データを生成するまで
    • 設計と開発
      • 可変性と不確実性が高い
      • 高度な創造性と再現できないような作業を必要とすることが多い
    • テストと運用
      • 創造性と専門能力が必要
      • 予測可能性と機械的な性質を追求し、可変性を最小限に抑えたアウトプットの生成(短くて予測可能なリードタイム、ほぼゼロの不良)を目標とする
  • 設計/開発と同時にテスト/運用を行い、高速なフローと高品質を実現することを目標とする
    • 小さなバッチサイズで仕事を進め、バリューストリームのあらゆる部分で品質を保証していくことが必要

リードタイムとプロセスタイム

  • リードタイムはチケット作成から作業完了まで
  • プロセスタイムは作業開始から作業完了まで
    • リードタイムと比較して、仕事がキューに滞留している時間が省略される
  • 顧客が感じる時間はリードタイムなので、プロセスの改善では、プロセスタイムではなく、リードタイムに注目する
    • しかし、リードタイムのなかでのプロセスタイムの割合は、作業効率の重要な指標

数ヶ月単位のデプロイリードタイム

  • 以下のような環境に多い
    • 大きくて複雑な組織
    • 密結合のモノリシックアプリケーション
    • インテグレーションテスト環境が貧弱
    • テストと本番環境までのリードタイムが長い
    • マニュアルテストが多い
    • 必要とされる承認プロセスが複数ある
  • 問題点
    • プロジェクトの最終段階ですべての変更を1つにまとめたときに、正しくビルドできなかったり、テストに合格しなかったり、使い物にならない場合がある
    • 問題の原因を特定して修正方法を見つけるのに数日から数週間かかる

%C/A

  • 完全正確率 (percent complete and accurate, %C/A)
    • バリューストリームの各ステップが出力するものの品質
    • 下流の顧客が「そのままの形で使える」仕事を受け取った割合

DevOpsとはなにか?

DevOpsの誤解

  • DevOpsはスタートアップだけにあてはまる
    • DevOpsを実践してきた開拓者は、Google、Amazon、Netflix、Etsyなど大企業
  • DevOpsはアジャイルを駆逐する
    • DevOpsの原則と実践はアジャイルと両立する
  • DevOpsはITILと両立しない
    • 両立する
  • DevOpsは情報セキュリティやコンプライアンスと両立しない
    • 伝統的な統制の手段は使わないが、すべてのステージの日常業務の中に組み込むことで両立する
  • DevOpsはIT運用の廃止、"NoOps"という意味だ
    • 性質は変わるかもしれないが重要な存在であり続け、開発は共同作業を行う
  • DevOpsは、単なる"Infrastructure As Code"あるいはオートメーションである
    • 自動化を必要とするが、文化的な規範やアーキテクチャも必要
    • 「天文学が望遠鏡ではないのと同じように、DevOpsはオートメーションではない」
  • DevOpsは、OSS専用だ
    • メインフレームだろうが成果を上げている

DevOpsのビジネスバリュー

  • 業績の高い組織は、機動性と信頼性がともに高い
    • コードと変更のデプロイを30倍頻繁に実施
    • コードと変更のデプロイリードタイムを200倍高速に実施
    • 本番デプロイの成功率が60倍高い
    • サービスを復旧するためにかかる平均的な時間が168倍高速
    • 生産性、マーケットシェア、利益性の目標達成する確率が2倍高い
    • 時価総額の増加が3年間で50%高い
  • これらの企業は、社員の仕事に対する満足度が高く、燃え尽きた社員の割合が低い
  • 自分の会社をすばらしい職場として友人に薦める割合も2.2倍になる
  • 情報セキュリティの成績もよい

DevOpsはデベロッパーの生産性向上に役立つ

  • 単純にデベロッパーを追加すると、個々のデベロッパーの生産性が下がるだけでなく、プロジェクト全体の生産性が下がる
    • 『人月の神話』より
  • 「DevOpsを採用している大企業は、数千人のデベロッパーを抱えていますが、小規模なチームがまるでスタートアップのようにとてつもなく生産的に仕事ができる」
    • Randy Shoup
  • DevOpsを採用している組織は、デベロッパーの数を増やすと、1日あたりのデプロイ数を線形に増やすことができる
    • 成績の低い企業では、むしろ下がる
    • 2015 State Of DevOps Report
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment