ネットワークツールを連携させ、データを統合し、ネットワーク運用をオーケストレーションする方法
ネットワークおよびツールチームのための実践的な統合ガイド ほとんどのエンタープライズネットワーク運用チームは、多数のツールを活用しています。監視ツールは異常を検知し、ITSMはチケットキューを管理し、IPAMはアドレスデータを保持します。
ソフトフォンで [応答] をクリックして、電話に出ました。 私の一部はそれを無視したかったのですが、この問題はあまりにも長い間私を悩ませていました.
それは、アプリケーション チームのメンバーの XNUMX 人でした。 彼は建物の反対側に数百フィート離れたところに座っていましたが、ほとんどの場合、私たちは何百万マイルも離れているように感じました.
この新しい実装のプロジェクト マネージャーも今、ホバリングしていました。 私は彼女が好きでしたが、彼女は緊張していました。 顧客とその件に関する他のすべての人は、昨日これが機能することを望んでいました。
「VLAN に問題がある可能性はありますか?」と、電話越しの声が尋ねました。
無意味な質問でしたが、私はそれを言うつもりはありませんでした。 率直に言って、ファイアウォールに問題があるかどうかを彼が尋ねなかったのには驚きました。 私は、この問題で調べていた単一の VLAN 内または VLAN 間でブロッキングがまったくないことを彼に保証しました。 これがネットワークの問題だとは本当に信じていませんでしたが、通常、最初に非難されるのはこれです。
私たちは再び行き詰まりに陥ったため、昼食後に他のチームリーダーとのミーティングを予定しました。
私はオフィスを出て、バーガーキングを手に取った. 電話は午後1時だったので、急いで戻らなければならなかったのでイライラしましたが、少なくとも机に戻ったときは、フライドポテトを食べて、背の高いコーラを飲みました。
電話会議に参加した直後に、セキュリティ マネージャーは、特定の VLAN 間で分離していない理由について質問し始めました。 もちろん、これは問題とはまったく関係がありませんでしたが、私たちのネットワークと、この場合、アプリ サーバーとバックエンド データベースの間に何もないことがどうして良かったのかを説明する義務がありました。 それはすべてレイヤ 2 であり、率直に言って、私たちのセキュリティ担当者がまだ私たちのネットワークを知らなかったことに腹を立てていました。
プロジェクト マネージャーが割り込んできて、結論を出すために接続のトラブルシューティング方法を丁寧に尋ねました。 彼女は私が聞いた「レベルセット」や「バブルアップ」などの用語を使用しましたが、意味不明であると即座に却下しました.
どう答えたらよかったの？ 彼女は頭が良いことは知っていましたが、ネットワーキングについては何も知りませんでした。 私はパスの追跡について話し始め、そのようなことはすぐに誰かがパスでファイアウォールを立ち上げる結果になりました。 最初は誰がそれを持ち出したのかわかりませんでした。アプリケーション チームのメンバーだったと思います。
私は目を丸くしましたが、少なくとも、ストレージまたはアプリケーションチームの誰かがタイムアウトについて話し始めました。
ビンゴ！
私は彼の言ったことを確認するために興奮して飛び込み、サーバーが通信しているがタイムアウトした場合、接続は問題ないと説明しました. 特にデバイス間はすべてレイヤー 2 であったため、タイムアウトを引き起こす構成がないことを確認しました。 これは、どういうわけか、グループ全体が受け入れました。 ようやく少しずつ前進し始めました。
この問題は家のアプリケーション側にありましたが、ネットワーキングについて大雑把な知識しか持っていない人々とネットワークの問題の可能性を調査するために、いくつかの会議が必要でした. 確かに協力したいという気持ちはありましたし、問題が解決した後は大笑いしましたが、そこに至るまでのプロセスは苦痛でした。
最初、問題のアプリケーションまたはバックエンド ストレージについては何も知りませんでした。 彼らは実際にどのようにお互いにコミュニケーションをとっていたのでしょうか? どのポートが使用されていましたか? これは本当に完全な停止でしたか、それとも断続的な停止でしたか?
秒、残りのチーム リーダーのほとんどはネットワークについてほとんど知識がありませんでしたが、すぐにそれが問題であると想定しました。 つまり、まずそうでないことを確認してから、ブロードキャスト ドメイン、TCP/IP、アクセス制御リスト、およびステートフル ファイアウォールについてほとんど知らない人々のグループにそれを証明する必要がありました。
三番、担当者はフルスタック エンジニアではありませんでした。つまり、プロジェクト マネージャーは、インシデントに関連するすべての技術分野を合理的に理解していませんでした。 これは、私たちが明確な方向に進んでいなかったことを意味します。 努力は確かに協力的でしたが、まとまりがなく、暗闇で撮影しているようにも感じました.
私の経験は特別なものではないと思います。 私たち技術専門家の多くは、協力しようとして非難合戦を経験しています。 エンタープライズ IT では、サイロ間の部族的な知識がいまだに非常に現実的です。時折、深い技術知識を持つフルスタック エンジニアやプロジェクト マネージャーがいるかもしれませんが、概して、私たちはまだ壁で囲まれたチームと最小限の知識共有に対処しています。
その中で私が直面した問題 アプリケーションのトラブルシューティング 私はこのことを説明しました。 個人的には、各チーム リーダーは自分の領域を非常によく知っていましたが、お互いの領域についてはほとんど知りませんでした。 たとえば、アプリケーションがバックエンド サーバーとどのように通信しているかはわかりませんでした。また、このトラブルシューティング セッションまで、どのサーバーが互いに通信しているかもまったく知りませんでした。
また、アプリケーション担当者は、これらの特定のサーバー間にファイアウォールがないことを知りませんでした。 私たちの発券システムでインシデントを作成する前に、彼らがその XNUMX つの理論だけでどのくらい議論したのか疑問に思う必要があります。
その上、インシデントを処理するプロジェクト マネージャーは、不適切な言葉遣いの電子メールとチケットのあいまいなメモ以外に、インシデントの技術的側面について統一された見解を持っていませんでした。
チームが特定の問題や設計について共同作業を行う場合、情報を共有することが重要です。 しかし、多くの場合、共有するのが難しいか、高レベルからランダムな情報を理解するのが難しい. ログ ファイル、データ ダンプ、電子メール、およびチケットのメモはすべて適切な場所にありますが、暗闇の中でコラボレーションしようとしているチーム間のギャップを埋めるためのより優れたソリューションが必要です。
最も一般的なトラブルシューティング手順を自動化することは、簡単に共有できる情報のベースラインを取得する XNUMX つの方法です。 実際、洗練された自動化ツールは、最も一般的なトラブルシューティング タスクを単純に自動化するだけでなく、さまざまなプラットフォーム関連の show コマンドを実行して、問題が発生した時点でベースラインを取得する必要があります。
複数のチームが同時に同じ情報にアクセスして、技術的な詳細とグラフィック形式の両方で分析できるようになり、そうでなければ個々のチーム、さらに悪いことに個々のエンジニアの手にある知識が民主化されます。
私はストレージの専門家ではありませんし、アプリケーション開発の第一人者でもありません。 私の推測では、ほとんどの企業組織では、エンジニアは私と同じようにまだ XNUMX つまたはいくつかの分野に特化していると思います。 アプリケーションの速度低下の原因や、インフラストラクチャのパスが完全に壊れている理由を特定するために迅速に前進する場合は、協力する必要があります。
非難のゲームを拒否し、知識を民主化し、チーム間で簡単に利用できるようにするツールを利用するコラボレーションの文化は、私たちのローカルドライブに蓄積するのではなく、確かに最初にネットワークを非難するのではなく、前進する方法です.