การสร้างวัฒนธรรม On-Call ที่ดีต่อสุขภาพ

 (developers.soundcloud.com)
25 คะแนน โดย xguru 2021-06-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เคล็ดลับจาก SoundCloud เกี่ยวกับ “On-Call” ซึ่งเป็นการกำหนดวิศวกรที่จะถูกเรียกตัว (Paging) เพื่อเข้าไปแก้ปัญหาเมื่อเกิดเหตุขัดข้องนอกเวลางาน

  1. งาน On-Call เป็นทางเลือก (Optional, เฉพาะผู้สมัครใจเท่านั้น)

  2. เนื่องจากเป็นการทำงานนอกเวลาทำการปกติ จึงมีค่าตอบแทนรายชั่วโมง และเมื่อมีการตอบรับเพจจะได้รับค่าตอบแทนเพิ่มเป็นรายชั่วโมง

  3. วิศวกร On-Call ประกอบด้วยหลายโรเทชัน

  4. แต่ละโรเทชัน

→ ประกอบด้วยกลุ่มวิศวกรที่เป็นตัวแทนของหนึ่งทีมหรือหลายทีม

→ จะมีวิศวกร 1 คนคอยประจำอยู่เสมอเพื่อรับผิดชอบการสนับสนุนระดับแรกสำหรับปัญหาของทุกทีมในโรเทชันนั้น

→ วิศวกรคนอื่น ๆ จะคอยเป็นการสนับสนุนระดับที่สองสำหรับปัญหาเกี่ยวกับบริการของทีมตนเอง

→ การสนับสนุนระดับที่สองเป็นแบบ best-efforts: อาจถูกเพจได้ตลอดเวลาและจะช่วยอย่างเต็มที่เท่าที่ทำได้ แต่หากไม่พร้อมก็ไม่จำเป็นต้องตอบรับ

ทำไมงาน On-Call ถึงดีต่อวิศวกร?

  • การให้งาน On-Call กับวิศวกรหลากหลายประเภทนอกเหนือจาก DevOps และ SRE (Site Reliability Engineers) เป็นผลดีทั้งต่อบริษัทและตัววิศวกรเอง

  • ช่วยลดภาระของวิศวกรทีมปฏิบัติการที่มักต้องทำงานนอกเวลาอยู่เสมอ

  • ช่วยสร้างแรงจูงใจให้วิศวกรสร้างระบบที่เสถียรและมีเอกสารประกอบอย่างดี

→ การได้เห็นปัญหาด้วยตัวเองเมื่อเกิดเหตุ จะทำให้ได้อินไซต์ว่าควรปรับปรุงและทำให้ระบบแข็งแรงขึ้นอย่างไร

  • การได้ช่วยดูแลทั้งระบบของตนเองและของผู้อื่นเป็นโอกาสที่ดีให้วิศวกรได้เรียนรู้

แนวปฏิบัติด้านกระบวนการ: ทุกองค์กรแตกต่างกัน แต่นี่คือกระบวนการที่ดีที่สุดที่ SoundCloud ค้นพบ

  • แต่ละโรเทชันมีรอบผลัดเปลี่ยนต่างกัน แต่ส่วนใหญ่จะสลับทุก 1 ถึง 2 วัน

  • การเข้าเวร On-Call ประมาณ 3 วันต่อเดือนถือว่าเหมาะสมที่สุด มากกว่านั้นจะเสี่ยง burnout และน้อยกว่านั้นก็จะไม่มีประสิทธิภาพ

→ กล่าวคือ จำนวนคนที่เหมาะสมในโรเทชันคือ 8~12 คน และ 10 คนถือว่าสมบูรณ์แบบ

  • เลือกผู้ดูแลแบบเป็นทางการหรือไม่เป็นทางการภายในโรเทชัน เพื่อจัดการตารางเวรและการเปลี่ยนแปลงสมาชิกในโรเทชัน

→ ตัวอย่าง) การปรับตารางเวรในช่วงวันหยุดยาว

ทีมโรเทชันและองค์กร

  • องค์กรของ SoundCloud มีการพัฒนาไปตามเวลา และเกิดการควบรวม/แยกตัว/สร้างทีมใหม่/ย้ายทีมข้ามแผนกอยู่เสมอ

  • แต่ทีมโรเทชัน On-Call ไม่ได้พัฒนาไปในจังหวะเดียวกับองค์กรวิศวกรรม

  • ปัจจุบัน หลายโรเทชันจึงดูเหมือนเป็นการรวมทีมที่ไม่เกี่ยวข้องกันแบบสุ่ม

  • แต่สิ่งนี้ไม่ได้เป็นปัญหา และความพยายามที่จะเปลี่ยนแปลงก็ถูกยุติลงหลังจากวิศวกรคัดค้าน

