NetOps には敵ではなく支持者が必要
一日中楽しみにしていた食事に手をつけようとした時に、料理が生焼けであることに気が付きます。 イライラして、あなたは店員に厳しく話しかけ、チップを減らしてしまうかもしれません。 彼らは自分のせいではないのに、笑顔でそれを受け止めます。 結局、彼らはあなたの食事を用意しなかったのです。 しかし、彼らはキッチンとのインターフェースであり、最終的には、目に見えないところで起こる失敗の代償を払うのは彼らなのです。
レストランのサーバーであろうと、<ここにサービス名を挿入> のカスタマー サービス担当者であろうと、何か問題が起こったときにあなたの不安、フラストレーション、怒りの矢面に立たされるのは、一般的にあなたとやり取りする人です。
データセンターでも同様です。
IT は、より高い最適化とスピードを達成するという目標を掲げてデジタル変革を進めていますが、社内の「顧客」とやりとりする可能性が最も高いのは NetOps チームであり、プロセスが期待どおりに迅速に進まないと、不満を抱くユーザーの矢面に立たされることになります。
最新のもの/アプリ/サービスの導入を妨げているのは必ずしも「NetOps」ではないことを認識することが重要です。 スピードの妨げとなるのは、組織が IT 運用の変革を目指す際に、DevOps のすべての前提を採用できないことが原因であることが多いです。
DevOps を実行していますか、それとも自動化のみを行っていますか?
CAMS は、DevOps の中核となる原則を広めるために最も一般的に使用される手段です。 CAMS は、文化、自動化、測定、共有の略です。
これら 4 つのうち、自動化は最も熱心に受け入れられる可能性が高いでしょう。 IT 内のサービス速度を向上させるための取り組みにおいて、他の 3 つは置き去りにされたり、完全に無視されたりする傾向があります。
特に注目すべきは、一般的に無視されている 3 つの概念が絡み合っていることです。 チームが機能ごとに分離したまま、他のチームにとって重要ではない指標に重点を置いている場合、文化を変えることは困難です。 私たちは、自分たちが評価されるものに向かって努力します。 ネットワークの稼働時間で評価される場合、たとえ運用部門の担当者がapplicationの稼働時間の改善に努めていたとしても、私たちはネットワークの稼働時間に重点を置くことになります。
つまり、私たちが Red Hat と協力し、DevOps、NetOps、自動化の曖昧な世界に踏み込んだ「ネットワーク自動化の現状」調査を思い出すかもしれません。 その中で、NetOps が求める指標 (測定) と開発および運用に携わる人々が求める指標 (測定) の間に大きな隔たりがあることがわかりました。
NetOps のほぼ 4 分の 3 (73%) が「ネットワークの稼働時間」を主要な指標として挙げています。 一方、開発者と運用担当者の 59% は、「applicationの稼働時間」が主要な指標であると回答しました。 逆に、デプロイの頻度で評価される開発者と運用 (30%) は、NetOps (16%) とセキュリティ (17%) のほぼ 2 倍です。
この格差はなぜ重要なのでしょうか? 私の主な目標がネットワークを利用可能な状態に保つことであるならば、私はネットワークに集中して時間を費やすつもりです。 計測と監視（DevOps の共有コンポーネントにとって重要な後者）は、まずネットワークに重点を置き、次にapplicationに重点を置くことになります。 時間があれば。 誰もセキュリティに時間を割く余裕はなく、そもそもセキュリティで評価される人もいません。 実際、セキュリティに関して最も多く挙げられた測定基準は、<ドラムロールをお願いします>「ネットワークの稼働時間」であり、この基準で測定されたセキュリティ専門家の 59% がそう答えました。
依然として IT の中心であり、自動化とオーケストレーションを実装する必要があるチームを構成する人々は、必ずしも同じ目標に向かっているわけではありません。 この不整合の要因は、運用ドメインの継続的な分離です。 NetOps グループとセキュリティ グループは、「単一機能」チームの構成で作業する可能性が高くなります。 NetOps はネットワークを心配しています。 安全？ 安全。 操作? システムオペレーション。
しかし、それはそれよりもさらに深いところにあります。 なぜなら、大きなサイロの中にはさらに小さなサイロがあるからです。 マトリョーシカ(ロシアの入れ子人形) のように、NetOps 内には多くの異なるチームがあり、一見単純な「新しいサイト」リクエストでも、完了するまでにさまざまなチームを経由する必要があります。 このような要求を実現するには、多くのインフラストラクチャとapplicationサービスをプロビジョニングしてオンボードする必要があります。 新しいサイトには、それをホストするためのコンピューティング リソースとネットワーク リソースだけでなく、他の多くの要件も必要です。 Web サーバーとそのストレージ。 アクセス制御。 証明書とキー管理。 負荷分散。 ファイアウォールルール。 この「単純な」リクエストが通過しなければならない IT 内サイロのリストは、延々と続きます。
そして、NetOps サイロ内のサイロの1 つが自動化されていない場合、プロセスは急停止してしまいます。 このような要求に応えるには、数週間とは言わないまでも数日かかる場合があります。
外部から、つまり依頼者から見ると、NetOps は仕事をうまくこなせていないように見えます。 一見単純な要求に思えるものの実現になぜこれほど時間がかかるのかと問いただす人々の不安を背負っているのは、「相手先」であり、「連絡係」であり、「IT パートナー」である。 実際には、他のプロバイダーによって管理されているバックボーンの奥深くにあるルーターに問題がある場合、技術の初心者がインターネットの障害についてローカル プロバイダーを責めるのと同じように、私たちは NetOps を責めます。
敵ではなく擁護者になる
多くの組織にとって、より協調的で透明性の高い IT への移行はまだ始まったばかりです。 IT 部門の一部のグループは必要性を認識し、必要な変更を受け入れていますが、すべてがそうであるわけではありません。 applicationサービスに関する調査を実施してきた 5 年間で、ビジネスが求め、必要とするスピードを達成するために必要な文化的および組織的変化を実際に開始するのに必要な戦略的重要性のレベルに「DevOps」が達するとは考えられませんでした。 代わりに、組織は自動化を採用し、DevOps にとって重要な他の 3 つのコンポーネントを忘れてしまいました。
IT への DevOps の動きが単なる自動化以上のものであることを認識していないのは問題です。 速度を上げるにはパイプラインを自動化する必要があり、そのパイプラインは IT 内のほぼすべての運用ドメインとサイロを通過することを認識していないことが問題です。 つまり、影響を受ける全員が自動化に移行する必要があります。そうしないと、求めている展開の速度と頻度を実現できなくなります。 ただ自動化を導入するだけでは成功は期待できません。 自動化がサイロ化されたグループ間の境界を越える必要がある場合、大きな文化的変化がなければ失敗するでしょう。
必要な変化は上から起こらなければなりません。 特に組織変更。 自分たち自身を再編成するのは、とても無理ですよね？ 目標の優先順位を変更して、まったく異なる一連の指標を使用することはできませんよね?
それは不可能であり、必要な変更を行える人々を教育し、説得しない限り、自動化されたパイプラインの真っ只中で手動プロセスに縛られてしまうことになります。
したがって、NetOps をスケープゴートとして使うのはやめ、NetOps も不満を抱いている可能性があることを認識しましょう。 代わりに、意思決定者に対して、組織構造を再評価し、測定の優先順位を変更して、ビジネスと継続的なパイプラインの残りの部分との整合性を高める必要があることを思い出させます。
最前線にいる NetOps の人たちに怒鳴ると満足感が得られるかもしれませんが、そもそも怒りを引き起こした状況は実際には変わりません。 そして、変化がなければ、パイプラインはこれ以上速くなりません。
NetOps の敵ではなく擁護者になりましょう。 彼らは受けられるあらゆる援助を必要としている。