자동 복구의 안전한 경계 설정하기

알려진 상태를 복구하세요

자동 복구는 정의된 실패를 자동으로 탐지하고 허가된 복구 조치를 시도합니다. 실패한 프로세스를 다시 시작하거나 비정상 인스턴스를 교체하는 것이 예입니다. 조치는 실패와 서비스의 상태 모델에 맞아야 합니다.

Kubernetes는 실패한 워크로드 인스턴스를 교체하고 선언된 상태에 맞출 수 있습니다. 잘못된 애플리케이션 로직이나 모든 저장소 실패를 수정하지는 않습니다. 인프라 복구와 소프트웨어 정확성에는 서로 다른 검사가 필요합니다. Kubernetes 자동 복구.

수단보다 목표를 먼저 정하세요. 내보내기를 복원한다는 것은 처리 대상 작업이 올바르게 완료된다는 뜻입니다. 실행 중인 컨테이너는 하나의 전제 조건일 뿐입니다.

세 가지 변경을 구분하세요

에이전트가 복구 후 수정을 제안할 수 있습니다. 그 제안은 새로운 소프트웨어 변경입니다. 복구 컨트롤러의 권한을 무제한으로 이어받아서는 안 됩니다.

컨트롤러는 검사 실패 시 자체 성공 기준을 수정해서도 안 됩니다. 그러면 서비스를 개선하지 않고도 개선되었다고 보고할 수 있습니다.

활성화 전에 복구 정책을 작성하세요

다음 정책은 가상의 예입니다. 숫자는 설계 선택을 설명하며 권장 기본값이 아닙니다.

최소 권한 ID를 사용하세요. 정책 버전, 실행 계기의 증거, 조치, 리소스, 결과를 기록하세요. 컨트롤러를 비활성화할 독립적인 방법을 제공하세요. 상위 대응 요청을 받을 사람을 정하세요.

성공적인 복구와 함께 실패 경로도 테스트하세요

재시도는 부수 효과를 반복할 수 있습니다. 워커가 파일을 저장하고 작업 완료를 확인하기 전에 멈출 수 있습니다. 다시 실행하도록 허용하기 전에 멱등성을 검증하세요. 클라우드 네이티브 실패 예시를 참고하세요.

재시도는 과부하 상태인 의존 서비스의 부하를 더 키울 수도 있습니다. 시도 횟수 제한, 시간 제한, 적절한 재시도 간격 증가를 사용하세요. 전체 워커의 재시도가 동시에 일어나지 않게 하세요. AWS는 백오프와 지터가 이런 증폭을 줄이는 이유를 설명합니다. 재시도 지침.

가상 정책을 세 가지 사례로 테스트하세요. 워커 하나가 멈추면 복구되어야 합니다. 데이터베이스 장애가 있으면 반복 교체를 막아야 합니다. 불확실한 무결성 실패에서는 자동화를 중지하고 대응 결정을 요청해야 합니다.

텔레메트리 누락도 확인하세요. 하트비트가 없다는 것은 워커 실패 또는 수집 경로 실패일 수 있습니다. 컨트롤러에는 AI 설명에 대한 확신이 아니라 조치를 뒷받침하는 충분한 증거가 필요합니다.

정책이 도움이 되는지 측정하세요

검증된 복구, 실패한 시도, 상위 대응 요청, 중복 작업, 사용자 영향이 지속된 시간을 기록하세요. 비슷한 조건에서 이전 운영 방식과 비교하세요.

근본 결함을 엔지니어링 작업으로 유지하세요. 메모리가 누수되는 프로세스를 반복해서 다시 시작하면 당장의 영향은 줄어도 누수는 계속됩니다. 지속적인 개선에서 관찰을 지속적인 수정으로 연결하는 방법을 학습하세요.