日本で DevOps をロケットスタートする方法

牛尾　剛

マイクロソフト　コーポレーションシニアテクニカルエバンジェリスト DevOps

牛尾　剛 | @sandayuuDevOps シニア テクニカル エバンジェリストDevOps/ アジャイルの組織導入 15+ 年インターナショナルチーム文化技術・英語勉強系コミュニティ著者　オブジェクト脳、英語勉強法ヴォーカリスト1994 年 IT 業界へ、 2015 年マイクロソフト入社 DX DevOps Technical Working Group グローバル チームメンバDevOps ハッカソン国内外カンファレンスでの講演経験も多数http://blogs.technet.com/b/livedevopsinjapan/Live DevOps in Japan　ブログ、 DevOps インタビュー（日・英） Channel 9 動画（日・英） メソッド屋のブログ （生産性と文化）

https://channel9.msdn.com/Blogs/livedevopsinjapan/http://simplearchitect.hatenablog.com/

Team DevOps – David Tesar and Me

日本でも本当に DevOps で劇的効果が出ることを

実感してもらいたい

ざっとわかる DevOps

DevOps とは、人・プロセス・プロダクトの集合体で継続的にエンドユーザに価値を提供することである

2 プロセス 3 プロダクト1 人

DEV OPS

- Donovan Brown

DevOps とは、人・プロセス・プロダクトの集合体で、継続的にエンドユーザに価値を提供することである

2 プロセス 3 プロダクト1 人

DEV OPS

- Donovan Brown

10 デプロイ／日も可能に

DevOps のメリット

出典 : https://puppetlabs.com/

コードのデプロイ速度30 倍リードタイム 1 / 200エラー 1 / 60

エラーからの復旧 168 倍

標準的な DevOps のビュー (aka Gene Kim’s “Three Ways”)

DevelopmentBusiness

OperationsCustomer

1 way : リードタイムの短縮

【 DevOps Enterprise 2015 参加レポート】第 2 回 – Docker による DevOps ソフトウェアサプライチェーンの改善 http://blogs.technet.com/b/livedevopsinjapan/archive/2015/11/13/devops-enterprise-2015-2.aspx

2 way : 本番環境 / ユーザからのフィードバック3 way : 継続的な実験と学び

DevOps プラクティスの一覧

• Infrastructure as Code (IaC)• 継続的インテグレーション• 自動テスト• 継続的デプロイ• リリースマネジメント• アプリ パフォーマンスの監視• ロード テストと自動スケーリング

• 可用性監視• 変更 / 構成管理• 機能フラグ（フューチャーフラグ）• 環境へのプロビジョニングの自動解除• セルフサービス環境• 自動回復 ( ロールバックとロールフォワー

ド )• 仮説に基づく開発

• 運用環境でのテスト• フォールトインジェクション• 使用状況監視 / ユーザー テレメトリ

http://www.itproguy.com/devops-practices/

サブプラクティス主要なプラクティス

DevOps StoryT H E

M I C R O S O FT

マイクロソフトのチーム構成

初めの状態

QA Dev Ops ビジネス企画

マイクロソフトのチーム構成

Dev + QA = エンジニアリングチーム

エンジニアリング Ops ビジネス企画

マイクロソフトのチーム構成エンジニアリング + Ops + ビジネス企画= サービスチーム

サービスチーム(Feature team)

マイクロソフトのチーム構成

顧客との直接のコラボレーション

サービスチーム(Feature team)

顧客

INNOVATION

BuildMeasure

Learn

DevOps の始め方と具体的テクニック

日本向け DevOps 導入ステップ

1. DevOps プレゼンテーション＆デモ

2. Value Stream Mapping3. 文化とギャップ要素のインストール

4. DevOps ハックフェスト

5. モニタリングと継続的改善

Value Stream Mappingリードタイムに関係するプロセスの可視化と共有、課題の共有

Value Stream Map の例

Value Stream Mapping の「無駄」無駄の種類 マーク 定義 例

欠陥の無駄(Defects)

D 誤った、抜けのある、不透明な情報や成果物。システムを破壊し、解決するのに時間と労力が必要

壊れたビルド、不正確な設定、不正確な要求

マニュアル / モーション(Manual / Motion, Handoffs)

M オーバーヘッド、コーディネーション、作業引き渡し、もしくはセットアップや、仕事の実行に関する非効率性

ミーティング、手動デプロイ、チーム間の作業引き渡し

