私たちの組織のIT部門は、定期的にオペレーティングシステムのパッチをプロジェクトプロダクションサーバー（Ubuntu-18.04 LTSおよびUbuntu-20.04 LTS）にプッシュするため、アプリケーション（Docker、Kubernetes、MYSQL、システムカーネルなど）は自動的に最新バージョンと一部のアプリではサービス関連のエラーが表示されます。これにより、アプリケーションの実行に多くの問題が発生し、生産に影響を与えます。我々は、自動パッチによって引き起こされる問題を解決するために多くの時間を費やしています。
パッチを中断するためにIT部門と多くの議論をしましたが、自動更新はセキュリティの脆弱性につながる可能性があり、中断することはできませんでした。
本番環境には IT 自動パッチ適用方法をお勧めしますか？他の会社では、この問題をどのように処理するかを教えてください。
この問題に関するいくつかの考え/提案が役に立ちます。
よろしくお願いします。
答え1
非プロダクション環境で最初にテストせずに、アップデート/パッチされたパッケージ（実際にはカスタムアプリケーションコードの依存関係）をプロダクションにプッシュすることはお勧めできません。これは、非プロダクション環境で最初にテストするのではなく、独自のカスタムアプリケーションコード（またはライブラリ/クラス/モジュールなどの依存関係）の変更を本番環境に適用するのと同じくらい悪いことです。
セキュリティパッチは重要ですが、稼働時間とカスタマーサービスレベル契約（SLA）を満たす能力も重要です。パッチを適用することで完全にセキュリティを維持できますが、パッチのためにサービスが中断され続け、すべての顧客を失うと、誰もが損害を受けます。
組織は、合理的な時間内にパッチレベルが安定して（変更されずに）維持されるトレードオフを作成し（顧客SLAが影響を受けないように）、OSパッチをアプリケーションコードと同様に一般的な非本番テスト環境シーケンスに配置する必要があります。 ：開発、QA、統合、ステージングなどを実行し、OSパッチと連携するようにテストされたアプリケーションコードと共に本番環境に適用されます。