NetOpsの自動化の採用により、NetOps Opsの必要性が高まります

自動化は未来です。 DevOps は長い間、目に見えるものすべてを自動化するという考え方を採用してきましたが、NetOps は生産プロセスで自動化とオーケストレーションを広範に使用して、両者のギャップを急速に埋めています。

2018 年のアプリケーション配信の現状に関する調査では、回答者のほぼ半数 (46%) が、本番環境で自動化を少なくとも「部分的に」使用していると回答しました。 これには、大規模な生産変更 (25%)、小規模な生産変更 (26%)、さらにはインシデント対応 (22%) に常に自動化を使用することが含まれます。 半数以上が、3 つのケースすべてにおいて自動化を「時々」使用しています。

その自動化はさまざまな方法で実装されます。 Cisco、VMware、 OpenStackなどのネットワーク自動化は人気があり、Puppet、Chef、古き良き Python スクリプトなどのフレームワークやツールも人気があります。

自動化が実際に起こっていると言うのは控えめな表現ではありません。 NetOps が到着しました。 これは訓練ではありません。

表面的にはそれは刺激的ですが、それが何を意味するのかを掘り下げてみると、まだ表面化していない課題があることがわかります。

たとえば、ファイアウォールやルーターの変更を自動化することは一つの方法です。 それを包括的な展開プロセスに含めることは、別の話です (念のため言っておきますが、その正しい用語は「オーケストレーション」です)。

システムとスクリプトを連鎖（統合）し始めると、「アプリケーション」に相当するものが構築されます。 展開、管理、保守、アップグレード、パッチ適用、ライセンス付与が必要な可動部分が多数あります。

これはシシュフォスの苦役のような仕事ではありませんが、NetOps が考慮していない可能性が高い仕事です。

開発者が ServiceNow にチケットを入力すると、必要なリソースのプロビジョニング、構成、課金を自動的に行う IT ワークフローが開始されるのは素晴らしいことです。 しかし、ServiceNow が失敗したらどうなるでしょうか? あるいは、その脆弱なチェーンの構成要素の 1 つが突然倒れてしまう場合もあります。 あるいは、コンポーネントの 1 つをアップグレードすると統合が壊れるのでしょうか?

目を閉じると、その考えに過剰反応して開発者たちが大笑いしている声が聞こえてくるでしょう。

IT の自動化によって生じる予期せぬ結果の 1 つは、IT 部門が保守するソフトウェアとシステムが増えることです。 そのうちのいくつかは重要であり、他のものよりも多くの注意と給餌を必要とします。

企業組織内には、ソフトウェア システムを稼働させ続けることを任務とする「メンテナンス」または「サポート」開発者が多数存在するのと同様に、NetOps オペレーションの日常業務を処理するために、IT 部門内にも同様の役割が必要になります。

ネットオプスオプス。 はい、これはひどい造語ですが、自動化によって NetOps 展開タスクがますます消費されるようになるにつれて何が必要になるかを正確に説明する方法です。

これらのタスクの一部は、既存の運用スタッフが担当できる性質のもの（統合、ソフトウェア システムなど）になります。 しかし、ネットワークに特有のものもあり、スクリプトとシステム、および関連するネットワーク コンポーネントの両方を理解している人物が必要です。

コード/スクリプト/テンプレートが何を実行しているかがわからないと、トラブルシューティング、更新、変更を行うことはできません。

もしスノーモービルに何が起こったのかと聞かれたら、私には全く分からないと答えるでしょう。 ボンネットを開けてバッテリーを充電する方法は知っていますが、車を動かす部品をいじれとは言わないでください。 これは、JavaScript に精通した開発インターンに COBOL コピーブックの更新を依頼するのと同じです。 それはまさに災難を招く原因です。

最終的に、NetOps には、ネットワークとそれを自動化するために使用されるシステムに関する知識を持つ人々 (NetOps Ops) が必要になります。 自動化が普及すればするほど、エンジニアが次の大きなプロジェクトに取り組んでいる間に、自動化を維持する役割を担う人材を配置することがますます重要になります。