構成のドリフトとそれを防ぐ方法のガイド

構成のドリフトは、すべての IAAC 開発者にとって重要な懸念事項です。この記事では、構成ドリフト管理、その重要性、原因、および考えられる解決策について学びます。

構成ドリフトとは何ですか?

アプリケーション所有者は、顧客エクスペリエンスを継続的に向上させるために、アプリケーションと基盤となるインフラストラクチャを時間をかけて変更する必要があります。これらの顧客は、社内にいる場合も社外にいる場合もあります。

これらの更新や変更の結果として、アプリとインフラストラクチャの構成が変更されます。これらの変更は、有益な場合もあれば、システムの強化された状態を悪化させる場合もあります。構成ドリフトはこれを表す用語です。

構成ドリフトの仕組み

ソフトウェアの制作および配信システムが複雑になるにつれて、構成のドリフトが発生する可能性が高まります。通常、コードは開発者のワークステーションから共有開発環境、テスト環境と QA 環境、そして最終的にはステージング環境と運用環境に転送されます。

潜在的な影響は、パイプラインに沿ってドリフトが発生する距離に応じて増大します。開発者のラップトップにインストールされているパッケージのバージョンとテスト サーバーにインストールされているバージョンの間にわずかな違いがあるだけでも、問題のデバッグが遅れる可能性があります。通常、ステージングと本番のみが相互のレプリカであることが期待されます。多くの企業が毎日何度も新しいコードをデプロイするため、負担は非常に大きくなります。

構成ドリフトの一般的な原因

コミュニケーションの欠如

場合によっては、上流チームが下流パートナーによる変更についてコミュニケーションできず、その結果、下流システム全体がダウンしてしまうことがあります。

ホットフィックス

ホットフィックスは、アプリケーションの次回計画された更新まで待てない重大な問題に対処するために行われるコードの変更です。問題の解決に取り組んでいるエンジニアが、パイプライン内の他の環境に変更を加えたり、同じ修正を文書化しなかったりすることがあり、その結果、ドリフトが発生することがあります。多くの場合、元の問題を再導入すると、このずれが解決されます。

重要なパッケージのアップデート

重要なパッケージの更新は、ホットフィックスに似ています。どちらも高速で実行されます。主な違いは、将来のインシデントを回避するために重要なパッケージの更新が適用されることです。そのため、このような更新はホットフィックスと同様にドリフトを引き起こす可能性があります。

自動化の欠如

自動化によって構成のドリフトの可能性が完全に排除されるわけではありません。それは可能性を減らすだけです。

利便性の変更

開発者による変更は一時的なものである場合があります。たとえば、開発者が一部の機能をテストするためにテスト サーバーに新しいパッケージをインストールし、それを元の状態に戻すのを忘れた場合にドリフトが発生します。

構成管理はなぜ重要ですか?

構成ドリフトが大きな被害をもたらす可能性がある理由の 1 つは、ドリフトが壁の後ろの家での小さな漏水と同じように、インフラストラクチャの基礎を徐々に蝕むため、誰もそれを継続的に探していない場合、ドリフトが発見されない可能性があることです。

構成のドリフトが発見された場合、すべての原因となった構成のドリフトの根本的な原因を見つけるには時間がかかりますが、これは緊急時に貴重なリソースとなります。

ソフトウェア開発では、ドリフトはリリース サイクルを遅らせる大きな原因となります。不必要な労力が発生し、開発者の生産性が妨げられる可能性があります。

コストの削減

IT インフラストラクチャの詳細なイメージがあれば、重複やオーバープロビジョニングを特定することで、必要な全体量を削減できます。

生産性の向上

安定したよく知られた構成のクラスターにより、バッチ管理とインフラストラクチャ構築が可能になります。さらに、一意の (またはスノーフレーク) サーバーを制限することで、個々の設定を手動で管理する必要性が軽減されます。

より高速なデバッグ

一貫した構成により、デバッグ チームは構成ミスを排除できます。チームは、サーバー、サーバー クラスター、環境間の構成の不一致を探す必要がないため、他の潜在的な原因に集中してチケットをより迅速に解決できます。

構成のドリフトによって発生する問題

セキュリティ上の問題

