ブログ GES ネットワークの謎を解明
ネットワークの謎を解明する: リバース エンジニアリングの技術 ネットワークにおいて、リバース エンジニアリングとは、何かがどのように構築されたかを調べてそれをコピーしようとすることではありません (ドイツのエニグマ マシンのように...)
自動化、オーケストレーション、 DevOps、スクリプト作成などが私のソーシャル メディア フィードを支配しています。 自動化とは、シンプルさ、スケーラビリティ、および記録保持のために、ボタンを押すだけで繰り返し可能な方法で手動タスクを実行する行為です。 OEM に応じて、これを実現する方法はたくさんありますが、どの方法が適切でしょうか?
コードとしてのインフラストラクチャと独自の自動化
これまで見てきたことは、OEM が自動化を実行するための独自の独自の方法を出し続けていることです。 次に、OEM に関係なく、インフラストラクチャをコードとして表示する Ansible のような OEM に依存しないアプローチがあります。 コードとしてのインフラストラクチャを使用すると、下にある OEM に応じて適切に処理される特定のクエリを実行できます。 どちらのアプローチについても、本質的に正しいとか間違っているということはありません。 私の観点からは、OEM 自動化ツールで大きな成功を収めてきました。 コードとしてのインフラストラクチャに対するサードパーティのアプローチでも、同様の成功を見てきました。
自動化のポイントは、明日は指数関数的な結果をもたらす可変リターンを今日達成できるようにすることです。
どちらの方法にも欠けているのは、混合アプローチです。 ここだと信じてる NetBrain 際立っている。 本格的な Ansible Tower のインストールと同じくらい深くなりますか? いいえ。しかし、それが自動化について議論するポイントです。 あまりにも頻繁に、人々がこう言うのを耳にします。 明日！"
何を知っていますか？ 彼らは通常正しいです。 自動化のポイントは、明日は指数関数的な結果をもたらす可変リターンを今日達成できるようにすることです。
自動化は最終的な結果をもたらします—それを使用する場合
たとえば、「ボブ」または「シェリル」が仕事で週に 1 時間節約できる時間を考えてみましょう。 額面通りにはあまり見えません。 ただし、週 52 時間は年 1 時間、つまり年 1.5 週間と 7 日です。 Bob と Cheryl のチームに 2 人のメンバーがいて、この最初の自動化ステップが全員に同じことをした場合はどうなるでしょうか? ビジネスでは、XNUMX 週間と XNUMX 日間の生産性が回復しています。 これはちょうどXNUMX時間でした。 XNUMX 人あたり XNUMX、XNUMX、または XNUMX 時間やったらどうなるでしょうか。 驚異的で、人々が考えるほどファンタジーではありません。
そこで、単なる「自動化」以上の価値を提供するものに投資してみませんか？ コードとしてのインフラストラクチャは優れていますが、コードを理解できる人はいますか? OEM 固有のアプローチは優れていますが、現在、それを実行する才能はありますか? または、最新の状態になるように再トレーニングできますか?
についても同じ議論が成り立ちます。 NetBrain、そして私は、それを使用する方法を学ぶことと、人々にそれを取得するよう説得しようとすることの両方の側にいました. 新しいテクノロジーには、追加のトレーニング、立ち上げ、採用が必要です。 違いは 範囲と使いやすさの融合. 新しいテクノロジーがどんなに優れていても、使いにくいものであれば誰も採用しません。 まだ Zune を使っている人はいますか? いいえ、私はそれを非常に疑っています。 （後ろの一人の男については、私はそれを理解しています—あなたはそれを愛しています。） しかし、ビジネスとして、私たちは個人のために設定している基準に目を向ける必要があります.
「ネットニュー」を超えた自動化
NetBrain オートメーション プロビジョニング (変更管理) だけでなく、運用も自動化する機会が提供されます。自動化に関するほとんどの議論は、「まったく新しい」ロールアウトと現在のロールアウトとの比較、および実装後の「まったく新しい」ロールアウトの管理方法に集中しているようです。多くの場合、これらは別のチームです。1 つのチームだけでなく、両方のチームの利点を理解するように注意する必要があります。インフラストラクチャをコードとして愛し、そのためのサポート パイプを構築する開発エンジニアについて話すとき、サポート エンジニアがそれを理解していないと、ボトルネックが発生し、ビジネスに悪影響を及ぼします。