DevNetOpsとは

DevNetOpsとは

DevNetOpsとは、DevOpsの理念、原則、行動様式をネットワーク運用(NetOps)に適用することです。DevOpsの理念は、1980~2000年代に発生したソフトウェアエンジニアリングの文化とリーン生産革命から始まりました。DevOpsの原則は一般にCALMS(Culture(文化)、Automation(自動化)、Lean(無駄を省く)、Measurement(測定)、Sharing(共有))として知られています。

最もよく言及されるDevOps原則の1つは、ウォーターフォール方式と相反することです。ウォーターフォール方式では、プランニング、構築、テストのサイクルが長期的にわたっる一連のステップとして実行されます。『The DevOps Handbook』には、IT業界と製造業で実施されたDevOpsの調査から、導入を小規模に頻繁に行うほど、運用のスピード、俊敏性、品質が向上することが判明したと記載されています。

信頼性は、ビジネスの目標を迅速に達成するための重要な前提条件です。持続性がないのにスピードを重視しても失敗します。早い段階で失敗することは、反復の間に改善できる場合に限って組織にとって有益となります。同時に、近年一般的になってきたDevOpsの実装は、サイト信頼性エンジニア(SRE)の役割です。DevNetOpsも同様に、ネットワーク信頼性エンジニア(NRE)の職務として実装されます。

DevNetOpsパイプラインとは

DevNetOpsパイプライン

DevNetOpsパイプライン

開発から導入までの期間を短縮し、導入時に納入品に対する変更を小さくし、短時間に速いサイクルで作業をするために、DevNetOpsパイプラインでは、技術的な変更と製品導入までの作業を自動化します。

バージョン管理されたコードリポジトリにコミットすれば、先進的な構築とテストの継続的統合(CI)パイプラインが動き出します。一連の自動と手動の判定を経て、納品候補のペイロードは、コミットされ信頼できる納品状態になるまで、仮想環境、シミュレーション、ラボでテストされます。継続的納品(CD)パイプラインの状態が、コミットされた納入品が常に導入可能な状態であることを保証しています。継続的な導入が、ステージング環境、その後の実稼働環境に向けての自動的な後押しとなります。

ただし、変更をランタイム環境(ステージングや実稼働環境など)に導入する前に、変更するまたは変更しないインフラストラクチャを、マイクロサイズアーキテクチャ単位で把握することが重要です。大規模でモノリシックな変更は安全性が低く、構築と検証に時間がかかります。そのうえ、小規模なパケットの変更の場合と比較して、問題の特定が困難です。

継続的な導入の前においては、変更しないインフラストラクチャも同様に重要です。実際に導入した製品の内容をエンジニアが変更するような導入は、非効率で有用ではありません。変更を安全にテストし、問題の改善方法を見定めるためには、実稼働環境のランタイムを再現する必要があります。

継続的な監視、測定、対処は、DevNetOpsの最終工程です。サービスレベル指標に対する実稼働中のフィードバックは、ネットワークの過渡的な状態に対して、対処的または積極的な調整を行うために使用されます。また、分析されたテレメトリ、インシデント、外部変更要求は体系化されたネットワークシステムの状態を示しており、継続的な改善としてフィードバックされます。

自動化されたDevNetOpsパイプラインの概要

ツール

プロセス

人材

コードとしてのネットワーク

設定のシークレット、アーティファクト、gitOpsのリポジトリ

ブランチング、レビュー、ペアリング、アジャイル

コードスキル(プログラミングが必須とは限らない)

パイプラインオーケストレーション

パイプライン CI/CD ツール、テストフレームワーク

TDD、測定値の判定

構築とデバッグのスキル、パイプラインのプロフェッショナル

マイクロおよび不変なアーキテクチャ

ZTP 用に成果物を準備、ベンダー リフラクター

小刻みなコミット/導入

自動的な CLI/TTY

オーケストレーションされたアップグレード

ZTD、仮想化、ラボ、トラフィック ドレーニング

ステージングとシミュレーション カナリア分析

営業時間内の保守、ロール バックまたはロール フォワード

耐障害性設計とドリル

トラフィック生成、DoS、Chaos Monkey

障害が発生したウィンドウ、ドキュメントの制限

理解するための強制エラー

継続的な測定

ビッグ データ分析、ML、ITops 統合

インシデント プレイブック、容量計画

統計による管理、メトリック、効率性

継続的な滞欧

自動修復、FaaS、予測統計

自律監視

テレメトリ、指標、自己回復の構築

継続的な改善

アップグレード、機能、修正、変更

ローカルの教訓を記録してグローバルな知識にする

積極的で受容性のある、反省会

DevNetOpsのメリット

  • チームの文化と行動が信頼性エンジニアリングと一貫していて、それらが小規模で頻繁な導入と組み合わされると、チームと企業のパフォーマンスは向上します。1
  • DevNetOpsでは、ベンダーのシステムの統合、特にソフトウェアのアップグレードとパッチをより迅速に行うことができます。この迅速化でベンダーを説得し、小さなペイロードを短期間で提供しながら、機能や修正のための長いリードタイムの問題を解決します。これにより、ベンダーの市場投入までの時間とオペレーターの導入までの時間の差を大幅に縮めることができます。
  • DevNetOpsによってエンジニアのストレス(導入に関する心配)が減り、仕事に対する満足度が向上します。

NRE、DevNetOps、DevOpsの関係性とは

DevOpsとDevOpsのエンジニアたちは、業務アプリケーションの開発と運用に携わっています。ネットワーク、特に一部のタイプのSoftware-Defined Networking(SDN)には、アプリケーションクラスターを実行するという役割があります。ただし、ネットワークは企業内にも存在し、サービスプロバイダはソフトウェアアプリケーションとプラットフォームを実行するドメインと、開発用のドメインを分離しています2。エンタープライズアプリケーションに特化したNetOpsネットワークの例としては、ワイドエリアバックボーン、トランスポート、バックホール、データセンターアンダーレイネットワークなどがあります。

DevOpsとDevNetOpsの区別は、同じ企業のチーム間で行うのではなく、ベンダーと顧客の間でネットワークのDev-Opsを分離することで行います。たとえば機能の迅速な反復や製品の実験など、一部のDevOpsの目標は、ネットワークの基盤インフラストラクチャの典型的な目標ではありません。それにもかかわらず、DevOpsの原則とメリットはネットワーキングにも同じように当てはまります。

DevOpsと同様に、DevNetOpsは理念、原則、ベストプラクティスの集合体ですが、それらはネットワーク信頼性エンジニアリング(NRE)によって実装されます。「Dev」と「エンジニアリング」の目標は同じです。しかし、DevOpsの原則が継続的学習に向けて反復と進化の速度を上げる一方で、NREは信頼性を第一の目標として重視しています。この2つは、「何を」と「なぜ」という対の目標であり、それぞれを補い合っています。