2P by neo 3달전 | favorite | 댓글 1개
  • LLM을 사용하여 알림을 실행 가능한 것과 소음으로 분류
    • 알림 기록과 Slack 대화를 분석하여 알림이 실행 가능한지 여부를 판단
    • 처리를 위한 상황별 정보(인사이트 와 추가 리소스)를 제공하여 알림 피로를 줄여줌
  • Slack과 연동 하여 동작, 알림 패턴을 분석하고, 채널의 알림에 대한 주간 리포트 제공

모듈식 아키텍처

  1. 알림 수집: Datadog이 웹훅을 통해 알림을 FastAPI 서버로 전송
  2. FastAPI 서버: 시스템의 핵심으로, 들어오는 알림을 처리하고 Slack과 상호 작용하며 데이터 흐름을 관리
  3. Slack 통합: 알림 관리와 상호 작용을 위한 사용자 인터페이스를 제공
  4. 데이터베이스: 알림 데이터와 임베딩을 저장하기 위해 Postgres와 pgvector를 사용

통합

유연한 데이터 모델을 사용하여 여러 통합을 지원할 수 있음. 현재 Opslane은 Datadog을 지원

GN⁺의 정리

  • Opslane은 알림 피로를 줄이고 실행 가능한 알림을 분류하여 온콜 경험을 덜 스트레스받게 하는 도구
  • Slack과의 통합을 통해 알림 관리와 디버깅을 돕고, 주간 보고서를 통해 알림 품질을 분석함
  • 오픈 소스로 제공되어 커뮤니티의 기여를 환영하며, Datadog과의 통합을 지원함
  • 비슷한 기능을 가진 도구로는 PagerDuty와 VictorOps가 있음.
Hacker News 의견
  • 첫 번째 의견: 경고를 실행 가능한 것과 소음으로 분류하고 처리하기 위한 맥락 정보를 제공함으로써 경고 피로를 줄이는 제품에 대해 논의함

    • 이 문제는 유용한 관찰 가능성을 만들지 못하는 회사의 문제를 더 잘 보여줌
    • 제품은 환영받을 만하지만, 나쁜 문화적 관행을 가능하게 하는 측면을 주요 판매 포인트로 강조하지 않기를 바람
    • 통신업계는 15년 전에 Fault Management 자동화를 통해 이 문제를 해결했음
    • 경고가 Slack으로 이동하면서 데이터가 비구조화된 텍스트가 되어 복잡한 필터링 솔루션이 필요해짐
  • 두 번째 의견: 중요한 작업에 신뢰할 수 없는 LLM을 사용하는 것에 대한 우려를 표명함

    • 원래 문제를 해결하고 LLM을 추가하지 않기를 바람
  • 세 번째 의견: All Quiet 창립자가 LLM을 사용하지 않는 도구를 개발 중임을 언급함

    • 사용자들이 중요한 경고가 불투명한 LLM에 의존하지 않기를 원함
    • AI는 증상에 도움을 줄 수 있지만 근본 원인인 관찰 가능성과 프로세스 문제를 해결하지 못함
  • 네 번째 의견: LLM을 통해 알림의 중요성을 필터링하는 것에 대한 우려를 표명함

  • 다섯 번째 의견: Slack에 도구를 밀접하게 결합하는 것이 사용 가능한 플랫폼을 제한함

    • 다른 인스턴트 메시징 플랫폼도 존재함
    • IM을 사용하는 것에 대한 더 넓은 문제는 다른 댓글 스레드에서 논의 중임
  • 여섯 번째 의견: 이 방향에 대한 큰 팬임을 언급함

    • 초기 부트스트래핑 및 지속적인 베이스 라이닝에 대한 궁금증을 표명함
    • Louie.AI 팀이 SE와 주요 직책을 채용 중임을 알림
  • 일곱 번째 의견: 현재 직장에서 경고 시스템의 문제를 알고 있지만 해결할 수 없는 이유를 설명함

    • 경고를 끌 수 없고, 근본 원인을 식별하거나 해결할 수 없는 문제
    • 온콜을 잘 운영하는 것은 문화적 문제임
    • 기술적 도구는 문화적 문제를 해결할 수 없음
    • 문화적 문제를 해결하려면 다른 직장을 찾거나 문제를 받아들이는 방법밖에 없음
  • 여덟 번째 의견: 제품을 만든 것에 대해 축하하며, 첫 번째 단락에 단어가 빠졌음을 지적함

  • 아홉 번째 의견: 비즈니스 경고를 위한 유사한 UI를 찾고 있음

    • Snowflake/BigQuery와 같은 데이터 소스를 사용하는 도구를 원함
    • 사용한 도구들은 스팸성 Slack 채널로 끝났음을 언급함