待ちの無駄(Waiting)

W 次の価値のあるステップを開始、もしくは終了することの遅れ

承認待ち、リソースの待ち、予定されたミーティング待ち

未完了の作業(Partially Done)

PD 未完了の作業、何らかの操作。他者からの入力やアクションが必要となる。欠陥とタスク切替、待ちを招く

デプロイされていないコード、不完全な環境設定、実行中バッチ

タスクの切り替え(Task Switching)

TS タスクの切り替えは、高価なコンテキストスイッチを招き、エラーが発生しやすくなる

進捗上限による無駄作業、障害による中断、アドホックなリクエスト

余分なプロセス(Extra Process)

EP 価値のないステップやプロセス。大抵、公式、非公式な標準作業に含まれる

不要な承認、不要なドキュメント、無駄なレビュー

余分な機能(Extra Feature)

EF 機能、たいていは実装フェーズで追加されたもの。リクエストされていない、ビジネスに沿っていない、顧客価値がない

“ 次に必要かもしれない”、不要なアップデートや要求、望んでいない

ヒーローまたはヒロイン(Heroics)

H 仕事を完了させる、もしくは顧客を満足させるために、ある人に大変な負荷がかかっている状態。ボトルネック

数日必要なデプロイ、長年の知識が必要、極端な調整が必要

文化の違いによる Agile 導入難度Agile / DevOps の日本導入はそのままでは難しい Agile 導入

難度権力の差(PDI)

個人の自立(IDV)

男性社会(MAS)

不確実性忌避(UAI)

長期指向(LTO)

日本 80 54 46 95 92 80フランス 66 68 71 43 86

イタリア 65 50 76 70 75

アメリカ 49 40 91 62 46 29

イギリス 45 35 89 66 35 25

ドイツ 55 35 67 66 65 31

http://www.clearlycultural.com/geert-hofstede-cultural-dimensions/power-distance-index/Alistair Cockburn Twitter: https://twitter.com/TotherAlistair/status/731591878777417729

DevOps は 西洋文化の上に成り立っている「文化」をインストールすれば良い

DevOps

Agile西洋文化

日本文化

インターナショナルチームでの気づき

意思決定・ゴールに無理がなくロジカル。

物事を高速にこなしているのではなく、同じ価値に対する物量が少ない。

お客様のやりたいことが明確で、やり取りも物量も少ない。

バカバカしい質問でも気軽に質問する

あるがままの自分を受け入れてもらえて「常識」が存在しない。

KPI があるのみで、あとは自分で考える。上下関係・指示・承認がほぼ無い。

「楽しんでいるか？」が最も重視される。

米国と比較した日本の単位時間当たりの生産性比較

米国　 100%日本の生産性の動向 2015 年版　 http://www.jpc-net.jp/annual_trend/

日本　 62%

対

インターナショナルチームの生産性の秘密

物量が違う

Be Lazy

Drew Robbins

Be Lazyより少ない時間で、成果を最大化する

非エッセンシャル思考 エッセンシャル 思考

世の中のほとんどのことは「ノイズ」である

書籍「エッセンシャル思考」より

行動 やることをでたらめに増やす　・差し迫ったものからやる　・反射的に「やります」　・期限が迫ると根性で頑張る

やることを計画的に減らす　・本当に重要なことを見極める　・大事なこと以外は断る　・あらかじめ障害を取り除いておく結果 無力感

　・何もかも中途半端　・振り回されている　・何かがおかしい　・疲れ切っている

充実感　・質の高い仕事ができる　・コントロールしている　・正しいことをやっている　・毎日を楽しんでいる

考え方 みんな・すべて　・やらなくては　・どれも大事だ　・全部こなす方法は？

より少なく、しかしより良く　・これをやろう　・大事なことは少ない　・何を捨てるべきか？

Ask for Help

Aleks, Julien, and Damien

Karadamedicaチーム /PO/UCD 自ら考え、協力し行動して成果を出す文化に

詳細は Agile Japan で発表します！

VSM ・自動化でリードタイム 13 日が 3 日に MS 技術フル活用！

文化インストールの詳細に関してはこちらメソッド屋のブログ

http://simplearchitect.hatenablog.com/

ソフトウェア生産性の向上と、インターナショナル文化とDevOps の考え方に関するブログ

DevOps 導入ギャップ要素のインストール

アジャイル開発の実施

上位マネージメント / 関係者の巻き込み

