SIとしてできるDevOps  DevOps Day Tokyo 2013を聞いて

結論

SIでも出来るDevOps的な取り組みはある。
特に、ビジネスメトリクス、インフラメトリクの収集、見える化が良いのではないか?

エントリのの内容

DevOps Day Tokyo 2013を見てSI所属の人間が考えたことです。
セッションの内容に関する情報はあまりありません。

 
セッションに関する情報は下記が参考になります。
 

そもそも運用がない!?開発がなくなる!?

SIのシステムの中には開発して納入して終わり。運用は完全にお客様まかせ

ってパターンもあるので、まず開発、運用のパターンから整理します。

 

  • 納入後契約関係が切れお客様が完全に運用をやるパターン
    • 問い合わせが頻繁に来るパターン
    • 問い合わせがこないパターン
  • SIが継続的に開発し、お客様が運用するパターン
    • 客先常駐で開発するパターン
    • 自社開発するパターン
  • 開発、運用を一括して委託されているパターン
    • サービスレベルさえ維持していれば運用がいろいろ出来る権限のあるパターン
    • 権限、オペレーションが限定されている運用のパターン

パターンごとに、何ができそうか書いていきます。

 

納入後契約関係が切れお客様が完全に運用をやるパターン

問い合わせが来ようとも、来なくても、基本路線としてはDEVが消滅、もしくは、大幅縮小するパターンです。そもそもの話として、継続的デリーバリーはそもそも求められていない、提供する契約体系になっていません。「変化への追随なにそれ?」とか「いや、このドメインのシステムは変化ねえよ」というのりで、とっととDEVを解散してコストを落とすことが正義のタイプのパターンです。

 

が、実際のところ、そこまで手離れがいいシステムばかりかというと忘れた頃に問い合わせはあったりするので、SIとしては問い合わせへの対応コストをいかに減らすか、OPSの状況をどうやって低コストで把握するか?といったことは重要でしょう。

 

となると役に立ちそうなのは、ビジネスメトリクスとインフラメトリクスの収集です。例えば、パフォーマンス対応の時に、一定時間の交渉をすればインフラメトリクスをお客様からいただく事はできます。しかしながら、ビジネスメトリクスをいただけることは稀です。というか、提供したシステムにビジネスメトリクスを取得する仕組みがないことのほうが多いでしょう。どういう使われ方をしているのかよくわからないまま、インフラメトリクスだけを見つつ対応することが多いように思います。これだと、場当たり的な対応はできても根本的な対応は難しいです。

 

また、メトリクスをとるメリットとして、予防保守、増設の提案、更新プロジェクトの受注の見通し(使用されていないシステムの更新は受注できない)など色々あるように思えます。セキュリーティーの話があるので、「リアルタイム、オンライン」でメトリクスが取れるとは限りませんが、「バッチ、オフライン」でメトリクスを取る価値は意外と大きいのではないかと思います。

 

また、話は変わりますが、最近のハードウェアには保守ベンターに情報を自動送信するものが多く出てきており、障害対応が簡略化できるので個人的には助かってます。SIの納入するシステムも同様の仕組みを込みこんでいくことがいいのでないでしょうか?

 

SIが継続的に開発し、お客様が運用するパターン

DEVがSI、OPSが顧客の場合ですね。で、DEV、OPSの物理的な距離が近い場合と遠い場合があります。また、DEVが大陸で言葉が通じなくて、かつ、連絡に数POP必要という絶望的な場合もあるでしょう・・。

 

この場合、やっかいのなのは下記のようなことがあるでしょう。

 

  • 別会社であること
  • コミュニケーションコストが高い可能性
    • 机が離れている、場所が離れている*1
    • 同一言語が使えない、業務時間帯がずれている*2
    • メール、会話等のコストが高い*3

 

@mirakuiさんのセッションで、「迷ったら健全な方」との話がありましたが、上記のような状況下では「健全とはなんぞや」といった状態になります。また、特に厄介なのが、決裁者、営業らの非エンジニアも巻き込んで認識を揃えなければならいない。セッションを色々聞いてやはり感じたのが、DevOpsはツールの話ではなく、またエンジニアだけの話でもなく、経営を巻き込んだ話です。

 

となると、会社間の経営方針、戦略、パートナーシップ、決裁者、営業時の契約といったあたりの話も重要になってきます。現場のエンジニア同士では会社をまたいでコンセンスが取れていても、上長、営業レベルからストップが入る可能性はあるでしょう。

 

また、直接の関係者がうまくやっても、双方の本部からPMOがやってきて、、みたいなことあるでしょう。

 

ということで、このパターンでどういったことが出来るのか、なにをやるべきは正直見えていません。とりあえず、思いつくところとしては下記ぐらいです。

 

  • ビジネスメトリクス、インフラメトリクの収集、および、DEV側への開示、上層部への開示
  • 物理的にDEVとOPSを近づける(建屋、部屋、机の並び、メールの経路のレベルで)

まじめに考えると頭が痛くなってくるので、『可能な範囲でやれることをみつけてやる』が落とし所かという気がします。

 

開発、運用を一括して委託されているパターン

DEV、OPSが同一会社の場合です。が、「OPSが権限を持っている場合」と、

「顧客から作業を委託されているだけで運用作業、運用の変更には顧客承認がいる場合」があるでしょう。

 

ただ、上記の差により、若干スピード間は変わりますが、いずれの場合でもセッションで語られていたDevOps的な取り組みは出来るのではないかと思います。

 

気になっていること DevOpsの効果測定

「Web系でサービス運用しているパターン」、「開発、運用を一括して委託されているパターン」ならば、「リリースサイクルが短く出来た」とか、「障害修正時間が短くなった」とか、それによって「離脱率が下がった」とか「新規サービスが早期投入できて売上UPです!!」みないな話はわりとやりやすい気がします。

 

が、SIで「ぶっちゃけ、これで利益いくら上がって、コストどんだけ下がるの??」「予測できなくても後付でいいから、統計的に有意にメリットと示せる??」みたいなことを言われると固まります。

 

SIという業態ですと、運用品質、サービス品質を上げても、それが数字(特に利益)に現れるまで時間がかかります。障害対応の時間、残業時間等のあたりはわりと早期に数字の跳ねてくるような気もしますが、これらが直接的にコストに跳ねてくるかというとコストは人月で決まるので、「みんなが心穏やかに平和に過ごせるだけでコスト変わってません。死亡率だけ下がりました。」みたいなことはありそうです。

 

ということで、DevOps自体のメトリクス、システム開発、運用のメトリクスってどうするんだ、、、というのが自分の中では課題です。

 

最後に

DevOps Day Tokyo 2013非常に良かったです。正直なところ、まじ、頭いたいわーみたいな感じはあるのですが、メトリクス取得はわりあいどの状況下でもやりやすいと思うので、まず、出来るところからといった印象です。

 

おまけ、オススメの資料

*1:予算の関係で同一スペースが確保できないとか、もしくは、派遣法の関係で席を離されるとかあります。

*2:オフショア大好きな人たちはやっぱり多いです

*3:直接メールできない、リーダからの転送方式とか、担当同士が会話する文化がない