Microsoft Architect Forum 2013

10 年前から始まったマイクロソフトの DevOps

～今とこれから～

日本マイクロソフトエバンジェリスト

高添 修・長沢 智治

Agenda

正しいアーキテクチャの重要性は誰もが知るところただし、どんなアーキテクチャであってもやるべきことがある

Merc. Stage ShuttleJob

Cache

HTTP

SQLFeed Store DSS

FTP

Dynamic Systems Initiative (2003.05)

必要なリソース

運用ポリシー運用特性

既存、あるいは新しいシステムのモデルを作成

モデルに則したシステム運用

モデルに則した自動的なリソース確保とシステム構成

ストレージサーバー ネットワークITライフサイクルをつなぐ共通定義モデル

Oslo (2007.10)

dc.exe

*.csdl*.ssdl*.msl

…

Export

Compile

*.d

*.sql

Visual Studio Quadrant

Repository

• XAML (WF, WPF, …)• SML / CML• WSDL• …

Converters

• CLR Metadata• Active Directory• WMI / WS-Man• …

Loaders

• Oslo Process Server• System Center DCM• Visual Studio TFS• SharePoint• RedDog• …

Runtimes

Models

“F5”

Instances &Observations

• SAP• MQ• …

Adapters

ビジネスと IT ビジネスのトレンド

クラウド時代の到来利用者への直接的な貢献

IT の戦略的な役割

戦略的な IT への変化1990年代

Business

IT

Business

IT Business

IT

便利 有効 不可欠Cost Center Key Infrastructure Morphing IT

確立したビジネスモデル 全体計画→全体リリース 技術的な意思決定はIT 部門

ビジネスモデルにIT が関与

ニーズに応じたリリース 技術的な方向性は

経営者層へ

ビジネスを IT がけん引 ジャスト イン タイム IT 計画と投資は、

顧客中心に

2000年代 2010年代

クライアント/サーバー Web / Web サービス デバイスとサービス

DevOps: ビジネスにフォーカス

Defineビジネス価値の創発

Developアイデアを動くソフトウェアへ

Operateソフトウェアをビジネス価値として提供

要求

運用開発

動くソフトウェア

DevOps: バリアによる損失

Defineビジネス価値の創発

Developアイデアを動くソフトウェアへ

Operateソフトウェアをビジネス価値として提供

要求

運用開発

動くソフトウェア

| |

DevOps: 継続的に価値を提供

Defineビジネス価値の創発

Developアイデアを動くソフトウェアへ

Operateソフトウェアをビジネス価値として提供

要求

運用開発

動くソフトウェア

高い透明性 | 価値の流れ | ムダ取り

継続的フィードバック | 継続的品質 | 継続的デリバリー

DevOps: 課題要求

運用開発

動くソフトウェア

運用が欠如した受け入れ基準

技術的負債の蓄積

運用を考慮した設計の欠如

長い開発とテストの仕掛かり

運用準備が整わないソフトウェア

長いデプロイの仕掛かり 開発と運用のワークフローの相違と分離

本番稼働中の障害への対応

デバッグが困難な本番環境での対応

実行可能なフィードバックの欠如による MTTR の長期化

価値との相関関係が不明瞭

DevOps: Operation Readiness 開発における運用への備えを

Problem

Solution

Value

運用要件を満たしていないソフトウェア 最終的な段階での阻害要因となる

本番稼働時に情報収集が困難となる害要因になる

早期の要求獲得と品質の作りこみ 運用の受け入れ駆動開発 (ATDD), ラボによる自動化

継続的インテグレーション, 継続的デプロイメント害要因になる

ビジネス価値に到達するソフトウェアへ ソフトウェアをビジネス価値として提供する

サイクルタイムを短縮できる

DevOps: Operation Readiness 開発における運用への備えを

要求

運用要件(ログ/QoS)

開発

テスト

疑似本番環境でのテスト

運用要件含めた品質の作りこみ

継続的な開発とテスト

DevOps: Just-in-Time Delivery 開発のアジリティと継続的カイゼンへ

Problem

Solution

Value

顧客ニーズにアラインできない開発サイクル ビジネス価値の提供が不定期となり、ユーザーの期待に応えられない

開発サイクルが定まらず、品質とデリバリーがビジネスに合わない害要因になる

アジャイルプラクティスとカイゼン スクラムのフレームワークによる「検査と適応」

継続的にフィードバックを得る仕組みと体質づくり害要因になる

ビジネス価値に到達するソフトウェアへ 適切なビジネス価値を定期的に提供し続ける

サイクルタイムの短縮と QCDS のバランス調整ができる

DevOps: Just-in-Time Delivery 開発のアジリティと継続的カイゼンへ

PRIORITIZE PLAN EXECUTE RESPOND

スプリント(2週間)

デイリースクラム

プロダクトオーナー チーム

スクラムマスター

DevOps: Mean time to Repair 本番稼働中の対応の最適化へ

Problem

Solution

Value

運用中の障害検出と解決が極めて困難 高い MTTR によるビジネス価値への浸食

継続的なフィードバックへの阻害になる

本番稼働環境でも開発プラクティスを実践 本番環境相当でのテストの継続的な実施 (仮想テスト環境)

統合されたインシデント管理, 本番環境でのデバッグの実践害要因になる

MTTR の短縮 ソフトウェアをビジネス価値として提供し続ける

サイクルタイムを短縮できる

DevOps: Mean time to Repair 開発における運用への備えを 運用の問題解決フロー

開発 運用

問題検知

改修依頼

情報提供

解決確認

問題受入

分析調査

改修

問題解決

開発の問題解決フロー

問題解決

継続的な流れを生む仕組みへ継続的運用テスト

継続的フィードバック

継続的デプロイメント

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

“MTTR 短縮” のためのアプリ監視

アラート

動作パターン識別

より詳細な情報

監視から開発のアサイン

開発のアサイン

Visual Studio から確認したところ

Ops & Dev Tool のアラート連携

Web テストと世界から自動監視

Visual Studio にてテスト定義ファイル

.webtest の保存

世界中にあるマイクロソフトの

データセンターから監視

レスポンスだけ見てもこんなに違いが !

Operations Manager

Global Service Monitor

ビルドとアプリ管理の自動化

TFS 連携による開発環境管理の

自動化

Orchestrator

Integration Pack

Orchestrator へのインプット

Orchestrator から受け取り

実際の業務処理(普通のコード)

自動プロセスへ

開発とテスト環境の構築

開発環境用のプライベートクラウドを

自動構築

リソースの解放と制限

開発者用のツールから仮想マシンを管理

※ スナップショットも

Virtual Machine

Manager

Microsoft Architect Forum 2013

ビジネスのための IT には必須

できていないのであれば、ぜひともご検討を

Microsoft Architect Forum 2013

Resources概念とソリューションについて

Enterprise DevOps ホワイトペーパー (英語)

http://aka.ms/EntDevOpsWp

ソフトウェア開発環境の最新動向と出張セミナー http://aka.ms/ALMjp

マイクロソフト製品による実現方法について

Integrating Operations Manager with Development Processes (DevOps) Topics

http://technet.microsoft.com/ja-jp/library/jj614609.aspx

How to Synchronize Alerts with TFS in System Center 2012 SP1

http://technet.microsoft.com/ja-jp/library/jj614615.aspx