사고 관리 - 패턴 | 패턴 |

사고 관리 - 패턴

잘 설계된 운영 우수성에 대해 자세히 알아보기 → 사고 관리

패턴

찾을 위치	유사성
플랫폼 \| 모니터링	✅ 경고 아키텍처에는 심각도 분류가 포함되어 있어 중요한 사고(프로덕션을 사용할 수 없음, 데이터 손상, 보안 저하)를 페이지 온콜에 즉시 라우팅합니다.
플랫폼 \| 모니터링	✅ 심각도가 높은 사고(성능 저하, 부분 중단)는 신속한 업무 시간 조사에 대한 즉각적인 알림을 생성합니다.
플랫폼 \| 모니터링	✅ 경고(임계값 대비, 구성 드리프트)가 일일 요약에 집계되어 사전 예방적 조치를 취합니다.
플랫폼 \| 모니터링	✅ 경고 보강에는 영향받은 사용자 수, 오류 비율 백분율, 최근 배포, 관련 경고, 직접 대시보드 링크와 같은 진단 컨텍스트가 포함됩니다.
플랫폼 \| 모니터링	✅ 알림 컨텍스트는 별도의 쿼리를 통해 기본 정보를 수집하지 않고 즉시 상황 평가를 제공하여 확인까지 소요되는 평균 시간을 단축합니다.
플랫폼 \| 모니터링	✅ 경고 그룹화는 단일 기본 문제의 수백 개의 관련 경고를 집계 통계를 사용하여 하나의 알림으로 통합하여 경고 폭풍을 방지합니다.
플랫폼 \| 모니터링	✅ 그룹화된 경고는 응답자가 압도되지 않고 문제 패턴을 드러내는 수, 비율, 영향받은 트랜잭션을 표시합니다.
플랫폼 \| 모니터링	✅ 경고 일시 중지 - 예상되는 서비스 점검 기간 또는 자동 수정 기간 동안 알려진 전달 상태가 경고를 생성하지 못하도록 방지

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 모니터링	⚡️ 통합 실패로 5분 이내에 100개의 개별 알림이 생성되고 온콜 전화를 통해 각 알림은 타임스탬프를 제외하고 동일합니다.
플랫폼 \| 모니터링	⚡️ 경고에는 범위, 최근 변경 사항 또는 문제 패턴에 대한 컨텍스트가 부족하며, 온콜 엔지니어는 기본 정보를 수동으로 수집해야 합니다.
플랫폼 \| 모니터링	⚡️ 모든 경고는 심각도에 상관없이 동일한 채널을 통해 라우팅됩니다. 중요한 프로덕션 중단은 사소한 경고와 경쟁합니다.
플랫폼 \| 모니터링	⚡️ 서비스 점검 예약 기간 동안 경고가 발생하여 모니터링 시스템에 대한 Trust 훼손하는 거짓 양성을 생성합니다.
플랫폼 \| 모니터링	⚡️ 경고 그룹화가 없으며, 각 트랜잭션 실패로 사고 중 경고 폭풍을 생성하는 별도의 경고가 실행됩니다.
플랫폼 \| 모니터링	⚡️ 경고는 관련 대시보드에 대한 링크를 제공하지 않으며, 응답자는 사고 응답 중 모니터링 도구를 찾는 데 시간을 할애합니다.

패턴

