いつどこからでも改善 第四回「DevOpsに備えたプロセス自動化」

IT・IT製品TOP > Key Conductors > 岩村 郁雄(特定非営利活動法人itSMF Japan) > いつどこからでも改善 第四回「DevOpsに備えたプロセス自動化」
この記事をtweetする このエントリーをはてなブックマークに追加

IT現場の道先案内人 Key Conductors

いつどこからでも改善 第四回「DevOpsに備えたプロセス自動化」

開発 2013/03/01

ITILは英国The Minister for the Cabinet Officeの登録商標および共同体登録商標であって、米国特許商標庁にて登録されています。

「いつどこからでも改善」第一回では継続的サービス改善(CSI)の概念と活用の勘所をお伝えし、第二回ではサービスオペレーションを起点としたCSIの事例を、第三回ではサービスデザインとサービスストラテジのフェーズを起点としたCSIの事例について説明した。
「いつどこからでも改善」第四回は、「開発と運用の融合」と言われるDevOpsの波に対して、従来のIT運用のプロセスに求められる変化を明らかにし、その改善アプローチについて述べる。

従来のIT運用から見たDevOpsの特性と課題

DevOpsとは

DevOpsはDevelopment(開発)の「Dev」とOperation(運用)の「Ops」を結合した造語である。「Velocity 2009」イベントのFlickrの講演が昨今のDevOpsの原点と言われ、ネット企業でWebアプリケーションの運用ノウハウを共有する取組みから生まれた、開発チームと運用チームのコラボレーションのための方法論である。ガートナーの用語集※1によると、DevOpsは、次の特徴を持つ。
■多くの大手パブリック・クラウドのサービスプロバイダーが、初期段階でITサービス提供を俊敏に行う必要性から用いた手法
■人(と文化)を重視し、運用と開発チーム間のコラボレーションを改善する(アジャイルマニフェスト)
■より良い技術を利用しようと試みる。特に自動化ツールの技術は、一層のプログラマブルかつダイナミックなインフラストラクチャの利用を促進する
クラウドをシステム基盤とし、アジェイルを開発手法として用い、WebアプリケーションをベースとしたITサービスが、当面のDevOpsの適用対象として想定されているが、広義の解釈では、ビジネス環境の変化に対応して新しいサービスを迅速に市場投入するために、それを支えるITシステム構築の迅速化の取組みの一環としても広く注目されるようになってきている。

※1 Gartner IT Glossary - DevOps - http://www.gartner.com/it-glossary/devops/

開発方式による変更の特性比較

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図1 「変更要件の高まりと変更規模の大きさに関する開発手法による比較」

一方で、ITIL®に代表される従来のIT運用からDevOpsの方法論を読み解くと、どのような運用プロセスに影響をおよぼす可能性があるのかが予想できる。最初に本番環境でサービスが稼働し始めてから、時間の経過とともに幾多の変更要件が発生し、その変更を本番環境に適用しつつサービスを改善していくことはサービスのライフサイクルの観点で必然である。変更要件の高まりと変更規模の大きさは相関関係があり、要件を充足する機会が少ないほど、変更の規模は大きくなる。従来型の開発手法の代表としてウォーターフォール方式があるが、これは、変更要件をある程度の数、期間、工数で累積することで、比較的大きめの変更を数ヶ月〜年単位に実施する方式である。一方、DevOpsで用いられることの多いアジャイル方式は、変更要件を細かく実装する方式であり、小さな変更を日に何度も実施しているサービスも実在する。(図1)
この2つの開発手法と、その結果として起きる変更に関する特性の比較は次表のような傾向が見て取れる。(表1)

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

表1 「開発方式と変更に関する特性の比較」

DevOpsに対する従来のIT運用に想定される課題と対応する運用要件

従来のIT運用は主に、ウォーターフォール方式を対象とした各種管理プロセスを確立してきた。このため、アジャイル方式を中心としたDevOps型サービス実装の要件に対して、各種の課題が発生することが予想される。表1で述べた特性に沿って、想定される課題とそれに対応するための運用要件を述べる。

