自動化についてNetOpsにコンタクトする方法

エンタープライズ アプリケーションの開発、テスト、導入、運用、保守に関する意思決定は、サイロの中で行われるものではありません。以前は、ネットワーク運用担当者が主導権を握っていたかもしれませんし、結果的に何かが起こる前の最後の砦だったかもしれません。正直なところ、彼らのほとんどがそのような状態を好んでいたでしょう。

しかし、状況は変わりました。今やNetOpsは厳しい管理を行うどころか、自分で物事を進めたがる人々（率直に言えばDevOpsの人々）に攻め立てられています。ここで言う物事とは、NetOpsが「やらないでほしい」と思うこと（新しいアプリケーションのセキュリティ プロトコルを回避したり、アプリケーションのアップデートのためにロード バランシングの設定をいじったりするようなこと）です。

現在、DevOpsの人々が物事をより良くしようとしていることはほぼ間違いありません。物事をより適応的に、より自己管理できるように、細かい管理が必要なくなるように、より「アジャイル」になるように取り組んでいます。

今日のエンタープライズ環境では、DevOpsが「アジャイル」なワークスタイルを維持するにはNetOpsが必要です。DevOps単独では実行できません（これらのアプリケーションはすべて、基礎インフラストラクチャ上で実行されています）。また、NetOpsが従来の責任をすべて放棄して後ろに下がることは期待できません。そのようなことを望んでいるわけでもありません。NetOpsは、DevOpsが作成するすべてのアプリケーションのセキュリティとパフォーマンスの維持において重要な役割を果たしており、CI/CDワークフローに重要なスキルと能力をもたらします。

自動化によってより良い仕事を実現する

もし皆さんがDevOpsの担当者で、NetOpsの同僚をCI/CDワークフローにより深く参加させようとしているのであれば、まず彼らが参加したいと思い、現状を変えることに価値を見いだす必要があります。これは意外と簡単に実現できます。自動化によって、退屈で時間のかかる、何度も行わなければならない日常的な作業を簡単に解決できるためです。分別ある従業員であれば、ボットに委ねても構わないと思えるような作業です。

変更指示はこの典型的な例です。積み上げられたオーダーの中から、変更点をひとつひとつ手作業で入力していき、自分のやり方が正しいかどうか再確認します。なぜなら、今朝で9回目の変更ですべてが混ざってきているからです。そもそも、なぜこの分野に入ったのか？これからも毎日、一日中変更指示書を埋めていくのか？そうは思いません。

もっと良い方法があります。それは、本来ならば興味深く生産的になるはずの一日を妨げるような、何度も繰り返される余計な作業をすべて自動化することです。

自動化によってアプリケーションが改善する

会社の上層部は、私たちがこれに関してリードすることを望んでいました。なぜなら、製品がすべてだからです。製品を作っている人たちが自分の仕事を好きかどうかなんて関係ありません（それは違います！）。

とはいえ、アプリケーションのパフォーマンスとセキュリティがしっかりしていれば、業務が退屈で余計なものでなくなるという非常に素晴らしい効果がもたらされます。

アプリケーションの信頼性と安全性を確保するサービスを自動化することで、より興味深く、繰り返しの少ないプロジェクトに時間を割くことができるだけでなく、サービスの質も向上します。良く練られた自動化されたワークフローは、それだけでは成立しないからです。自動化されたワークフローが動作するための最適なモデルを作成し、最適な結果を何度も生み出すことがNetOpsエンジニアの役割なのです。

自動化の利点は、最初に正しい方法で行えば、その後は毎回正しい方法で行えることです。

自動化されたワークフローでは、NetOpsが自分の専門分野のコントロールを維持できるだけでなく（アプリケーションの速度、信頼性、安全性を高めることができます）、非常に簡単に使用できる自動化されたプロセスを生成することができ、DevOpsは二度と不正を行うことは考えなくなるでしょう（これもアプリケーションの速度、信頼性、安全性を高めることができます）。

自動化は協力があってこそ成り立つ

