SQL을 통한 고객 영향 분석
내부 오류율은 고객에게 미치는 영향을 결정하지 않습니다. 사고 대응에는 결제 실패, 내보내기 지연, 데이터 사용 불가 또는 고객이 경험할 수 있는 기타 통제된 효과 등 문서화된 제품 결과가 필요합니다.
하나의 영향 행 정의
사건 및 승인된 보고 단위당 하나의 제한된 행을 내보내거나 파생합니다. 유용한 필드에는 incident_id, 가명 account_id, 계획 또는 서비스 계층, 제어된 impact_type, affected, impact_duration_ms, 환경 및 UTC 시간이 포함됩니다.
피해 인구뿐만 아니라 평가 인구도 유지하십시오. 조인이 영향을 받은 계정만 찾는 경우 결과 백분율에는 신뢰할 수 있는 분모가 없습니다. 집계 테이블에 고객 이름, 이메일, 요청 본문, 지원 메시지, 원시 콘텐츠를 포함하지 마세요. 승인된 응답자로 계정 수준 드릴다운을 제한합니다.
사건의 범위를 정하라
고객 영향 SQL 레시피는 계획별로 평가되고 영향을 받는 계정을 계산하고 영향을 받는 점유율을 계산하며 영향을 받는 행에 대해서만 평균 기간을 계산합니다. 해당 픽스쳐에는 영향을 받는 기업 계정 3개와 영향을 받는 스타터 계정 2개가 표시됩니다.
서비스 수준 검색 후 쿼리를 사용합니다.
- 사고 시작과 영향을 받은 제품 결과를 확인합니다.
- 동일한 전체 창에 대해 평가된 계정 모집단을 구축합니다.
- 계획, 지역, 경로 또는 검토된 다른 제한된 차원별로 영향을 비교합니다.
- 새로 영향을 받은 계정과 복구된 계정을 별도의 흐름으로 추적합니다.
- 사건 기록에 쿼리, 정의, 결과를 보존합니다.
승인된 대응 정책 없이 더 높은 계획을 더 높은 인간 영향과 동일시하지 마십시오. 계획은 우선순위 차원 중 하나이며 계약 또는 안전 요구 사항을 대체하지 않습니다.
복구 확인
복구는 고객에게 표시되는 워크플로가 다시 성공하고 지연된 재시도 또는 작업이 고갈되었음을 의미합니다. 롤백 타임스탬프만으로는 증거가 되지 않습니다. 전체 버킷을 계속 관찰하고 요청량이 사라지지 않았는지 확인하세요.
incident_impact_observed 이벤트 스키마는 필드 수준 시작 계약을 제공합니다. 사고 대응 가이드에서는 감지, 경로 및 릴리스 범위 지정, 타임라인 및 복구를 다룹니다. API 신뢰성 사용 사례는 영향 분석을 제공할 수 있는 더 광범위한 측정 전략을 제공합니다.