대부분의 관측성 스택은 '무슨 일이 일어났나요?'라는 한 가지 질문에 답하는 데 탁월합니다.
다음 질문에서는 더 약합니다. 어디서 고쳐야 할까요?
이러한 격차는 사고 대응 속도가 느려지는 부분입니다. 팀은 오류율을 확인하고, 추적을 열고, 로그를 읽고, 배포 타임라인을 확인한 후에도 여전히 코드베이스를 직접 검색해야 합니다.
익숙한 사건
배포 후 API가 간헐적으로 500을 반환하기 시작한다고 상상해 보세요. 대시보드에 스파이크가 표시됩니다. 결제 서비스의 추적 지점입니다. 로그에는 유효성 검사 오류가 포함되어 있지만 메시지는 일반적입니다.
그 순간 팀에는 다른 차트가 필요하지 않습니다. 방향이 필요합니다.
- 체크아웃을 소유한 저장소
- 실패한 경로에 연결된 핸들러
- 유효성 검사 동작을 변경한 최근 커밋
- 수정 사항을 검토해야 하는 사람이나 팀
이것이 코드 컨텍스트입니다.
코드 컨텍스트가 중요한 이유
코드 컨텍스트가 없는 관찰 가능성은 인식을 생성합니다. 코드 컨텍스트를 통한 관찰 가능성은 복구 경로를 생성합니다.
차이는 작지만 운영상 중요합니다. 추적을 통해 요청이 실패했음을 알 수 있습니다. 게시/결제. 코드 컨텍스트는 유효성 검사 분기, 어제 변경된 파일 및 일반적으로 해당 영역을 검토하는 소유자를 가리킬 수 있습니다.
이러한 매핑을 통해 많은 사고의 첫 시간을 절약할 수 있습니다.
최소한의 유용한 컨텍스트
풀 요청에 전체 조사를 첨부할 필요는 없습니다. 리뷰어는 일반적으로 간결한 사실 집합이 필요합니다.
- 생산 증상
- 영향을 받는 서비스
- 파일이나 기능일 가능성이 높음
- 최근 배포 또는 코드 변경
- 소유자 또는 검토자
- 제안된 다음 조치
그 이상의 어떤 것도 그러한 사실을 뒷받침해야지, 묻어두어서는 안 됩니다.
대시보드가 멈추는 곳
대시보드는 시스템 동작을 확인하기 위한 것입니다. 풀 요청은 시스템 동작을 변경하기 위한 것입니다. 건전한 문제 해결 워크플로는 엔지니어에게 매번 수동으로 연결하도록 요청하는 대신 이러한 세계를 연결합니다.
신호가 코드를 찾을 수 없으면 경고는 다른 대기열 항목이 됩니다. 신호가 코드를 찾을 수 있으면 팀은 패치, 롤백, 백로그 항목 열기 또는 심층 조사 여부를 결정할 수 있습니다.
무엇을 향해 구축해야 하는가
실제 목표는 더 큰 관측 가능성 표면이 아닙니다. 더 짧은 경로입니다.
생산 신호 -> 코드 컨텍스트 -> 검토 가능한 작업
해당 작업은 끌어오기 요청일 수 있습니다. Jira 문제일 수도 있습니다. 문제가 업스트림 제공업체에 속한다는 메모일 수 있습니다. 요점은 제작팀이 말할 때마다 백지 상태에서 조사를 시작할 필요가 없다는 것입니다.
관찰 가능성은 실패를 보여줍니다. 코드 컨텍스트는 실패할 곳을 제공합니다.