■課題1:規模やリスクは小さいが、実装期間が短く頻度が多いため、変更の影響評価が重荷になる

変更要件が発生してから実装までの期間が数日あるいは即日のように短くなり、また、日に数回といった頻度になることもあるため、変更要求※2の対応をスピードアップし、サイクルを短くする必要がある。
従来の変更管理プロセスで「通常の変更」と呼ばれる変更の場合、最初にRFCを起票し、優先度を付け、変更計画に組み入れられるかどうかを評価し承認する一連の影響評価手続きを実施する。アジャイル方式を前提とした規模やリスクが小さく、頻度が高い変更を「通常の変更」で承認しようとすると、いつも同じような影響評価を繰り返し行うことになり、評価作業が重荷になる可能性が高い。
これに対してITILでは、例えばユーザからのパスワードのリセットのような変更は、変更によってもたらされる影響が一定の範囲内であり、リスクも想定される範囲内と判断できるので、これらを「標準的な変更」と呼ばれる変更として事前に定義することが推奨されている。「標準的な変更」は、RFCの起票を不要とし、変更の承認も事前に済んでいる形式とすることができるので、変更の影響評価手続きを簡略化もしくは省略することができる。従来のIT運用の変更管理プロセスで、DevOps型サービス実装に必要される変更に対応するには、この「標準的な変更」の適用を促進することが不可欠である。

※2 変更要求:RFC(Request for Change)とも呼ばれ、変更実施を要求する際に要求部門が起票する。
■課題2:頻繁な展開とリリースが発生し、運用受け入れ要件の充足を確認できない

従来のIT運用における展開とリリースでは、展開により本番への影響が無いことを確認し、リリースにより変更、追加される運用手順について「運用受け入れ試験(UAT)」を実施し、運用部門が受け入れ可能であることを確認してからリリースを実施する。DevOpsで「デプロイ」と呼ばれる本番への展開は、従来のIT運用のUATのような一連の手続きを実施していると到底追いつくことのできない頻度で実施することが想定、期待されている。DevOps型サービス実装のデプロイは、変更の規模やリスクが小さいこともあり、基本的に従来のIT運用における運用手順に変更を及ぼすような変更にならないことが多い。このため、前述の「標準的な変更」の延長として、「標準的なデプロイ」といった種別の展開とリリース種別を定義し、本番投入に関する手続きを簡略化する必要がある。ただし、DevOps型サービス実装のデプロイが既存の運用手順に及ぼす影響の評価は、開発部門だけでは実施することはできないので、運用部門による新しい評価基準の策定とチェックが必須である。

■課題3:内部統制の視点

開発と管理の権限を分離することで適正な財務報告が可能となる。この内部統制の視点によると、開発と運用の連携を緊密にすることは適正な財務報告を阻害する要因になり兼ねない。この課題に対して、従来のIT運用におけるプラクティスが適用できる。すなわち前述のようなDevOps型サービス実装の要件を実現するために、変更管理プロセスと、リリース管理および展開管理プロセスを自動化、高度化し、従来どおり開発と本番稼働後の管理=運用を分離するアプローチを取ることができる。

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図2 「IIL® V3におけるDevOpsへの対象エリア」

このように、DevOpsに対する従来のIT運用に想定される課題と対応する運用要件を考察すると、従来のIT運用の現場で想定されるDevOpsへの対象エリアは、サービストランジションのライフサイクル・フェーズに色濃く現れている。(図2)
以下、サービストランジションを起点とした改善として、変更管理プロセスと、リリース管理および展開管理プロセスを自動化するための具体的なアプローチについて述べる。

変更プロセスの自動化 - 「標準的な変更」の適用促進 -