แนวปฏิบัติด้านวัฒนธรรม: เพื่อประโยชน์ของวิศวกร On-Call และทั้งบริษัท ควรส่งเสริมบรรทัดฐานและทัศนคติดังต่อไปนี้

  • คนที่อยู่ในเวร On-Call ควรเป็นคนที่อยากอยู่เวรจริง ๆ วิศวกรที่รับภาระนี้ด้วยความสมัครใจ (และได้รับค่าตอบแทน) จะมีแรงจูงใจมากกว่าเมื่อรับมือกับเหตุขัดข้อง

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

  • วิศวกร On-Call มักใช้เวลาในชั่วโมงทำงานปกติเพื่อสืบสวนปัญหาเหล่านี้ ไม่ให้ลุกลาม หรือไม่ให้ต้องเพจคนอื่นในเวลานอกงาน

  • เมื่อตอบสนองต่ออุบัติการณ์ วิศวกรสามารถเรียกวิศวกรคนอื่นมาช่วยได้ ไม่มีใครชอบถูกเรียกเป็นการสนับสนุนระดับที่สองกลางดึก แต่หากช่วยตอบรับได้ ก็จะเป็นโอกาสในการช่วยเหลือและสอนให้คนแรกจัดการสถานการณ์ลักษณะเดียวกันได้เองในอนาคต

  • หลังจากผ่านไประยะเวลาที่สมเหตุสมผลแล้ว ควรสามารถส่งต่องานให้คนอื่นได้อย่างอิสระ ในกรณีของอุบัติการณ์ร้ายแรงหรือยืดเยื้อ หากวิศวกรเหนื่อยจนทำงานต่อได้ไม่เต็มประสิทธิภาพ ก็ควรส่งต่องานภายใน 4 ชั่วโมงหรือน้อยกว่านั้น

  • ที่สำคัญที่สุดคือ “การสร้างวัฒนธรรมแห่งการเรียนรู้ ไม่ใช่วัฒนธรรมแห่งการตำหนิ” ซึ่งย้ำเท่าไรก็ไม่เกินจริง

→ ความผิดพลาดเป็นส่วนที่หลีกเลี่ยงไม่ได้ของการรับมือกับอุบัติการณ์ และการเรียนรู้จากความผิดพลาดจะช่วยสร้างองค์กรวิศวกรรมที่แข็งแกร่งและมีความสามารถทางเทคนิคมากขึ้น

→ หากลงโทษผู้คนเพราะความผิดพลาด วิศวกรจะกลัวการลงมือเมื่อเจอสถานการณ์ใหม่ กลัวการขอความช่วยเหลือ และกลัวความโปร่งใส

→ ท้ายที่สุดแล้ว ในวัฒนธรรมแห่งการตำหนิ ผู้คนจะเลิกทำ On-Call rotation หรือไม่ก็ลาออกจากบริษัท

เมื่อเกิดอุบัติการณ์ใหญ่

  • การรับมือกับการล่มของทั้งไซต์หรืออุบัติการณ์ร้ายแรงเป็นเรื่องที่สร้างความเครียดให้ทุกคน

  • นี่เป็นเหมือนการทดสอบความแข็งแกร่งของวัฒนธรรม On-Call ของบริษัทด้วย

  • การที่วิศวกรทำงานร่วมกันและไว้วางใจกันมีความสำคัญยิ่งกว่าสิ่งอื่นใด

  • หากสามารถยอมรับว่ายังไม่รู้ ขอความช่วยเหลือจากผู้อื่น พูดอย่างตรงไปตรงมาเมื่อทำผิดพลาด และบอกได้ว่าเหนื่อยเกินกว่าจะทำต่อไหว ก็จะช่วยแก้ปัญหาได้เร็วขึ้น

  • พฤติกรรมเหล่านี้ควรถูกปลูกฝังก่อนที่จะเกิดอุบัติการณ์ใหญ่ วิศวกรจะเรียนรู้จากประสบการณ์ผ่านการรับมือกับอุบัติการณ์เล็ก ๆ และการร่วมมือกับเพื่อนร่วมงาน

→ อุบัติการณ์เล็ก ๆ คือการซ้อมสำหรับอุบัติการณ์ใหญ่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
xguru 2021-06-07

สตาร์ทอัพมีคนน้อย จึงให้ความรู้สึกเหมือนต้อง on-call อยู่ตลอดเวลา..

แต่พอองค์กรเริ่มใหญ่ขึ้นเล็กน้อย ก็จะกลายเป็นว่ามีเพียงบางคนที่ต้อง on-call ต่อเนื่อง และต้องคอยแก้ปัญหาแม้ในช่วงเย็นและวันหยุดสุดสัปดาห์ จนเห็นภาวะหมดไฟได้

โดยพื้นฐานแล้วคงต้องสร้างวัฒนธรรมให้ดีตั้งแต่ต้น (ว่าไปแล้วผมเองก็ดูจะทำได้ไม่ค่อยดี เลยกำลังทบทวนตัวเองอยู่ครับ..)