팀에서는 마치 비용이 결함에 포함된 것처럼 생산 버그에 관해 이야기하는 경우가 많습니다. 잘못된 조건이 배송되었습니다. 마이그레이션에서 극단적인 경우를 놓쳤습니다. 대기열 소비자가 너무 공격적으로 재시도했습니다. 코드를 수정하면 비용이 종료됩니다.
그 견해는 너무 작습니다.
프로덕션 버그의 비용은 버그를 발생시킨 코드 라인에만 국한되지 않습니다. 조직이 주변에서 생활하는 데 소비하는 시간입니다.
기다림이 사건의 양상을 바꾼다
5분 안에 수정되는 버그는 대개 코드 문제입니다. 한 시간을 기다리는 버그는 조정 문제가 됩니다. 하루를 기다리는 버그는 신뢰 문제가 됩니다.
동일한 근본적인 결함이라도 그것이 지속되는 기간에 따라 매우 다른 손상을 초래할 수 있습니다.
- 고객은 동일한 깨진 경로를 반복적으로 겪습니다.
- 지원팀은 확실한 답변 없이 티켓을 수집합니다.
- 영업 또는 성공 팀은 임시 설명을 작성하기 시작합니다.
- 엔지니어들은 무엇이 안전한지 확신할 수 없기 때문에 근처 배포를 일시 중지합니다.
- 더 많은 데이터가 불량하거나 부분적으로 처리된 상태로 시스템에 입력됩니다.
- 원래 배포 컨텍스트는 그것을 가진 사람들에게서 사라집니다.
이러한 비용 중 어느 것도 이국적이지 않습니다. 그들은 정상적인 생산 드래그입니다.
MTTR은 값비싼 시간을 놓쳤습니다
평균 복구 시간은 유용하지만 가장 많은 낭비를 초래하는 순간을 숨길 수 있습니다.
시계는 일반적으로 문제가 감지되면 시작되고 서비스가 복구된 것으로 간주되면 중지됩니다. 이는 신뢰성에 관해 중요한 사실을 말합니다. 실패를 이해하고, 소유자를 찾고, 증거를 수집하고, 검토 가능한 변경을 기다리는 데 사건이 얼마나 소요되었는지는 알려주지 않습니다.
문제 해결 워크플로의 경우 비용이 많이 드는 격차는 다음과 같은 경우가 많습니다.
alert -> evidence -> code path -> owner -> patch -> review -> deploy팀이 처음 네 단계를 압축할 수 있으면 코드 검토가 더 일찍 시작되고 최종 수정 사항을 평가하기가 더 쉬워집니다.
컨텍스트 붕괴는 실제 비용입니다
최신 코드는 추론하기가 더 쉽습니다. 저자는 변화가 일어난 이유를 기억합니다. 검토자는 토론을 기억합니다. 기능 플래그, 출시 계획 및 테스트 가정은 여전히 신선합니다.
시간이 지날수록 수사는 더욱 무거워진다. 엔지니어들은 몇 시간 전에 내린 결정을 다시 읽습니다. 배포 창을 재구성합니다. 대시보드를 다시 엽니다. 문제가 다른 사건과 관련이 있는지 묻습니다. 수정 사항은 여전히 작을 수 있지만 이를 병합하는 데 필요한 신뢰도를 구축하기가 더 어려워집니다.
빠른 교정은 속도에만 관한 것이 아닙니다. 팀이 컨텍스트를 갖고 있는 동안 컨텍스트를 보존하는 것입니다.
엔지니어링 대시보드에 비용이 항상 표시되는 것은 아닙니다.
일부 생산 문제는 원격 측정에서 미미해 보이지만 여전히 비즈니스에 타격을 줍니다.
권한 버그는 소수의 고가치 계정에 영향을 미칠 수 있습니다. 청구 상태 버그는 수동 재무 작업을 생성하는 동안 소량의 엣지 케이스로 나타날 수 있습니다. 결제 문제는 한 지역의 하나의 결제 방법에만 영향을 미칠 수 있지만 지원 영향은 즉각적일 수 있습니다.
엔지니어링 대시보드는 필요하지만 전체 복구 부담을 포착하는 경우는 거의 없습니다. 올바른 사고 요약에는 추적 및 로그와 함께 고객 경로, 가능한 경우 계정 또는 테넌트 영향, 지원 신호 및 코드 소유권이 포함되어야 합니다.
대기 비용을 줄이는 방법
팀은 동일한 루프에서 조사와 검토를 수행할 때 대기 비용을 줄입니다.
이는 다음을 의미합니다.
- 경고는 관련 추적 및 로그에 연결됩니다.
- 실패 창은 배포와 비교됩니다.
- 의심되는 코드 경로의 이름은 다음과 같습니다.
- 소유권이 자동으로 해결됩니다.
- 제안된 패치는 검토할 수 있을 만큼 작습니다.
- 불확실성은 자신감 있는 말 뒤에 숨겨져 있는 것이 아니라 눈에 보입니다.
AI 지원 교정이 유용한 경우가 바로 여기에 있습니다. 비밀 생산 변경을 해서는 안 됩니다. 증거를 준비하고, 가능한 가장 작은 수정 사항의 초안을 작성하고, 수락, 편집 또는 거부할 수 있는 풀 요청을 소유자에게 전달해야 합니다.
실제 측정 기준은 올바른 결정을 내릴 때입니다.
봇이 빠르게 차이를 생성하기 때문에 팀이 승리하는 것이 아닙니다. 올바른 검토자가 더 빨리 올바른 결정을 내릴 수 있으면 성공합니다.
때때로 그 결정은 "수정 사항 병합"입니다. 때로는 "롤백"되는 경우도 있습니다. 때로는 "이것은 업스트림 사건입니다." 때로는 "패치가 아닌 사람의 조사가 필요합니다."
기다리는 것은 모든 결정을 지연시키기 때문에 비용이 많이 듭니다. 목표는 광적인 자동화가 아닙니다. 목표는 생산 신호에서 증거 지원 조치까지의 더 짧은 경로입니다.
