สวัสดีครับ/ค่ะ ผม/ฉันกำลังทำเครื่องมือสำหรับนักพัฒนาเป็นไซด์โปรเจกต์ระหว่างทำงานประจำ และอยากแชร์ Relivio ที่ช่วยจัดระเบียบการตัดสินใจในช่วง 15 นาทีหลังดีพลอย
สำหรับผม/ฉัน สิ่งที่คาใจเกี่ยวกับการดีพลอยไม่ใช่ตัวการดีพลอยเอง แต่เป็น 15 นาทีหลังจากนั้น CI ผ่านแล้ว และแดชบอร์ดก็ดูปกติเป็นส่วนใหญ่ แต่เมื่อ error เพิ่มขึ้นเล็กน้อย มันไม่ได้ชัดเจนในทันทีว่านี่เป็นผลจากการดีพลอยครั้งนี้ เป็นความแกว่งที่เดิมทีก็มีเป็นครั้งคราวอยู่แล้ว หรือควร rollback ตอนนี้เลย
Relivio ไม่ใช่เครื่องมือที่จะมาแทน monitoring เดิม Monitoring เก่งในการมองดูสภาพระบบโดยรวมในเวลาปกติ ส่วน Relivio เป็นเลเยอร์แคบ ๆ ที่ปิดคำถามเดียวว่า "การดีพลอยครั้งนี้ ตอนนี้โอเคไหม"
สิ่งที่ทำมีอย่างง่าย ๆ คือรับ error log, stack trace, exception type และข้อมูลการดีพลอยที่มีอยู่แล้ว แล้วสร้าง verdict เดียวในระดับการดีพลอย
- การตัดสิน 3 ระดับ: STABLE / WATCH / RISK
- รายการ API ที่ได้รับผลกระทบ
- next action แบบหนึ่งบรรทัด
มีหลักการหนึ่งที่ยึดไว้อย่างชัดเจน คือจะไม่รับข้อมูลที่ฝั่งผู้ใช้ต้องวัดใหม่แล้วส่งมาเอง ถ้าไม่มีเส้นแบ่งนี้ สุดท้ายมันก็จะไหลไปเป็นการสร้าง APM ขนาดเล็กขึ้นมาใหม่อีกตัว
คนใช้งานดู verdict ได้ผ่านคอนโซลหรือการแจ้งเตือนทาง Slack / Discord ส่วนเอเจนต์จะอ่าน verdict เดียวกันผ่าน API หรือ MCP server โครงสร้างนี้ตั้งใจให้บันทึกการตัดสินหลังดีพลอยสามารถถูกอ่านได้ภายหลัง ทั้งโดยเอเจนต์ตัวอื่นหรือโดยตัวผม/ฉันเองในอนาคต
- ลองใช้ได้ทันที (ไม่ต้องสมัคร): relivio.dev/demo
- Source / repo ของแอปเดโม: github.com/lazypl82/relivio-demo-fastapi
- TypeScript SDK: npm relivio
- Python SDK: PyPI relivio
- รวม MCP server
- แนะนำผลิตภัณฑ์: relivio.dev
ตอนนี้ยังเป็น alpha และยังหาผู้ใช้กลุ่มแรกไม่ได้ มีประเด็นต่อไปนี้ที่อยากรู้เป็นพิเศษ
- คุณรู้สึกไหมว่าจำเป็นต้องมีเลเยอร์ที่ดูแล 15 นาทีหลังดีพลอยแยกต่างหาก หรือสแตกเดิมที่มีอยู่ก็เพียงพอแล้ว?
- การแบ่ง 3 ระดับเป็น STABLE / WATCH / RISK ใช้ได้จริงในงานหรือไม่? (
WATCHคือส่วนที่ผม/ฉันมั่นใจน้อยที่สุด) - โครงสร้างที่ให้เอเจนต์อ่าน verdict ผ่าน MCP มีประโยชน์ไหม?
ยังไม่มีความคิดเห็น