組織の重要なアプリケーションやデータの維持に関係するすべてのソリューションをDevOpsチームとNetOpsチームのどちらかのみが独自に考え出すことは、ほとんどの場合で不可能です。この2つのチームが協力し合う必要があるのは、昔から変わらないことです。そして今日の自動化機能は、このようなやり取りにおける摩擦を減らすのに大いに役立っています。

DevOps、NetOps、SecOpsなどのOpsは島のように孤立した存在ではありません。現代のCI/CDワークフローでは、複雑なシステム全体に迅速かつ容易に（つまり自動的に）複製できる、明確に定義された実証済みの方法を開発することが成功の鍵となります。このような自動化されたワークフローのための確かな基盤を作るには、DevOps、NetOps、SecOpsの間に強固なパートナーシップが必要であり、それぞれが専門知識を提供して互いをサポートする必要があります。

どのような環境（クラウド、コンテナなど）であっても、アプリケーションは基盤となるアプリケーション サービス、ネットワーク サービス、セキュリティ サービスに依存しています。NetOpsは、ネットワーク上のデータの流れを維持し、アプリケーションの拡張性と応答性を確保し、必要なときにデータが利用でき、常にセキュリティが確保されるようにする役割を担っています。また、すべてのOpsチームは、アプリケーションが意図したとおりに動作しないリスク、ネットワークが過負荷状態になるリスク、外部の脅威が資産を攻撃しようとするリスクなどのリスクを低減する役割を担っています。興味深いことに、Puppetによる2019年度のDevOpsの状況レポートによると、ソフトウェア開発に良い結果をもたらすDevOpsの原則（文化、自動化、測定、共有）は、セキュリティに良い結果をもたらす原則と同じであることがわかっています。

このようなさまざまなOpsチーム間のやり取りは常に行われています。それがインターネット時代のITのあり方です。しかし、改善の余地は常にあります。例えば、「アジャイル」なソフトウェア開発プロセスが登場して、アプリケーションの開発と導入の速さの限界を押し広げました。その頃、DevOpsは「コードから顧客まで」の時間を短縮する方法を採用し、より「アジャイル」な開発アプローチへと大きく変化し始めました。

このスピードアップがDevOpsの大変革をもたらしています。これには、DevOpsがより速く、よりプロアクティブに動けるというプラスの面と、他の部門のプロセスが同じように動作するように設定されていないと摩擦が生じるというマイナスの面があります。

他の部門を無視したり、新しいやり方に追いついていない同僚を無視したりするのは良くありません。DevOpsがすべてを自分たちでやろうとすると、非効率で不十分なものになります。そうすると、（不注意であろうとなかろうと）プロセスは崩壊することになり、プロセスが崩壊するとあらゆる種類の問題が発生します。そしてDevOpsだけでなく、お客様を含むすべての人に悪影響を及ぼすことになるのです。

DevOpsが本当に適した仕事をするためには、NetOpsを敵ではなくパートナーとして必要とします。そして、強固なパートナーシップの要となるのがコミュニケーションです。DevOpsは、アプリケーションをサポートするために必要なサービスをどのように得るかについて、ネットワーク チームとコミュニケーションをとる必要があります。

多くの場合、DevOpsチームは自動化、全体的なフレームワーク、Infrastructure as Codeなどの専門家です。一方で、ネットワーク チームはプロビジョニングが必要な実際のアーキテクチャ リソースやそのプロビジョニングに利用できるツールを把握する専門家です。DevOpsとNetOpsは対話と相互理解を通じて、自動化が必要な場所やそれを実現するための最善策を特定することができます。

DevOpsにとって失うものは何もなく、NetOpsの担当者がCI/CDワークフロー全体で自動化の役割を拡大するのを支援することで得られるものは多いでしょう。重要なのは、皆さんがコード開発の専門家であるのと同様に、同僚の1人または複数がそのコードをサポートするためのネットワークおよびセキュリティ サービスをプロビジョニングする専門家であることを認識することです。彼らが最高のエキスパートになれるよう手助けするチャンスを逃さないでください。