손상된 패키지 자동 복구

손상된 패키지 자동 복구

우리 조직의 IT 부서는 정기적으로 운영 체제 패치를 프로젝트 프로덕션 서버(Ubuntu-18.04 LTS 및 Ubuntu-20.04 LTS)에 푸시하므로 애플리케이션(Docker, Kubernetes, MYSQL, 시스템 커널 등)은 자동으로 최신 버전과 일부 앱에는 서비스 관련 오류가 표시됩니다. 이로 인해 애플리케이션 실행에 많은 문제가 발생하고 생산에 영향을 미칩니다. 우리는 자동 패치로 인해 발생하는 문제를 해결하는 데 많은 시간을 소비합니다.

패치를 중단하기 위해 IT 부서와 많은 논의를 했으나 자동 업데이트는 보안 취약점으로 이어질 수 있어 중단할 수 없다고 했습니다.

프로덕션 환경에 IT 자동 패치 방법이 권장됩니까? 다른 회사에서는 이 문제를 어떻게 처리하는지 알려주세요.

이 문제에 대한 몇 가지 생각/제안이 도움이 될 것입니다.

미리 감사드립니다.

답변1

비프로덕션 환경에서 먼저 테스트하지 않고 업데이트/패치된 패키지(실제로 사용자 정의 애플리케이션 코드의 종속성)를 프로덕션에 푸시하는 것은 좋지 않습니다. 이는 비프로덕션 환경에서 먼저 테스트하지 않고 자신의 사용자 정의 애플리케이션 코드(또는 라이브러리/클래스/모듈과 같은 종속성)의 변경 사항을 프로덕션에 적용하는 것만큼 나쁩니다.

보안 패치는 중요하지만 가동 시간과 고객 서비스 수준 계약(SLA)을 충족하는 능력도 중요합니다. 패치를 적용하여 완벽하게 보안을 유지할 수 있지만 패치로 인해 서비스가 계속 중단되어 모든 고객을 잃게 되면 모두가 손해를 보게 됩니다.

조직은 합리적인 시간 동안 패치 수준이 안정적으로(변경되지 않고) 유지되는 절충안을 마련한 다음(고객 SLA가 영향을 받지 않도록) OS 패치를 애플리케이션 코드와 마찬가지로 일반적인 비프로덕션 테스트 환경 시퀀스에 배치해야 합니다. : 개발, QA, 통합, 스테이징 등을 수행하고 OS 패치와 작동하도록 테스트된 애플리케이션 코드와 함께 프로덕션에 적용됩니다.

관련 정보