DevOpsの大事なことは、だいたい原点に書いてある（後編）～ Developers Summit 2013 Summer

2013年8月6日

夏に行われるデブサミ、「Developers Summit 2013 Summer」が、8月1日に開催されました。テーマはエンタープライズに向けたDevOps。

（この記事は「DevOpsの大事なことは、だいたい原点に書いてある（前編）～ Developers Summit 2013 Summer」の続きです）

DevOpsの典型的なやり方

ITの現場の多くで、開発と運用チームの関係はこのようなものだと言われています。つまり、開発は「ビジネスの要望に応えて機能を実現しているのは自分たちだ」と考え、一方で運用も「安定運用でビジネスを支えているのは自分たちだ」と考えています。

しかし実際にビジネスから見れば、どちらも大事なんですね。両方うまくやってほしい。

そこでDevOpsによって協力していこう、となるわけです。そのときの典型的なやり方がこれです。必ずしもこれが正解というわけではありませんが。

開発側は、継続的デプロイメントと呼ばれる、ざっくりいえばアジャイル開発の手法をデプロイにまで拡張したような方法論を軸にします。これを実現するために、バージョン管理のGitや自動テストツール、Jenkinsなどを使うわけです。

運用側は、いわゆるコードとしてのインフラとして、クラウドやChef、Puppetなどを使います。これによって変化に強く柔軟な運用を実現するわけです。

この両方のあいだを、さらにチケッティングシステムなどのツールでつなぐこともあります。

もう1つ大事なことがあります。それは、ビジネス側から見てDevOpsがうまくいっているかどうか把握できることです。

DevOpsにBizを巻き込むためのメトリクス

DevOpsによって現場の協力関係ができることはもちろんいいことですが、一方でDevOpsをはじめると自動テスト環境を構築することで以前より多くサーバを使う必要があったりして、効果がビジネス側に伝わらなければ「エンジニア達がなにか好き勝手にやっている」と見られてしまう可能性があります。

なのでDevOpsでは、さらにBizも巻き込んだ協力関係というのが求められるわけです。

Bizを巻き込んだDevOpsでは、メトリクスが欠かせません。DevOpsで実現されている変化が正しい方向に向かっているのかを、つねにDevとOpsとBizが共有するメトリクスで確認し合う、という関係が望ましいと思います。

これを実現するには、DevとOpsはログからどんなメトリクスが取り出せて、それがどんな意味を持っているのかをBizに説明できなければなりませんし、Bizはそのメトリクスの中で何が大事なのかをコミットしなければなりません。

あるいはエンタープライズ向けのアプリケーションでは、社内向けシステムのように利用者が社員の場合があります。こうした場合には、メトリクスによってビジネスの進行具合をはかるのが難しいこともあります。そのときはメトリクス以外の何を評価すべきか考えなければなりません。

こうしたDevとOpsとBizの摺り合わせが大事でしょう。

それ以外にも、DevOpsをエンタープライズで用いるにはいくつかの課題があります。

DevOpsをエンタープライズで用いるときの課題

もともとDevOpsはFlickrやTwitterやFacebookのようなオンラインサービス系の企業から登場しました。これらのサービスは、DevもOpsもBizもみんな同じ会社の社員です。ところがエンタープライズでは、発注企業がいて、SIerがそれを受託し、運用は発注企業の情報子会社がやる、などというパターンもあります。

こうした状況でどうやってDevOpsを実現するかは課題でしょう。鍵を握るのは、ビジネスを前進させ、変化を乗り越えたいはずのBizたる発注者、ユーザーの姿勢だと思います。

BizとDev/Opsがメトリクスを握れるのか？共有できるのか？という点も課題だと思います。

これはDev/Ops側がきちんとログやメトリクスをBiz側に専門用語などを抜きにして説明できるのかという点と、Biz側がちゃんとメトリクスを選ぶ決断ができるのか、という点の両方が挙げられます。また、そもそもメトリクスがとりにくい例もあるはずなので、その場合には何をもってビジネスが前進しているといえるのか、ステークホルダーであらかじめ共有する必要があるでしょう。