ทีมของเราชอบการทดลอง Slurm แต่ละรายการไม่ใช่การทำซ้ำแบบคงที่จากครั้งก่อน แต่เป็นการสะท้อนถึงประสบการณ์และการเปลี่ยนแปลงจากดีไปสู่ดีขึ้น แต่ด้วย เราตัดสินใจใช้รูปแบบใหม่ทั้งหมด - เพื่อให้ผู้เข้าร่วมมีเงื่อนไขใกล้เคียงกับ "การต่อสู้" มากที่สุด
หากเราสรุปสั้นๆ ว่าเราทำอะไรบ้างระหว่างหลักสูตรเร่งรัด “เราสร้าง เราพัง เราซ่อมแซม
เรากำลังเรียนอยู่" SRE มีค่าเพียงเล็กน้อยในทางทฤษฎีเท่านั้น มีเพียงการฝึกฝน วิธีแก้ไขที่แท้จริง ปัญหาที่แท้จริง
ผู้เข้าร่วมถูกแบ่งออกเป็นทีมเพื่อให้จิตวิญญาณการแข่งขันที่แข็งแกร่งไม่ยอมให้ใครหลับหรือเปิดตัว "Angry Birds" บน iPhone ตามตัวอย่างของ Dmitry Anatolyevich
ปัญหา ข้อผิดพลาด จุดบกพร่อง และงานต่างๆ ได้รับการจัดเตรียมให้กับผู้เข้าร่วมโดยที่ปรึกษาสี่คน Ivan Kruglov ผู้พัฒนาหลักของ Booking.com (เนเธอร์แลนด์) เบ็น ไทเลอร์ ผู้พัฒนาหลักของ Booking.com (สหรัฐอเมริกา) Eduard Medvedev, CTO ของ Tungsten Labs (เยอรมนี) Evgeniy Varavva นักพัฒนาทั่วไปของ Google (ซานฟรานซิสโก)
นอกจากนี้ผู้เข้าร่วมจะถูกแบ่งออกเป็นทีมและแข่งขันกันเอง น่าสนใจ?
Ivan, Ben, Eduard และ Evgeniy มองไปที่ผู้เข้าร่วม Slurm SRE ที่น่าสงสารพร้อมกับเหล่เลนินผู้ใจดีก่อนเริ่มการแข่งขัน
ดังนั้นภารกิจ:
เราเป็นของเรา เราจะสร้างโลกใหม่...
มีเว็บไซต์รวบรวมตั๋วหนัง เหตุการณ์ต่างๆ ได้รับการประดิษฐ์ขึ้นโดยที่ปรึกษาในสถานการณ์ที่ได้เตรียมไว้ล่วงหน้า (แม้ว่าจะไม่มีใครยกเว้นการแสดงด้นสดที่ซับซ้อนและร้ายกาจเป็นพิเศษ) ประสิทธิภาพของไซต์นั้นได้รับการอธิบายโดยใช้ตัวชี้วัดต่างๆ ปัญหาอาจแตกต่างกันมาก: ตั๋วสำหรับโรงละครมูแลงรูจไม่ได้โหลดลงในฐานข้อมูล โปสเตอร์ภาพยนตร์และการแสดงจะถูกโหลดเข้าสู่ฐานข้อมูลภายในเวลามากกว่า 10 วินาที คำอธิบายของภาพยนตร์แต่ละเรื่องค้าง 0,1% ของคำสั่งซื้อถูกจองแล้ว ในบางครั้งระบบประมวลผลการชำระเงินขัดข้องเป็นเวลาหนึ่งหรือสองนาที และสิ่งไม่พึงประสงค์มากมายที่อาจเกิดขึ้นกับผู้เข้าร่วม Slurm SRE ในงานจริงของเขา
เราพร้อมจะจัดการทุกอย่าง...และทุกๆ คน
เว็บไซต์ที่ต้องทนทุกข์ทรมานมายาวนานของเราประกอบด้วยไมโครเซอร์วิสหลายอย่าง หน้าที่ของมันคือรวบรวมข้อมูลเกี่ยวกับการแสดง ราคา และที่นั่งว่างจากโรงภาพยนตร์ทุกแห่ง โดยแสดงประกาศภาพยนตร์ ให้คุณเลือกโรงภาพยนตร์ การแสดง ห้องโถงและสถานที่ จองและชำระค่าตั๋วได้ โดยทั่วไปแล้วทุกสิ่งที่ผู้ชมทำได้เพียงฝันถึง มีเพียงผู้ใช้เท่านั้นที่ไม่สงสัยด้วยซ้ำว่าการต่อสู้ครั้งใหญ่เพื่อความเสถียรและการเข้าถึงไซต์นั้นเกิดขึ้นภายในอะไร
สำหรับไซต์ที่มีความเข้มข้นสูง เราได้สร้างตัวบ่งชี้ SLO, SLI, SLA, สถาปัตยกรรมและโครงสร้างพื้นฐานที่พัฒนาแล้ว, ปรับใช้ไซต์, ตั้งค่าการตรวจสอบและการแจ้งเตือน และเราไปกัน
SLO, SLI, SLA
SLI - ตัวบ่งชี้ระดับการบริการ SLO คือเป้าหมายระดับการให้บริการ SLA - ข้อตกลงระดับการให้บริการ
SLA เป็นคำศัพท์วิธีการของ ITIL ที่แสดงถึงข้อตกลงอย่างเป็นทางการระหว่างลูกค้าของบริการและซัพพลายเออร์ โดยมีคำอธิบายของบริการ สิทธิและภาระผูกพันของคู่สัญญา และที่สำคัญที่สุดคือระดับคุณภาพที่ตกลงกันไว้สำหรับข้อกำหนดนี้ บริการ.
SLO เป็นวัตถุประสงค์ระดับการบริการ: ค่าเป้าหมายหรือช่วงของค่าสำหรับระดับการบริการที่วัดโดย SLI ค่าปกติสำหรับ SLO คือ “SLI ≤ เป้าหมาย” หรือ “ขีดจำกัดล่าง ≤ SLI ≤ ขีดจำกัดบน”
SLI เป็นตัวบ่งชี้ระดับการบริการ ซึ่งเป็นการวัดเชิงปริมาณที่กำหนดไว้อย่างรอบคอบในด้านหนึ่งของระดับการให้บริการที่มีให้ สำหรับบริการส่วนใหญ่ คีย์ SLI ถือเป็นเวลาแฝงของคำขอ - ระยะเวลาที่ใช้ในการตอบกลับคำขอ SLI ทั่วไปอื่นๆ ได้แก่ อัตราข้อผิดพลาด ซึ่งมักแสดงเป็นเศษส่วนของคำขอทั้งหมดที่ได้รับ และปริมาณงานของระบบ ซึ่งโดยปกติจะวัดเป็นคำขอต่อวินาที
ก่อนอื่น เราจะพังเครื่องบิน จากนั้นสาวๆ และสาวๆ...
ปัจจัยภายในและภายนอกเริ่ม “สปอย” SLO ตั้งแต่นาทีแรก ทุกอย่างตกเป็นหน้าที่ของผู้ดูแลระบบ ไม่ว่าจะเป็นข้อผิดพลาดของนักพัฒนา ความล้มเหลวของโครงสร้างพื้นฐาน การไหลเข้าของผู้เข้าชม และการโจมตี DDoS ทุกสิ่งที่ทำให้ SLO แย่ลง
“- เรียนผู้เข้าร่วม ฉันรีบเร่งเพื่อให้คุณพอใจ สิ่งแรกที่คุณล้มเหลวคือ... ทุกอย่าง!”
ในระหว่างนี้ วิทยากรได้พูดคุยถึงความเสถียร ข้อผิดพลาดที่จ่ายได้ แนวทางปฏิบัติในการทดสอบ การจัดการการขัดจังหวะ และภาระในการปฏิบัติงาน
เราไม่ใช่คนสโต๊คเกอร์ ไม่ใช่ช่างไม้...
จากนั้นผู้เข้าร่วมก็เริ่มแก้ไขสิ่งต่าง ๆ สิ่งสำคัญคือต้องเข้าใจว่าควรคว้าอะไรก่อน
“- ข้าแต่พระเจ้า ข้าพระองค์ไม่เคยเห็นมันพังทลายเช่นนี้ ทั้งในรูปแบบนี้และในตำแหน่งเช่นนี้!”
เลยเกิดอุบัติเหตุขึ้น. บริการประมวลผลการชำระเงินหยุดทำงาน จะดำเนินการอย่างไรเพื่อเรียกคืนฟังก์ชันการทำงานในเวลาที่สั้นที่สุด?
ผู้เชี่ยวชาญที่มองผู้เข้าร่วมด้วยความรักใคร่กำลังเตรียมเคล็ดลับอีกอย่างหนึ่ง
แต่ละทีมจัดระเบียบการทำงานของกลุ่มเพื่อขจัดอุบัติเหตุ - เกี่ยวข้องกับเพื่อนร่วมงาน แจ้งผู้มีส่วนได้เสีย (ผู้มีส่วนได้ส่วนเสีย) ในขณะเดียวกันก็มีการกำหนดลำดับความสำคัญ ด้วยวิธีนี้ ผู้เข้าร่วมจึงได้รับการฝึกอบรมให้ทำงานภายใต้ความกดดันภายใต้เงื่อนไขเวลาที่จำกัดอย่างยิ่ง
“มีเรื่องสยองขวัญอะไรเกิดขึ้น!”
หายใจออก...และออกกำลังกายให้เสร็จ
ร่วมกับวิทยากร หลังจากที่แต่ละปัญหาได้รับการแก้ไขและไซต์มีความเสถียรชั่วคราว ทีมงานได้ศึกษาเหตุการณ์จากมุมมองของ SRE เราวิเคราะห์ปัญหาอย่างละเอียด สาเหตุ ความคืบหน้าในการกำจัด หลังจากนั้น ทั้งแบบทีมต่อทีมและโดยรวม เราได้ตัดสินใจเกี่ยวกับวิธีการป้องกันเพิ่มเติม: วิธีปรับปรุงการตรวจสอบ วิธีเปลี่ยนสถาปัตยกรรมอย่างชาญฉลาด วิธีปรับแนวทางการพัฒนาและการดำเนินงาน วิธีแก้ไขกฎระเบียบ วิทยากรสาธิตการปฏิบัติชันสูตรพลิกศพ
“ใครจะอยากทรมานอีก! - ฉัน!"
ความสำเร็จของทีมได้รับการบันทึกไว้บนกระดานคะแนนอิเล็กทรอนิกส์อย่างเคร่งครัดและชัดเจน
สำหรับสถานที่แรก - โบนัสจากผู้มีส่วนได้ส่วนเสีย
ที่มา: will.com