比較的です 十分に理解 開発では、デッドコード（リファクタリング、または機能やアルゴリズムの変更のために使用されなくなったコード）をコードベースから削除する必要があります。 （そうしないと、バグのリスクが発生し、新しい開発者がデッドコードを理解する必要があるため、また実際に使用されているかどうかなど、新しい開発者が理解するのがはるかに困難になります。）同じ原則が他のITインフラストラクチャにも適用されます。
簡単な例：サイトが使用されなくなった後の、ロードバランサー上の未使用の仮想IPの削除。 表面的には、この構成をそのままにしておくことによるリスクやコストはありません。 確かに、それを削除することは間違いなくリスクが少なく、コスト（作業）も少なくなります。管理者なら誰でも知っているように、変更の導入はほとんどの停止が発生するときに行われるため、変更は回避されることがよくあります。 しかし、新しい人がロードバランサーの操作に関与する必要がある場合はどうなりますか？ または、XNUMX年後、アクティブなサイトとアクティブでないサイトの詳細が忘れられて曖昧になったときはどうでしょうか。 残念ながら、どのサイトが死んでいるかを示す大きな兆候はありそうにありません。 その時点で新しいアドレス空間への移動がある場合、未使用のIP仮想IPの移行にかなりの労力が費やされます。 DNSの変更。 VIPの再構成、追跡データベースの更新など。トラフィックのないサイトが正しく機能していることを確認するのが難しいため、変更が成功したかどうかに関する不確実性と相まって。
サイトが将来不要になると単純に判断できませんでしたか？ 単純ではありません。 おそらく、サイトは四半期末または年末にのみアクセスされます。
システムの無秩序な増加を監視することは、デッドコードクリープの別の形態である可能性があります。 おしゃれな新しいストレージシステムには独自の監視システムが付属しているため、ストレージ部門は監視を統合するのではなく、それに依存しています。 エンタープライズモニタリング システム。 新しいDBについても同じです。 新しいワイヤレスアクセスポイントなど。 間もなく、10、20、100を超えるさまざまな監視システムがあり、それぞれがデータのサイロ化されたビューを備えています。 もちろん、これにより、ユーザーからアプリケーション、ゲストVM、ハイパーバイザー、切り替え、ストレージ、およびその逆のパフォーマンスをトレースし、控えめに言っても、すべての要素と追加のワークロードを相互に関連付けることができます。 （通常は指差しを伴い、最後に数日後、上級管理職が関与し、最終的に根本原因を特定するための戦争室ができました。）
開発は通常、機能の提供、または変更の発生を目的としています。 IT運用は通常、物事を維持し、利用可能にすること、または変更を最小限に抑えることを目的としています。
エンタープライズITがより機敏になり、消費者（現在はすべてApple Storeのインスタントプロビジョニングと頻繁なアプリの更新に慣れている）の期待に沿ったサービスを提供する場合は、これを変更する必要があります。 ITは開発のようにならなければなりません–変化を受け入れます。 デッドコード（古いDNSエントリ、ネットワーク構成とアクセスリスト、ロードバランサー構成、仮想マシン、パペットマニフェストなど）をクリーンアップするリスクは、将来維持するリスクよりも少ないことを認識してください。 同様に、ポイントモニタリングをエンタープライズシステムに統合する努力は、長期的にはすぐに報われることを理解してください。おそらく次のトラブルインシデントで。 またはその前に、次の従業員が開始し、複数のシステムを学習する必要がなくなったとき。 または、実行中の監視システムが3ではなく、15つしかないため、次のサーバーの更新に必要なシステムが少ない場合。
仮想化、クラウド、ハイブリッドクラウドによって加速するデータセンターの変化のペースに伴い、デッドコードとシステムを削除するITの重要性は日々ますます重要になっています。
あなたの部門はこれにどのように対処していますか？