2015年最終四半期,InfoQは健全なDevOps文化に最も寄与するDevOpsプラクティスについてのサーベイを実施し,その結果を“Patterns of DevOps Culture”(eMagでも参照可能)という記事で紹介した。目的は,優れたDevOpsプラクティスをコミュニティによる投票で選ぶことだ。
参加者72名の投票(2015年12月30日現在)では広範な結論を推測することはできないが,興味深い結果をいくつか指摘することは可能だ。
今回の結果から何よりも明白なのは,参加者の間で合意に達したプラクティスがひとつもない,ということだ。事実,いずれも投票の10%にさえ達していない – 最高位であった“スプリント/バックログに運用要件を含める”でさえ,9%の票しか集められなかった。その一方で,いずれのプラクティスも,少なくとも2人の参加者の投票を獲得している(最小の“インフラストラクチャレビュー”は7票を獲得している)。
DevOpsの標準的な定義,および/あるいはプラクティスの一覧というものが存在しない以上,このような結果になるのは当然かも知れない。この結果が示す事実は,DevOps文化を実現するためには,現在の文化や組織,変化への抵抗などの状況的要因によって,それぞれ違うプラクティスが必要なのかも知れないということだ。
トップ5のプラクティス(投票数の40%以上を獲得している)に注目すれば,DevとOpsの整合性を意識し,ワークフローと目標の共有を進めることの重要性が理解できる。
トップ5の中でオートメーションに関連する2つのプラクティスは,迅速なデリバリとフィードバックを可能にする基本的要素であるので,それほど意外ではない。
注目すべきなのは,6位(“Dev(開発)によるアプリケーションパフォーマンスの監視”)と7位(“アプリケーションのデプロイをDevが担当する”)が,いずれも従来はOps(運用)の責任であったものをDevが担当する,という点に着目していることだ。これらのプラクティスが上位に選ばれたことを説明するには,タスクを実行する上でアプリケーションのコードやアーキテクチャに最も近い人々を選任する(DevとOpsの間の引き継ぎに伴うオーバーヘッド – 時には非難 – を低減するために)という目的に加えて,次のような副次的な効果もあるのではないかと思われる。
これらのプラクティスが実施されるということは,チケット文化に伴って開発と運用の間に存在する“混乱の壁(wall of confusion)”を克服しようという,少なくとも意思があるものと解釈される。
開発がデプロイメントに責任を負うべきだというものと,専門のチームが責任を負うことになるというものという“矛盾する”プラクティスが,意図的にリストに含まれている点に注目してほしい。その結果は,前者に対する賛成票が,後者に対して3倍以上の票を獲得したことから明らかだ。
もうひとつの興味深い結果は,DevOpsの要件としてしばしば引き合いに出される“開発のオンコール”と“運用システムに対して開発がルートアクセス権を持つ”のランクが,どちらも極めて低いことだ。現実的にこれら2つのプラクティスが妥当かどうかは,組織の文化によるとも考えられるが,いずれも健全なDevOps文化を達成する上で基本的な問題ではないということを,この結果は示している。管理の十分に行き届いた環境であっても,現実には難しいのかも知れない。
最後に興味深い点として指摘したいのは,今回の調査は我々の“Patterns of DevOps Culture”シリーズと並行して実施されたにも関わらず,”非難をしない事後分析”が全投票の5%,”他チームメンバのメンタリング”が3%など,シリーズで紹介したパターンがそれほど上位にランクインしていないことだ。
これらのプラクティスの中に,InfoQで詳しく取り上げてほしいと思うものはあるだろうか? 下記のコメントで教えて頂きたい。