ITILの変更管理プロセスは、変更を実施したことでサービス品質が低下しないよう、ITコンポーネントを変更する際の一連の手順を定義することを推奨している。ビジネスへの影響、リスク、コストなどの要素により変更を以下の3つのタイプに分類し、それぞれのタイプごとに手順を定義して順守することをガイドしている。
 ■標準的な変更(Standard Change):事前承認済みの変更。RFC起票不要
 ■通常の変更(Normal Change):事前承認処理(必要に応じて変更諮問委員会)が必要な変更。RFC起票が必要
 ■緊急の変更(Emergency Change):緊急の承認会議(緊急変更諮問委員会)が必須の変更。RFC起票が必要

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図3 「ITIL変更管理プロセス」

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図4 「『変更の受け入れおよび分類』における標準的な変更」

図3は、変更管理プロセス全体のワークフローを表している。(出典:ITUP※3) この中の「変更の受け入れおよび分類」では、起票されたRFCを前述の3つの変更タイプを含めて大きく3つの手順に分岐して受け入れおよび分類している。(図4) 左側の分岐は、変更の基準となる「変更ポリシ」の許容範囲外であるために拒否される際の手順である。また、RFCが必要な「通常の変更」と「緊急の変更」は受け入れと分類の時点では同じ手順で処理され、右側の分岐で優先順位と影響評価が実施される。そして中央の分岐に記載された「標準的な変更」は、変更が自動的に許可され、図3に見られる変更の影響評価やスケジューリング、要求側との情報のやり取りなどの手順を飛び越えて一足飛びに「変更の実施の調整」の手順まで進められることが分かる。
DevOpsの頻繁な変更要件に対し、開発部門と運用部門が協議し事前承認を得た上で、日々の運用に影響がない変更は、「標準的な変更」と定義することができる。あるいは当初は一連の承認プロセスを実施する「通常の変更」で変更を実施し、影響範囲が限定でき、成功実績を積むことで、それを「標準的な変更」に移行することもできる。「通常の変更」を「標準的な変更」に順次移行することで、DevOps型サービス実装の変更要件を満たせるようになり、変更の成功率向上や迅速なビジネス要件への対応を促進する効果がある。

※3 ITUP (IBM Tivoli Unified Process): http://www-06.ibm.com/jp/press/2009/04/1501.html ITサービスマネジメントに関する各種情報をWebブラウザーで参照可能にしたITILに準拠した無償のIBM提供ツール
執筆者注:「サービスマネジメント導入支援ツール ITUP」でインターネット検索してください。

展開とリリースのプロセス自動化 - 技術の活用 -

※会員登録いただくと図をご覧いただけます。
会員登録はこちら(無料)

図5 「パッケージ展開手順の標準化・自動化候補」