찾을 위치	유사성
플랫폼 \| 운영	✅ 온콜 순환은 컨텍스트 보존 대비 매주 또는 매주 균형을 맞추는 부담 분포입니다.
플랫폼 \| 운영	✅ 모든 경고 유형에 대한 실행북이 문서화되어 딥 도메인 전문 지식 없이 통화형 엔지니어가 효과적으로 대응할 수 있습니다.
플랫폼 \| 운영	✅ 실행북에 문제 설명, 진단 단계, 수정 절차, 에스컬레이션 기준, 관련 문서 링크가 포함되어 있습니다.
플랫폼 \| 운영	✅ 런북은 사후 작업 항목을 통해 발전하는 버전 관리의 실시간 문서입니다.
플랫폼 \| 운영	✅ 핸드오프 절차에는 활성 문제, 최근 변경 사항, 알려진 위험, 예정된 서비스 점검을 포함하여 컨텍스트를 전송하는 순간적인 회의가 순환 중에 포함됩니다.
플랫폼 \| 운영	✅ 전환 중 정보 손실을 방지하는 쓰기된 핸드오프 노트 보완 구두 핸드오프
플랫폼 \| 운영	✅ 페이지 빈도, 시간 후 사고 수, 거짓 양성 비율을 측정하여 아키텍처 조치가 필요한 지속 불가능한 통화 부담을 식별합니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 운영	⚡️ 런북이 없으며, 온콜 엔지니어는 부족 Knowledge 의존하고 주제 전문가에게 자주 에스컬레이션합니다.
플랫폼 \| 운영	⚡️ 실행북은 팀 구성원이 액세스하고 업데이트할 수 있는 공유 버전 관리가 아닌 개인 문서에 저장됩니다.
플랫폼 \| 운영	⚡️ 온콜 순환 전환은 핸드오프 회의 없이 수행되며, 들어오는 엔지니어에게 활성 문제 및 최근 변경 사항에 대한 컨텍스트가 부족합니다.
플랫폼 \| 운영	⚡️ 아키텍처 개선을 촉진하는 대신 운영 영웅을 통해 무기한으로 지속되는 통화 부담
플랫폼 \| 운영	⚡️ 통화 시 메트릭(페이지 빈도, 시간 초과 사고, 거짓 양성)은 추적되지 않으며 부하 패턴은 표시되지 않습니다.
플랫폼 \| 운영	⚡️ 런북은 초기 배포 중에 한 번 생성되며 시스템이 발전하거나 새 오류 모드가 나타나면서 업데이트되지 않습니다.

패턴

찾을 위치	유사성
플랫폼 \| 운영	✅ 특정 문제 도메인을 처리하는 주제 전문가를 정의하는 기술 에스컬레이션 경로
플랫폼 \| 운영	✅ 관리 에스컬레이션 경로에서 심각도 또는 기간 임계값을 초과하는 사고에 대한 알림을 수신하는 관리자를 정의합니다.
플랫폼 \| 운영	✅ 공급업체 에스컬레이션 경로는 Salesforce에서 지원하는 사례 생성 절차 및 심각도 기준을 문서화합니다.
플랫폼 \| 운영	✅ 경영진 에스컬레이션 경로에서 비즈니스에 중요한 사고에 대한 알림을 수신하는 경영진을 정의합니다.
플랫폼 \| 운영	✅ 에스컬레이션 기준은 명시적이고 객관적입니다. 심각도 수준, 시간 임계값, 영향받는 사용자 수, 비즈니스 영향 평가
플랫폼 \| 운영	✅ 에스컬레이션 경로는 런북에 문서화되며 연락처 정보를 검색하지 않고 사고 중에 액세스할 수 있습니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 운영	⚡️ 에스컬레이션 경로는 문서화되지 않으며, 사고가 발생하는 동안 적절한 연락처를 찾는 시간을 낭비합니다.
플랫폼 \| 운영	⚡️ 에스컬레이션 기준은 모호합니다(“불량한 경우 에스컬레이션”); 응답자에게 에스컬레이션 시기에 대한 명확한 지침이 없습니다.
플랫폼 \| 운영	심각도 임계값이 정의되지 않으므로 관리 알림이 너무 늦게 수행되며, 경영진은 사용자에게 사고를 알 수 있습니다.
플랫폼 \| 운영	⚡️ Salesforce 지원 에스컬레이션 절차는 문서화되지 않으며, 팀이 지원 사례를 연기하여 중요한 응답 시간을 잃습니다.
플랫폼 \| 운영	⚡️ 주제 전문가 연락처가 오래된 경우, 순환 변경 시 에스컬레이션이 잘못된 사람에게 도달하거나 실패합니다.

