62% ของวิศวกรที่อยู่ในเวรยามหมดไฟภายใน 12 เดือน (PagerDuty 2026) นี่ไม่ใช่ปัญหาของคน แต่เป็นปัญหาการออกแบบทางวิศวกรรม สาเหตุหลักสามประการที่มีในทุกเวรยามที่หมดไฟ: 1. การแจ้งเตือนเกี่ยวกับอาการแทนที่จะเป็นสาเหตุ การเพิ่มขึ้นของ CPU, ความลึกของคิว, อัตราคำขอ — สิ่งเหล่านี้ไม่ใช่เหตุการณ์ใดๆ ทั้งสิ้น แต่ทั้งหมดล้วนทำให้คนตื่นขึ้นมาตอนตีสาม 2. คู่มือการดำเนินการล้าสมัย แจ้งเตือนเกิดขึ้น แต่คู่มือชี้ไปยังบริการที่เปลี่ยนชื่อแล้ว วิศวกรต้องย้อนกลับมาวิเคราะห์ระบบด้วยอะดรีนาลีนและไม่มีการนอนหลับ 3. เวลารับผิดชอบแบบสมมาตรสำหรับภาระงานที่ไม่สมมาตร วันสุดสัปดาห์คือซูเปอร์โบวล์ วันธรรมดาคือการวิ่งเร็ว แต่การจัดเวรเดียวกันกลับจัดการทั้งสองแบบเหมือนกัน สี่วิธีแก้ไขที่ทีมที่ดีที่สุดนำไปใช้: 1. งบประมาณข้อผิดพลาด จำกัดงานเวรยามที่ไม่ได้วางแผนไว้ไว้ที่ 25% ของแต่ละสัปดาห์ หากเกินกว่านั้น การพัฒนาฟีเจอร์ใหม่จะหยุดลง ซึ่ง Google SRE เป็นผู้เขียนคู่มือไว้ 2. การแจ้งเตือนเชื่อมโยงกับ SLO หากไม่เกี่ยวข้องกับการละเมิด SLO ที่ผู้ใช้สามารถสังเกตได้ มันคือเสียงรบกวน 23% ของเวลาเวรยามเป็นการแจ้งเตือนผิดพลาด (Blameless 2026) 3. คู่มือหรือลบออก การแจ้งเตือนในระบบผลิตต้องมีคู่มือการดำเนินการที่อัปเดตอยู่เสมอ หรือจะต้องลบการแจ้งเตือนนั้นออก คุณจะสูญเสียการแจ้งเตือนไปครึ่งหนึ่ง — นั่นคือจุดประสงค์ 4. การจัดเวรตามภาระงาน ช่วงเวลาเร่งด่วนต้องมีการดูแลมากขึ้นหรือเวรสั้นลง การจัดเวรแบบเดียวสำหรับทุกคนเป็นการลงโทษผู้ที่ได้รับช่วงเวลาเร่งด่วน หากคุณเป็นผู้นำด้านวิศวกรรม การออกแบบเวรยามคือหน้าที่ของคุณ ไม่ใช่ของฝ่ายทรัพยากรบุคคล หรือหัวหน้าทีมของคุณ — คุณเอง สัปดาห์นี้: เปิดแดชบอร์ด นับจำนวนการแจ้งเตือน และถามว่ามีกี่รายการควรได้รับการจัดการโดยแพลตฟอร์ม ไม่ใช่มนุษย์ #EngineeringLeadership #OnCall #SRE