変更管理プロセスにおいて「標準的な変更」を適用することで、変更手順の迅速化を図ることができるが、それと同時に、実際に変更を適用するためのパッケージ展開(デプロイメント)の実行を迅速化する必要がある。ITUPツールの「展開の実行」ワークフローでは、ITILの「リリース管理および展開管理」に準じて、対象CI※4の準備状況確認に始まり、展開後本番サービス立ちあげの直前で行う展開パッケージに対するアクセス権限の付与に至るまで、 一連の展開手順が定義されている。(図5)
こちらも変更管理プロセスのワークフローと同様に、確実な展開とリリースを目的として、段階を踏まえた展開の実行を行うように手順化されているが、次のようなテクノロジーを活用することで、DevOps型サービス実装における展開手順のいくつかを標準化、自動化することが可能となってきている。
■多数の展開対象へのパッケージ一斉自動展開技術(ソフトウェア自動配布)
■機能テスト、回帰テスト、負荷テストおよび統合テストを効率化するテスト仮想化、自動化技術
■CPU、メモリー、Disk、Network、OS、ミドルウェアなどを、ユーザがサービスカタログ形式で選択的に要求できるようにし、要求されたITリソースをオンデマンドで自動的に割り当てるプロビジョニング技術
■バックアップ、スナップショット、など、展開やリリース失敗時の即時ロールバックやリストア技術
DevOps型サービス実装では、パッケージ展開を類型化し反復して行う特性があるので、特に図5の太枠などは、前述のテクノロジーを活用して、手順を標準化、自動化し、成功率も頻度も高いパッケージ展開を実現することができる。
※4 CI(Configuration Item): 構成アイテム。ITサービスの提供のために管理する必要がある、あらゆるコンポーネントまたはその他のサービス資産 (出典:「ITIL®日本語版用語集、v1.0、2011 年10 月13 日」 http://www.itil-officialsite.com/nmsruntime/saveasdialog.aspx?lID=1222&sID=242 )

既存IT運用とDevOps - 今後の展望 -

ここまでで、DevOps型サービス実装に備えて従来のIT運用に期待される、変更管理プロセスとリリース管理および展開管理プロセスに関する自動化アプローチを述べた。実際には、DevOps型サービス実装と従来のIT運用との接点は、従来からの開発と運用の接点と同じ性質を持ち、ITILの「キャパシティ管理」、「構成管理」、「インシデント管理」、「問題管理」、「サービスレベル管理」などもDevOps型サービスの実装サイクルとスピードに対応した変革が求められることになる。
また、仮想アプライアンスのような「サービスを提供するインフラストラクチャとその上で稼働するアプリケーション、さらにその運用までも、あらかじめDevOps型サービス実装に最適化して1つのサービスとして提供するモデル」も登場している。これらのモデルによるサービス提供が従来のIT運用と完全に切り離して運用できるのであれば、当面は従来のIT運用とDevOps型サービスの運用を並存させる選択肢も考えられる。並存させる中、DevOps型サービスが成功実績を積み、既存サービスがDevOps型サービスへ移行することができるようになれば、従来のIT運用をDevOps型の新しいサービス提供モデルへ統合するアプローチが必至となるであろう。
しかし、サービス提供による価値創出のために、サービスを管理するプロセスの標準化、高度化、改善を継続的に実施することは、どのアプローチ、どのサービス実装手法においても不可欠であり、サービスマネジメントのベストプラクティス活用の機会は尽きない。

「いつどこからでも改善」 - まとめ -

本稿「いつどこからでも改善」は4回にわたり、サービスのライフサイクルを起点とした改善への取組みについて、いくつかの改善適用事例と参考になりそうなテクニック、アプローチを説明した。サービスマネジメントの課題に対し、ライフサイクルのどのフェーズで取り組むべき課題であるのかという側面から向きあうと、改善へのアプローチを確立しやすくなる。
次の機会があれば、今度はサービスマネジメントの4つの「P」と言われる、「人材」、「プロセス」、「ツール」、「パートナー」の要素面から各種課題に取り組むアプローチについて紹介してみたい。
本稿がITの運用管理に携わる方々の各種活動の一助となれば幸いである。

会員限定で「読者からのコメント」が読み書きできます! 「読者からのコメント」は会員限定の機能。会員登録を行い、ログインすると読者からのコメントが読み書きできるようになります。

会員登録(無料)・ログイン

Myリストへ 印刷用ページへ

この記事をtweetする このエントリーをはてなブックマークに追加


この寄稿記事に掲載している情報は、掲載日時点での情報となります。内容は変更となる場合がございますのでご了承下さい。また、「Key Conductors」の寄稿記事及び当該記事に寄せられたコメントについては、執筆者及びコメント投稿者の責任のもと掲載されているものであり、当社が、内容の最新性、真実性、合法性、安全性、適切性、有用性等を保証するものではありません。


30005931


IT・IT製品TOP > Key Conductors > 岩村 郁雄(特定非営利活動法人itSMF Japan) > いつどこからでも改善 第四回「DevOpsに備えたプロセス自動化」

このページの先頭へ

キーマンズネットとは
IBMサービスマネジメント・エバンリジェリスト。日本IBMシステムズ・エンジニアリング(株)にて、15年にわたりサービスマネジメントのためのシステム設計や構築、プロセス確立案件をリード。ITIL V2 ManagerおよびITIL V3 Expert資格を保有。

ページトップへ