BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース DevOps文化に銀の弾丸はない -InfoQ調査結果より

DevOps文化に銀の弾丸はない -InfoQ調査結果より

原文(投稿日:2015/12/31)へのリンク

2015年最終四半期,InfoQは健全なDevOps文化に最も寄与するDevOpsプラクティスについてのサーベイを実施し,その結果を“Patterns of DevOps Culture(eMagでも参照可能)という記事で紹介した。目的は,優れたDevOpsプラクティスをコミュニティによる投票で選ぶことだ。

参加者72名の投票(2015年12月30日現在)では広範な結論を推測することはできないが,興味深い結果をいくつか指摘することは可能だ。

Results Table

今回の結果から何よりも明白なのは,参加者の間で合意に達したプラクティスがひとつもない,ということだ。事実,いずれも投票の10%にさえ達していない – 最高位であった“スプリント/バックログに運用要件を含める”でさえ,9%の票しか集められなかった。その一方で,いずれのプラクティスも,少なくとも2人の参加者の投票を獲得している(最小の“インフラストラクチャレビュー”は7票を獲得している)。

DevOpsの標準的な定義,および/あるいはプラクティスの一覧というものが存在しない以上,このような結果になるのは当然かも知れない。この結果が示す事実は,DevOps文化を実現するためには,現在の文化や組織,変化への抵抗などの状況的要因によって,それぞれ違うプラクティスが必要なのかも知れないということだ。

トップ5のプラクティス(投票数の40%以上を獲得している)に注目すれば,DevとOpsの整合性を意識し,ワークフローと目標の共有を進めることの重要性が理解できる。

  • スプリント/バックログに運用要件を含める
  • 開発/製品チームに運用エンジニアが(複数)参加する
  • 重要な指標に対する目標と責任を共有する

トップ5の中でオートメーションに関連する2つのプラクティスは,迅速なデリバリとフィードバックを可能にする基本的要素であるので,それほど意外ではない。

  • マシンのプロビジョニングの自動化
  • コードとしてのインフラストラクチャ(Infrastructure as Code)

注目すべきなのは,6位(“Dev(開発)によるアプリケーションパフォーマンスの監視”)と7位(“アプリケーションのデプロイをDevが担当する”)が,いずれも従来はOps(運用)の責任であったものをDevが担当する,という点に着目していることだ。これらのプラクティスが上位に選ばれたことを説明するには,タスクを実行する上でアプリケーションのコードやアーキテクチャに最も近い人々を選任する(DevとOpsの間の引き継ぎに伴うオーバーヘッド – 時には非難 – を低減するために)という目的に加えて,次のような副次的な効果もあるのではないかと思われる。

  • 開発チームが,運用環境でのアプリケーション実行に伴う非機能的な影響を理解することにより,運用チームとより多くの共感を持つことが可能になる(1位のプラクティスに寄与する可能性もある)。
  • 運用チームが日毎のデプロイメントおよび監視タスクから部分的に解放されることで,インフラストラクチャやツールの自動化に時間を振り当てることが可能になり,結果としてそれらのタスクが促進される。
  • オートメーションが前提となり,開発チームが直接処理可能になることで,公式な引き継ぎや,詳細で変更の多いドキュメントの必要性がなくなる。

これらのプラクティスが実施されるということは,チケット文化に伴って開発と運用の間に存在する“混乱の壁(wall of confusion)”を克服しようという,少なくとも意思があるものと解釈される。

開発がデプロイメントに責任を負うべきだというものと,専門のチームが責任を負うことになるというものという“矛盾する”プラクティスが,意図的にリストに含まれている点に注目してほしい。その結果は,前者に対する賛成票が,後者に対して3倍以上の票を獲得したことから明らかだ。

もうひとつの興味深い結果は,DevOpsの要件としてしばしば引き合いに出される“開発のオンコール”と“運用システムに対して開発がルートアクセス権を持つ”のランクが,どちらも極めて低いことだ。現実的にこれら2つのプラクティスが妥当かどうかは,組織の文化によるとも考えられるが,いずれも健全なDevOps文化を達成する上で基本的な問題ではないということを,この結果は示している。管理の十分に行き届いた環境であっても,現実には難しいのかも知れない。

最後に興味深い点として指摘したいのは,今回の調査は我々の“Patterns of DevOps Culture”シリーズと並行して実施されたにも関わらず,”非難をしない事後分析”が全投票の5%,”他チームメンバのメンタリング”が3%など,シリーズで紹介したパターンがそれほど上位にランクインしていないことだ。

これらのプラクティスの中に,InfoQで詳しく取り上げてほしいと思うものはあるだろうか? 下記のコメントで教えて頂きたい。

この記事に星をつける

おすすめ度
スタイル

BT