StudyDad

AI 장애 분석 포스트모템 시리즈 9/9포스트모템 초안이 만들어지면 다음에는 공유 방식이 남았습니다. 공유 대상이 Mattermost, Teams, 사내 게시판, GitLab issue 중 무엇이든 원칙은 같았습니다. AI는 초안을 만들고, 최종 확정은 사람이 합니다.자동 공유 전에 두는 단계바로 자동 전송을 붙이지 않았습니다. 먼저 이 순서로 여러 번 사람이 돌려본 뒤 반복되는 단계만 골라서 자동화 후보로 옮겼습니다.사람이 시간 범위와 서비스명을 입력합니다.AI가 Datadog/AWS/Git 데이터를 조회합니다.AI가 포스트모템 초안을 만듭니다.사람이 fact와 assumption을 검토합니다.민감정보를 제거합니다.내부 공유 채널에 초안을 올립니다.승인 후 공식 포스트모템으로 이동합니다.사람 검토와 민..

AI 장애 분석 포스트모템 시리즈 8/9AI가 만든 RCA 초안을 그대로 공유하지 않았습니다. AI는 근거를 잘 모으지만 확정된 사실과 그럴듯한 추론을 같은 톤으로 섞을 때가 있었습니다. 편집에서 계속 붙잡은 건 다섯 가지 분리였습니다.FactAssumptionHypothesisRuled outActionFact — 출처가 있는 것만 남겼습니다이번 사례의 fact:GET /v3/auth traffic은 baseline 대비 6~10배 증가했습니다.major GC count는 0이었습니다./heartbeat는 ALB target group health check path였습니다.health check timeout은 30초였습니다.target group slow start는 0초였습니다.R2DBC pool..

AI 장애 분석 포스트모템 시리즈 7/9AI에게 장애 분석을 시키면 결과가 길게 나옵니다. 명령어, 로그, 표, 가설, 추천 조치가 한꺼번에 쏟아지기 때문입니다. 그런데 읽는 사람 입장에서 그건 아직 포스트모템이 아니었습니다.읽는 사람은 아래를 빠르게 판단할 수 있어야 했습니다.무엇이 일어났는가영향은 무엇인가확인된 사실은 무엇인가아직 가설인 것은 무엇인가무엇을 배제했는가어떤 조치를 해야 하는가그래서 AI에게 데이터를 조회시키기 전에 출력 형식부터 먼저 잡았습니다.형식을 먼저 정하면 결과가 안 흔들렸습니다같은 조사 조건이어도 형식을 안 정하면 결과가 매번 다르게 나왔습니다. 어떤 날은 timeline이 길고, 어떤 날은 root cause 후보가 먼저 나오고, 어떤 날은 action item이 빠졌습니다...

AI 장애 분석 포스트모템 시리즈 6/9장애가 나면 최근 배포부터 의심하고 싶어집니다. 이번 사례도 그랬습니다. 서비스는 ECS blue/green 방식으로 배포되고 있었고, 장애 중간에도 CodeDeploy deployment가 있었습니다.먼저 확인한 질문은 두 가지였습니다.1. 장애 직전에 새 코드가 배포됐는가?2. 장애 중간에 배포가 회복을 도왔는가, 아니면 악화시켰는가?배포 이력에서 실제로 본 것GitLab이나 사내 Git에서 아래 데이터를 봤습니다.merge requestpipelinedeployment jobimage tagtask definition revisiondeployment start/end timerollback 여부AWS ECS/CodeDeploy까지 연결해서 아래도 붙였습니다...

AI 장애 분석 포스트모템 시리즈 5/9Datadog에서 나온 후보를 그대로 결론으로 옮기지 않았습니다. 그래서 AWS로 반박할 수 있는지 먼저 봤습니다. 이번 사례에서 Datadog은 세 가지 큰 단서를 보여줬습니다.auth endpoint long span/heartbeat timeoutMySQL pressure이 세 가지를 AWS CLI로 ECS, ALB, CodeDeploy, RDS를 조회해서 다시 확인했습니다. 만약 AWS MCP를 붙였다면 같은 질문을 다른 도구로 던지는 문제였을 것입니다. 검증 방식은 도구와 별개였습니다.검증할 질문을 고정했습니다새 데이터를 많이 모으는 게 목적이 아니었습니다. 이번 단계에서는 Datadog 가설을 검증하는 데 집중했습니다. 그래서 질문은 다섯 가지로 좁혔습니..