イケてるベンダ / アジャイルコーチの選定

アジャイルプロジェクトの自動テスト率

32%27%

テストをある程度ちゃんと書けているアジャイルプロジェクトの割合

37%11% 48%

テスト駆動開発

RED

GREEN

REFACTOR

TDD

1. 失敗するテストを書く

3. 重複を無くす

2. コードを動くようにする

http://labs.nintex.com/code-dojo-test-driven-development/

テスト駆動開発を知る

https://channel9.msdn.com/Blogs/livedevopsinjapan/6min-DevOps-10

6 Minutes DevOps：テスト駆動開発

DevOps ハックフェストエキスパートと一緒に自動化するハッカソン実施

定期的に実施し、 DevOps Dojo として、いつでも学べる場にするのもよい

ハックフェスト in Microsoft ペアプログラミング

モニタリングと継続的改善定期的にリードタイム等の改善状況を共有する

Demo day 記念撮影

初公開 国内 DevOps 実践事例とその成果

NEC Solution Innovators

Docker / Compose / Terraform / Serf + VSTS / Azure を用いたハイブリッドクラウドストーリ

「今まで、 1990 年代の開発だったのが、 2017 年の開発をしている気分です」 - 福井様

エンプラ文化を変革　リードタイム 8.5 カ月 ->1週間に

最新 DevOps プラクティスの実現デモ

計画1 監視 + 学習

リリース開発 + テスト

2

開発 運用

DevOps4

3

コードの記述

単体テスト

2

ビルド

バージョン管理

ビルドの検証

リリース

開発者が反復作業を開始して、機能にアイデアを実装する

開発 + テスト

ソース ビルド

継続的インテグレーション

バリュー• デリバリの迅速化• 再利用性 • リソースの最適化

測定指標• デプロイメントのリード タイム• MTTR• MTTD

cspkg

テスト

DEV OPS

クラウド ロード テスト

統合テスト環境

自動化された機能テスト環境

3

運用前環境

ステージング環境

監視 + 学習

すべてのテストに合格したら、ビルドをテスト環境にデプロイし、

リリース プロセスの各ステージでテストを行う

リリース

ソース リポジトリ 開発

リリース管理

バリュー• リソースの最適化• デリバリの迅速化

測定指標• デプロイの頻度• MTTR• 可用性

ステージング

運用DEV OPS

Continuous IntegrationRelease ManagementTsuyoshi Ushio

デモ環境

ビルドの作成とPublish

リリースマネジメント環境毎に負荷テスト、

デプロイ

Azure WebAppsにデプロイ

Visual Studio Team Service で既に作成された Build を、ステージング・本番等の環境にリリースするのを自動化する

ユーザーがどのようにアプリを使用するか、どのようにアプリが応答するか、

問題やバグの修正にどのくらい時間がかかるかを把握する

監視 + 学習

4

監視

フィードバック

次の反復作業を計画

Feature flags andMonitoring

Tsuyoshi Ushio

運用環境でのテスト

バリュー• 実験が可能• 回復力の強化• デリバリの迅速化

測定指標• デプロイ率• MTTR• 可用性• 変更のリード タイム

運用環境 B

運用環境 A

90%

10%

デモ環境

フィーチャフラグの組み込み

特定ユーザへ特定機能の公開

A/B テスト

本番の結果から学習する

Launch Darky を使って、特定機能を、特定ユーザにのみリリース / ロールバックする。また、結果の効果測定をする

DevOps プラクティスの一覧

• Infrastructure as Code (IaC)• 継続的インテグレーション• 自動テスト• 継続的デプロイ• リリースマネジメント• アプリ パフォーマンスの監視• ロード テストと自動スケーリング

• 可用性監視• 変更 / 構成管理• 機能フラグ（フューチャーフラグ）• 環境へのプロビジョニングの自動解除• セルフサービス環境• 自動回復 ( ロールバックとロールフォワー

ド )• 仮説に基づく開発

• 運用環境でのテスト• フォールトインジェクション• 使用状況監視 / ユーザー テレメトリ

http://www.itproguy.com/devops-practices/

サブプラクティス主要なプラクティス

日本でも本当に DevOps が劇的効果が出ることを

実感してもらいたい

Be Lazy で考えてみた

DevOps スタータキットを公開

「メソッド屋のブログ」で今すぐ検索！

DevOps プラクティス紹介動画

プレゼンテーション資料

DevOps プラクティスをいつでも学べる