대기 중 최악의 부분은 깨어나지 않는 것입니다. 깨어나 검색 문제를 건네주고 있습니다.
경고에는 결제 오류가 증가하고 있다고 나와 있습니다. 대시보드에서 뭔가 잘못되었음을 확인합니다. 그런 다음 실제 작업이 시작됩니다. 추적 보기를 열고, 로그를 스캔하고, 마지막 배포를 비교하고, 소유자를 찾고, 기능 플래그 상태를 확인하고, 이전 Slack 스레드를 검색하고, 버그가 API, 결제, 프런트엔드 또는 인프라에 속하는지 결정합니다.
아직은 진단이 아닙니다. 그것이 바로 검색입니다.
사고 대응에 숨겨진 세금
대부분의 프로덕션 디버깅 작업 흐름에서는 여전히 사람이 인덱싱 계층이라고 가정합니다. 도구는 신호를 방출하지만 엔지니어가 신호를 연결해야 합니다.
경고는 서비스를 알 수 있습니다. 추적은 실패한 범위를 알 수 있습니다. 로그 줄에 예외가 포함될 수 있습니다. Git은 무엇이 바뀌었는지 알고 있습니다. 코드 소유자는 누가 파일을 검토하는지 알고 있습니다. 배포 시스템은 어떤 커밋이 활성화되었는지 알고 있습니다. 이슈 트래커는 지난주에 동일한 실패가 발생했는지 여부를 알고 있습니다.
각 시스템은 유용합니다. 문제는 이들 사이의 격차다.
엔지니어가 사건의 처음 15분 동안 탭 사이를 이동하는 데 소비하면 조직은 두 배의 비용을 지불합니다. 버그는 여전히 살아 있으며, 이에 대해 가장 잘 추론할 수 있는 사람은 사무 업무에 관심을 집중하고 있습니다.
검색은 문맥이 아니다
로그 검색 중 오류 소음을 찾을 수 있습니다. 상태 코드에 대한 추적을 검색하면 증상을 찾을 수 있습니다. 타임스탬프로 커밋을 검색하면 후보를 찾을 수 있습니다.
그 어느 것도 문맥과 동일하지 않습니다.
맥락은 사고 개요가 숙련된 엔지니어가 먼저 묻는 질문에 이미 답변하고 있음을 의미합니다.
- 어떤 고객 경로가 실패하고 있습니까?
- 어떤 서비스, 엔드포인트, 작업 또는 대기열이 관련되어 있나요?
- 배포 후에 오류가 시작되었나요?
- 추적에 어떤 코드 경로가 나타납니까?
- 관련 파일의 소유자는 누구입니까?
- 이 서명이 이전에 나타났습니까?
- 가능한 가장 작은 수정 또는 롤백 경로는 무엇입니까?
해당 브리핑은 당직 엔지니어가 입력을 시작하기 전에 존재해야 합니다.
더 좋아진 첫 화면
사건의 첫 번째 화면은 빈 터미널이 아닌 준비된 사건 파일처럼 느껴져야 합니다.
프로덕션 신호, 의심되는 코드 경로, 최근 변경 세트 및 소유자가 표시되어야 합니다. 추측과 사실을 구분해야 합니다. 증거가 약할 때 말해야 합니다. 수정 끌어오기 요청 초안을 작성하기에 충분한 확신이 있는 경우 검토에 첨부된 관련 로그 및 추적을 사용하여 이를 수행해야 합니다.
이는 당직 판단을 대체하지 않습니다. 그것은 그것을 보호합니다.
인간의 관심은 "이것이 올바른 해결책인가?"라고 묻는 것이 더 좋습니다. "어느 탭에 단서가 있었나요?"
검토 전에 자동화가 수행해야 할 작업
좋은 사건 자동화는 지루한 조사 단계를 처리해야 합니다.
- 클러스터 중복 경고 및 오류 이벤트.
- 가장 유용한 추적과 로그를 하나의 요약으로 가져옵니다.
- 실패 기간을 배포 기록과 비교하세요.
- 스택 프레임과 범위를 파일, 함수 및 소유자에 매핑합니다.
- 증거가 뒷받침하는 경우에만 최소한의 패치 초안을 작성하십시오.
- 리뷰어가 검증해야 하는 가정을 설명하세요.
출력은 여전히 일반적인 풀 요청일 수 있습니다. 사실 그래야 합니다. 풀 요청에는 이미 검토, CI, 소유권, 토론 및 감사 추적이 포함되어 있습니다.
대기시간 기준이 바뀌어야 합니다
지금은 2026년입니다. 생산이 중단된 오전 4시에 엔지니어가 수동으로 셸 명령을 작성하는 것이 기준이 되어서는 안 됩니다.
기준선은 사건을 읽고, 주변 증거를 수집하고, 이를 코드에 연결하고, 검토 가능한 다음 단계를 소유자에게 전달하는 시스템이어야 합니다.
통화 중에는 항상 판단이 필요합니다. 먼저 검색 엔진처럼 행동할 필요는 없습니다.