安全でない構成は、セキュリティ侵害の最も頻繁な原因の 1 つです。保護された構成から始めた場合でも、構成のドリフトにより、他の攻撃やネットワーク侵害が発生する可能性が高くなります。

ダウンタイム

構成エラーによって重大なダウンタイムが発生する可能性があり、攻撃者が DoS 欠陥を利用したり、重要なサーバーを侵害したりする可能性があります。しかし、それだけではありません。ネットワーク デバイスの構成を変更して、パフォーマンスに影響を与えたとします。いつでも「ゴールデン コンフィギュレーション」に戻ることができますよね?構成に欠陥がある場合、サービスの復元にはさらに長い時間がかかります。

コンプライアンス違反

ISO 27001 、PCI-DSS、HIPAA などの規制に準拠するには、厳格なセキュリティ管理が必要です。構成のドリフトを停止しないと、コンプライアンスに違反する可能性があります。

パフォーマンスの低下

通常、構成は、意図した状態にあるときに最も最適な状態になります 。アドホックな変更はボトルネックや競合を引き起こし、ネットワークの最適化の試みを妨げる可能性があります。

無駄な時間

よく理解していないネットワークやネットワークのドキュメントと一致しないネットワークのトラブルシューティングには時間がかかることがあります。これは、構成のドリフトにより、ユーザーにダウンタイムが発生するだけでなく、ネットワークが本来の状態にあれば存在しなかった、または解決が容易だったはずの IT トラブルシューティングの問題が発生する可能性があることを意味します。

構成のドリフトを監視する際に注意すべきよくある間違い

理想的な世界では、開発者用のすべての環境サーバー (Dev/QA/Staging/Prod) が同じ構成を持つことになります。残念ながら、それは「現実の」世界では物事がどのように機能するかではありません。商用環境では、ソフトウェアに新しい機能が導入されると、アプリケーション所有者がインフラストラクチャを頻繁に変更します。

ソフトウェア環境を可能な限り均一にするためには、構成のドリフトを監視することが重要です。管理を構成すると、経費が削減され、生産性とデバッグ時間が向上し、ユーザー エクスペリエンスが向上します。

監視をできるだけ成功させるには、組織は構成管理を使用して構成のドリフトを監視する場合でも、間違いを回避する必要があります。

よくある間違いを以下に示します。

CMDB を保守しない

構成管理データベース (CMDB) を最新の状態に保つことは、構成管理の重要な要素です。構成管理データベースによって提供される、ネットワークのハードウェアおよびソフトウェアのインストールに関する情報を 1 か所で調べることができます。データは資産または構成アイテムごとに収集され、職場での可視性と透明性を提供します。

CMDB を保守しないと、企業は、ある項目の構成が別の項目にどのような影響を与えるかを完全に理解できなくなる危険にさらされます。組織は、その結果を理解せずに、インフラストラクチャとセキュリティに損害を与えるリスクを負います。

CMDB は、特に資産の数が増えると管理が困難になることがありますが、構成のドリフトを適切に追跡し、インフラストラクチャを理解するには、効果的なデータベースの編成と管理が不可欠です。

構成のドリフトを監視する方法の計画がない

組織には、監視が必要な大規模で複雑なインフラストラクチャが存在することがよくあります。どのコンポーネントを最も監視する必要があるかを判断することが重要です。そうしないと、構成管理がすぐに管理不能になり、混乱する可能性があります。

組織は、企業および特定の事業単位の監視にどの資産が不可欠であるかを指定する必要があります。最も重要なシステムが監視されますが、それは部門ごと、業界ごとに異なります。

自動的に監視しない

組織は、いくつかの方法で構成のドリフトを監視できます。ただし、一部のアプローチは他のアプローチよりも洗練され、成功しています。

構成のドリフトを手動で監視するにはコストと時間がかかります。手動監視では人的ミスの可能性も明らかになります。これは、会社のインフラストラクチャの設置面積が非常に小さい場合を除き、構成の変動を監視するための最良の手法ではありません。

自動モニタリングは、構成を望ましい状態に維持するための最も開発された効率的な方法です。専用の構成監視システムはドリフトを即座に検出し、迅速な修正を含むソリューションを頻繁に提供します。これにより、ビジネスのインフラストラクチャができるだけ早く、最小限の影響で望ましい状態に戻ることが保証されます。

