▲ 48 · 25 comments on source · Hacker News · behat · 6 months ago
Launch HN: Relvy (YC F24) – 온콜 런북, 자동화
안녕하세요 HN! 저희는 Relvy AI( https://www.relvy.ai )의 Bharath와 Simranjit입니다. Relvy는 소프트웨어 엔지니어링 팀의 온콜 런북을 자동화합니다. 대규모로 텔레메트리 데이터와 코드를 분석할 수 있는 도구를 갖춘 AI 에이전트로, 팀이 프로덕션 이슈를 몇 분 만에 디버깅하고 해결하도록 돕습니다. 영상은 여기 있습니다: [[[ https://www.youtube.com/watch?v=BXr4_XlWXc0 ]]] 많은 팀이 어떤 형태로든 AI를 사용해 온콜 부담을 줄이고 있습니다. 로그를 Cursor에 붙여넣고 있을 수도 있고, Datadog의 MCP 서버와 함께 Claude Code를 사용해 디버깅하고 있을 수도 있습니다. 저희가 확인한 것은 자율적인 근본 원인 분석(root cause analysis)이 AI에게 어려운 문제라는 점입니다. 이는 벤치마크에서도 드러납니다 - Claude Opus 4.6은 현재 OpenRCA 데이터셋에서 36% 정확도를 보이며, 이는 코딩 작업과 대조적입니다. 여기에는 세 가지 주요 이유가 있습니다: (1) 텔레메트리 데이터의 양이 모델을 노이즈로 압도할 수 있습니다; (2) 데이터 해석/추론은 엔터프라이즈 컨텍스트에 의존합니다; (3) 온콜은 시간이 제한된 고부담 문제로, 조사 시간 동안 AI가 탐색할 여지가 거의 없습니다. 사용자를 잘못된 경로로 이끄는 오류는 쉽게 용서되지 않습니다. Relvy에서는 텔레메트리 데이터 분석을 위한 특화된 도구를 구축하여 이러한 문제들을 해결하고 있습니다. 저희 도구는 조밀한 시계열 데이터에서 이상 징후를 감지하고 문제 슬라이스를 식별하며, 로그 패턴 검색을 수행하고, 에이전트 컨텍스트를 압도하지 않으면서 span 트리에 대해 추론할 수 있습니다. 에이전트를 런북 중심으로 고정하면 에이전트적 탐색이 줄어들고, 숙련된 엔지니어가 취할 가장 유용한 단계를 반영하는 더 결정론적인 단계로 이어집니다. 그 결과 분석이 더 빨라지고, AI가 무엇을 했는지 검토하고 이해해야 하는 엔지니어의 인지 부하가 줄어듭니다. 작동 방식: Relvy는 docker-compose(또는 helm 차트, 또는 저희 클라우드에 가입)를 통해 로컬 머신에 설치되고, 스택(관측성 및 코드)을 연결하고, 첫 번째 런북을 생성한 뒤 Relvy가 최근 알림을 조사하도록 합니다. 각 조사는 저희 웹 UI에서 노트북으로 제시되며, 엔지니어가 AI를 검증하고 신뢰를 쌓는 데 도움이 되는 데이터 시각화가 포함됩니다. 여기서부터 Relvy는 Slack의 알림에 자동으로 대응하도록 구성할 수 있습니다 Relvy가 자동화하는 런북 단계의 예시: - 특정 대시보드를 확인하고, 오류가 특정 샤드에 국한되어 있는지 확인합니다. - APM 페이지에 처리량 급증이 있는지 확인하고, 있다면 소수의 IP에서 발생한 것인지 확인합니다. - 최근 커밋을 확인하여 이 엔드포인트에 변경 사항이 있었는지 확인합니다. 또한 사람의 승인 하에 Relvy가 완화 조치를 자동화하기 위해 실행할 수 있는 AWS CLI 명령을 구성할 수도 있습니다. 저희에 대해 조금 말씀드리면 - 저희는 2024년 가을에 YC를 했습니다. 작은 언어 모델로 지속적인 로그 모니터링을 실험하며 여정을 시작했는데, 너무 느렸습니다. 그 후 근본 원인 분석을 효과적으로 해결하는 데 깊이 투자했고, 오늘날의 제품은 초기 고객들과 약 1년간 작업한 결과물입니다. 오늘 한번 사용해 보세요. 피드백이나 회사에서 온콜 부담을 어떻게 해결하고 계신지 듣고 싶습니다. 의견이나 제안 감사합니다!
원문 게시글에서 발췌한 번역본입니다. 전문과 원문 댓글은 아래 링크에서 확인하세요.
Discussion on runchr
Loading comments…
to comment.