PagerDuty หรือเหตุใดฝ่ายปฏิบัติการนอนไม่หลับ

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

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

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

เพจเจอร์ดิวตี้คืออะไร?

ดังนั้น เพื่อแก้ไขปัญหาเหล่านี้ เราจึงเริ่มมองหาเครื่องมือที่สะดวก หลังจากค้นหาแล้ว เราก็เลือก PagerDuty สำหรับเรา PD ดูเหมือนเป็นโซลูชันที่ค่อนข้างสมบูรณ์และรัดกุมพร้อมการผสานรวมและการตั้งค่าจำนวนมาก เธอชอบอะไร?

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

เจ้าหน้าที่ปฏิบัติหน้าที่คือใคร?

นี่อาจเป็นสถานที่แรกที่จะเริ่มตั้งค่า PD

ที่ FunCorp ก็เหมือนกับบริษัทอื่นๆ ที่มีตำแหน่งเจ้าหน้าที่กิตติมศักดิ์ มันถูกถ่ายทอดจากวิศวกรถึงวิศวกรวันละครั้ง มีสิ่งที่เรียกว่าบรรทัดแรกและบรรทัดที่สองของการตอบสนองต่อการแจ้งเตือนจาก PagerDuty สมมติว่าการแจ้งเตือนที่มีลำดับความสำคัญสูงมาถึง และหาก 10 นาทีหลังจากการเรียกไปยังเจ้าหน้าที่ปฏิบัติหน้าที่จากบรรทัดแรก ไม่มีการตอบสนองต่อการแจ้งเตือนนั้น (เช่น ไม่ได้โอนไปยังสถานะรับทราบหรือแก้ไขแล้ว) การโทรจะไปที่วินาที วิศวกรประจำ สิ่งนี้ได้รับการกำหนดค่าใน PagerDuty ผ่านนโยบายการยกระดับ

หากเจ้าหน้าที่ประจำการคนที่สองไม่ตอบสนอง การแจ้งเตือนจะถูกส่งกลับไปยัง หลัก ถึงเจ้าหน้าที่ปฏิบัติหน้าที่

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

มาดูกันว่าเหตุการณ์ต่างๆ มาจากไหน

เราใช้การบูรณาการอะไรบ้าง?

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

• โพร

ระบบรวบรวมตัวชี้วัดหลักคือ Prometheus มีการเขียนเกี่ยวกับเรื่องนี้ไว้มากมายใน Habré ฉันจะบอกว่าเรามีหลายรายการสำหรับสภาพแวดล้อมที่แตกต่างกัน: รายการหนึ่งรวบรวมตัวชี้วัดจากเครื่องเสมือนและนักเทียบท่า อีกรายการหนึ่งจากบริการของ Amazon และรายการที่สามจากเครื่องฮาร์ดแวร์ Telegraf ส่วนใหญ่จะใช้เป็นผู้ส่งออกตัวชี้วัด

• อีเมลล์

ฉันคิดว่าทุกอย่างชัดเจนจากชื่อที่นี่ การรวมนี้ใช้เพื่อส่งการแจ้งเตือนจากสคริปต์บางตัวที่ดำเนินการโดย cron PD จะให้ที่อยู่ที่แน่นอนแก่คุณซึ่งคุณส่งจดหมายไป เมื่อสร้างบริการด้วยการผสานรวมดังกล่าว คุณสามารถกำหนดลำดับความสำคัญได้ว่าจะประมวลผลเหตุการณ์ขาเข้าตามลำดับใด วิธีสร้างการแจ้งเตือนอย่างชัดเจน (สำหรับจดหมายขาเข้าแต่ละฉบับ สำหรับจดหมายขาเข้า + กฎบางอย่าง ฯลฯ)

• หย่อน

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

พวกเราทำ:

ที่เราเห็น:

• API

บูรณาการ HTTP ที่จริงแล้ว ไม่มีอะไรน่าสนใจเป็นพิเศษที่นี่ มีเพียงคำขอ POST ที่มีเนื้อหาในรูปแบบ JSON ตัวอย่างเช่น สิ่งที่น่าสนใจ: เราใช้มันสำหรับการตรวจสอบภายนอกโดยใช้ https://www.statuscake.com/. บริการนี้จะตรวจสอบการเข้าถึงเว็บไซต์ของเราจากส่วนต่างๆ ของโลก ในกรณีที่เราได้รับรหัสตอบกลับที่ไม่สามารถยอมรับได้ (เช่น 502) เหตุการณ์จะถูกสร้างขึ้น จากนั้นทุกอย่างจะเป็นไปตามสายโซ่ที่อธิบายไว้ข้างต้น StatusCake นั้นมีความสามารถในการตรวจสอบ URL ภายใน, ใบรับรอง SSL หรือการหมดอายุของโดเมน

• LibreNMS

นี่เป็นระบบการตรวจสอบอื่น คุณสามารถอ่านเพิ่มเติมได้บนเว็บไซต์ของพวกเขา https://www.librenms.org/. ด้วยความช่วยเหลือนี้ เราตรวจสอบอินเทอร์เฟซเครือข่ายและ iDRAC จากเซิร์ฟเวอร์

นอกจากนี้ยังมีการผสานรวม เช่น Datadog, CloudWatch คุณสามารถดูเพิ่มเติมเกี่ยวกับสิ่งที่เกิดขึ้นกับพวกเขาได้ ตรงนี้.

การแสดง

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

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

หลังจากการค้นหา "บอร์ด" ที่กระชับและให้ข้อมูลสำหรับ PD ใน GitHub อย่างละเอียดแต่ไม่ประสบผลสำเร็จ เราก็ตัดสินใจเขียนของเราเอง - เฉพาะสิ่งที่เราต้องการเท่านั้น แม้ว่าในตอนแรกจะมีแนวคิดที่จะแสดงอินเทอร์เฟซ PD เอง แต่มันก็ดูไม่สะดวกมากยิ่งขึ้น

ในการเขียน สิ่งที่คุณต้องทำคือรับรหัสจาก PD ที่มีสิทธิ์อ่านอย่างเดียว
และนี่คือสิ่งที่เราได้รับ:

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

ดูแหล่งที่มาของการดำเนินการนี้ได้ที่นี่.

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

ที่มา: will.com