ฉันใช้เวลาหนึ่งสัปดาห์ในการฝึกงานวิศวกร SRE ได้อย่างไร หน้าที่ในสายตาของวิศวกรซอฟต์แวร์

วิศวกร SRE - ผู้ฝึกงาน

ก่อนอื่นให้ฉันแนะนำตัวเองก่อน ฉัน - @tristan.read,วิศวกรส่วนหน้าในกลุ่ม จอภาพ::สุขภาพ GitLab. สัปดาห์ที่แล้ว ฉันได้รับเกียรติให้ฝึกงานกับวิศวกร SRE ที่พร้อมให้ความช่วยเหลือคนหนึ่งของเรา เป้าหมายคือการสังเกตวิธีที่เจ้าหน้าที่ปฏิบัติหน้าที่ตอบสนองต่อเหตุการณ์ต่างๆ ในแต่ละวัน และได้รับประสบการณ์ชีวิตจริงในการทำงาน เราต้องการให้วิศวกรของเราเข้าใจความต้องการของผู้ใช้ได้ดีขึ้น ฟังก์ชัน จอภาพ::สุขภาพ.

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

เหตุการณ์

มี 2 ​​เหตุการณ์ภายในหนึ่งสัปดาห์

1. นักขุดคริปโต

GitLab.com มีการใช้งานเพิ่มขึ้นอย่างรวดเร็วในวันพุธ นักวิ่ง GitLab'ก เกิดจากความพยายามที่จะใช้นาทีของนักวิ่งเพื่อขุดสกุลเงินดิจิตอล เหตุการณ์ดังกล่าวได้รับการจัดการโดยใช้เครื่องมือลดการละเมิดของเราเอง ซึ่งจะหยุดงานของนักวิ่งและลบโปรเจ็กต์และบัญชีที่เกี่ยวข้อง

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

2. การลดประสิทธิภาพของ Canary และแอปพลิเคชันหลัก

เหตุการณ์นี้เกิดจากการชะลอตัวและความถี่ของข้อผิดพลาดที่เพิ่มขึ้นใน Canary และเว็บแอปพลิเคชันหลักบน Gitlab.com มีการละเมิดค่า Apdex หลายค่า

เปิดงานเหตุการณ์: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442

ค้นพบที่สำคัญ

ต่อไปนี้เป็นบางสิ่งที่ฉันเรียนรู้ระหว่างสัปดาห์ที่ปฏิบัติหน้าที่

1. การแจ้งเตือนมีประโยชน์มากที่สุดเมื่อตรวจจับความเบี่ยงเบนจากบรรทัดฐาน

การแจ้งเตือนสามารถแบ่งออกเป็นหลายประเภท:

• การแจ้งเตือนตามค่าเกณฑ์ที่กำหนด เช่น “เกิดข้อผิดพลาด 10xx ต่อวินาที”
• การแจ้งเตือนที่เกณฑ์เป็นค่าเปอร์เซ็นต์ เช่น “ความถี่ของข้อผิดพลาด 5xx ต่อ 10% ของปริมาณคำขอทั้งหมดในเวลาที่กำหนด”
• การแจ้งเตือนตามค่าเฉลี่ยในอดีต เช่น "ข้อผิดพลาด 5xx ที่เปอร์เซ็นไทล์ที่ 90"

โดยทั่วไปแล้ว ประเภทที่ 2 และ 3 จะมีประโยชน์มากกว่าสำหรับ SRE ที่ปฏิบัติหน้าที่ เนื่องจากเผยให้เห็นถึงการเบี่ยงเบนไปจากบรรทัดฐานในกระบวนการ

2. การแจ้งเตือนจำนวนมากไม่เคยบานปลายไปสู่เหตุการณ์ที่เกิดขึ้น

วิศวกร SR จัดการกับการแจ้งเตือนอย่างต่อเนื่อง ซึ่งหลายรายการไม่ได้มีความสำคัญจริงๆ

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

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

ข้อเสนอแนะคุณสมบัติ: https://gitlab.com/gitlab-org/gitlab/issues/42633

3. SRE ที่ปฏิบัติหน้าที่ของเราใช้เครื่องมือมากมาย

ภายใน:

