NetOps は Github を採用しているが、vimdiff を使い続けている人物が 1 人いる
NetworkToCodeコミュニティが実施したNetDevOps Fall 2016 Surveyからのその他の洞察
NetworkToCode コミュニティには、ネットワーキングとコードに情熱を抱く人々が集まっています。 ありきたりな言い方かもしれませんが、これらの人々は、ネットワークの自動化が流行り（そして経営者の義務）になる前から、ネットワークの自動化に取り組んできました。
2016 年の秋、コミュニティは、ネットワークとコードに重点を置いた幅広い質問に関する調査を実施しました。 生の結果（上記リンク）は公開されています。 オンライン調査ツールの性質上、データを正規化しない限り (作業が必要です)、結果のデータ セットを分析するのは困難です。 幸運なことに、読者の皆さん、私はあなたに代わってその作業を行っており、よりグラフィカルでカラフルな方法で洞察を提供することができます。
賢明な読者は、私が長い間、一般的に「DevOps」原則と呼ばれるものをネットワークに適用することを提唱してきたことに気付くでしょう。そして、当然のことながら、このデータを掘り下げる際に私が多くのエネルギーを注いだのもその点です。
コードとネットワーキングに重点を置いたグループでは、DevOps に対する見方が少なくとも大部分肯定的であったことは驚くことではありません。 DevOps に「興味がない」と答えたのはわずか 6.75% で、25.74% がすでに DevOps を導入していると回答しました。 その他の大部分は、評価してはいないものの（28.27%）、少なくとも検討中（39.24%）でした。
この調査の優れた提供者は、Infrastructure as Code に関する NetOps の観点など、このトピックに関してかなり詳細な質問をいくつかしました。 これによってさらに無関心が広がり、約 10% が「興味がない」と回答しました。 興味深いのは、インフラストラクチャ・アズ・コードが「すでに運用中」であると主張したのはわずか 19.35% であったのに対し、回答者の 54% が構成の展開に自動化を使用し、さらに 66% が構成のアーカイブを自動化していると回答したことです。 構成管理を自動化している NetOps は 1 つだけです (構成変更の管理に vimdiff を堂々と使用している NetOps ではないことは確かです)。
通常、最初に思い浮かぶ質問は、「Infrastructure as Code とは何ですか?」です。 おそらくこれが、多くの人が「評価」や「検討」をしているにもかかわらず、実際に「実行」している理由の根本にあるのでしょう。 疲労の定義は現実であり、今日では明確な定義が提供されていないため、一時的な用語について結論を導き出すことは困難です (とはいえ、それが私たちの仕事なので、いずれにせよ結論を導き出すことになりますよね)。
では、NetOps は何を自動化するのでしょうか? デジタル変革を遅滞なく進めていくためにはそうする必要があると私たちは繰り返し伝えていますが、特にエンタープライズ ネットワークは、自動化を自由に試せる環境ではないこともわかっています。 これらは、今日のビジネス全体が依存している重要なネットワークです。 NetOps はかなり自動化されていることがわかりました。
構成の生成、アーカイブ、および展開は、現在自動化されている上位 3 つの操作です。 データの収集と報告も活発化しているようです。
実際、構成管理 (および冒険的な NetOps) を除いて、回答者の組織のかなりの数ですべての操作が自動化されているようです。
しかし、もちろん、構成関連のタスクの自動化は、それがどのくらいの頻度で行われるのか、そして、したがって、自動化が正当化されるのか、という疑問を投げかけます。 私は（おそらくこのトピックに関する現在の考えに反するでしょうが）、変更を本番環境にデプロイする頻度が低いほど、自動化の価値が実際に高まると主張します。 もちろん、自転車の乗り方を「忘れる」ことはありませんが、数か月または数年が経過すると、いわばサドルに戻って初めて乗るという経験は、苦痛な（間違いだらけの）経験になる可能性があります。 デプロイメントでも同様です。 しかし、それはまた別の日に話しましょう。
NetOps はかなり定期的に展開しており、約半数 (50.92%) がマイナーな変更を 1 日 1 回以上本番環境に展開し、37.59% がメジャーな変更を月に 1 ～ 5 回展開していることがわかりました。 これは、Web ネイティブで主に単一アプリをサポートする技術プロバイダー (Netflix、PayPal、Facebook など) が宣伝する驚異的な「1 日 200 回」にはほど遠いですが、平均 200 を超えるアプリケーションをサポートする企業としては、かなり速いペースでアプリを動かしています (当社のアプリケーション配信状況調査による)。
最後に、彼らはどのようにしてこれらすべての変化を管理しているのか疑問に思うでしょう。 タイトルにもあるように、変更の管理には vimdiff だけを使用していると主張する、誇り高い NetOps が実際に存在しました。 データの構造を考えると、それを本番環境の変更頻度と関連付けることは困難ですが、私はこの NetOps とぜひ話をしたいと思っています。なぜなら、外部からのプレッシャーに関係なく、自分にとってうまくいく方法を誇りを持って貫いている彼または彼女は私のヒーローだからです。
NetOps の残りの部分は何に依存していますか? 彼らの多くが Github を使用していることがわかりました。 正確には47%です。 また、別の大きなグループ (39%) は Rancid/Oxidized を使用しています。 Rancid (1991 年にカリフォルニア州バークレーで結成されたアメリカのパンクロック バンドと混同しないでください) は、構成のバックアップを管理するネットワーク ツールです。 Oxidized も設定バックアップを管理するためのネットワーク ツールで、RANCID の代替としてよく宣伝されています。Oxidized について詳しく知りたい場合は、専用のサブレディットがあります。
驚くべきことに、8% は構成の変更をまったく追跡していません。 私は一度ラボでこれを試してみましたが、片道 100 Mbps、反対方向 1.5 Mbps というひどく非対称なクロスネットワーク リンクになってしまいました。 はい、私は約 11 年前にグリーン ベイの研究所で偶然に現代のブロードバンド ケーブル モデルを再現しました。 いいえ、残念ながら私は印税をもらっていませんが、良いことに嫌がらせのメールも受け取っていません。 繰り返しになりますが、組織の規模とのクロス集計ができなければ、その根拠を理解するのは困難です。 興味深いことに、11.91% が 0 ～ 50 台のネットワーク デバイスを管理しているため、この 8% は管理可能な数のデバイスを管理しており、問題なく対応していると推測できます。 NetOps の最大のグループ (38.63%) は 1,000 台を超えるデバイスを管理しており、他の 28.23% は 251 ～ 1,000 台のデバイスを管理しています。したがって、NetOps の大多数は多数のデバイス (ほぼ間違いなく異機種) を担当しており、そのため、構成の変更を追跡することは、ネットワークの継続的な健全性だけでなく、ネットワーク オペレーターの健全性のためにも必要になると言えます。
一般的に言えば、NetDevOps の世界を、彼らが自ら名乗っているように、そして彼らが何を使用しているか、何を重要視しているか、そして彼らが活動する環境がどのようなものであるかについての見解を、たとえ 50,000 フィートの高さから眺めただけでも、私は本当に楽しみました。
NetOps は IT 組織のバックボーンであり、企業がデジタル変革を進め、ネットワークとそれを安全に稼働させ続けるオペレーターの負担が増大する中で、あらゆるものを稼働させ続ける責任がますます高まっています。
ネットワーク運用を従来のモデルから、より機敏な DevOps のようなモデルに全面的に見直すことは不可能だと思います。 ビジネスのデジタル変革と同様に、IT のデジタル変革も、ビジネスの軌道を狂わせる可能性のある既存のプロセスを中断させないことを念頭に、段階的に行われます。 この調査では、DevOps という名称ではないものの、あるいはそれが意味する純粋主義者の考えを完全に満たすものではないものの、企業ネットワークをデジタル変革の旅へと確実に前進させている変革が明らかに起こっていることが示されています。