構成のドリフトを監視する方法:

構成ドリフトが引き起こす可能性のある損害を認識すると、構成ドリフトの検出が最優先事項である理由が明らかになります。何を保持すべきか、そしてなぜそれがドリフトを生み出す変更として提示されたのかを知ることが、そのプロセスの最初のステップです。

何を探しているかを知る

組織全体にとって重要なコンポーネントと各ビジネスユニットにとって重要なコンポーネントを特定することで、組織の優先順位を付けることができます。

これは部門によって異なり、高度に規制された業界では広範囲にわたる場合もあれば、より狭いシステムクリティカルなファイル/アプリケーションのみに焦点を当てている場合もあります。システムの重要性によって、監視システムの頻度と重要度が決まります。

ベースラインを設定する

さまざまな設定により、運用環境とテスト段階の間には常に差異が生じます。ドリフトをチェックするためのベースラインは、各ステップがどうあるべきか、および許容される偏差の種類を定義することによって作成されます。

初期のテスト段階は、ユーザー受け入れテスト設定やゼロ ドリフト製造段階よりも高いドリフト許容値に適している可能性があります。

システムを監視する

必要な監視のレベルは、組織の成熟度、現在のシステム、ツール、チェックが必要な構成の総数、および必要な精査のレベルによって異なります。要件とコンプライアンスに応じて、監視は組織内の各部門で異なる場合があります。

構成のドリフトを防ぐ方法

モニタリングでは、構成のベースラインと許容ギャップが定義された後、インフラストラクチャが適切な構成に保たれるようにする必要があります。監視戦略がなければ、構成計画と文書の作成に時間が無駄になります。

構成のドリフトを監視するにはさまざまなアプローチを使用でき、多くの企業は成熟度とコンプライアンス要件に基づいて方法論とツールを組み合わせます。

常時手動監視

個々のマシン構成を手動で確認し、既知の構成ファイルと比較できます。人間的側面のため、このプロセスは依然としてエラーが発生しやすく、従業員の労働時間に関してコストがかかります。少数の特定のサーバー クラスター、またはインフラストラクチャの設置面積が控えめな企業で小規模にのみ使用する必要があります。

監査

チームは構成監査の一環としてサーバー構成を手動で検査し、指定されたモデルと比較します。これらの監査には、システムの構築方法を決定するための専門知識が必要であり、その後、システムを保存すべきかどうかを決定する文書化されていない機会について徹底的に調査する必要があるため、費用がかかる可能性があります。

また、監査チームは、次回の監査中に適用される構成文書に必要な調整を行います。監査は通常、時間とコストを考慮して、高価値クラスターまたはコンプライアンス重視のクラスターに対して保持され、通常は年に複数回、定期的に実行されます。

監査では、事前に決められたスケジュールでの一貫性と再現性のあるサーバー構成が保証されます。

ただし、次の監査まで、設定はドリフトして残ります。

リアルタイムの自動監視

自動化されたリアルタイム監視は、構成を望ましい状態に保つための最も洗練された方法です。これを行うには、専用のサーバー セットアップ ツールを使用してサーバーまたはサーバーのグループを構成する方法の説明とともに、サーバーまたはサーバーのグループを作成する必要があります。

これらのプログラムは、軽量エージェントを使用して、そのグループ内のサーバーの構成を監視し、その定義と比較します。

この自動プロセスはドリフトについて即座に警告し、通常はサーバーのドリフトを修正するためのいくつかの選択肢を提供します。

最後の言葉:

コンピューターまたはデバイス間で一貫性のない構成項目 (CI) が構成ドリフトの根本原因です。データセンター環境では、ソフトウェアとハ​​ードウェアの変更が完全に文書化または追跡されずにその場で行われる場合、構成のドリフトが自然に発生します。

高可用性および災害復旧システムの障害の多くは、構成のドリフトに起因します。管理者は、構成のドリフトを最小限に抑えるために、ハードウェア デバイスのネットワーク アドレス、デバイスにインストールされているソフトウェア バージョン、および行われたアップグレードに関する細心の記録を保持する必要があります。