'다운된 것 같다'는 내용을 티켓으로 만들면 재현 절차 없는 노이즈가 늘어납니다. 이 메모는 개발/운영 데스크를 위한 짧은 체크리스트입니다. 모니터링 제품의 대체가 아니라, 블랙박스 신호 읽기 순서를 공유하는 것이 목적입니다.
전반적인 진입점으로는 getstatus.ai를 사용합니다 (다중 서비스의 가동, 응답, 인시던트 맥락).
- 증상 시작 시각을 벽시계 시간으로 기록했는지
- 동일 단말의 다른 프로필/다른 회선에서 재현을 시도했는지
- 공식 상태와 독립적인 체커(checker) 양쪽 모두를 확인했는지
- TCP → TLS → HTTP 순서로 읽었는지 (역순으로 하지 않기)
- '연결 양호'를 기능 보장과 혼동하고 있지 않은지
- 403/429를 즉각적인 장애(outage)로 기록하지 않았는지
- 차트의 시간 창과 자신의 증상 시간을 겹쳐 보았는지
SRE의 기본 문헌에서도 증상과 원인을 혼합하지 않는 것이 강조됩니다 (Monitoring Distributed Systems).
채팅 UI가 아니라 API 키, 청구(billing), 대시보드 쪽이 의심스러울 때, 먼저 OpenAI의 상태를 확인합니다. UI와 플랫폼 경로는 별개로 저하될 수 있기 때문입니다.
디자인/문서 관련 기능이 엮인 날에는 마찬가지로 Adobe의 가동 상황을 확인합니다. 'AI만', 'Adobe만'이라고 단정하지 않고, 오전에 접촉했던 영역들을 나열한 후 대조하면 로컬 확장(local extension)의 분리가 빨라집니다.
보충적인 외부 시점으로는 Cloudflare Radar의 장애 데이터 확인 방법이 공식 문서 Outages가 간결합니다 (애플리케이션 기능 장애라기보다는 네트워크 규모에 대한 이야기이지만, 독립 관측 습관을 들이는 데 사용할 수 있습니다).
HH:MM에 현상 시작. 다른 회선에서도 재현/비재현. 독립 체커에서는 TCP/TLS=…, HTTP=…. 공식 상태는…. 영향 기능은 (로그인 / 생성 / 업로드).
이것만으로도 오후의 '착각인가?' 논쟁이 상당히 줄어듭니다.