読者です 読者をやめる 読者になる 読者になる

運開分離とDEVOPS

この記事は「システムエンジニア Advent Calendar 2016」の記事です。

さて、今日はクリスマス☆イブ。ITな香りがほんわかするポエムを書いてしまおうと思います。

システムエンジニア Advent Calendarってあったから、とりあえず登録しといたんですが、よく見ればSIerって書いてありますね!? ワタシ、ユーザ企業の人間なので社内SEとして内製とか運用とかしてる人間ですが、まあ、細かいことは良いよね? クリスマスだし!

今回は運用と開発を両方やってきた人間としてエンプラ系で思う「運開分離」と、どちらかというとWeb界隈から普及してきた「DEVOPS」に関して書いてみようと思います。

運開分離

会社がエンタープライズよりになると「運開分離」というキーワードが首をもたげてきます。

これは文字通り「開発」と「運用」の責務を明確に分離し、人や組織も分離するという思想です。

さて、何故そんなことをするのでしょうか?

色んな理由があります。

例えば資産化率の安定化。開発を新規案件、運用を保守やトラブル対応等の非資産化としてチームを構成することで、突発的なトラブルで予定していた開発が進まない、というのを防ぐことが出来ます。

この分け方の場合、開発と運用で求められるスキルセットはほぼ同じです。どちらもアプリとインフラ、業務とシステムを抑える必要があります。

一方、別の定義もあります。

本番環境の作業、すなわちリリース以降の工程を担うのが運用チームで、要求出しからリリースまでの担当をするのが開発チームだという区分です。

どちらかというと、こっちの方がエンプラ的には多いんじゃないでしょうか?

この場合、「運用」と「開発」では求められるスキルが違うことも多くなる印象です。「運開分離」という言葉を出すときには多くの場合、こちらの組織構造を念頭に置いていると思います。

そして、なぜこのような状態で運開分離が唱えられるのかというと、セキュリティです。

たとえば、「アプリケーション開発者が,本番環境のDBを操作できると,財務諸表にかかわるデータを修正できる可能性があったからだ」と説明される場合があります。

「運用」と「開発」を分離することで、このようなリスクを避ける事が出来ます。個人的んはそれって??? と思うんですが、それは後述するのでいったん置いときます。

運用と開発は仲が悪い

運用と開発が仲が悪いという話はよく聞きますね。「なれる!SE」でも、インフラ開発に当たるSE部とインフラ保守・運用に当るOS部は仲悪いですね。業界あるあるネタだということがここからもわかります。

この理由は組織によっていろいろ違います。たとえば、最初はミッションから来る対立だったものの、のちには人の代替わりなんかもあって対立だけが残り感情的な対立になるようなケースすらあります。

逆にやたら運用と仲の良い開発の人やその逆もあります。なぜこのような事態が起こるかというと、個人的な印象としてはKPIが異なるからです。

運用と開発のKPI

これは完全に組織依存ですが、良くありそうな運用のKPIは「システムを落とさないこと」、同じく開発のKPIは「新規機能を作って利益を上げる事」なのではないでしょうか?

この場合、「攻めの開発、守りの運用」と評されることがあるようにお互いのゴールが異なるため、しばしば意見が対立します。

しかし、良く考えてみましょう。本当に運用の最重要ミッションは「システムを落とさないこと」ですか? 開発の最重要ミッションは「新規機能を作る事」ですか?

違います。ほとんどの会社が真に掲げてる最重要ミッションは「利益を最大化すること」、つまり「会社が儲けること」です。もう少し綺麗な言葉で言えば、「お客さんの笑顔のため」ですね?

大事なのはこの基準を共通化することです。運用と開発だけではなく、ビジネスサイドも本質的には共有するべきです。

各組織毎に割り振られたKPIは、それを計測するたのめ1指標でしかないはずですが、多くの場合はそれが絶対化されて、ひいては開発と運用の意見の対立が生まれます。

本当は同じゴールを最終的には目指してるはずなので、一時的にどっちかが折れるのは妥当ですが、そこを理解しないとお互いの利益だけを主張することになるので。

DEVOPSは開発Tが運用をすること?

周りから、良く言われるのですがDEVOPSというムーブメントは「開発Tが運用をすること」ではありません。

