Opslane - เครื่องมือที่รวมข้อความ on-call เพื่อลดความเครียด

 (github.com/opslane)
2 คะแนน โดย GN⁺ 2024-07-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใช้ LLM เพื่อจัดประเภทการแจ้งเตือนว่าเป็นสิ่งที่ต้องดำเนินการหรือเป็นเพียงสัญญาณรบกวน
    • วิเคราะห์ประวัติการแจ้งเตือนและบทสนทนาใน Slack เพื่อตัดสินว่าการแจ้งเตือนนั้นต้องมีการดำเนินการหรือไม่
    • ช่วยลดความล้าจากการแจ้งเตือนด้วยการให้ข้อมูลตามบริบทสำหรับการจัดการ (อินไซต์และทรัพยากรเพิ่มเติม)
  • ทำงานร่วมกับ Slack โดยวิเคราะห์รูปแบบการแจ้งเตือน และให้รายงานรายสัปดาห์เกี่ยวกับการแจ้งเตือนของช่อง

สถาปัตยกรรมแบบโมดูลาร์

  1. การรวบรวมการแจ้งเตือน: Datadog ส่งการแจ้งเตือนผ่าน webhook ไปยังเซิร์ฟเวอร์ FastAPI
  2. เซิร์ฟเวอร์ FastAPI: แกนหลักของระบบ ทำหน้าที่ประมวลผลการแจ้งเตือนขาเข้า โต้ตอบกับ Slack และจัดการการไหลของข้อมูล
  3. การผสานรวม Slack: ให้ส่วนติดต่อผู้ใช้สำหรับการจัดการและโต้ตอบกับการแจ้งเตือน
  4. ฐานข้อมูล: ใช้ Postgres และ pgvector เพื่อจัดเก็บข้อมูลการแจ้งเตือนและ embeddings

การผสานรวม

ด้วยการใช้โมเดลข้อมูลที่ยืดหยุ่น จึงรองรับการผสานรวมได้หลายแบบ ขณะนี้ Opslane รองรับ Datadog

สรุปโดย GN⁺

  • Opslane เป็นเครื่องมือที่ช่วยลดความล้าจากการแจ้งเตือนและคัดแยกการแจ้งเตือนที่ต้องดำเนินการ ทำให้ประสบการณ์ on-call มีความเครียดน้อยลง
  • การผสานรวมกับ Slack ช่วยเรื่องการจัดการการแจ้งเตือนและการดีบัก พร้อมวิเคราะห์คุณภาพของการแจ้งเตือนผ่านรายงานรายสัปดาห์
  • เปิดให้ใช้งานแบบโอเพนซอร์สและยินดีรับการมีส่วนร่วมจากชุมชน พร้อมรองรับการผสานรวมกับ Datadog
  • เครื่องมือที่มีฟังก์ชันคล้ายกัน ได้แก่ PagerDuty และ VictorOps

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-07-29
ความคิดเห็นจาก Hacker News

  • ความคิดเห็นแรก: พูดถึงผลิตภัณฑ์ที่ช่วยลดความล้าจากการแจ้งเตือนด้วยการจัดประเภทการแจ้งเตือนว่าอะไรนำไปสู่การลงมือทำได้และอะไรเป็นเพียงสัญญาณรบกวน พร้อมให้ข้อมูลบริบทเพื่อใช้จัดการ

    • ปัญหานี้สะท้อนให้เห็นชัดยิ่งขึ้นถึงปัญหาของบริษัทที่ไม่สามารถสร้าง observability ที่มีประโยชน์ได้
    • ผลิตภัณฑ์นี้เป็นสิ่งที่น่ายินดี แต่หวังว่าจะไม่เน้นการขายโดยชูจุดเด่นในแง่ที่เอื้อให้แนวปฏิบัติทางวัฒนธรรมที่ไม่ดีดำเนินต่อไป
    • อุตสาหกรรมโทรคมนาคมแก้ปัญหานี้ไปแล้วเมื่อ 15 ปีก่อนด้วยระบบอัตโนมัติด้าน Fault Management
    • เมื่อการแจ้งเตือนย้ายไปอยู่ใน Slack ข้อมูลก็กลายเป็นข้อความที่ไม่มีโครงสร้าง ทำให้ต้องมีโซลูชันการกรองที่ซับซ้อน

  • ความคิดเห็นที่สอง: แสดงความกังวลต่อการใช้ LLM ที่ไม่น่าเชื่อถือกับงานสำคัญ

    • อยากให้แก้ปัญหาต้นทางและไม่ต้องเพิ่ม LLM เข้าไป

  • ความคิดเห็นที่สาม: กล่าวว่าผู้ก่อตั้ง All Quiet กำลังพัฒนาเครื่องมือที่ไม่ใช้ LLM

    • ผู้ใช้ไม่ต้องการให้การแจ้งเตือนสำคัญต้องพึ่งพา LLM แบบกล่องดำ
    • AI อาจช่วยบรรเทาอาการได้ แต่ไม่สามารถแก้รากปัญหาซึ่งคือเรื่อง observability และกระบวนการได้

  • ความคิดเห็นที่สี่: แสดงความกังวลเกี่ยวกับการใช้ LLM กรองความสำคัญของการแจ้งเตือน

  • ความคิดเห็นที่ห้า: ชี้ว่าการผูกเครื่องมือเข้ากับ Slack อย่างใกล้ชิดเกินไปจำกัดแพลตฟอร์มที่ใช้งานได้

    • ยังมีแพลตฟอร์มส่งข้อความแบบทันทีอื่น ๆ อีก
    • ประเด็นที่กว้างกว่านี้เกี่ยวกับการใช้ IM กำลังถูกพูดถึงในเธรดความคิดเห็นอื่น

  • ความคิดเห็นที่หก: ระบุว่าชอบทิศทางนี้มาก

    • สงสัยเกี่ยวกับการบูตสแตรปช่วงแรกและการทำ baseline อย่างต่อเนื่อง
    • แจ้งว่าทีม Louie.AI กำลังเปิดรับตำแหน่ง SE และตำแหน่งสำคัญอื่น ๆ

  • ความคิดเห็นที่เจ็ด: อธิบายว่ารู้ปัญหาของระบบแจ้งเตือนในที่ทำงานปัจจุบัน แต่แก้ไม่ได้เพราะอะไร

    • เป็นปัญหาที่ปิดการแจ้งเตือนไม่ได้ และไม่สามารถระบุหรือแก้สาเหตุรากได้
    • การทำ on-call ให้ดีเป็นปัญหาเชิงวัฒนธรรม
    • เครื่องมือทางเทคนิคไม่สามารถแก้ปัญหาเชิงวัฒนธรรมได้
    • หากจะจัดการปัญหาเชิงวัฒนธรรม ก็มีแค่ต้องหางานใหม่หรือหาทางยอมรับมัน

  • ความคิดเห็นที่แปด: แสดงความยินดีกับการสร้างผลิตภัณฑ์นี้ และชี้ว่ามีคำหนึ่งหายไปในย่อหน้าแรก

  • ความคิดเห็นที่เก้า: กำลังมองหา UI ลักษณะคล้ายกันสำหรับการแจ้งเตือนทางธุรกิจ

    • ต้องการเครื่องมือที่ใช้แหล่งข้อมูลอย่าง Snowflake/BigQuery
    • บอกว่าเครื่องมือที่เคยใช้สุดท้ายก็ลงเอยเป็นช่อง Slack แบบสแปม