เรากำลังประกาศหลักสูตรภาคปฏิบัติหลักสูตรแรกเกี่ยวกับ SRE ในรัสเซีย: .
ในช่วงเข้มข้น เราจะใช้เวลาสามวันในการสร้าง ทำลาย ซ่อมแซม และปรับปรุงเว็บไซต์รวบรวมเพื่อจำหน่ายตั๋วภาพยนตร์
เราเลือกผู้รวบรวมตั๋วเนื่องจากมีสถานการณ์ความล้มเหลวมากมาย: การไหลเข้าของผู้เยี่ยมชมและการโจมตี DDoS, ความล้มเหลวของหนึ่งในไมโครเซอร์วิสที่สำคัญจำนวนมาก (การอนุญาต, การจอง, การประมวลผลการชำระเงิน), ความไม่พร้อมใช้งานของหนึ่งในโรงภาพยนตร์หลายแห่ง (การแลกเปลี่ยนข้อมูลเกี่ยวกับ ที่นั่งว่างและการสำรองที่นั่ง) และรายการถัดไป
เราจะกำหนดแนวคิดเรื่องความน่าเชื่อถือสำหรับไซต์รวบรวมของเรา ซึ่งเราจะพัฒนาต่อไปในด้านวิศวกรรม วิเคราะห์การออกแบบจากมุมมองของ SRE เลือกตัวชี้วัด ตั้งค่าการติดตาม กำจัดเหตุการณ์ที่เกิดขึ้น ดำเนินการฝึกอบรมสำหรับการทำงานเป็นทีมกับเหตุการณ์ต่างๆ ในสภาวะที่ใกล้เคียงกับการสู้รบ ให้จัดให้มีการซักถาม
โปรแกรมนี้ดำเนินการโดยพนักงานของ Booking.com และ Google
ครั้งนี้จะไม่มีการมีส่วนร่วมระยะไกล: หลักสูตรนี้สร้างขึ้นจากการมีปฏิสัมพันธ์ส่วนตัวและการทำงานเป็นทีม
รายละเอียดใต้คัทครับ
ลำโพง
อีวาน ครูลอฟ
นักพัฒนาหลักที่ Booking.com (เนเธอร์แลนด์)
นับตั้งแต่ร่วมงานกับ Booking.com ในปี 2013 เขาทำงานในโครงการโครงสร้างพื้นฐาน เช่น การส่งข้อความและการประมวลผลแบบกระจาย BigData และเว็บสแต็ก การค้นหา
ขณะนี้กำลังแก้ไขปัญหาเกี่ยวกับการสร้างคลาวด์ภายในและ Service Mesh
เบน ไทเลอร์
นักพัฒนาหลักที่ Booking.com (สหรัฐอเมริกา)
มีส่วนร่วมในการพัฒนาภายในแพลตฟอร์ม Booking.com
เชี่ยวชาญในด้านโครงข่ายบริการ/การค้นพบบริการ การจัดตารางงานแบบกลุ่ม การตอบสนองต่อเหตุการณ์ และกระบวนการหลังชันสูตร
พูดและสอนเป็นภาษารัสเซีย
เยฟเจนีย์ วาราฟวา
นักพัฒนาทั่วไปที่ Google (ซานฟรานซิสโก)
ประสบการณ์จากโครงการเว็บที่มีโหลดสูงไปจนถึงการวิจัยด้านคอมพิวเตอร์วิทัศน์และหุ่นยนต์
ตั้งแต่ปี 2011 เขามีส่วนร่วมในการสร้างและดำเนินการระบบแบบกระจายที่ Google โดยมีส่วนร่วมในวงจรชีวิตของโครงการทั้งหมด: การวางแนวความคิด การออกแบบและสถาปัตยกรรม การเปิดตัว การพับ และขั้นตอนกลางทั้งหมด
เอดูอาร์ด เมดเวเดฟ
CTO ที่ Tungsten Labs (เยอรมนี)
ทำงานเป็นวิศวกรที่ StackStorm ซึ่งรับผิดชอบการทำงานของ ChatOps ของแพลตฟอร์ม พัฒนาและใช้งาน ChatOps สำหรับระบบอัตโนมัติของศูนย์ข้อมูล วิทยากรในการประชุมรัสเซียและนานาชาติ
โครงการ
โปรแกรมกำลังได้รับการพัฒนาอย่างแข็งขัน ตอนนี้ก็ประมาณนี้ครับ ภายในเดือน ก.พ. ก็น่าจะปรับปรุงและขยายตัวได้
หัวข้อ #1: หลักการพื้นฐานและวิธีการของ SRE
- การเป็น SRE ต้องใช้อะไรบ้าง
- DevOps กับ SRE
- เหตุใดนักพัฒนาจึงให้ความสำคัญกับ SRE และรู้สึกเสียใจมากเมื่อพวกเขาไม่อยู่ในโครงการ
- SLI, SLO และ SLA
- งบประมาณข้อผิดพลาดและบทบาทใน SRE
หัวข้อ #2: การออกแบบระบบแบบกระจาย
- สถาปัตยกรรมและฟังก์ชันการทำงานของแอปพลิเคชัน
- การออกแบบระบบขนาดใหญ่ที่ไม่เป็นนามธรรม
- ความสามารถในการใช้งาน/การออกแบบสำหรับความล้มเหลว
- gRPC หรือ REST
- การกำหนดเวอร์ชันและความเข้ากันได้แบบย้อนหลัง
หัวข้อ #3: โครงการ SRE ได้รับการยอมรับอย่างไร
- แนวทางปฏิบัติที่ดีที่สุดจาก SRE
- รายการตรวจสอบการยอมรับโครงการ
- การบันทึก การวัด การติดตาม
- นำ CI/CD มาอยู่ในมือของเราเอง
หัวข้อที่ 4: การออกแบบและการเปิดตัวระบบแบบกระจาย
- วิศวกรรมย้อนกลับ - ระบบทำงานอย่างไร?
- เราเห็นด้วยกับ SLI และ SLO
- ฝึกการวางแผนขีดความสามารถ
- การเปิดตัวการรับส่งข้อมูลไปยังแอปพลิเคชัน ผู้ใช้ของเราเริ่ม "ใช้งาน" มัน
- เปิดตัว Prometheus, Grafana, Elastic
หัวข้อ #5: การตรวจสอบ การสังเกต และการแจ้งเตือน
- การตรวจสอบเทียบกับ ความสามารถในการสังเกต
- ตั้งค่าการติดตามและแจ้งเตือนด้วย Prometheus
- การตรวจสอบ SLI และ SLO ในทางปฏิบัติ
- อาการเทียบกับ สาเหตุ
- กล่องดำกับ การตรวจสอบกล่องขาว
- การตรวจสอบความพร้อมใช้งานของแอปพลิเคชันและเซิร์ฟเวอร์แบบกระจาย
- สัญญาณสีทอง 4 สัญญาณ (การตรวจจับความผิดปกติ)
หัวข้อที่ 6: การฝึกปฏิบัติการทดสอบความน่าเชื่อถือของระบบ
- ทำงานภายใต้แรงกดดัน
- ความล้มเหลวในการฉีด
- ลิงเคออส
หัวข้อ #7: การฝึกปฏิบัติในการตอบสนองต่อเหตุการณ์
- อัลกอริธึมการจัดการความเครียด
- ปฏิสัมพันธ์ระหว่างผู้เข้าร่วมเหตุการณ์
- การชันสูตรพลิกศพ
- การแบ่งปันความรู้
- การสร้างวัฒนธรรม
- การตรวจสอบข้อผิดพลาด
- ดำเนินการซักถามอย่างไม่มีตำหนิ
หัวข้อ #8: วิธีปฏิบัติในการจัดการโหลด
- โหลดบาลานซ์
- ความทนทานต่อข้อผิดพลาดของแอปพลิเคชัน: ลองใหม่, หมดเวลา, การฉีดความล้มเหลว, เบรกเกอร์
- DDoS (การสร้างโหลด) + ความล้มเหลวแบบเรียงซ้อน
หัวข้อ #9: การตอบสนองต่อเหตุการณ์
- การซักถาม
- การปฏิบัติเมื่อโทร
- อุบัติเหตุประเภทต่างๆ (การทดสอบ การเปลี่ยนแปลงการกำหนดค่า ความล้มเหลวของฮาร์ดแวร์)
- ระเบียบการการจัดการเหตุการณ์
หัวข้อ #10: การวินิจฉัยและการแก้ปัญหา
- การบันทึก
- แก้จุดบกพร่อง
- ฝึกวิเคราะห์และแก้ไขข้อบกพร่องในแอปพลิเคชันของเรา
หัวข้อ #11: การทดสอบความน่าเชื่อถือของระบบ
- การทดสอบความเครียด
- การทดสอบการกำหนดค่า
- การทดสอบประสิทธิภาพ
- ปล่อยนกขมิ้น
หัวข้อที่ 12: งานอิสระและการทบทวน
คำแนะนำและข้อกำหนดสำหรับผู้เข้าร่วม
SRE คือความพยายามของทีม เราขอแนะนำอย่างยิ่งให้เรียนหลักสูตรเป็นทีม นั่นเป็นเหตุผลที่เราเสนอส่วนลดมากมายสำหรับทีมสำเร็จรูป
ราคาของหลักสูตรคือ 60 ₽ ต่อคน
หากบริษัทส่งกลุ่มตั้งแต่ 5 คนขึ้นไป - 40 ₽
หลักสูตรนี้สร้างขึ้นบน Kubernetes หากต้องการผ่าน คุณต้องรู้จัก Kubernetes ในระดับพื้นฐาน ถ้าไม่ร่วมงานกับเขาก็สามารถเข้า Slurm Basic ได้ ( หรือ ).
นอกจากนี้ คุณต้องมีความเชี่ยวชาญใน Linux และรู้จัก Gitlab และ Prometheus
หากคุณมีความคิดที่ซับซ้อนในการเข้าร่วม เช่น สำหรับ CEO, CTO และทีมนักพัฒนาที่จะมาเข้าร่วมหลักสูตร และเพื่อให้พวกเขาเข้ารับการฝึกงานโดยคำนึงถึงแนวดิ่งการจัดการ โปรดเขียนถึงฉันทางข้อความส่วนตัว
ที่มา: will.com