自動化についてNetOpsと話す方法

ネットワークチームを構成しているのは、同僚や仕事仲間、場合によっては友人でもある人たちです。チームのメンバーには、真実を知る権利があります。そして、その真実を伝えるのに最適なのが、ほかならぬ皆さんです。自動化によって、従来のNetOps業務の多くがどのように（良い方向へ）変わっていくのか、その真実を伝えましょう。

エンタープライズアプリケーションの開発、テスト、デプロイ、運用、保守に関する意思決定は、もはや部門内だけで行われるものではありません。かつてはネットワーク運用担当者が主導権を握り、重要な変更を実施する前の最終承認者となっていたのかもしれません。率直に言えば、その多くはそうした状況を好んでいたのでしょう。

しかし、状況は変わりました。今やNetOpsは厳格に管理するどころか、自分たちで作業を進めたがる人々（率直に言えばDevOps担当者）から次々と要求を突きつけられています。しかも、新しいアプリのためにセキュリティプロトコルを迂回したり、アプリのアップデートに伴って負荷分散の設定を変更したりと、NetOpsとしては避けてほしい作業ばかりです。

結局のところ、DevOpsに携わる人々は、物事をより良くしようとしているだけだとも言えます。変化への適応力を高め、細かな管理を減らして自律性を高め、よりアジャイルに（大文字の「A」で始まる「Agile」に）しようとしているのです。

実際のところ、今日のエンタープライズ環境でDevOpsがアジャイルな働き方を維持するには、NetOpsが必要です。DevOpsだけでは対応できません。そもそも、すべてのアプリケーションは基盤となるインフラストラクチャ上で稼働しているからです。また、NetOpsに一歩引いて従来の責務をすべて手放すよう求めることもできませんし、そうすべきでもありません。NetOpsは、DevOpsが開発するすべてのアプリケーションのセキュリティとパフォーマンスを維持するうえで重要な役割を果たし、CI/CDワークフローに不可欠なスキルと能力をもたらします。

自動化で業務を改善

DevOps担当者がNetOpsの同僚にCI/CDワークフローへより深く関与してもらいたいのであれば、まずは参加する意欲を持ち、現状を変える価値を理解してもらう必要があります。これは実際、それほど難しくありません。自動化によって容易に解決できる身近な課題は、何度も繰り返さなければならない、単調で時間のかかる定型作業だからです。誰もが喜んでボットに任せたいと思うような作業です。

変更指示書は、その好例です。山積みの指示書を1件ずつ確認し、変更内容をすべて手入力したうえで、間違いがないか再確認する。今朝だけでもう9件目ともなれば、どれも同じに見えてきて、そもそもなぜこの仕事を選んだのだろうと思ってしまうかもしれません。毎日、一日中、変更指示書の処理に追われるためでしょうか。そうではないはずです。

もっと良い方法があります。それは、本来なら興味深く生産的に過ごせる1日の妨げとなる、冗長で何度も繰り返される作業を徹底的に自動化することです。

“F5の「State of Application Services Report」によると、42%の組織がすでにアプリケーションサービスのデプロイを自動化しています。”

自動化でアプリをさらに向上

本社のお偉方は、製品の話がすべてだから、これを最初に持ってきてほしいと言っていました。作り手が仕事を楽しんでいるかなんて、どうでもいいですよね？（いいえ、そんなことはありません！）

とはいえ、単調な反復作業が減ることで、アプリのパフォーマンスとセキュリティが強化されるという、うれしい副次効果も得られます。

自動化の優れた点は、最初に正しく設定すれば、その後も毎回確実に正しく実行されることです。

アプリケーションの信頼性とセキュリティを支えるサービスを自動化することで、反復作業の少ない、より興味深いプロジェクトに充てる時間を確保できるだけでなく、サービスの品質も向上します。適切に設計された自動化ワークフローは、自然に生まれるものではありません。NetOpsエンジニアの役割は、各自動化ワークフローの基盤となる最適なモデルを構築し、最適な結果を繰り返し生み出せるようにすることです。

“自動化の優れた点は、最初に正しく設定すれば、その後も毎回確実に正しく実行されることです。”

自動化されたワークフローでは、NetOpsが専門領域の管理を維持できるだけでなく（これにより、アプリの高速性、信頼性、セキュリティが向上します）、DevOpsが独自の方法で進めようとは二度と考えないほど使いやすい自動プロセスを構築できます（これもまた、アプリの高速性、信頼性、セキュリティの向上につながります）。

協力が自動化を促進

組織の重要なアプリとデータを維持するために必要なあらゆるソリューションを、DevOpsチームまたはNetOpsチームが単独で見いだせることは、ほとんどありません。これまでも、両チームの連携は不可欠でした。現在の自動化機能は、こうした連携に伴う摩擦の大幅な軽減に役立ちます。

DevOps、NetOps、SecOps……どのOpsも単独では成り立ちません。最新のCI/CDワークフローで成功するには、複雑なシステム全体に迅速かつ容易に（つまり自動で）展開できる、明確に定義され実証済みの手法を確立することが重要です。こうした自動化ワークフローの強固な基盤を築くには、DevOps、NetOps、SecOpsが緊密に連携し、それぞれの専門知識を生かして互いを支える必要があります。

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

さまざまなOpsチーム間では、常に連携が行われています。インターネット時代を通じて、ITはこのように運用されてきました。しかし、改善の余地は常にあります。たとえば、アジャイルソフトウェア開発プロセスの登場により、アプリの開発とデプロイをどこまで迅速化できるか、その限界が押し広げられました。このときDevOpsは、よりアジャイルな開発アプローチへの大きな転換を始め、「コードから顧客へ」を迅速化する手法を採用しました。

このスピードの向上が、DevOpsで現在起きている大きな変革を後押ししています。DevOpsがより迅速かつ先回りして対応できるようになる一方で、他部門のプロセスが同じ進め方に対応していない場合には、部門間の摩擦を生む可能性もあります。

ほかの部門を無視したり、新しい仕事の進め方にまだ十分追いついていない同僚を軽視したりするのは得策ではありません。DevOpsがすべてを自分たちだけで担おうとすると、非効率なうえ、十分な成果も得られません。その結果、意図の有無にかかわらずプロセスが機能しなくなり、さまざまな問題につながる可能性があります。影響を受けるのはDevOpsだけではありません。最も悪影響を避けるべきお客さまを含め、関係者全員に及びます。

DevOpsが本来の役割を十分に果たすには、NetOpsを敵ではなくパートナーと捉える必要があります。そして、強固なパートナーシップの要となるのがコミュニケーションです。DevOpsは、アプリを支えるために必要なサービスを利用する方法について、ネットワークチームと話し合う必要があります。

多くの場合、DevOpsチームは自動化や全体的なフレームワーク、Infrastructure as Codeなどに精通しています。一方、ネットワークチームは、実際にプロビジョニングが必要なアーキテクチャリソースと、そのプロビジョニングに利用できるツールを把握しています。DevOpsとNetOpsは、対話を重ね、互いを尊重することで、自動化が必要な領域と、その最適な実現方法を特定できます。

DevOpsチームにとって、NetOpsチームがCI/CDワークフロー全体で自動化の適用範囲を広げられるよう支援することに、失うものはなく、多くのメリットがあります。重要なのは、DevOpsチームがコード開発の専門家であるのと同様に、同僚の中にも、そのコードを支えるネットワークおよびセキュリティサービスのプロビジョニングに精通した専門家がいると認識することです。そうした同僚が専門性を最大限に発揮できるよう支援する機会を逃さないでください。