エンタープライズ アプリケーションの開発、テスト、展開、運用、保守に関する意思決定は、サイロ内で行われるわけではありません。 かつては、ネットワーク運用担当者が制御権を持ち、重要な事態が発生する前の最後の手段となっていたかもしれません。 そして正直に言うと、彼らのほとんどはおそらくそのやり方を好んだでしょう。
しかし、状況は変わりました。 現在、NetOps には、厳密な制御を実行するのではなく、自分で物事を進めることを好む人々 (正直に言えば、DevOps の人々) が殺到しています。 NetOps が望まないこと (新しいアプリのセキュリティ プロトコルを回避したり、アプリの更新の負荷分散設定を変更したりすることなど)。
現在、DevOps の人々は、おそらく物事をより良くしようとしているだけです。 より適応性があります。 より自己管理的になり、マイクロマネジメントが少なくなります。 よりアジャイル（大文字の A で）。
問題は、今日の企業環境では、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 は、ネットワークを介したデータの流れを維持し、アプリのスケーラビリティと応答性を確保し、必要なときにデータが利用可能であり、常に安全であることを保証する役割を担っています。 また、すべての運用チームには、アプリが意図したとおりに動作しないリスク、ネットワークが過負荷になるリスク、外部の脅威が資産を攻撃しようとするリスクなど、リスクを軽減する役割があります。 また、 Puppet による 2019 年の DevOps の現状レポートによると、ソフトウェア開発で良好な結果をもたらす DevOps の原則 (文化、自動化、測定、共有) は、セキュリティで良好な結果をもたらす原則と同じであるというのは興味深いことです。
さまざまな運用チーム間のやり取りは継続的に行われます。 これは、インターネット時代を通じて IT が運用されてきた方法です。 しかし、アジャイル ソフトウェア開発プロセスが登場し、アプリの開発と展開のスピードの限界を押し広げたように、改善の余地は常に存在します。 当時、DevOps は開発に対するよりアジャイルなアプローチへの大きな変化を起こし始め、「コードから顧客へ」というより迅速な方法を採用しました。
この速度の向上が、DevOps が現在目撃している大きな変化を推進しています。 DevOps には、より迅速に行動し、より積極的に行動できるという良い面と、他の部門のプロセスが同じように動作するように設定されていない場合に摩擦が生じる可能性があるという悪い面があります。
他の部門を単に無視したり、新しいやり方にまだ追いついていない同僚を無視したりするのは、悪い考えです。 DevOps がすべてを自社で行おうとすると、非効率的で不十分になります。 このようにしてプロセスは（意図的かどうかにかかわらず）壊れ、壊れたプロセスはあらゆる種類の問題を引き起こす可能性があります。 これは DevOps だけではなく、顧客を含め、最も悪影響を与えたくないすべての人にとって重要です。
DevOps が本当に適切に機能するには、NetOps を敵ではなくパートナーとして必要とします。 そして、強固なパートナーシップを築くための要となるのはコミュニケーションです。 DevOps では、アプリをサポートするために必要なサービスを取得する方法について、ネットワーク チームとコミュニケーションを取る必要があります。
多くの場合、DevOps チームは自動化、全体的なフレームワーク、コードとしてのインフラストラクチャなどの専門家になりますが、ネットワーク チームはプロビジョニングが必要な実際のアーキテクチャ リソースと、そのプロビジョニングに使用できるツールを理解する専門家です。 会話と相互尊重を通じて、DevOps と NetOps は自動化が必要な場所と、それを実現するための最善の方法を特定できます。
DevOps では失うものは何もなく、NetOps の担当者が CI/CD ワークフロー全体に自動化の役割を拡張できるように支援することで得られるものは多くあります。 重要なのは、あなたがコード開発の専門家であるのと同じように、あなたの同僚の 1 人以上がそのコードをサポートするネットワークおよびセキュリティ サービスのプロビジョニングの専門家であることを認識することです。 彼らが最高の専門家になれるよう支援するチャンスを逃さないでください。