AI 장애 분석 포스트모템 시리즈 4/9metric query가 열린 뒤 Old Gen부터 다시 봤습니다. 가장 먼저 확인한 건 요청량이었습니다.시간대요청량baseline9~16 RPS13:30 KST 전후약 70 RPS13:40 KST 전후약 103 RPSGET /v3/auth가 6~10배 늘어 있었습니다. 이때 top resource는 압도적으로 GET /v3/auth였고, /heartbeat는 background health probe에 가까웠습니다.Datadog indexed span 기준으로 GET /v3/auth 요청이 증가했고, 같은 시간대에 Old Gen은 상승했지만 major collection time은 0에 가까웠습니다.Old Gen 증가는 그 안에서 다시 의심하기로 했습니다.trac..

AI 장애 분석 포스트모템 시리즈 3/9Datadog scope를 보완하고 AI에게 첫 조사 요청을 넣었습니다. 이때 프롬프트에서 계속 붙잡고 있어야 했던 문장은 하나였습니다.Do not assume /heartbeat is the root cause.사람이 본 그래프를 알려주되, 그 그래프를 원인으로 확정하지 못하게 했습니다.초기 단서를 원인으로 못박지 않게 만든 프롬프트프롬프트 자체는 아래처럼 단정하지 않게 만들었습니다.Investigate production incident.Time:2026-06-12 13:00~14:00 KSTKnown clue:- Datadog screenshot shows a slow GET /heartbeat trace.- JVM Old Gen appears to incre..

AI 장애 분석 포스트모템 시리즈 2/9Datadog API Key와 Application Key를 환경변수에 붙였습니다. /api/v1/validate는 바로 200을 돌려줬습니다. 인증 자체는 성공이었습니다.하지만 같은 key로 metric query를 던졌을 때 답이 달랐습니다.GET /api/v1/query -> 403POST /api/v2/query/timeseries -> 403GET /api/v1/hosts -> 403APM trace search와 logs search, events, monitors는 열려 있었습니다. metric timeseries와 host inventory는 막혀 있었습니다.인증 성공은 분석 가능이 아니었습니다이 ..

AI 장애 분석 포스트모템 시리즈 1/9Datadog에서 GET /heartbeat trace 하나가 30초 timeout 경계에 붙어 있는 화면을 보고 있었습니다. 같은 시점에 JVM Old Gen이 올라와 있었습니다.초기 단서: 일부 GET /heartbeat span이 30초 timeout 경계에 붙어 있었습니다.이 스크린샷 한 장을 Claude Code에 붙여두고 원인을 물어보려고 했습니다. 그런데 프롬프트를 어떻게 써야 하나 잠깐 고민하다가 이상한 점이 보였습니다. AI가 볼 수 있는 건 이 화면 한 장뿐이었습니다.프롬프트보다 먼저 막힌 지점먼저 Datadog API Key와 Application Key를 환경변수로 붙였습니다. /api/v1/validate는 성공했습니다. metric quer..

운영 콘솔 아키텍처 시리즈 9/9아키텍처 문서를 쓸 때 가장 쉬운 방식은 구성도를 그리고 사용한 기술을 나열하는 것이다.React, S3, CloudFront, API Gateway, Lambda, RDB, Express.이 정보도 필요하다. 하지만 시간이 지나면 더 중요한 질문이 남는다.왜 그렇게 했는가?문제 상황운영 콘솔은 한 번 만들고 끝나는 도구가 아니다. 기능이 추가되고, 사용자 범위가 바뀌고, 데이터가 늘고, 장애가 발생한다. 그때마다 처음 설계한 사람이 모든 맥락을 기억하고 있을 수는 없다.특히 다음 질문은 반복해서 돌아온다.왜 콘솔을 하나로 합치지 않았는가왜 RDB를 쓰지 않았는가왜 Lambda 앞에 API Gateway를 뒀는가왜 일부 API는 상주 서버로 처리했는가왜 리포트 생성을 비동..