NetOpsによる自動化の導入で「NetOps Ops」が必要に

F5エコシステム | 2018年2月15日

自動化は未来を切り拓きます。DevOpsでは以前から、あらゆるものを自動化するという考え方が取り入れられてきました。一方、NetOpsでも本番プロセスに自動化とオーケストレーションを幅広く活用し、DevOpsとの差を急速に縮めています。

F5の「State of Application Delivery 2018」調査では、回答者の半数近く(46%%)が、本番環境で自動化を少なくとも「部分的に」利用していると回答しました。これには、大規模な本番環境の変更(25%)、小規模な本番環境の変更(26%)、さらにはインシデント対応(22%)で常に自動化を利用している回答者が含まれます。3つのケースすべてで、半数を超える回答者が自動化を「時々」利用しています。

soad18 本番環境での自動化

このような自動化は、さまざまな方法で実装されています。CiscoやVMware、OpenStackなどのネットワーク自動化が広く利用されているほか、PuppetやChefなどのフレームワークやツール、昔ながらのPythonスクリプトもよく使われています。

自動化が現実に進んでいると言っても、決して控えめな表現ではありません。NetOpsの時代が到来しました。これは訓練ではありません。

一見すると胸が躍る話ですが、その意味を掘り下げてみると、まだ表面化していない課題があることがわかります。

たとえば、ファイアウォールやルーターの変更を自動化することと、それを包括的なデプロイプロセスに組み込むことは別物です(ちなみに、後者の正式な用語はオーケストレーションです)。

システムとスクリプトを連携(統合)し始めると、「アプリケーション」に相当するものが構築されます。そこには、導入、管理、保守、アップグレード、パッチ適用、ライセンス管理が必要な多くの構成要素があります。

これは果てしなく続く徒労ではありませんが、NetOpsでは考慮されていない可能性が高い作業です。

開発者がServiceNowでチケットを起票するだけでITワークフローが開始され、必要なリソースのプロビジョニング、構成、課金まで自動的に行われるようになったのは素晴らしいことです。しかし、ServiceNowが機能しなくなったらどうなるでしょうか。あるいは、その脆弱な連鎖を構成するコンポーネントの1つが突然停止した場合や、いずれかのコンポーネントをアップグレードしたことで連携が機能しなくなった場合はどうでしょうか。

目を閉じれば、その光景を思い浮かべ、他人の不幸を喜ぶ開発者たちの含み笑いが聞こえてきそうです。

ITの自動化がもたらす意図せぬ結果の1つは、IT部門が保守すべきソフトウェアやシステムが増えることです。その中には重要なものもあり、ほかよりも入念な運用と保守が必要になります。

企業組織内には、ソフトウェアシステムを稼働させ続けることを専任とする「保守」または「サポート」担当の開発者が大勢います。それと同様に、IT部門でもNetOps Operationsの日常的な運用に対応する役割が必要になるでしょう。

NetOpsOps。確かにひどい造語ですが、NetOpsの導入作業がますます自動化される中で、今後必要となるものを的確に表しています。

そうしたタスクの中には、統合やソフトウェアシステムなど、既存の運用スタッフが担えるものもあります。しかし、ネットワークに固有のタスクもあり、その場合は、スクリプトやシステムと関連するネットワークコンポーネントの両方を理解している人材が必要です。

コード、スクリプト、テンプレートがどのように動作するかを理解していなければ、トラブルシューティングや更新、変更はできません。

スノーモービルのどこが故障しているのかと聞かれても、私にはまったく分かりません。ボンネットを開けてバッテリーを充電することはできますが、走行に関わる部品をいじれと言われても無理です。それは、JavaScriptに習熟した開発インターンにCOBOLのコピーブックを更新させるようなものです。まさに大惨事を招きかねません。

最終的には、NetOpsには、ネットワークとその自動化に使用するシステムに精通した担当者(NetOps Ops)が必要になります。自動化の活用が進むほど、エンジニアが次の大きな取り組みに注力する一方で、その自動化の保守を担う担当者を配置することがますます重要になります。

共有

著者について

Lori Mac Vittie
Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事

関連するブログ記事

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視
F5エコシステム | 2025/04/15

F5 Application Study Tool:OpenTelemetryによるF5 BIG-IP環境の監視

F5の新しいオープンソースツールは、BIG-IP環境を詳細に可視化し、データを追跡するとともに、強力でカスタマイズ可能なインサイトを得るための基盤を提供します。

F5 BIG-IPでAI防御を実現
F5エコシステム | 2024/11/13

F5 BIG-IPでAI防御を実現

F5 BIG-IP Advanced WAF、BIG-IP APM、BIG-IP SSL Orchestratorが、生成AIアプリ向けに包括的なセキュリティソリューションを提供する仕組みをご覧ください。

F5 Advanced WAFによるGraphQL APIの保護
F5エコシステム | 2021/08/31

F5 Advanced WAFによるGraphQL APIの保護

ここ数年、多くの組織がデジタルトランスフォーメーションを進めており、COVID-19のパンデミックによってその動きは加速しています。

アプリケーションサービスの現状 通信業界版:リーダーとしての台頭
F5エコシステム | 2019/02/19

アプリケーションサービスの現状 通信業界版:リーダーとしての台頭

通信ネットワークが進化し、さまざまな業界の幅広いユースケースに対応するなか、通信業界の回答者がテクノロジーリーダーとしての存在感を高めていることがわかります。

デジタルトランスフォーメーションは、単なるペーパーレス化ではない
F5エコシステム | 2017/07/10

デジタルトランスフォーメーションは、単なるペーパーレス化ではない

デジタルトランスフォーメーションは、単なるペーパーレス化ではありません。真のモダナイゼーションにアプリケーションアーキテクチャとセキュリティの再構築が必要な理由を、F5ブログでご覧ください。

やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。
F5エコシステム | 2016/09/19

やめましょう。もう本当にやめましょう。HTTPSはHTTPより高速ではありません。

もうやめましょう。HTTPSはHTTPより高速ではありません。プロトコルのパフォーマンスに関する微妙な違いと、暗号化トラフィックを適切に最適化する方法については、F5ブログをご覧ください。