패턴

찾을 위치	유사성
플랫폼 \| 운영	✅ 중요 운영 이벤트 후 5영업일 이내에 실수 없는 사고 후 검토 수행
플랫폼 \| 운영	✅ 죄책감 없는 문화는 개별 비난이 아닌 시스템 개선에 초점을 맞추어 정직한 평가를 위한 심리적 안전을 조성합니다.
플랫폼 \| 운영	✅ 타임라인에는 첫 번째 신호, 감지, 확인, 조사, 응답, 복구, 확인을 통한 초기 조건의 세부 순서가 포함되어 있습니다.
플랫폼 \| 운영	✅ 타임라인 타임스탬프 - 감지, 응답, 복구 단계의 기간 분석을 지원하는 각 이벤트
플랫폼 \| 운영	✅ 근본 원인은 사고를 직접 유발한 기술 오류 또는 조건을 식별하며, 기여 요소와 구분합니다.
플랫폼 \| 운영	✅ 기여 요소 분석은 사고 영향을 활성화하거나 강화한 조직, 프로세스 또는 아키텍처 조건을 보여줍니다.
플랫폼 \| 운영	✅ 감지 분석 - 사고가 감지된 방법 및 감지가 더 빠를 수 있는지 여부를 평가합니다.
플랫폼 \| 운영	✅ 응답 평가에서 응답 도중 성공한 항목과 필요보다 느린 항목 또는 어려운 항목을 식별합니다.
플랫폼 \| 운영	✅ 작업 항목이 구체적이며 할당되며 반복을 방지하거나 향후 응답을 개선하는 타임바운드
플랫폼 \| 운영	✅ 작업 항목에서 구체적인 과업을 촉진하는 모호한 개선(“모니터링 개선”)을 방지합니다(“10분 동안 API 오류 비율이 5%를 초과하는 경우 경고 추가”)

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 운영	⚡️ 사고 후 토론에서 문서 또는 체계적인 개선 사항이 없는 “배치 작업에 버그가 발생했으므로 수정되었습니다”의 결론을 내립니다.
플랫폼 \| 운영	⚡️ 사고 후 검토는 시스템 개선이 아닌 개별 오류에 집중하여 심리적 안전을 해소합니다.
플랫폼 \| 운영	⚡️ 기간 분석을 방지하는 타임스탬프가 없는 타임라인, 팀에서 감지 또는 응답이 느린지 여부를 파악할 수 없음
플랫폼 \| 운영	⚡️ 근본 원인 분석은 즉각적인 기술적 원인을 조직 또는 프로세스 기여 요소와 구분하지 않습니다.
플랫폼 \| 운영	⚡️ 감지 분석 건너뛰기, 사용자가 사고를 먼저 보고할 수 있는 모니터링 간격이 식별되지 않음
플랫폼 \| 운영	⚡️ 작업 항목은 소유자 또는 기한 없이 모호합니다. 개선 사항이 논의되지만 구현되지는 않습니다.
플랫폼 \| 운영	⚡️ 사고 후 검토는 5영업일 이내에 수행되지 않으며, 컨텍스트가 사라지고 개선을 위한 긴급성이 사라집니다.

패턴

찾을 위치	유사성
플랫폼 \| Knowledge Management	✅ 사고 후 검토는 문서화되고 조직 학습을 위해 즉각적인 사고 응답자를 넘어 광범위하게 공유됩니다.
플랫폼 \| Knowledge Management	✅ 사고 후 검토는 공유된 Wiki 또는 Knowledge 자료에 저장되며 태그가 지정되어 여러 사고에 걸쳐 패턴 분석이 가능합니다.
플랫폼 \| Knowledge Management	✅ 후속 검토 시 작업 항목 완료가 추적되어 후속 검토 없이 소급적인 토론이 반복되는 것을 방지합니다.
플랫폼 \| Knowledge Management	✅ 작업 항목 완료율은 개선 사항이 구현되었는지 아니면 단순히 논의되었는지 보여주는 운영 상태 지표로 측정됩니다.
플랫폼 \| 운영	✅ 사고 패턴이 여러 사고 전반에서 분석되어 아키텍처 투자가 필요한 시스템 문제를 드러냅니다.
플랫폼 \| 운영	✅ 사고 후 학습을 기반으로 실행북이 업데이트되어 절차에 실제 사고 대응 환경이 반영됨

