ข้อความเตือนตอนตีสามที่อ่านไม่รู้เรื่องคือต้นทุนที่ซ่อนอยู่ของทุกทีม ใครเข้าเวรต้องตื่นมาตีความ log ดิบก่อนว่าเกิดอะไร รุนแรงแค่ไหน แล้วต้องทำอะไรต่อ Versus Incident ออกแบบจุดนี้ใหม่คือ incident ทุกชิ้นที่ถึงมือคนต้องมาพร้อมแพ็กเกจ triage สรุปสั้น ระดับความรุนแรง และขั้นตอนถัดไปที่แนะนำ งานเขียนสรุปย้ายออกจากเวลาของคนเข้าเวรไปอยู่ในท่อก่อนส่ง
บทความนี้สรุปจากบันทึกการอ่าน docs และ repo ต้นฉบับของทีมเรา ซึ่งเก็บไว้ที่ Issue #12 ของ muse101 โดยใช้ docs ทางการของ Versus Incident และ repo ต้นฉบับ VersusControl/versus-incident เป็นหลักควบคู่กัน เรายังไม่ได้รันระบบนี้จริง ตัวเลขและพฤติกรรมข้างล่างจึงมาจากเอกสาร ไม่ใช่ผลทดลองของเรา
สรุปสำหรับผู้บริหาร
- Versus Incident คือ AI SRE agent แบบ self-hosted (Go, MIT, 914 ดาว) ที่ไม่ส่งข้อความดิบมาให้คนตีความ
- ทุก incident มาพร้อม แพ็กเกจ triage 3 ชิ้น: สรุป ระดับความรุนแรง และขั้นตอนถัดไป — มีสองเกรดคือบทวิเคราะห์จาก AI ถ้ามี key หรือข้อสรุป deterministic ถ้าไม่มี ท่อออกแบบให้ไม่ทิ้ง incident แม้โมเดลล่มหรือชนเพดาน
- แพ็กเกจวิ่งผ่านท่อเดียวกันหมด: จัดฟอร์แมตด้วย template ของเรา กระจายทุกช่องทาง ไม่ ack ในเวลาจะตามถึง on-call
- ความไว้ใจไม่ได้มาฟรี: มีโหมดซ้อม (shadow) ให้วัด judgement ก่อนเปิดของจริง
- ข้อจำกัด: ฟีเจอร์ metrics/traces/cross-signal ยังอยู่ใน roadmap หน้า docs เองบอกว่ากำลังทำ
ในแพ็กเกจมีอะไรบ้าง
| ชิ้น | ใครเขียน | เอาไปทำอะไรต่อ |
|---|---|---|
| สรุปเหตุการณ์ | AI SRE triage | อ่าน 30 วินาทีรู้เรื่อง ไม่ต้องเปิด log ดิบก่อน |
| ระดับความรุนแรง | AI SRE triage | ตัดสินใจได้ทันทีว่าลุกเลยหรือรอเช้า |
| ขั้นตอนถัดไป | AI SRE triage | มีจุดเริ่มสืบสวน ไม่เริ่มจากศูนย์ |
| ฟอร์แมตข้อความ | template ของเรา (Go templates) | สำนวนและฟิลด์ตรงกับวิธีทำงานของทีม |
ตารางนี้คือสัญญาของระบบ ไม่ใช่รายการฟีเจอร์ประดับ สิ่งที่ควรตรวจก่อนไว้ใจคือสามช่องแรกเขียนดีแค่ไหน ซึ่งวัดได้ก่อนเปิดของจริงด้วยโหมดซ้อม (ดูหัวข้อถัดไป) ส่วนช่องสุดท้ายเป็นของเราเอง เขียน template ให้ตรงกับวิธีทำงานของทีมได้เต็มที่
ภาพรวมทั้งตัวแบบประเมินครบ
สำหรับคนที่อยากเห็นของทั้งชิ้นก่อนลงรายละเอียด นี่คือสรุปแบบประเมินครบจาก docs หน้าแรกบวกหน้าที่อ่านเพิ่ม ระบบรับ incident สองทางคือ AI auto-detect (เรียน pattern ปกติจาก logs, metrics, traces และ Kubernetes แล้วเตือนเฉพาะของใหม่) กับ webhook ที่เรากำหนดเอง ทั้งสองทางวิ่งผ่านท่อเดียวกันคือจัดฟอร์แมต กระจายทุกช่องทาง ไม่ ack ในเวลาจะตามถึง on-call
AI ทำงานสามโหมดขั้นบันไดคือ training (ดูอย่างเดียว) shadow (ซ้อมเตือนเงียบ ๆ พร้อม would-have-alerted log) และ detect (เตือนจริงพร้อม AI triage) ฟีเจอร์รอบตัวมีข้อความ template ด้วย Go templates ตั้งค่าด้วย YAML รองรับ environment variables มี REST API และการ์ดสรุปรายสัปดาห์แบบ off-by-default ส่วนของ Enterprise คือ alert fatigue กับ SSO/HA ส่วนที่หน้า docs เองบอกว่ายังทำอยู่คือ metrics traces และ cross-signal correlation
ของใหม่เท่านั้นที่ได้แพ็กเกจ
แพ็กเกจ triage ไม่ได้แจกให้ทุกบรรทัดใน log เพราะถ้าแจกทุกบรรทัดมันคือ spam รูปแบบใหม่ เงื่อนไขการเกิด incident มีสองทาง ทางแรกคือ AI เจอ error หรือ anomaly ใหม่ที่ไม่เคยปรากฏมาก่อนจากการเรียน pattern ปกติของระบบ (ชี้ agent ไปที่ logs, metrics, traces และ Kubernetes ไม่ต้อง maintain alert rules) ทางที่สองคือ webhook ที่เรากำหนดเองจาก Alertmanager, Grafana, Sentry, CloudWatch SNS, FluentBit หรือสคริปต์ของเรา
ไม่ว่าต้นทางไหน ของที่ถึงมือคนผ่านท่อเดียวกันคือจัดฟอร์แมต กระจายไปทุก channel ที่เปิดไว้ (Slack, Teams, Telegram, Viber, Email, Lark) และถ้าไม่มีใคร acknowledge ในเวลาจะ escalate หา on-call (PagerDuty, Opsgenie, incident.io, ServiceNow) ตั้งค่าด้วย YAML ที่รองรับ environment variables
แพ็กเกจมีสองเกรด และท่อไม่ทิ้งของ
รายละเอียดที่ docs ระดับลึกเผยคือแพ็กเกจ triage ไม่ได้มีแบบเดียว ถ้าไม่ได้ตั้ง AI key (หรือมีสวิตช์ปิดตอนรัน) agent จะสร้างข้อสรุป deterministic จาก pattern เองคือหัวเรื่อง ระดับความรุนแรงจากสูตร และตัวอย่าง log ที่เซ็นเซอร์แล้วไม่เกินสามบรรทัด พร้อมประทับตราว่า AI ไม่ได้ดูชิ้นนี้ คนอ่านจึงแยกออกว่าชิ้นไหนผ่านโมเดลมาแล้วชิ้นไหนยัง
ก่อนถึงขั้น enrichment ยังมีด่านประหยัดและกันพังอีกสองด่านคือถ้า pattern เดียวกันเพิ่งวิเคราะห์ไป จะใช้ผลเก่าแทนการเรียกโมเดลซ้ำ และมีเพดานจำนวนครั้งเรียกโมเดลต่อชั่วโมง ถ้าชนเพดานระบบยังเตือนเหมือนเดิมแต่ถอยไปใช้ข้อสรุป deterministic ถ้าเรียกโมเดลแล้ว error ก็ถอยแบบเดียวกัน ทุกผลลัพธ์รวมถึง fallback ถูกบันทึกไว้ให้ดูย้อนหลังว่าตั้งค่าอะไรผิดตรงไหน หลักคิดคือท่อเตือนต้อง fail-open ห้ามทิ้ง incident เพราะเหตุผลภายใน
อีกชั้นคือความสะอาดของข้อมูล ท่อซ่อน secrets ตั้งแต่ขั้นอ่าน และการ์ดสรุปรายสัปดาห์ (incidents report รวมยอด แยกต้นทาง แยกความรุนแรง บริการที่โดนหนักสุด และแนวโน้ม ส่งเป็นการ์ดภาพเข้า channel) จะเซ็นเซอร์ทุกฟิลด์ก่อนวาดพิกเซลเดียว ฟีเจอร์นี้เป็นของ OSS แต่ปิดไว้โดยค่าเริ่มต้น เปิดจาก admin UI เอาเอง
วัดใจก่อนไว้ใจด้วยโหมดซ้อม
คำถามที่ต้องถามก่อนฝากงานเขียนสรุปไว้กับ AI คือมันเขียนดีแค่ไหน คำตอบของ Versus คือโหมดขั้นบันไดสามขั้น training (ดูและเรียนอย่างเดียว ไม่เตือน) แล้ว shadow (ทำงานครบทุกขั้นแต่เขียน would-have-alerted log แทนการเตือนจริง) แล้วค่อย detect (เตือนจริง) ทีมเอา log ซ้อมไปเทียบกับความจริงว่าถ้าเตือนไปจะถูกกี่ครั้งผิดกี่ครั้ง เหมือนตารางคะแนนก่อนส่งนักกีฬาลงสนาม
นี่คือจุดที่มุมเก่า (shadow) กลายเป็นส่วนประกอบของมุมใหม่ (triage) อย่างพอดี shadow ไม่ใช่ฟีเจอร์เด่น แต่เป็นเครื่องมือสอบผ่านก่อนให้ AI เขียนสรุปแทนเรา ทีมที่หยิบไอเดียไปใช้โดยยังไม่ใช้ Versus ควรหยิบสองอย่างนี้คู่กันคือสัญญาว่าทุก incident ต้องมีสรุป ระดับ และขั้นตอนถัดไป กับโหมดซ้อมเงียบ ๆ ไว้วัด judgement ก่อนเปิดของจริง
ปุ่มวิเคราะห์ลึกที่อ้าง runbook ของทีมเอง
นอกจาก triage อัตโนมัติตอนเกิดเหตุ ยังมีปุ่มวิเคราะห์ลึกแบบกดเองบนหน้ารายละเอียด incident (analyze mode) AI จะรวบรวมบริบททั้ง incidents ล่าสุด ประวัติ pattern และสรุปบริการ แล้วคืนข้อเชิงลึกแบบมีโครงสร้างลง dashboard งานนี้มี timeout สองนาที ผลถูกบันทึกเสมอแม้เจอ error และตั้งให้โหมดลึกใช้โมเดลแรงกว่าตัว default ได้
ชิ้นที่ทำให้โหมดนี้น่าเชื่อกว่าคำแนะนำลอย ๆ คือเครื่องมือค้น runbook (find_runbook) มันเอาคำถามสั้น ๆ จาก incident ไปค้นคลัง runbook Markdown ของทีมเราเองด้วย similarity search แล้วดึงขั้นตอนจริงที่ทีมไว้ใจมาอ้างในบทวิเคราะห์ เช่น runbook แก้ connection pool เต็มของ Postgres ข้อสำคัญคือเครื่องมือนี้ค้นอย่างเดียว ไม่เคยรันคำสั่ง ไม่ trigger on-call ไม่ส่ง notification คนอ่าน runbook ส่วนคนรันยังเป็นมนุษย์เหมือนเดิม
ข้อควรจดก่อนอิจฉาคือฟีเจอร์กัน alert fatigue (ของซ้ำ ๆ ถูกแยกไป channel รอง ไม่กวน on-call) เป็นของ Enterprise ปิดไว้โดยค่าเริ่มต้น ไม่ใช่ของ OSS ที่อ่านมาทั้งบท
ความเห็นจากประสบการณ์ตรง
ส่วนนี้ไม่ใช่คำเคลมของ Versus แต่เป็นความเห็นของผมจากการทำงานจริงกับ agent มาหลายเดือนว่าทำไมดีไซน์ของมันถึงสมเหตุสมผล วิธีทำงานของบล็อกนี้เองมีเงาของแพ็กเกจ triage อยู่โดยไม่ได้นัดหมายคือทุกครั้งก่อนขึ้น production ต้องมี preview ให้ตรวจก่อน (shadow ของเรา) ทุกคำอ้างต้องตรวจด้วยการรันจริงไม่ใช่เชื่อตามตัวอักษร (deterministic fallback ของเรา) และคู่มืออย่าง PLAYBOOK กับ TEMPLATE ก็คือ runbook ที่ agent รุ่นต่อไปหยิบไปอ้างได้
บทเรียนที่เจ็บที่สุดคือความไว้ใจต้องมีเครื่องมือวัด ไม่ใช่ความรู้สึก เราเคยเจอ agent อีกตัวรายงานว่าตรวจแล้วผ่าน แต่พอตรวจซ้ำด้วยมือพบว่าไม่ได้ตรวจจริง ตั้งแต่นั้นกติกาของทีมคือ headless ACK ไม่นับเป็นการรับทราบ ต้องมีหลักฐานใน ledger กลางเท่านั้น โหมด shadow ของ Versus แก้ปัญหาเดียวกันในโลก SRE คือไม่ถามว่าไว้ใจ AI ไหม แต่ถามว่าวัดมาแล้วได้กี่คะแนน
อีกเรื่องคือ fail-open กับการขออนุมัติเป็นคนละชั้นกัน ระบบเตือนต้อง fail-open เพราะทิ้ง incident ไม่ได้ แต่งานที่มีผลข้างเคียง (deploy, commit, push) ต้องมีประตูอนุมัติโดยมนุษย์เสมอ ของ Versus แยกสองชั้นนี้ถูกคือท่อเตือนไม่มีวันดรอปของ ส่วน runbook ค้นได้อย่างเดียว คนรันยังเป็นมนุษย์ ทีมไหนหยิบไอเดียไปใช้แล้วรวมสองชั้นนี้เป็นชั้นเดียว (AI ตัดสินใจแล้วรันเองเลย) จะได้ความเร็วมาแลกกับความเสี่ยงที่ไม่มีใครเซ็นรับ
สรุปชวนใช้
สิ่งที่เอาไปใช้ได้ทันทีแม้ยังไม่ใช้ Versus มีสามอย่าง อย่างแรกคือกำหนดแพ็กเกจ triage เป็นมาตรฐานของทีมว่าเตือนทุกครั้งต้องตอบสามคำถามคือเกิดอะไร รุนแรงแค่ไหน ทำอะไรต่อ อย่างที่สองคือโหมดซ้อมเงียบ ๆ สำหรับระบบเตือนอะไรก็ได้ก่อนเปิดของจริง อย่างที่สามคือ template กลางที่แยกสำนวนออกจากโค้ดเตือน แก้คำพูดไม่ต้องแก้ระบบ
เงื่อนไขกลับมาดูใหม่มีสามข้อคือ roadmap ด้าน metrics traces และ cross-signal correlation ทำเสร็จแล้วหรือยัง ชุมชนมีคนรัน production จริงรีวิวไว้แค่ไหน และเรามีเวลาซ้อมนานพอให้ไว้ใจงานเขียนสรุปหรือไม่ ถ้าครบเมื่อไรค่อยกลับมาประเมินแบบรันจริงอีกครั้ง
ขอบคุณทีม VersusControl สำหรับงานต้นแบบแบบเปิดเผยใน repo versus-incident และเอกสารที่ docs.versusincident.com รวมถึงรายงานประเมินฉบับเต็มจาก muse101 Issue #12 ที่เป็นแหล่งหลักให้บทความนี้