사용자에게 보이는 기능을 모니터링하고, 이를 진단할 수 있는 충분한 리소스 및 애플리케이션 증거를 추가하며, 적시에 사람의 조치가 필요한 상황에만 호출하십시오. 각 경고에 담당자, 첫 단계 및 에스컬레이션을 연결하십시오. 사고 중에는 완화를 조정하고, 증거를 보호하며, 실제 사용자 여정을 통해 복구를 검증하십시오.
중요한 기능부터 시작하십시오.
서버가 핑에 응답한다고 해서 애플리케이션이 작동한다는 것이 입증되지는 않습니다. 공개 페이지 검색이나 통제된 테스트 엔드포인트 접근과 같은 대표적이고 무해한 사용자 여정을 선택하십시오. 성공이 무엇인지 정의하고, 실행할 때마다 실제 주문을 생성하거나 콘텐츠를 게시하거나 고객 알림을 보내는 합성 검사를 피하십시오.
애플리케이션 내부뿐만 아니라 적절한 외부 관점에서도 모니터링하십시오. 외부 관찰은 서버가 보지 못하는 접근 또는 라우팅 문제를 드러낼 수 있습니다. 내부 측정은 여정이 실패한 이유를 설명할 수 있습니다. 모든 지표를 사용할 수 있다는 이유만으로 큰 대시보드를 수집하기보다 두 관점을 기능에 연결하십시오.
진단 가치가 있는 신호를 선택하십시오.
Google의 SRE 지침은 지연 시간, 트래픽, 오류 및 포화를 사용자 대면 시스템에 유용한 신호로 강조합니다. 이를 사용하여 응답 시간, 요청량, 실패한 요청 및 제한된 리소스의 압박과 같은 동작을 설명하십시오. 하나의 지표 정의가 웹사이트, 전송 서비스 및 백그라운드 작업자 모두에 적용된다고 가정하지 말고 애플리케이션에 적합한 측정을 선택하십시오.
중요한 경우 성공한 요청과 실패한 요청의 동작을 분리하고, 평균만 보지 말고 느린 꼬리 결과를 조사하십시오. 서비스를 설명하는 경우 메모리 압박, 디스크 공간, 큐 깊이 또는 애플리케이션별 제한을 추가하십시오. 유용한 배치 작업 중에는 높은 CPU 수치가 정상일 수 있습니다. 사용자에게 보이는 영향이 즉각적인 조치가 필요한지 결정합니다.
모든 경고에 조치와 담당자를 지정하십시오.
경고는 영향을 받는 기능, 관찰된 상태 및 유용한 첫 확인 사항을 명시해야 합니다. 배포 전에 담당자와 에스컬레이션 경로를 지정하십시오. 즉각적인 중단이 필요한 상태와 예정된 검토에 적합한 항목을 구분하십시오. 반복적인 저가치 호출은 운영자가 시스템을 무시하도록 훈련시키고 중요한 신호를 인식하기 어렵게 만듭니다.
작은 경고 검토를 사용하여 모호함을 제거하십시오. 이 예시 표는 잠재적인 모니터링 결정을 설명하며, SwissOctet 지원 범위나 가용성 약속이 아닙니다. 임계값은 실제 애플리케이션의 기준선에 대해 테스트해야 합니다. 운영자가 경고가 해제된 시점과 여전히 검증해야 할 사항을 알 수 있도록 복구 조건을 포함하십시오.
| 관찰된 상태 | 유용한 대응 | 포함할 컨텍스트 |
|---|---|---|
| 대표적인 사용자 여정 실패 | 영향 평가 및 완화 | 영향받는 엔드포인트, 기간 및 최근 변경 |
| 계획된 한도에 근접한 디스크 | 증가 및 보존 검토 | 볼륨, 증가율 및 안전한 여유 공간 |
| 백업 검증 실패 | 복구 경로 보호 | 작업, 마지막 사용 가능 시점 및 오류 |
| 릴리스 중 지연 시간 증가 | 변경 사항 검사 또는 롤백 | 기준선, 릴리스 시간 및 영향받는 요청 |
작은 사고 대응 구조를 준비하십시오.
대응 프로세스는 압박 속에서도 이해할 수 있어야 합니다. 사고가 서로 다른 역할을 필요로 할 만큼 클 경우 코디네이터, 기술 작업을 처리하는 사람, 업데이트를 담당하는 사람을 지정하십시오. 작은 프로젝트는 역할을 결합할 수 있지만, 하나의 명확한 결정 지점이 여전히 도움이 됩니다. 서비스가 실패하기 전에 커뮤니케이션 채널을 합의하십시오.
Google의 사고 대응 자료는 조정과 완화 우선 접근을 강조합니다. 프로젝트에 맞는 규모로 이를 적용하십시오. 영향을 파악하고, 안전한 조치를 선택하며, 여러 운영자가 상충되는 변경을 수행하지 않도록 하십시오. 타임라인과 결정을 기록하십시오. 완벽한 설명을 찾는 것이 영향을 받는 기능을 복원하는 안전한 조치를 지연시켜서는 안 됩니다.
구체적인 성능 저하 상황을 살펴보십시오.
릴리스 후 사이트가 느려지는 상황을 상상해 보십시오. 외부 검사는 완료 시간 증가를 보여주고, 내부 측정은 애플리케이션 오류와 증가하는 데이터베이스 작업을 보여줍니다. 코디네이터는 범위가 정해진 사고를 선언하고, 증거를 보호하며, 한 사람에게 릴리스와 기준선을 비교하도록 할당합니다. 다른 사람은 관련 없는 인프라 변경을 수행하는 대신 테스트된 롤백 경로를 준비합니다.
롤백이 애플리케이션의 데이터 상태에 안전한 경우 이를 사용하고 결과를 관찰하십시오. 안전하지 않은 경우 운영 계획에서 지원하는 더 좁은 완화 조치를 선택하십시오. 무엇이 언제 변경되었는지 문서화하십시오. 더 큰 VPS 또는 포트는 나중에 평가할 가치가 있을 수 있지만, 즉각적인 결정은 인프라 크기가 원인이라고 가정하기보다 증거를 다루어야 합니다.
증거를 보호하고 복구를 검증하십시오.
운영 로그와 사고 노트에는 주소, 식별자 및 고객 정보가 포함될 수 있습니다. 조사에 필요한 것을 수집하고, 접근을 제한하며, 자격 증명이나 비공개 주문 토큰을 공유 보고서에서 제외하십시오. 보안 사고가 의심되는 경우, 급한 정리로 정보를 파괴하기보다 적절한 증거를 보존하고 프로젝트의 대응 정책을 따르십시오.
NIST의 사고 대응 지침은 대응을 더 넓은 사이버보안 위험 관리 안에 위치시킵니다. 복구에는 의도된 기능을 확인하고 사고를 가능하게 한 상태를 해결하는 것이 포함됩니다. 대응을 종료하기 전에 사용자 여정을 테스트하고, 리소스 동작을 검토하며, 백그라운드 작업을 확인하십시오. 경고 해제나 프로세스 재시작만으로는 유용한 서비스로의 완전한 복귀를 입증하지 못할 수 있습니다.
사고를 측정 가능한 개선으로 전환하십시오.
영향, 타임라인, 기여 조건 및 취한 조치에 대한 짧은 검토를 작성하십시오. 검증할 수 있는 변경에 집중하십시오. 검사를 개선하거나, 권한을 수정하거나, 롤백을 연습하거나, 누락된 복구 종속성을 추가하십시오. 담당자와 완료 기준을 지정하십시오. 나중에 아무도 구현되었음을 확인할 수 없는 모호한 의도의 긴 목록을 피하십시오.
SwissOctet에 배포할 때는 선택한 하드웨어 및 확인된 관리 방식과 별도로 모니터링과 대응을 애플리케이션 운영의 일부로 계획하십시오. 카탈로그는 상시 대기하는 사고 대응 팀이나 연속 지원 시간을 보장하지 않습니다. 프로덕션 환경에 의존하기 전에 누가 경고를 받고, 누가 조치할 수 있으며, 실제 서비스 약관이 무엇을 포함하는지 결정하십시오.
실용 체크리스트.
- 무해한 대표 사용자 여정을 모니터링하십시오.
- 애플리케이션 동작을 설명하는 신호를 선택하십시오.
- 경고에 조치, 담당자 및 복구 조건을 지정하십시오.
- 사고 전에 조정 및 에스컬레이션을 합의하십시오.
- 증거를 보호하고 완전한 복구를 검증하십시오.
- 검토 후 테스트 가능한 개선 사항을 할당하십시오.
중요한 세부 사항.
서버 가동 시간 모니터링으로 충분한가요?+
아니요. 접근 가능한 머신이 고장 난 애플리케이션을 호스팅할 수 있습니다. 사용자가 의존하는 기능을 모니터링하고 장애를 진단할 리소스 증거를 추가하십시오.
모든 지표 임계값이 누군가를 즉시 호출해야 하나요?+
아니요. 적시에 주의가 필요한 실행 가능한 상태에만 긴급 중단을 사용하십시오. 우선순위가 낮은 작업은 명확한 담당자가 있는 검토 프로세스로 보내십시오.
사고는 언제 종료되나요?+
영향받는 기능과 관련 백그라운드 작업이 검증되고, 즉각적인 위험이 처리되며, 후속 조치가 기록된 후입니다. 프로세스 재시작만으로는 충분하지 않습니다.
출처로 이동하세요.
이 참고 자료는 이 가이드의 기술 개념을 뒷받침합니다. 프로덕션 시스템을 변경하기 전에 최신 문서를 확인하세요.
- Google SRE: 분산 시스템 모니터링 sre.google
- Google SRE 워크북: 사고 대응 sre.google
- NIST SP 800-61 Rev. 3: 사고 대응 csrc.nist.gov
SwissOctet의 편집 지침. 예시는 설명용입니다. 서비스 사양, 사용 가능한 옵션 및 계약 조건은 별도로 확인해야 합니다.