ผู้บัญชาการเหตุการณ์ระบบล่ม (Incident Commander)

ข้อมูลที่ต้องเตรียม

หัวข้อ “Inputs to request” ระบุไว้ว่าจะขออะไรจากคุณ ถ้ายังไม่มี AI จะถามกลับก่อน

ระดับความพร้อม: ต้องเตรียมข้อมูลก่อน

ต้องมีข้อมูลจริงมาด้วย — ตัวเลข ร่างงาน หรือสถานการณ์ของคุณ รันโดยไม่ใส่บริบทจะได้คำตอบกลาง ๆ

เครื่องมือและภาษา

ใช้ได้กับผู้ช่วย AI ทุกตัวที่รับข้อความยาว Skill.md ได้ผลเต็มที่กับผู้ช่วยที่โหลดไฟล์ทักษะได้ ไฟล์เป็นภาษาอังกฤษอย่างเดียว คุยต่อเป็นไทยได้ แต่อย่าแปลตัวไฟล์

ใครควรใช้

System Admin, DevOps นอกกลุ่มนี้ควรใช้ผลเป็นจุดตั้งต้น ไม่ใช่คำตอบสุดท้าย

กรอบงานที่วางไว้ให้ AI

ไม่ประกาศบทบาท แต่วางกรอบงานทันทีในบริบทของโครงสร้างระบบและ DevOps เหมาะกับงานที่โจทย์ชัดอยู่แล้ว

โครงสร้างของคำสั่ง ทีละส่วน

หัวข้อจริงในไฟล์ แต่ละส่วนรับผิดชอบคนละเรื่อง

• Inputs to request — เก็บข้อมูลที่ AI ไม่มีทางเดาเองได้
• Phase 1 — Stabilise — เพิ่มรายละเอียดเฉพาะของงานนี้ (แบ่งเป็น 4 ขั้น)
• Phase 2 — Diagnose — เพิ่มรายละเอียดเฉพาะของงานนี้ (4 ข้อย่อย)
• Phase 3 — Write up (blameless) — เพิ่มรายละเอียดเฉพาะของงานนี้ (5 ข้อย่อย)
• Rules — ปิดช่องที่ผลลัพธ์มักเพี้ยน (5 ข้อย่อย)

ทำไมถึงได้ผลนิ่งกว่าการพิมพ์ถามเอง

ผลที่สม่ำเสมอไม่ได้มาจากถ้อยคำ แต่มาจากกลไกข้างในนี้

• มีส่วน “ข้อมูลที่ต้องขอ” ระบุไว้ชัด AI จึงถามกลับแทนที่จะเดา
• มีข้อห้ามระบุไว้ ซึ่งเป็นส่วนที่คนมักลืมใส่ ทั้งที่ช่วยประหยัดเวลาแก้งานได้มากที่สุด
• ตัวแปร 6 จุด ปรับไปใช้กับงานของคุณได้โดยไม่ต้องเขียนใหม่

ขั้นที่ 1 — เปิดไฟล์และเลือกเครื่องมือ

วางไฟล์ในโฟลเดอร์ skills ของผู้ช่วยที่คุณใช้ — โหลดเป็นทักษะถาวร ไม่ใช่วางในแชทครั้งเดียว ใช้ได้ทั้ง ChatGPT, Claude และ Gemini

ขั้นที่ 2 — แทนค่าในวงเล็บทั้ง 6 จุด

มีช่องในวงเล็บ 6 จุด แต่ละจุดคือข้อมูลที่ AI เดาแทนคุณไม่ได้ ปล่อยไว้ตามเดิมจะได้คำตอบกลาง ๆ

ขั้นที่ 3 — รันและอ่านผล

AI จะรับบทเป็น DevOps Engineer / System Architect แล้วทำงานตามกรอบที่ไฟล์วางไว้ ถ้าข้อมูลไม่ครบ AI จะถามกลับก่อน — นั่นคือคำสั่งทำงานถูกต้อง ไม่ใช่ข้อผิดพลาด

แก้ตรงไหนเมื่อผลลัพธ์ไม่ตรงใจ

แต่ละหัวข้อคุมพฤติกรรมคนละอย่าง แก้ทีละหัวข้อแล้วรันใหม่ ถ้ารื้อพร้อมกันหลายจุด จะไม่รู้ว่าอะไรได้ผล

