증거에서 조치까지 잇는 장애 대응 흐름을 만들며 배운 점

AI 요약

장애를 감지한 뒤 다음에 무엇을 해야 할지 판단하기까지 어떤 일이 벌어지는지 살펴본 글입니다. 장애 관리자, SRE, 플랫폼 엔지니어, 제품 리더 등과 대화하면서 문제는 알림 부족이 아니라 이미 존재하는 여러 신호를 이해하고 조치할 수 있는 근거로 엮는 데 있다고 봅니다.

신호에서 조치까지

실험 중인 흐름은 Signal → Context → Evidence → Ownership → Action입니다. 예를 들어 결제 서비스 지연이 감지되면 관련 맥락과 증거를 모읍니다. 증거가 서로 맞지 않을 때 시스템이 특정 팀을 담당자로 단정하지 않고, 담당 확신도를 ‘모호함’으로 표시합니다. 사람들이 가정을 사실로 받아들이기 전에 근거와 불확실성을 확인하도록 하려는 접근입니다.

관련 담당자와 맥락이 정리되면 가능한 다음 조치를 제안할 수 있지만, 자동화가 결정을 대신하는 방식은 지향하지 않습니다. 무엇을 알고 있는지, 증거가 어디서 충돌하는지, 누가 관련 있어 보이는지, 다음 단계로 무엇을 고려할 수 있는지를 보여주는 형태입니다.

자동화보다 증거를 먼저

처음에는 담당자 확인에 초점을 맞췄지만, 조사 과정에서 문제는 더 넓게 드러났습니다. 담당자가 문서에 기록돼 있거나 이미 알려져 있어도, 팀은 사건 경위를 다시 맞추고 서로 다른 신호를 비교하며 책임과 증거의 신뢰도를 확인하는 데 시간을 씁니다. 그래서 작성자는 자동화보다 증거를 먼저 연결하고 불확실성을 드러내는 방향을 실험합니다.

새 모니터링 시스템을 만들거나 ServiceNow, observability 도구, incident-management 제품, 기존 기록 시스템을 대체하려는 것은 아닙니다. AI가 책임자를 무작정 결정하는 제품도 목표가 아닙니다. 증거를 연결해 협업 전 재구성 작업을 줄일 수 있는지 확인하려는 단계이며, 아직 검증된 결과는 없습니다. 가장 큰 질문은 기존 장애 대응 업무를 덜어주는지, 아니면 팀이 관리할 워크플로를 하나 더 만드는지입니다.

Indie Hackers 반응

• @RemNavi — 방금 한 시간 전에 겪은 문제인데, 증거가 조치보다 늦게 반영될 수 있습니다. 변경을 적용하고 외부에서 확인했더니 이전 상태가 보여서, 제대로 적용된 변경을 되돌릴 뻔했습니다. 읽기 결과는 5분 동안 캐시된 값이었습니다. 서로 다른 증거가 나온 것도 오류가 난 것도 아니고, 확인 결과가 ‘지금’의 상태를 보여주지 않았던 겁니다. 증거를 가져온 시점이 아니라 그 증거가 사실이었던 시점을 각 항목에 기록하는 게 좋겠습니다. 신선도는 사람들이 빠뜨렸다가 나중에 논쟁하는 필드입니다.
• @magickit — 제 경험상 ‘증거가 완전히 일치하지 않음’ 단계에서 대부분의 장애 대응 도구가 무너집니다. 사람은 상충하는 신호를 잘 조정하지만, 도구가 의견 차이를 숨기지 않고 솔직하게 드러내야 합니다. 담당자를 같은 흐름에 연결할 때는 제안된 담당자가 책임 추궁으로 받아들여질 위험도 살펴야 합니다. 그러면 사람들이 증거를 얼마나 솔직하게 입력하는지도 달라집니다. 담당자를 결론이 아니라 잠정 제안으로 남기는 일이 신뢰에 중요할 수 있습니다. Signal에서 Context로 넘어가는 과정 자체도 정말 어렵습니다.
• @vladzoff — 증거가 서로 맞지 않을 수 있다는 점이 정말 중요합니다. 어떤 시스템은 ‘이 신호를 찾았다’에서 곧장 ‘이게 원인임이 틀림없다’로 넘어가고, 그 뒤의 모든 판단이 그 가정 위에 쌓입니다. 시스템이 실제보다 더 많이 안다고 꾸미기보다 충돌을 드러내는 편이 더 유용할 것 같습니다.
• @aryan_sinh — 지금까지 대화한 팀들이 이 증거 계층이 대체할 구체적인 장애 대응 단계를 찾아냈나요, 아니면 아직 가치는 개념적인 수준인가요?
  • @Ubong Jacob — 바로 그 점을 검증하려고 합니다. 지금까지 조사에서는 담당자 확인, 맥락 재구성, 증거 조정, 협업 과정에서 반복적으로 마찰이 드러났습니다. 하지만 증거 계층이 실제로 구체적인 장애 대응 단계를 대체하는지는 아직 검증하지 못했습니다. 다음 실험에서는 최초 신호부터 첫 번째로 정확하고 조율된 조치까지 드는 일을 줄이는지, 팀이 관리할 워크플로를 하나 더 만들지 않고 확인하려 합니다.
• @sitewhisper — Signal → Context → Evidence → Ownership → Action 흐름은 ‘업무를 줄이는가?’라는 질문을 검증 가능하게 만듭니다. 우선 장애 유형 하나를 정하고 첫 번째로 정확한 조치까지 걸린 시간, 인계나 담당자 재배정 횟수, 같은 증거를 두 번 요청한 횟수를 기준으로 삼겠습니다. 담당자가 불분명할 때는 한 명을 억지로 고르지 말고 상위 후보 두 명, 서로 충돌하는 항목, 판단을 해결할 누락 정보 하나를 보여주면 좋겠습니다. 사람이 다른 조정 절차를 열지 않고 이를 얼마나 자주 확인하는지도 측정할 수 있습니다. 증거에는 신선도와 권위의 기준도 필요합니다. 최신 서비스 카탈로그와 최근 배포 기록을 오래된 스프레드시트와 같은 무게로 취급해서는 안 됩니다. 기존 장애를 대상으로 shadow mode 시험을 하면 새 시스템을 유지해야 하는 부담이 생기기 전에 재구성 시간을 줄이는지 확인할 수 있습니다.
• @kimkhwzxtfdecaiqica — 제대로 작동하는지는 어떻게 측정하고 있나요?
• @kimsktetckwdihllqno — 첫 사용자는 지금 어떻게 찾고 있나요?
• @kimoodmqwkwjrsbutyc — 다른 대안 대신 이 기술 스택을 고른 이유는 무엇인가요?
• @kimofsgcoylvqxpsmse — 유료로 제공할 계획인가요, 아니면 당분간 무료로 둘 생각인가요?

원문: Indie Hackers / 번역·요약: Trawling