체계적 이슈 트래킹 & 장애 추적

작업·장애를 표준 체계로 인입·분류·추적하고 장애는 RCA 보고서로 재발 방지까지 닫는 운영 문화 정착

기간2021–2026 (상시)

소속래브라도랩스(LabradorLabs)

역할데이터 엔지니어 · 2026년부터 데이터 엔지니어링 리드

이슈 관리문서 관리RCA장기 추적Kubernetes긴급 대응

0작업자의 메모

이슈 관리는 결과물이 아니라 습관이라서 포트폴리오에 넣기 애매해 보일 수 있습니다. 하지만 5년 동안 1,000건 넘는 작업과 장애가 남아 있다면, 그것 자체가 운영 시스템의 일부입니다.

RCA를 표준화한 이유는 장애 보고서를 예쁘게 만들기 위해서가 아니라, 다음 장애 때 “지난번에 어디까지 봤는지” 바로 이어갈 수 있게 하기 위해서였습니다.

데이터 수집·처리 파이프라인과 DB 운영은 정상 작업과 긴급 장애가 끊임없이 섞여 들어옵니다. 이슈가 흩어지면 무엇이 진행 중인지, 왜 터졌는지, 어떻게 막았는지가 사람 머릿속에만 남아 추적이 끊깁니다.

업무 유형 태그 체계(예: 장애·개선·신규 개발)로 이슈와 문서를 1:1로 연결해 장애·작업의 추적성 확보
장애 발생 시 표준 포맷의 원인 분석(RCA) 보고서를 직접 작성 — 장애 현황 · 발견 시각 · 원인 분석 · 조치 · 재발 방지
수집·처리 파이프라인의 상태 플래그(예: processed)로 단계별 진행을 추적해 누락·재처리를 체계화
복제 지연·데이터 정합성처럼 장기 추적이 필요한 이슈는 별도 추적 단위로 묶어 지속 트래킹
장애 보고서를 위해 error.log·syslog 등 증거 보존 원칙 수립 (해결 전 디렉터리 삭제 금지 등) — 정확한 원인 규명을 보장

예를 들어 Kubernetes CoreDNS·Airflow 스케줄러의 CrashLoopBackOff, 노드 Inode 고갈로 인한 Pod Eviction 같은 장애를 직접 원인 분석해 RCA로 정리했습니다.

1,000건 이상 — 5년간 작업·장애 이슈를 직접 관리, 완료율 약 85%

57건 이상 — 긴급(Emergency) 온콜 이슈를 추적·대응

추적성 확보 — 업무 유형 태그로 이슈와 문서를 1:1 연결해 장애·작업을 끊김 없이 추적

재발 방지 표준화 — 빠른 인지 → 원인 규명 → 재발 방지 사이클을 표준 프로세스로 정착

데이터 엔지니어(2026년부터 데이터 엔지니어링 리드)로서 이슈 인입부터 RCA·재발 방지까지의 사이클을 단독으로 설계·운영하고 표준화했습니다. 업무 유형 태그·RCA 포맷·증거 보존 원칙을 세워 팀 전체가 추적 가능한 이슈 관리 문화를 정착시켰습니다.

개별 장애 사례(CoreDNS·Airflow CrashLoopBackOff, Inode 고갈 Pod Eviction 등)와 파이프라인 운영은 별도 항목으로 정리.