標準化は NetOps にとって有益です

標準化はイノベーションに対する攻撃と見なされることがあります。 多言語対応のビュッフェを諦めて、より限定されたメニューを採用せざるを得なくなるのは、確かに息苦しいことのように思える。 これは、標準化が、ISO 8076.905E のような正式な名前を持ち、チェックリストや監査人、監視委員会を伴う規制コンプライアンス標準に関連付けられることが多いためと考えられます。

現実には、企業組織による言語、プロトコル、フレームワークの選択を規定する標準はほとんど存在しません (実際、私が思いつく限りでは存在しません)。 企業における標準化を推進するのは、人材の可用性、持続可能性、ソフトウェアとシステムの（多くの場合、かなりの）寿命にわたる総所有コストなど、より実用的な考慮事項です。

調査によると、過去 20 年間のソフトウェアの平均寿命は約 6 ～ 8 年です。 興味深いことに、コード行数 (LOC) で測定すると、プログラムの寿命は大きくなるにつれて長くなる傾向があります。 100 万 LOC を超えるシステムとソフトウェアの寿命は 10 年以上、つまり 12 ～ 14 年続くようです。 これを無関係だと無視するかもしれませんが、結局のところ、ネットワーク自動化システムはソフトウェアとシステムであることを認識することが重要です。 開発組織から出てくるソフトウェアと同じような注意、管理、メンテナンスが必要です。 運用パイプラインをコードとして扱う場合は、自動化されたパイプラインのかなりの割合がコードになることを受け入れる必要があります。

したがって、そのソフトウェアまたはシステムの寿命全体にわたって、複数のオペレーターと開発者が、そのソフトウェアまたはシステムの更新、保守、運用、および変更の展開を担当することは間違いありません。

そして、これこそが標準化を推進する原動力であり、特にネットワークおよびapplicationサービス インフラストラクチャの展開と運用を自動化および調整するシステムの開発と保守に取り組む NetOps にとって重要です。 

サイロは農場向け

あなた (またはあなたのチーム) が Python を選択し、別の人が PowerShell を選択した場合、事実上、スキルの共有を妨げる運用サイロが構築されていることになります。 「 State of Network Automation 2018」で報告されているように、NetOps が直面している最大の課題はスキル不足 (49% が回答) であることを考えると、複数の言語やツールセットを導入してさらなる摩擦を生み出すのは愚かなことのように思われます。 同様に、地元に才能のある人材がいない言語やツールセットを選択するのも悪い考えです。 他の組織や近隣の大学が Python を教えていて、PowerShell を使用することを選択した場合、そのシステムで作業するために必要なスキルを持つ人を見つけるのは困難になります。

組織が単一の言語に標準化することはまれですが、少数の言語に標準化する傾向があります。 NetOps は開発および DevOps 標準からヒントを得る必要があります。これにより、人材プールがさらに拡大します。

価値実現までの時間は貴重

多くの NetOps 組織は、DevOps と継続性を求めるビジネス要求を満たすことに関しては、すでに不利な立場に立たされています。 NetOps とネットワーク自動化の残念な現実は、事前にパッケージ化された統合がほとんど利用できない異機種混合のエコシステムであるということです。 ネットワーク自動化の現状に関する調査では、この「統合の欠如」が自動化に対する 2 番目に多く挙げられた課題であり、NetOps の 47% が同意していることがわかりました。

ツールセットとインフラストラクチャ（applicationサービスなど）を可能な限り標準化すると、組織全体の統合の負担を軽減する機会が得られます。 あるチームが開発したものを他のチームが活用して、他の自動化プロジェクトの価値実現までの時間を短縮できます。 再利用は価値実現までの時間を改善する上で重要な要素です。 オープンソースに対する開発者の傾向と、今日のapplicationsの 80 ～ 90% がサードパーティ/オープンソース コンポーネントで構成されているという事実から、再利用が見られます。 これにより開発がスピードアップし、価値実現までの時間が短縮されます。 既存の統合を活用することで、同じ原則をネットワーク自動化に適用できます。

標準化のメリットを享受するために、運用ドメイン全体で共有と再利用の文化を確立します。

イノベーションの促進

標準化は、当初一部の人が考えていたようにイノベーションを妨げるのではなく、イノベーションの触媒となる可能性があります。 運用ドメイン全体でソフトウェアとシステムを標準化し共有することで、新しい要件やシステムについて共同作業できる、より強固な思考と経験が得られます。 組織内に、時には長いオンボーディング サイクルなしで、新しい機能に関する意見、アイデア、実装を提供できる人材プールを構築します。

標準化により、親しみやすさのおかげで実装もスピードアップします。 同じ言語、ライブラリ、ツールセットを使い続けるほど、能力が向上します。 つまり、生産性が向上し、車輪の製造に費やす時間が短縮され、新しい機能で差別化を図り、付加価値を高める方法を検討する時間が増えることになります。

標準化はチャンス

特に、お気に入りの言語やツールセットがチームから削除された場合、標準化は最初は息苦しく感じられることがあります。 しかし、自動化システムとソフトウェアの強力な基盤を構築する機会として標準化を取り入れることは、ビジネスに利益をもたらし、NetOps に継続的デプロイメント ツールチェーン全体にわたって価値を付加する新たな機会をもたらします。

しかし、標準化のためだけに標準化するのはやめましょう。 既存のスキルセットと地元での人材の可用性を考慮してください。 大学やその他の企業を調査して、自動化と運用のスキルセットと人材の現状を理解し、特定の言語やツールセットを採用している組織が自社だけではないことを確認します。

長期的に最良の結果を得るには、標準化をセキュリティのように扱わず、実装が完了するまで残しておいてください。 自動化の取り組みの早い段階で標準化を取り入れることで、運用上およびアーキテクチャ上の負債に悩まされることを回避し、後で標準化が困難になるのを防ぐことができます。

標準化は、セキュリティと同様に、早いほど遅くよりも良いです。