• โครงการอินฟรา GitLab: มี runbooks อยู่ที่นี่ การมอบหมายกะ/สัปดาห์ งานตอบสนองต่อเหตุการณ์
• ปัญหา GitLab: การสืบสวน บทวิจารณ์ และการบำรุงรักษาจะได้รับการติดตามในประเด็นต่างๆ ด้วยเช่นกัน
• ป้ายกำกับ GitLab: งานอัตโนมัติจะเปิดตัวโดยใช้ป้ายกำกับเฉพาะ ซึ่งบอทใช้เพื่อติดตามกิจกรรมของงาน

ภายนอก:

• PagerDuty: การแจ้งเตือน
• Slack: กระแสข้อความ PagerDuty/AlertManager อยู่ที่นี่ บูรณาการกับคำสั่งเครื่องหมายทับเพื่อดำเนินการงานต่างๆ เช่น การปิดการแจ้งเตือนหรือยกระดับเหตุการณ์
• Grafana: การแสดงภาพเมตริกโดยเน้นที่แนวโน้มระยะยาว
• Kibana: ให้การแสดงภาพ/การค้นหาบันทึก ความสามารถในการเจาะลึกลงไปในเหตุการณ์เฉพาะ
• ซูม: มี "ห้องกลุ่มย่อย" ที่ทำงานอยู่ตลอดเวลาใน Zoom ช่วยให้วิศวกร SRE สามารถหารือเกี่ยวกับเหตุการณ์ต่างๆ ได้อย่างรวดเร็ว โดยไม่ต้องเสียเวลาอันมีค่าในการสร้างห้องและเชื่อมโยงผู้เข้าร่วม

และอื่นๆอีกมากมาย.

4. การตรวจสอบ GitLab.com ด้วย GitLab เป็นจุดเดียวของความล้มเหลว

หาก GitLab.com ประสบปัญหาบริการขัดข้องครั้งใหญ่ เราไม่ต้องการให้ส่งผลกระทบต่อความสามารถของเราในการแก้ไขปัญหา สามารถหยุดได้ด้วยการเปิดใช้งานอินสแตนซ์ GitLab ตัวที่สองเพื่อจัดการ GitLab.com อันที่จริงสิ่งนี้ใช้ได้กับเราแล้ว: https://ops.gitlab.net/.

5. คุณสมบัติบางประการที่ควรพิจารณาเพิ่มใน GitLab

• การแก้ไขงานที่มีผู้ใช้หลายคนคล้ายกับ Google เอกสาร สิ่งนี้จะช่วยในเรื่องงานในเหตุการณ์ที่เกิดขึ้นในระหว่างกิจกรรม เช่นเดียวกับงานในการซักถาม ในทั้งสองกรณี ผู้เข้าร่วมหลายคนอาจต้องเพิ่มบางอย่างแบบเรียลไทม์
• เว็บฮุคเพิ่มเติมสำหรับงาน ความสามารถในการรันขั้นตอนเวิร์กโฟลว์ GitLab ที่แตกต่างกันจากภายในจะช่วยลดการพึ่งพาการผสานรวม Slack ตัวอย่างเช่น ความสามารถในการอนุญาตการแจ้งเตือนใน PagerDuty ผ่านคำสั่ง slash ในปัญหา GitLab
  ข้อสรุป

วิศวกร SRE มีช่วงเวลาที่ยากลำบากและมีความซับซ้อนมากมาย คงจะดีไม่น้อยหากได้เห็นผลิตภัณฑ์ GitLab อื่นๆ ที่สามารถแก้ไขปัญหาเหล่านี้ได้ เรากำลังดำเนินการเพิ่มเติมบางอย่างกับผลิตภัณฑ์ซึ่งจะทำให้ขั้นตอนการทำงานที่กล่าวถึงข้างต้นง่ายขึ้น รายละเอียดดูได้ที่ ส่วนวิสัยทัศน์ผลิตภัณฑ์ Ops.

เรากำลังขยายทีมในปี 2020 เพื่อนำฟีเจอร์ที่ยอดเยี่ยมเหล่านี้มารวมกัน หากสนใจโปรดตรวจสอบ ตำแหน่งงานว่างและอย่าลังเลที่จะติดต่อทุกคนในทีมของเราหากมีคำถามใดๆ

ที่มา: will.com