1년치 운영 로그를 다시 한 번
자동화는 어디서 무너졌는가 — 12개월 운영 사건의 분류.
블로그를 시작한 1월부터 11월까지, 우리 운영에서 발생한 사건/장애를 분류했다. 총 38건.
분류
| 분류 | 건수 | 비고 |
|---|---|---|
| 외부 의존 (RSS, API 5xx, timeout 무한 retry) | 14 | 가장 많음 |
| 시간/시간대 (cron mistake, UTC vs KST, DST 가정) | 6 | 한 번에 큰 영향 |
| 데이터 형 (스키마 변경, dict 채로 떠다님) | 5 | Pydantic 도입 후 0 |
| 메모리/리소스 (Pandas OOM, SQLite WAL) | 5 | |
| 인증/세션 (cookie 만료, 슬랙 OAuth bug) | 4 | 통일 전후 분포 |
| 알람 자체의 실패 (sendmail 같은 호스트) | 4 |
알아낸 것
- 사건의 36% 가 외부 의존. 외부 API 가 우리 시스템의 가장 취약한 표면. 모든 외부 호출에 timeout · retry 상한 · circuit breaker (간단한 카운터로도) 가 필요.
- 시간대 사건의 영향이 크다. 건수는 적은데 한 번에 데이터가 9시간씩 어긋나서 후속 처리가 줄줄이 잘못된다. cron 은 UTC 로 적는다는 규칙 도입 후 0 건.
- 알람 자체의 실패가 4건. 알람 채널을 같은 호스트/같은 의존 안에 두지 않는다는 단순한 규칙으로 다 막혔다.
자동화로 줄어든 것
- 새벽 알람 처리 시간: 평균 4.2분 → 1.8분 (한국어 요약 봇 도입 후)
- 사건당 평균 다운타임: 18분 → 7분 (텔레그램 알람 + 1차 진단 봇)
- 매뉴얼 운영 작업 시간: 주당 4시간 → 1.5시간
다음 한 해의 한 가지
운영 사건을 줄이는 자동화는 충분히 해봤다. 다음 한 해는 사건이 나도 무너지지 않는 시스템 — circuit breaker, idempotency key, replay 가능한 이벤트 로그 — 에 시간을 쓴다.
🛒 이 글과 어울리는 추천 상품
위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.