장애는 언제나 미리 신호를 보낸다

이 글은 관측(observability) 카테고리의 다섯 번째 글,
관측의 끝이자 운영의 시작이다.
톤은 차분하지만 단호하게, **“예측 가능한 장애”**를 보여준다.

---

장애는 언제나 미리 신호를 보낸다

— 느림이 ‘사고’가 되기 전의 패턴들

장애 회고에서
자주 이런 말이 나온다.

• “갑자기 터졌어요”
• “예상 못 했어요”
• “전조가 없었어요”

하지만 로그와 지표를 다시 보면
대부분 이렇게 끝난다.

“아… 신호가 있었네.”

장애는 번개처럼 오지 않는다.
항상 느림이라는 언어로 먼저 말한다.

---

1. ‘전조’는 사건이 아니라 패턴이다

전조를 이렇게 찾으려 하면 실패한다.

• 에러 로그 한 줄
• CPU 급등 한 번
• 스파이크 하나

전조는 점이 아니라 선이다.

시간에 따라 반복되고,
서서히 빈도가 늘어나는 패턴

이 패턴을 못 보면
장애는 “갑작스러워” 보인다.

---

2. 가장 먼저 흔들리는 것은 평균이 아니다

전조의 시작은 거의 항상 여기다.

• 평균 응답 시간 ❌
• 처리량(TPS) ❌

대신 이것이 먼저 움직인다.

• p95의 완만한 상승
• p99의 간헐적 스파이크
• 느린 요청 비율의 증가

이건 의미가 명확하다.

“일부 요청이
먼저 큐에 들어가기 시작했다.”

 

---

3. “가끔 느리다”는 가장 위험한 말이다

운영에서 이 표현이 나오면
이미 신호가 온 것이다.

• “가끔 로그인 느려요”
• “특정 시간대에만 느려요”
• “한 번씩 튀어요”

이 말의 진짜 뜻은 이거다.

“큐가
비워졌다가
다시 차기 시작한다.”

아직 회복은 되지만,
여유가 사라지고 있다.

---

4. 타임아웃이 늘기 전, 이미 경고는 끝났다

중요한 사실 하나.

타임아웃은
전조가 아니라
결과다.

타임아웃이 보일 때는:

• p95/p99 상승이 한참 진행됐고
• 큐는 이미 안정 상태를 잃었으며
• 재시도는 준비를 끝냈다

그래서 타임아웃 알람은
늦다.

---

5. 재시도 증가도 ‘후행 신호’다

재시도는
장애의 원인이자 증폭기지만,
전조는 아니다.

• 재시도가 늘었다 → 이미 느리다
• 느려졌다는 신호는
  그 이전에 p95/p99가 보냈다

그래서 좋은 운영은
재시도 알람보다
지연 알람을 먼저 둔다.

---

6. “회복되는 스파이크”가 가장 위험하다

이 패턴을 기억하자.

• p99가 튄다
• 몇 분 후 정상으로 돌아온다
• 하루에 한두 번 반복된다

이건 좋은 신호가 아니다.

회복되는 스파이크는
시스템이
‘버티고 있다’는 뜻이지,
‘괜찮다’는 뜻이 아니다.

이 상태에서 트래픽이 조금만 늘면
회복은 멈춘다.

---

7. 예측 가능한 장애의 전형적인 타임라인

실무에서 자주 보는 흐름이다.

1. p95 완만한 상승 (경고)
2. p99 간헐적 스파이크 (주의)
3. 느린 요청 비율 증가
4. 타임아웃 소수 발생
5. 재시도 증가
6. 전면 장애

4번에서 움직이면 늦고,
1~2번에서 움직이면 산다.

---

8. “그럼 언제 개입해야 하나?”

이 기준을 기억하자.

p95가
평소 기준선을
지속적으로 벗어나기 시작할 때

이 순간이:

• 기능 축소
• 요청 제한
• 캐시 강제
• 분리 조치

를 가볍게라도 시작해야 할 시점이다.

---

9. 예측을 가능하게 만드는 단 하나의 습관

이걸 정착시키면
장애는 놀랍도록 예측 가능해진다.

“정상일 때의 분포를
정확히 알고 있는 것.”

• 평소 p95는 얼마인가?
• p99는 어느 정도가 정상인가?
• 느린 요청 비율은?

기준선이 없으면
전조는 잡히지 않는다.

---

10. 한 문장 정리

장애는
갑자기 오는 사건이 아니라,
계속 무시된 신호의 결과다.

---

관측 카테고리 정리 예고

다음 글에서는
관측 파트를 한 번에 정리한다.

관측이란
무엇을 보는 기술이 아니라
언제 행동할지를 정하는 기술이다
— 운영에서 살아남는 관측의 기준

이제 관측은
보고서가 아니라 의사결정 도구가 된다.