statistical-debugging

4 posts

크래시 상관관계는 거짓말한다. 진짜 버그를 가리키게 만드는 방법

Statistical debugging은 크래시와 연관된 predicate를 찾지만, 상관관계는 파일과 줄 번호가 아니다. 상관관계 점수에서 실제 버그 위치까지 순위 매기기, 필터링, 삼각 측량하는 방법이다.

Statistical debugging은 근본 원인이 아닌 predicate의 정렬된 목록을 준다. 모든 분기와 null check를 계측하고, 십만 번의 실행을 돌리면, 알고리즘이 점수판을 건네준다. 의 의 중요도는 0.94다. 의 도 마찬가지다. 하나는 버그고, 다른 하나는…

Sentry의 Seer는 트레이스를 읽을 수 있다. 그렇다고 항상 근본 원인을 찾는 건 아니다

Seer는 트레이스 트리, 연결된 오류, 프로파일링 데이터를 수집해 분산 문제를 진단한다. 실제로 어떻게 작동하는지, 어디서 빛나는지, 여전히 인간의 도움이 필요한 곳은 어디인지 설명한다.

프론트엔드에서 500 오류가 발생했다. 스택 트레이스는 React 컴포넌트를 가리킨다. 실제 문제는 세 개의 서비스 뒤에 있고, 누수하는 백그라운드 작업에 의해 고갈된 데이터베이스 커넥션 풀에 있다. 트레이스 폭포를 클릭해가며 타임스탬프를 연관 짓고 커밋 기록을 읽을 수도 있다.…

Statistical debugging은 printf 디버깅을 끝낼 거라 했다. 대부분의 팀은 결국 작동시키지 못했다

Statistical debugging은 프로그램 동작과 실패를 연관 지어 버그를 정확히 찍어주겠다고 약속했다. 이 아이디어가 연구 논문에서 운영 환경 시스템으로 건너오지 못한 이유를 설명한다.

Statistical debugging은 시대를 끝낼 예정이었다. 코드를 계측하고, 수천 번의 실행에서 트레이스를 수집하고, 상관관계 분석을 실행하면, 도구가 크래시를 유발할 가능성 순으로 모든 분기와 null check를 순위 매기는 것을 지켜볼 수 있을 것이다. 2000년대 중반의…

테스트는 통과했는데, 데이터는 여전히 잘못되어 있다

Statistical debugging은 운영 환경 데이터를 신호로, 버그를 이상 신호로 다룬다. 단 하나의 단위 테스트도 추가하지 않고 데이터 손상, off-by-one 오류, 침묵하는 실패를 찾는 방법이다.

당신의 테스트 스위트는 초록색이다. 로그는 조용하다. 대시보드에는 빨간 선이 없다. 그런데 3%의 사용자가 음수 합계가 적힌 인보이스를 받고 있거나, 추천 모델이 삭제된 상품을 조용히 맨 위에 올리고 있거나, 집계 파이프라인이 특정 시간대의 환불을 이중 집계하고 있다. 이것들은 데이터…