DevOps と NetOps の溝を埋める

ご存知ない方のためにお伝えすると、私たちは「…の間の溝を埋める」というテーマでシリーズを書いています。

これはチーム間の溝を埋めることに関するもので、最初は罠のように思えます。

DevOps チームと NetOps チームを、ほとんど個人レベルで対立させる記事をあまりにも多く見てきました。 それは役に立ちません。なぜなら、それは人やチームに関することではなく、彼らを形成した制約と期待に関することだからです。 これらのチーム内のメンバーは、ほとんど全員が仕事で同じこと、つまりクールなことをすることを楽しんでいます。 私たちは皆、誇りに思えるもの、役に立つもの、そしてクールなものを作りたいと思っています。

チーム間で異なるのは、そして私たちの仕事の形態を決定するのは、私たちが行うことの境界と影響、そして私たちが利用できるツールです。 DevOps チームは通常、applicationまたはサービスのコレクションを解決します。 NetOps チームは、企業、またはクラウド NetOps チームの場合は数百の企業のために問題を解決します (はい、実際に存在します)。 ほとんどのネットワーク チームは、少なくとも片足を物理世界に持っています。なぜなら、実際に光子と電子をある場所から別の場所へ押し出す何かが必要なためです。 ほとんどの DevOps チームは仮想の非現実的な世界で作業し、リソースをほぼ瞬時に作成および破棄するパワーを享受しています。 開発チームと DevOps チームは、基盤となるアーキテクチャの細部からコードとビジネス ロジックを抽象化することに満足しており (そして当然のことながら)、これは、API 呼び出しが適切な場所との間で確実に行われるように誰かが保証しているという暗黙の信頼のもとに行われます。 誰もが迅速に行動したい、物事が壊れないこと、あるいは壊れたときに簡単に診断して修復できることを望んでいます。 ただ、彼らが住む宇宙は、内部から見ると少し違って見えることがあります。

問題は、この 2 つの現実の境界で発生する可能性があります。 多くの組織では、各チームの作業慣行と SLA 要件の間に隔たりがあることは明らかです。 この摩擦は新しいものと思われるかもしれませんが、これは私たちが 10 年以上前から観察してきた状況です。これは単に、F5 のテクノロジーが常にapplication重視のチームとインフラストラクチャ重視のチームを相互接続してきたからです。 バックエンド サーバーの数の変更であっても、applicationの動作の変更であっても、applicationアーキテクチャの変更は常に、セキュリティ検査、コンテンツ ルーティング、負荷分散が行われるapplication配信レイヤーに反映される必要があります。 開発者がワークフローをより反復的に整理するようになったため、これらの変更はますます速く起こり、症状はより顕著になっています。

だからこそ、今はとてもエキサイティングな時期なのです。 なぜなら、この溝を埋めるこのような機会はかつてなかったからです。 F5 では、極めて堅牢なエンタープライズ クラスのテクノロジーを、より俊敏で自動化されたワークフローに組み込むためのツールを次々と開発しています。 私たちは、希望する人全員に、こうした新しい働き方に関するトレーニングを提供してきました。 そして、私たちは社内の働き方を変革してきました。

しかし、溝を埋める最良の橋は、理解と共有された経験から築かれるものです。 橋を支えるツールとプロセスは、コラボレーションのモルタルがなければ維持されません。 私がNGINX ともっと協力していく上で最も楽しみにしていることは、ギャップを乗り越えて、プロセス分割における NGINX 側、さらに重要なことに、顧客側から物事がどのように見えるかを確認する機会を得ることです。 協力することで、私たちは共通の顧客が安全で高速、かつ革新的なapplicationsの提供に携わるすべてのチーム間の理解を深められるよう支援することができます。 もちろん、そこにはテクノロジーがあるでしょう。結局のところ、それは私たちが作るものなのです。 しかし、これはより幅広いユースケースをカバーし、DevOps と NetOps に関するより包括的なビジョンに基づいて、私たちが最も注力しているグループ、つまり顧客とユーザーのニーズに応えるものになります。