ตัวแปรที่ต้องกรอกก่อนใช้งาน

แทนช่องในวงเล็บด้วยข้อมูลของคุณ ยิ่งเจาะจงยิ่งใช้ได้จริง

• [Symptom and blast radius — who is affected, how badly]
• [when it started]
• [recent changes — deploys, config, feature flags, infra]
• [current dashboards/alerts firing]
• [what has already been tried]
• [rollback options available]

ปรับความเข้มของข้อกำหนด

ปรับข้อกำหนดต่อจากตัวแปร แก้ทีละอย่าง ไม่งั้นจะไม่รู้ว่าอันไหนได้ผล

• เพิ่มหรือลดบรรทัดในหัวข้อ “Rules” คือวิธีคุมผลที่ตรงที่สุด หลุดกรอบซ้ำ ๆ ให้เติมข้อห้ามหนึ่งบรรทัด
• แทนคำกว้าง ๆ อย่าง “ลูกค้า” ด้วยคำอธิบายที่เจาะจงจนนึกภาพคนคนนั้นออก ผลลัพธ์จะเลิกกลาง ๆ ทันที
• ไฟล์นี้ยังไม่มีส่วนกำหนดสไตล์ เติมบรรทัดสั้น ๆ ว่าอยากได้โทนไหน ผลจะไม่แกว่งระหว่างรอบ

คำสั่งนี้ต้องเตรียมข้อมูลก่อน

กรอกทุกวงเล็บให้ครบก่อนส่ง ส่งทั้งที่ยังว่างจะได้ผลกลาง ๆ ที่ต้องมาแก้อยู่ดี

ต่อเป็น Workflow หลายขั้น

เอาผลจากคำสั่งนี้ไปเป็นข้อมูลตั้งต้นของคำสั่งถัดไปในหมวดโครงสร้างระบบและ DevOps ร่างก่อนแล้วค่อยส่งต่อให้ตรวจ ได้ผลดีกว่าสั่งทุกอย่างรอบเดียว

ข้อควรรู้เฉพาะไฟล์ Skill.md

ไฟล์นี้เป็น Skill.md ซึ่งตัวเนื้อหาเป็นภาษาอังกฤษโดยตั้งใจ เพราะเป็นไฟล์ที่ AI Agent อ่านเพื่อโหลดความสามารถ ไม่ใช่ข้อความที่คนอ่าน ถ้าจะแก้ ให้คงส่วน frontmatter ด้านบน (บรรทัด name และ description) ไว้ตามเดิม เพราะระบบใช้สองบรรทัดนี้ในการค้นหาและเรียกใช้สกิล ส่วนเนื้อหาด้านล่างแก้ได้อิสระ

หน้าตาของคำตอบ

ไม่ได้ล็อกเทมเพลตตายตัว แต่กรอบ 5 ส่วนทำให้คำตอบเดินตามลำดับเดิมทุกครั้ง

• สั่ง Rollback ทันทีเพื่อกู้ระบบ ระบุสัญญาณยืนยันผล แล้วค่อยเรียบเรียงไทม์ไลน์และปัจจัยร่วมเมื่อทราฟฟิกกลับมาปกติ

สิ่งที่คำสั่งนี้จะไม่ทำ

ข้อจำกัดเหล่านี้ตั้งใจใส่ไว้ — คำตอบที่ยอมบอกว่าไม่รู้ มีประโยชน์กว่าคำตอบที่มั่นใจแต่ผิด

• “Rules” ระบุสิ่งที่ห้ามทำไว้ชัดเจน 5 ข้อ คำตอบที่ข้ามข้อห้ามเหล่านี้ถือว่าไม่ผ่าน

วิธีดูว่ารอบนี้ได้ผลดีหรือยัง

สัญญาณของรอบที่ดี คือคำตอบอ้างอิงข้อมูลที่คุณให้จริง ไม่ใช่ตัวอย่างสมมติ ถ้า AI ถามกลับ แปลว่าคำสั่งทำงานถูกต้อง คำตอบที่กว้างจนใช้กับใครก็ได้ มักเกิดจากวงเล็บที่ยังไม่ได้แทนค่า