ทีมวิศวกรของคุณมีอาการเหนื่อยล้าหรือไม่? ถามคำถาม 8 ข้อนี้

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

ปัญหามักเกิดจากแนวทางที่ไม่ได้ตั้งใจในการเขียนการแจ้งเตือนเมื่อทีมเติบโตขึ้นและเริ่มใช้โครงสร้างพื้นฐานที่มีความซับซ้อนมากขึ้น ซึ่งถือเป็นเรื่องปกติ เนื่องจากบริษัทหรือทีมเติบโตขึ้น มักจะต้องใช้เวลาเพื่อให้วัฒนธรรมการสังเกตและแนวทางปฏิบัติที่ตื่นตัวมั่นคงจึงจะเป็นรูปเป็นร่าง

การสร้างการแจ้งเตือนที่ละเอียดอ่อนเกินไป มีเสียงดังเกินไป และระมัดระวังเกินไปนั้นทำได้ง่าย ในตอนเริ่มต้น ทุกอย่างดูน่าตื่นตัวเพียงเพราะว่าควรระมัดระวังและเพิ่มสัญญาณการผลิตให้สูงสุดในช่วงแรกๆ ของผลิตภัณฑ์

“ในขณะที่จำนวนและความซับซ้อนของคุณสมบัติและโครงสร้างพื้นฐานเพิ่มขึ้น การปรับปรุงการแจ้งเตือนมักจะลดลำดับความสำคัญลง”

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

เช่นเดียวกับบริษัทอื่นๆ อินเตอร์คอมไม่มีภูมิคุ้มกันต่อความไร้ประสิทธิภาพเหล่านี้ ดังนั้นเราจึงคิดค้นกระบวนการที่ค่อนข้างเบาเพื่อต่อสู้กับความเหนื่อยล้าที่ตื่นตัว

วิธีที่เราคิดเกี่ยวกับกลยุทธ์การแจ้งเตือน

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

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

8 คำถามที่ต้องถามเมื่อประเมินการแจ้งเตือนของทีม

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

เซสชั่นการตรวจสอบการแจ้งเตือนแต่ละรายการจะเริ่มต้นด้วยรายการการแจ้งเตือนที่เริ่มทำงานในช่วงเวลาก่อนหน้า โดยเรียงลำดับตามความถี่ของการแจ้งเตือน เราใช้แพลตฟอร์ม PagerDuty เป็นแหล่งที่มาของการแจ้งเตือน และคุณลักษณะการวิเคราะห์ให้ข้อมูลที่จำเป็นแก่เราเพื่อแยกย่อยความถี่ในการแจ้งเตือนและการตอบสนอง การแจ้งเตือนที่มีส่วนทำให้เกิดเสียงรบกวนโดยรวมมากที่สุด (เช่น ไฟไหม้บ่อยที่สุด) จะได้รับการตรวจสอบก่อน

การแจ้งเตือนแต่ละครั้งจะถูกส่งผ่านรายการตรวจสอบคำถาม:

1. การแจ้งเตือนยังคงมีความเกี่ยวข้องหรือไม่?

การแจ้งเตือนใดๆ ที่เกิดจากระบบที่ล้าสมัยหรือไม่ได้รับการบำรุงรักษาไม่ควรรบกวนวิศวกรที่รับสาย และควรลบออกทันที

2. การแจ้งเตือนสามารถดำเนินการได้หรือไม่?

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

3. ข้อมูลในการแจ้งเตือนมีประโยชน์ทันทีแม้ว่าจะไม่สามารถดำเนินการได้หรือไม่?

เราสามารถแบ่งข้อมูลการแจ้งเตือนออกเป็นสองประเภทกว้างๆ

• สัญญาณ: การแจ้งเตือนเหล่านี้จะเตือนถึงระบบปฏิบัติการที่ทำงานถึงขีดจำกัด แต่ไม่ได้หมายความว่าบริการจะได้รับผลกระทบเสมอไป ตัวอย่างอาจเป็นหนึ่งในเซิร์ฟเวอร์ของคุณที่ทำงานด้วย CPU 100% หากบริการยังทำงานได้ดี การโทรควรใช้เวลาอันมีค่าในการตรวจสอบหรือไม่ ท้ายที่สุดแล้ว เซิร์ฟเวอร์ของคุณก็ทำงานด้วยอัตราส่วนการทำงานต่อต้นทุนที่ดีที่สุด!
• อาการ: การแจ้งเตือนเหล่านี้จะเริ่มทำงานเมื่อประสบการณ์ของลูกค้าได้รับผลกระทบ ตัวอย่างที่นี่คือจำนวนข้อผิดพลาด HTTP 5XX ที่บริการของคุณส่งคืนให้กับผู้โทร

