장애 자동 대응의 안전장치 (Guarded Alert Remediation)

"경보를 받아 컨테이너 재시작 같은 조치를 자동으로 실행하면, 잘못된 명령이나 위조된 요청, 연쇄 실행은 무엇으로 막는가?" 이 페이지는 그 질문에 답한다. Guarded alert remediation은 Alertmanager의 webhook receiver 뒤에서 조치를 실행하는 시스템이 요청 인증, 반복 방지, 허용 목록, 시험 실행, 사람 승인, 도구 권한 분리 같은 장치를 여러 겹으로 두는 패턴이다. Source는 규칙 기반 webhook 앱과 AI 장애 관제 Agent 두 가지이며, 두 구현은 판단 주체가 다르지만 "실행 전에 무엇을 통과해야 하는가"라는 같은 문제를 다룬다. 이 패턴은 Agent Safety Boundary의 Authorization 경계에 해당하는 운영 사례로 볼 수 있다.

두 가지 구현 형태

• 규칙 기반 앱은 경보 조건과 조치를 코드에 미리 묶어 두고, AI 장애 관제 시스템은 Agent 분석과 playbook의 실행 정책을 결합한다. 사람 승인은 승인 기반 경로에 적용되며 AUTO 경로에는 없다.^[3:1] 이 차이는 AI Workflow vs Agent의 control boundary 관점에서 경로별로 읽어야 한다.

흐름

규칙 기반 webhook 앱은 경보 하나가 다음 순서로 검사를 통과해야 실행된다.^[1:3]

flowchart TB
    A[Alertmanager] -->|POST /alert| T{토큰 검증}
    T -->|불일치| X1[401 invalid token]
    T -->|일치| C{쿨다운 확인}
    C -->|쿨다운 중| X2[cooldown 응답, 실행 안 함]
    C -->|통과| M{경보 매칭과 허용 목록}
    M -->|불일치| X3[ok 응답, 실행 안 함]
    M -->|일치| D{dryRun}
    D -->|true| L[audit 로그만 기록]
    D -->|false| R[docker / ssh / script 실행]

AI 장애 관제 시스템의 로컬 코드에는 분석 뒤 playbook 조치와 대화 중 모델 제안을 처리하는 세 경로가 있다.^[3:2]

flowchart TB
    A[Alertmanager webhook] --> PB[알람 검증과 playbook 조회]
    PB --> RA[ReAct 또는 Orchestrator 분석: 조회 도구]
    RA --> C{playbook category}
    C -->|AUTO| F[고정 playbook 명령]
    C -->|NEEDS_APPROVAL| T[playbook 템플릿과 알람 label]
    C -->|READ_ONLY 또는 NONE| D[분석 결과만 알림]
    T --> P[PendingApprovalStore: 명령과 채널, TTL]
    U[Discord 사용자 대화] --> CA[ConversationAgent: 로그 조회와 실행 제안]
    CA --> V{isAllowed: 형식 검사}
    V -->|통과| P
    V -->|거부| X[거부]
    P --> Y{listener 조건 통과와 yes 또는 approve}
    Y -->|확인| E{실행 서비스의 공통 형식 검사}
    Y -->|취소 또는 만료| N[실행 안 함]
    F --> E
    E -->|통과| R[docker restart 실행과 결과 전송]
    E -->|거부| X

안전장치별로 막는 위험

설계 포인트

• 대화의 실행 제안에서는 형식 검사와 사람 승인이 두 겹의 경계다. 형식에 맞지 않는 명령은 거부되지만, docker restart postgres처럼 형식에 맞는 잘못된 대상은 검사만으로 차단되지 않는다. 이 경로는 playbook이나 별도 restart 대상 목록을 검사하지 않는다.^[3:6]
• Agent의 실행 도구 execute_command는 실제로 명령을 실행하지 않고 "제안"만 한다. 실행은 운영자 확인 뒤 별도 경로에서 일어난다.^[4:3]
• 대기 기록은 명령과 채널로 색인하고 기본 TTL은 30분이며, yes는 해당 채널의 대기 명령을 실행한다. approve <command>는 명령으로 대기를 찾는다. listener의 채널·role 필터는 값이 설정된 경우에만 동작하고, 대기 기록에 요청자나 승인자 user ID는 없다. 따라서 채널 구분을 개인별 승인 권한 검증으로 보아서는 안 된다. 실제 운영 설정은 이번에 확인하지 않았다.^[3:7]
• AUTO에서는 현재 GPUDcgmExporterDown에 등록된 docker restart dcgm-exporter가 승인 없이 실행된다. 분석 결론이 아니라 playbook의 명령을 사용하므로, 읽기 전용 분석 Agent가 실행 도구를 갖지 않는 것과 시스템에 자동 실행 정책이 있는 것은 양립한다.^[3:8]
• 실행 도구 객체는 생성 시점에 채널과 알림 정보를 고정한다. 그래서 Agent가 호출 때 채널 ID를 잘못 넘길 여지가 없다.^[4:4]
• 규칙 기반 앱은 dryRun을 기본값으로 켜 두고, 실제 실행은 명시적으로 끄는 방식이다.^[1:10] 새 정책을 운영에 넣기 전에 로그로 매칭 결과부터 확인하는 단계로 쓸 수 있다고 보인다.

한계와 주의

• 허용 명령을 늘릴수록 isAllowed() 검증 로직이 복잡해지고 실수 가능성도 커진다. 새 명령 유형을 추가하려면 정규식과 파싱 로직을 함께 고쳐야 한다.^[4:5]
• 규칙 기반 앱 예시 코드는 마지막 실행 시각을 AtomicLong 하나로 관리한다.^[1:11] 예시 코드를 그대로 쓰면 쿨다운이 경보·조치 종류와 관계없이 전체에 하나만 걸린다고 읽힌다.
• 예시의 토큰 검증은 원문 스스로 "단순 토큰 검증"이라고 표시한다.^[1:12]
• docker.sock을 직접 마운트하면 컨테이너 탈출 위험이 있다.^[1:13]
• 문서와 코드의 범위 차이: 개요·도구 분리 글의 승인 기반 설명^[4:6][2:1]과 파이프라인 문서의 AUTO 분기^[5]는 로컬 코드 a1ca1b7에서 서로 다른 경로로 구현되어 있다. 이 페이지는 그 로컬 버전의 정적 검사이며, 실제 서버의 배포 버전·설정이나 인젝션 성공을 검증한 기록은 아니다.^[3:9]

관련

• Alertmanager: 경보를 묶고 라우팅해 webhook receiver로 보내는 앞단이다. 이 패턴은 그 receiver 뒤에서 무엇을 실행할지를 다룬다.
• Agent Safety Boundary: 실행 전 권한 확인이 필요하다는 Authorization 경계의 운영 사례다.
• Typed Decision Model: 모델의 판단과 실행 권한을 분리한다는 같은 원칙을 판단 계층 쪽에서 다룬다.
• Agent Tool Use: 조회 도구와 실행 도구를 Agent별로 나누는 설계가 tool 권한 범위의 구체 예다.

테스트 질문

• Agent가 제안한 docker rm -f postgres를 운영자가 yes로 승인하면 실행되는가?
• 허용 목록이 있는데 사람 승인을 또 두는 이유는 무엇인가?
• 규칙 기반 자동 대응에서 dryRun과 쿨다운은 각각 어떤 위험을 막는가?
• 자동 분석 Agent에 실행 도구가 없는데도 dcgm-exporter가 승인 없이 재시작될 수 있는 이유는 무엇인가?
• ConversationAgent의 로그 조회 대상 검사와 재시작 대상 검사는 같은 경계인가?

출처