なので、先ほどの運開分離の話とは本質的に矛盾しません。DEOPSはバズワード化してるので定義はあいまいですが、この記事の中では比較的古くからある定義として「開発担当者と運用担当者が連携して協力する開発手法」としましょう。

これは裏を返せば「協力するために同じ環境を見ている」ともいえます。

それこそがDEVOPSの本質です。たとえば統合監視ツールやKibanaなど可視化ツールをいれることで、今までは運用しか見れたかったシステム負荷を開発も簡単に見れるようになります。

逆に、運用からは見えづらかった開発の動きも分かりやすくなります。

CI/CDがあることで、開発チームから何がリリースされてるかを把握することが簡単になりました。このように仕組みを導入して運用と開発のKPIのギャップを小さくするのがDEVOPSが登場した背景の一つだと思っています。

運開分離はするべき?

個人的には運開分離はするべきではありません。少なくとも組織レベルでは。

いくつか理由があります

  1. 運用と開発の技量が乖離する
  2. 運用を知らない開発者にちゃんとした運用設計は出来ない
  3. 開発ができない運用は単なるパンチャーなのでChefやAnsibleで代用される

チームを分離した当初とかなら良いのですが、純粋培養な人たちが大多数を占めると「本番を知らない開発」と「中身が分からない運用」が大量に生まれます。

いずれのパターンもお互いの本業を担うのに十全な力がありません。例えばトラブル対応等でログ集計をしたことがある人間はログを出すタイミングやフォーマットにも非常に気を使います。

たとえば、以下のようなそれぞれのログがあります。

A. 2016-12-24 10ms Start Christmas
B. 2016-12-24 10 ms Start Christmas
C. Start Christmas 2016-12-24 10 ms 

同じ情報量で単に表現を変えただけですが、あなたはどのログを選びますか? 運用経験者は「B」を選ぶ人が多いでしょう。

Aだとスペース区切りじゃないので単純にawk等の解析で人手間かかります。

Cだと複数のサーバで出力されたログを日付毎にソートするのが少し面倒です。

ちなみに、A,B,Cのいずれも情報量が同じなので「一手間」以上の違いはありませんが、選べるなら手間の無い方を選ぶはずです。この辺のログのフォーマット設計は運用をしてないとピンとこないと思います。

もうちょっというと、カンマ区切りやスペース区切りも課題があるので、TSVやLTSVを運用観点では選ぶでしょうね。

もちろん、これは一例で運用経験が無いと思いつかない設計というのはそれなりにあります。

開発を知らない運用はもっと深刻で、手順書の通りにしかできないなら人間がやる必要すらありません。

そうならないためにもアプリケーションを熟知し、どのような負荷をシステムに与える特性があるのか、いつが負荷が多いのかってのは作りを知らないとわからない部分です。

こういたスキルはとても高度で蓄積を必要とするものなので、外注に丸投げするものでは本来はありません。

また、CIなどの開発なんだか運用なんだか持ち分に困るツールの管理も運開分離を徹底した時には起こりがちです。

でもセキュリティが...

そもそも運開分離はセキュリティのために提唱されたといわれております。

でも、それって「運用は悪意が無い」という前提がないと意味ないですよね?

先ほどの「アプリケーション開発者が,本番環境のDBを操作できると云々」の話であれば、アプリケーション開発者が悪意を持ってデータ改ざんできるなら、運用担当者も改ざん意味ないのですよね。

なぜ、無条件にアプリケーション開発者がだめで運用担当者はOKになるのか理解ができません。

そうではなくて、例えばrootなどの特権の利用を制限するとか、監査ログをしっかりとるとか、運用担当者も不正が出来ないシステムにすることで、開発担当者も不正が出来ないようにするのが肝心です。

下手すると開発はガチガチに制限されてるけど、運用はrootで入り放題とかいう脆弱を生みかねないので、変な幻想は捨てるべきでしょう。

まとめ

エンプラの人たちが大好きな運開分離ですが、個人的には不要だと思います。

DEVOPSとは矛盾しないので必要な組織に入れたらいいと思いますが。

特に資産化工数の安定化はそれなりに重要なので、その観点で分けるのはありでしょう。

ただ、その場合でも技術と意識の乖離を防ぐために定期的には人をシャッフルすることが大事だと思います。