วัฒนธรรม On-Call ที่ GitHub สร้างขึ้น

GitHub เคยเป็นระบบโมโนลิธขนาดใหญ่ที่สร้างด้วย Ruby on Rails

ส่วนที่ยากที่สุดในโครงสร้าง on-call ของโมโนลิธ

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

• ช่วงห่างระหว่างการเข้า on-call นานมาก และแต่ละครั้งกินเวลา 24 ชั่วโมง วิศวกรแต่ละคนเข้า on-call ไม่เกิน 4 ครั้งต่อปี ทำให้ระหว่างการเข้าเวรไม่ได้บริบทมากพอ

• ระบบ monitoring และ alerting กระจายอยู่ตามหลายทีม และเพราะแต่ละคนได้สัมผัส on-call เพียง 24 ชั่วโมง จึงทำให้การดูแล monitoring และเอกสารสำหรับ on-call ไม่ค่อยได้รับการบำรุงรักษาอย่างดี

• เพราะวิศวกรส่วนใหญ่ไม่มั่นใจกับ on-call ของโมโนลิธ คนเพียง 5~10 คนที่เข้าใจระบบทั้งหมดดีจึงต้องเข้าร่วมทุก incident ใน production ทำให้เกิดความไม่สมดุลของภาระ on-call

วัฒนธรรม on-call แบบใหม่

อุปสรรคด้านการจัดโครงสร้างงาน

• สร้าง service catalog เพื่อให้ระบุ file ownership ได้ชัดเจนขึ้น โดยแมปไฟล์เข้ากับบริการ และแมปบริการกลับไปยังทีมอีกที

• เดิม monitoring และการแจ้งเตือนถูกตั้งไว้ครอบคลุมทั้งโมโนลิธ จึงปรับให้แต่ละทีมสร้าง monitoring สำหรับขอบเขตที่ตนรับผิดชอบ

• เนื่องจากมีหลายทีมที่ต้องทำงานนี้ จึงสร้าง issue ใน GitHub ให้แต่ละทีมและจัดเตรียม checklist ไว้ให้

อุปสรรคด้านวัฒนธรรมและการศึกษา

• การระบาดใหญ่ส่งผลกระทบด้านลบต่อผู้คน จึงต้องใช้แนวทางที่ให้ความสำคัญกับ empathy มากกว่าที่เคยคิดไว้

• วิศวกรส่วนใหญ่แทบไม่มีประสบการณ์ on-call และยังมีประสบการณ์ด้าน operations ไม่มากนัก จึงจัดทำและเปิดสอนการฝึกอบรม กำหนดเวลาทำงานร่วมกับผู้เชี่ยวชาญด้าน on-call จัดเตรียมเครื่องมือและเอกสารให้เพียงพอ และสร้างช่อง Slack สำหรับขอความช่วยเหลือ

• วิศวกรจำนวนมากกังวลว่า on-call จะกระทบชีวิตมากแค่ไหน หากยังมีประสบการณ์ไม่มาก การปรับเวลาชีวิตประจำวันระหว่างเข้า on-call อาจเป็นเรื่องยาก เพื่อรับมือกับเรื่องนี้ จึงรวบรวม tips/tricks จากผู้เชี่ยวชาญด้าน on-call และเตรียมมาตรการอย่างการให้คนอื่นช่วย backup ได้เมื่อพลาดการเรียก นี่เป็นปัญหาจากความไม่คุ้นเคย จึงเป็นสิ่งที่จะรู้สึกสบายใจขึ้นได้เมื่อผ่านการเข้า on-call หลายครั้งและเมื่อเวลาผ่านไป มากกว่าจากการฝึกเพียงอย่างเดียว

• หลายคนกังวลว่าจะรับมือกับ on-call ได้ไม่ดีพอ จึงพยายามสร้างความมั่นใจว่าการทำพลาดเป็นเรื่องที่ยอมรับได้ และไม่ว่าจะเก่งแค่ไหน incident ก็ยังเกิดขึ้นได้อยู่ดี

• แต่ละผลิตภัณฑ์มีระดับความรุนแรงไม่เท่ากัน บางทีมต้องตอบสนองภายใน 5 นาที แต่อีกบางทีมจัดการในวันถัดไปก็ได้ บางคนมองว่านี่ไม่ยุติธรรม แต่จริง ๆ แล้วเป็นเพียงเพราะวิศวกรแต่ละคนมีความสนใจต่างกัน

• ระหว่างนำการเปลี่ยนแปลงไปใช้ แต่ละทีมไม่สามารถใช้เวลาจำนวนมากเพื่อปรับปรุงประสบการณ์ on-call ได้ เมื่อ on-call ดำเนินไปได้ไม่ดี ก็ควรปรับปรุงกระบวนการ on-call โดยสื่อสารกับทีมว่าควรใช้ ~20% ไปกับการชำระหนี้ทางเทคนิค และอีก ~20% ไปกับการปรับปรุงประสบการณ์ on-call ซึ่งต้องอาศัยมุมมองระยะยาวจากผู้นำ

[galadbran]

ผมไม่ค่อยรู้เหมือนกันว่า on-call คืออะไรโดยคร่าว ๆ... น่าจะเป็นคำขอให้ช่วยซัพพอร์ตหรือเปล่านะ คงไม่ใช่การรับโทรศัพท์แบบบ้านเราแน่ ๆ...

[andrewchaa]

ในบริษัทของเรา โดยปกติจะเรียกว่า on-call คือการคอยตอบสนองต่อเหตุขัดข้องของระบบแบบเรียลไทม์นอกเวลางานประมาณสัปดาห์หนึ่งทุก ๆ สองเดือน มักใช้แอปชื่อ PagerDuty กันมาก และถ้าเกิดเหตุขัดข้องที่มี severity สูง เช่น มี dead letter เกิดขึ้น หรืออัตรา api failure rate เกินระดับที่กำหนด ... ก็จะมีการแจ้งเตือนเข้ามาที่โทรศัพท์มือถือทันที แล้วจึงเชื่อมต่อผ่านแล็ปท็อปของบริษัทเพื่อตรวจสอบล็อกและดำเนินการที่จำเป็น

[sukso96100]

น่าจะคิดว่าเป็นการเข้าเวรได้ครับ

[bach80]

ให้ความรู้สึกประมาณเวรหรือผลัดประจำสัปดาห์นะครับ คือผลัดกันรับมือเหตุขัดข้อง...