안티 패턴

찾을 위치	불만 사항
플랫폼 \| Knowledge Management	⚡️ 사고 후 검토는 문서화되지 않으며, 학습 내용은 조직 전체에 분산되지 않고 사고 대응 담당자에게 남아 있습니다.
플랫폼 \| Knowledge Management	⚡️ 사고 후 검토는 팀 구성원이 역사에서 배울 수 있는 공유 Knowledge 자료가 아닌 개인 문서에 저장됩니다.
플랫폼 \| Knowledge Management	⚡️ 작업 항목이 정의되었지만 추적되지 않으며 완료율은 알 수 없으며 개선 사항이 구현되지 않습니다.
플랫폼 \| Knowledge Management	⚡️ 후속 조치 없이 소급이 효과적이지 않다는 사실을 인식하지 않고 작업 항목 완료율이 낮음
플랫폼 \| 운영	⚡️ 사고 패턴은 여러 사고에서 분석되지 않으며, 각 사고가 별도로 처리되므로 시스템 문제는 숨겨져 있습니다.
플랫폼 \| 운영	⚡️ 사고 후 실행북이 업데이트되지 않으며, 시스템이 발전하고 새 오류 모드가 나타나면 절차가 오래된 상태가 됩니다.

패턴

찾을 위치	유사성
플랫폼 \| 운영	✅ 평균 감지 시간(MTTD) 추적 사고 발생에서 감지까지의 기간 측정
플랫폼 \| 운영	✅ 평균 승인까지 소요되는 시간(MTTA)은 감지에서 전화 통화 엔지니어 승인까지의 측정 기간을 추적합니다.
플랫폼 \| 운영	✅ 평균 복원 시간(MTTR) 추적 탐지에서 서비스 복원까지의 기간 측정
플랫폼 \| 운영	✅ 안정성 향상 또는 저하 여부를 보여주는 월별 추세 검토를 통해 사고 빈도를 추적합니다.
플랫폼 \| 운영	✅ 변경 실패 비율 추적 조치가 필요한 프로덕션 사고를 유발하는 배포의 측정 비율
플랫폼 \| 운영	✅ 변경 실패율은 모든 배포의 소수 부분인 지속적으로 낮게 유지됩니다.
플랫폼 \| 운영	✅ 스프린트 계획 시 개발 팀과 사고 메트릭이 공유되어 백로그 우선 순위 및 아키텍처 개선 사항을 알려줍니다.

안티 패턴

찾을 위치	불만 사항
플랫폼 \| 운영	⚡️ 사고 메트릭은 추적되지 않으며, 팀은 응답 시간이 향상되거나 저하되는지 여부를 파악할 수 없습니다.
플랫폼 \| 운영	⚡️ MTTD, MTTA, MTTR은 측정되지 않으며, 팀은 감지 또는 응답이 지체 지점인지 여부를 식별할 수 없습니다.
플랫폼 \| 운영	⚡️ 변경 실패율은 추적되지 않으며, 팀에서 품질 게이트가 유효한지 여부를 알지 못합니다.
플랫폼 \| 운영	⚡️ 사고 빈도 추세는 매월 검토되지 않으며, 주요 사고가 발생할 때까지 안정성 저하가 감지되지 않습니다.
플랫폼 \| 운영	⚡️ 사고 메트릭은 개발 팀에 공유하지 않고 운영 팀에 유지되며, 아키텍처 문제는 해결되지 않습니다.
플랫폼 \| 운영	⚡️ 메트릭은 추적되지만 결정을 알리는 데는 사용되지 않습니다. 작업이 없는 측정은 노력을 낭비하고 값을 제공하지 않습니다.