ทั้งสองประเภทนี้ทำงานได้ดีที่สุดควบคู่กันไป ผู้โทรควรตอบสนองและแก้ไขปัญหาอาการ และมองสัญญาณเป็นแหล่งข้อมูลเพิ่มเติมเท่านั้น

4. หากการแจ้งเตือนนั้นสามารถดำเนินการได้และเพจจิ้งต้องจัดการทันทีหรือไม่?

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

5. หากสามารถดำเนินการได้ จะมี runbook หรือลิงค์การแก้ไขปัญหาหรือไม่? ขั้นตอนชัดเจนพอที่จะให้วิศวกรในทีมทำตามหรือไม่?

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

“ การรักษาข้อมูลการแก้ปัญหาการแจ้งเตือนให้ชัดเจน เรียบง่าย และเป็นปัจจุบัน ช่วยลดเวลาเฉลี่ยของคุณเพื่อบรรเทาและกู้คืนจากเหตุการณ์ที่เกิดขึ้น ”

แม้ว่าคุณจะมีความเชี่ยวชาญ แต่คุณอาจเขียนโค้ดมานานแล้วจนคุณจำไม่ได้ชัดเจนว่าควรทำอย่างไร การรักษาข้อมูลการแก้ปัญหาการแจ้งเตือนให้ชัดเจน เรียบง่าย และทันสมัยอยู่เสมอจะช่วยลดเวลาเฉลี่ยของคุณเพื่อบรรเทาและกู้คืนจากเหตุการณ์ที่เกิดขึ้น (MTTM และ MTTR)

6. หากสามารถดำเนินการได้ จะมีลิงก์แดชบอร์ดหรือไม่ และแสดงสาเหตุที่เป็นไปได้ทั้งหมดหรือไม่

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

7. การแจ้งเตือนมีความละเอียดอ่อนเกินไปหรือไม่เฉพาะเจาะจงเพียงพอหรือไม่ จะได้รับประโยชน์จาก desensitization หรือการเปลี่ยนแปลงขอบเขตหรือไม่?

การแจ้งเตือนจำนวนมากมีประโยชน์แต่ปรับเทียบผิด พวกมันอาจกว้างเกินไปและไม่ยิงทุกครั้งที่ควร หรือเจาะจงเกินไปและยิงหลายครั้งสำหรับเหตุการณ์เดียวกัน ซึ่งทำให้เกิดเสียงรบกวน

8. สุดท้ายแล้ว มนุษย์ต้องแก้ไขหรือไม่?

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

โดยเฉพาะอย่างยิ่งหากคุณใช้งานบนแพลตฟอร์มระบบคลาวด์ เช่น AWS และสามารถจัดเตรียมโครงสร้างพื้นฐานโดยไม่ต้องกังวลเรื่องการขอฮาร์ดแวร์เพิ่มเติม ตัวอย่างเช่น หากโหนดในคลัสเตอร์การค้นหาของคุณแสดงดิสก์ที่ล้มเหลว ทำไมไม่แทนที่โดยอัตโนมัติ หากบริการมีทรัพยากรในการประมวลผลเหลือน้อยเนื่องจากปริมาณการใช้งานที่เพิ่มขึ้น ทำไมไม่ขยายขนาดและเพิ่ม VM หรือคอนเทนเนอร์เพิ่มเติมล่ะ จากนั้น รายละเอียดของวิธีแก้ไขจะถูกส่งไปยังทีมผ่านช่องทางที่ไม่แจ้งเตือน เพื่อให้พวกเขาสามารถทบทวนได้ตามต้องการ

คุณได้ตอบว่า "ไม่" สำหรับคำถามเหล่านี้หรือไม่?

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

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

คุณสนใจวิธีการทำงานของเราที่อินเตอร์คอมหรือไม่? เราชอบที่จะพูดคุยกับคุณ – ตรวจสอบบทบาทวิศวกรรมที่เปิดกว้างของเรา