서비스 홍보 뒤 몰려든 봇: 방문 수와 서버 부하를 나눠 보는 법
Hacker News 소개 뒤 서비스가 느려졌지만 실제 이용자는 많지 않았습니다. 운영자는 요청 경로와 요청 주체를 나눠 서버 부하의 거의 절반이 한 요청 주체에서 왔다는 점을 찾았습니다.
주제
장애 대응
장애 대응 관련 글을 모았습니다. 유토모 테크로그에서 새 기술과 제품이 일과 제품에 만드는 변화를 살펴봅니다.
장애 진단 105회에 추론비 15센트: 싼 판단 모델이 맞힌 것과 놓친 것 (Jev)
105번의 장애 진단에 든 Jev 추론비는 약 15센트였습니다. 수집기가 한 일과 두 실패 사례를 통해 저비용 1차 분류와 심층 조사를 나눌 조건을 살펴봅니다.
밤새 불어난 클라우드 요금, 경고 메일보다 필요한 것은 자동 중단
AWS와 구글 클라우드의 자동 지출 중단은 적용 범위와 출시 조건이 다릅니다. 배포 전에 차단 대상과 복구 정책을 확인하는 방법을 살펴봅니다.
AI로 만든 서비스, 오류가 났을 때도 내 제품일까
AI로 시스템을 만들었지만 오류 앞에서 막힌 실제 독자의 편지를 살펴봅니다. 출시 전 설명할 수 있어야 할 범위와, AI의 수정 제안을 검증하는 질문을 정리합니다.
정상 앱도 광고가 끊길 수 있다: 구글 광고 정지와 이의신청의 빈틈
RACE 개발자는 보안 검사에서 문제가 나오지 않았는데도 구글 광고 계정 정지와 반복된 이의신청 거절을 겪었습니다. 계정은 복구됐지만 원인은 설명되지 않았습니다. 광고 집행 전 준비할 증빙과 대체 유입 경로를 짚습니다.
AI가 장애를 대신 처리할수록 더 중요해지는 훈련: 온콜 팀이 준비할 일
AI가 일상 장애를 처리할수록 온콜 팀은 더 어려운 사건을 적은 실습으로 맡게 됩니다. 시뮬레이션 중심의 준비도 훈련을 정리했습니다.
개발 도구가 8시간 멈췄을 때, GitHub 장애가 바꾼 운영 점검표
GitHub의 8월 17일 장애는 자동 확장이 놓친 사이드카 한계와 재시도 폭증이 인증·CI·Copilot까지 번진 사례입니다. 개발팀의 외부 의존성·용량·복구 점검표를 정리했습니다.
드문 데이터베이스 오류가 서비스 장애가 되기까지
Tailscale은 6개월간 SQLite 손상 19건을 추적해 체크포인트와 쓰기 트랜잭션의 희귀한 경합을 찾아냈습니다. 패치 뒤에도 복구 기록과 경고를 통해 수정이 실제 장애를 막는지 검증했습니다.
