DevOpsとNetOpsの分断を解消

Robert Haynesテクニカルマーケティングマネージャー

お気づきでない方のためにご説明すると、F5では「…の隔たりを埋める」と題したシリーズを執筆しています。

今回はチーム間の隔たりを埋めることがテーマですが、最初は落とし穴のように思えます。

DevOpsチームとNetOpsチームを、まるで個人同士の対立であるかのように扱う記事を、あまりにも多く目にしてきました。しかし、それでは何の解決にもなりません。問題は人やチームではなく、それぞれのチームを形作ってきた制約や期待にあるからです。どちらのチームのメンバーも、仕事でやりたいことはほとんど同じです。それは、魅力的なものを作ることです。誰もが、誇りを持てて、役に立ち、そして何より魅力的なものを作りたいと考えています。

チームごとに異なり、日々の仕事のあり方を決めるのは、業務の範囲と影響、そして利用できるツールです。DevOpsチームは通常、1つのアプリケーションまたは一連のサービスに関する課題を解決します。NetOpsチームが対象とするのは1つの企業であり、クラウドNetOpsチームの場合は数百もの企業です（そうしたチームも実在します）。ほとんどのネットワークチームは、少なくとも片足を物理世界に置いています。光子や電子を実際にある場所から別の場所へ運ぶ何かが必要だからです。一方、ほとんどのDevOpsチームは仮想世界という形のない領域で働き、リソースをほぼ瞬時に作成、破棄できる力を活用しています。開発チームやDevOpsチームは、コードやビジネスロジックを基盤アーキテクチャの細部から切り離して抽象化しています。それは望ましいことであり、API呼び出しが適切な宛先に届き、そこから正しく返ってくるよう誰かが担保しているという暗黙の信頼の上に成り立っています。誰もが迅速に進めたいと考え、障害が起きないこと、また起きた場合には容易に診断して修正できることを望んでいます。ただ、それぞれが身を置く世界は、内側から見ると少し違って見えるのです。

この2つの現実が接する境界で、問題が生じることがあります。多くの組織では、異なるチームの業務慣行とSLA要件の間に、確かに隔たりがあります。この摩擦は新しいものと思われるかもしれませんが、F5のテクノロジーが常にアプリケーション重視のチームとインフラストラクチャ重視のチームをつないできたからこそ、F5はこの状況を10年以上にわたって目にしてきました。バックエンドサーバー数の変更にすぎない場合でも、アプリケーションの動作変更である場合でも、アプリケーションアーキテクチャの変更は、セキュリティ検査、コンテンツルーティング、負荷分散を担うアプリケーションデリバリーレイヤーに反映する必要がありました。現在、開発者がより反復的にワークフローを進めるようになり、こうした変更のペースがますます速まっているため、その兆候がより顕著になっています。

だからこそ、今は非常に期待が高まる時期です。この隔たりを埋める、これほどの機会はかつてありませんでした。F5では、極めて堅牢なエンタープライズクラスのテクノロジーを、よりアジャイルで自動化されたワークフローに組み込むためのツールを次々と開発しています。また、希望する方には、こうした新しい働き方に関するトレーニングを提供しています。さらに、F5社内の働き方も変革してきました。

しかし、隔たりを埋める最良の橋は、相互理解と経験の共有によって築かれます。その橋を支えるツールやプロセスも、協力という接着剤がなければ成り立ちません。私が最も楽しみにしているのは、NGINXとの連携をさらに深めることです。隔たりを越え、NGINXの視点、そして何よりも、プロセス上の隔たりを挟んだ先にいるNGINXのお客さまの視点から、物事がどのように見えるのかを知る機会になるからです。協力することで、安全で高速かつ革新的なアプリケーションの提供に携わるすべてのチーム間で、共通のお客さまが相互理解をさらに深められるよう支援できます。もちろん、そこにはテクノロジーも含まれます。何しろ、それこそが私たちの提供するものだからです。しかし、その取り組みはより幅広いユースケースを網羅し、DevOpsとNetOpsを包括する、より全体的なビジョンに基づくものになります。すべては、私たちが最も重視するお客さまとユーザーのニーズに応えるためです。

著者について

Robert Haynesテクニカルマーケティングマネージャー

Robert Haynesのその他のブログ記事