【DevOpsが変える開発と運用[＃1]】 DevOpsは開発と運用の分離と対立するのか？
一時期は下火になっていましたが、ここ１、２年でDevOps（デブオプス）というキーワードが再び聞かれるようになってきたように思えます。このブログでも、５カ月前に関連するエントリーを投稿しています。
『DevOpsではなく、TechOpsでIT運用管理を変える』
http://blogs.itmedia.co.jp/infra/2013/04/tech-8307.html
ITmedia系列のTech Targetでは、DevOpsというキーワードをこんな言葉で紹介されていました。
『「DevOps」という言葉が注目を集めている。一言でいえば「Dev（開発担当者）とOps（運用担当者）が連携してサービスのリリースサイクルを速める」といった概念だ。この言葉が企業の関心を集める背景には市場競争の激化があるといわれている。』
http://techtarget.itmedia.co.jp/tt/news/1306/28/news05.html
この説明文を見る限りでは、昨今の加速するIT開発事情が背景にあるように読み取れます。たしかにガートナーのハイプサイクルによれば、2011年版の段階でクラウド関連技術における黎明期技術で登場しており、2012年版でもまだ黎明期に位置づけられていますね。
http://blog.discountasp.net/the-cloud-2012-gartner-hype-cycle-update/
これだけを見ると最近の流行のように思えますが、「DevOps」が初めて登場したのは、私の知る限り、実は4年前の2009年にまで遡ることができます。
『10+ Deploys Per Day: Dev and Ops Cooperation at Flickr』
http://www.youtube.com/watch?v=LdOe18KhtT4
DevOpsが提唱され始めた頃は、開発部門と運用部門の対立が激化していたように思えます。開発部門はリリースにかける手間を極力減らしたいと考えますが、運用部門は本番環境の安定を守るための手順を順守するよう求めます。時にスケジュールがひっ迫している状況では、この類の姿勢の違いは組織間の争いに発展するものであり、開発部門と運用部門が殺伐とした企業も珍しくありませんでした。
例えば、既存システムの追加機能に関するカットオーバーが寸前に迫っているのにバグが収束しないという状況であったとして、開発部門は少しでも多くのバグフィックスをするために本番環境上で開発者が作業することを求めるでしょう。しかし、運用部門としては、安定稼働している既存機能への影響を加味して、あらかじめテスト環境で検証済みの手順でしか作業してはいけないとの姿勢を示したとします。少しでも時間の惜しい開発部門にとっては、「そんなルールでやっていたらバグが収束する前にカットオーバーを迎えてしまう！」と憤りを覚える人が出てくるでしょう。こうしたことが積み重なると、双方部門の仲は着実に悪化します。
なぜ開発と運用の現場が争うようになってしまったのか、その根源を考えると、2002年のSOX法に端を発する内部統制の強化が一因にあるということに同意する人は多いと思います。なにせ、内部統制では、不正な本番環境への変更を抑止するために、開発担当と運用担当を明確に区分することが望ましいとしているのですから、必然的に組織も分かれて、双方が自組織の立ち位置でしかモノゴトを考えない傾向が強まってしまいます。
ですが、開発と運用を分離させることは、性悪説に耐えるIT管理を可能とする内部統制の観点から死守すべきものです。これを否定してしまうということは、性善説によるIT管理しかできなかった20世紀の混沌期にまで退行することになりかねません。
はたして、内部統制を維持したままで開発と運用が協力する体制を確立することはできるのでしょうか。その答えがDevOpsというキーワードにあります。ひとまず、具体的なソリューションに触れているリンクをこの場で紹介しておきます。
http://www.atmarkit.co.jp/ait/articles/1309/18/news008.html
http://codezine.jp/article/detail/7349
http://www.infoq.com/jp/news/2013/05/integrate-devops-itil
今後、DevOpsを理解し、実践するための情報をシリーズとして扱っていこうと思います。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－