การสัมมนาผ่านเว็บมีเสียงไม่ดี เราจึงถอดเสียงมา
ฉันชื่อ เมดเวเดฟ เอดูอาร์ด วันนี้ฉันจะพูดถึงว่า SRE คืออะไร SRE ปรากฏอย่างไร เกณฑ์การทำงานสำหรับวิศวกร SRE คืออะไร เล็กน้อยเกี่ยวกับเกณฑ์ความน่าเชื่อถือ เล็กน้อยเกี่ยวกับการตรวจสอบ เราจะเดินบนจุดสูงสุดเพราะคุณไม่สามารถบอกอะไรได้มากนักในหนึ่งชั่วโมง แต่ฉันจะให้เอกสารสำหรับการตรวจสอบเพิ่มเติม และเราทุกคนกำลังรอคุณอยู่ . ในมอสโกเมื่อปลายเดือนมกราคม
อันดับแรก เรามาพูดถึงว่า SRE คืออะไร - วิศวกรรมความน่าเชื่อถือของไซต์ และปรากฏเป็นฐานะแยกเป็นทิศแยกกันอย่างไร. ทุกอย่างเริ่มต้นจากข้อเท็จจริงที่ว่าในแวดวงการพัฒนาแบบดั้งเดิม Dev และ Ops เป็นสองทีมที่แตกต่างกันโดยสิ้นเชิง โดยปกติแล้วจะมีสองเป้าหมายที่แตกต่างกันอย่างสิ้นเชิง เป้าหมายของทีมพัฒนาคือการเปิดตัวคุณสมบัติใหม่และตอบสนองความต้องการของธุรกิจ เป้าหมายของทีม Ops คือการทำให้แน่ใจว่าทุกอย่างทำงานได้ดีและไม่มีอะไรเสียหาย เห็นได้ชัดว่าเป้าหมายเหล่านี้ขัดแย้งกันโดยตรง: เพื่อให้ทุกอย่างทำงานได้และไม่มีอะไรเสียหาย ให้เปิดตัวฟีเจอร์ใหม่ให้น้อยที่สุดเท่าที่จะเป็นไปได้ ด้วยเหตุนี้จึงมีความขัดแย้งภายในมากมายที่วิธีการซึ่งปัจจุบันเรียกว่า DevOps กำลังพยายามแก้ไข
ปัญหาคือเราไม่มีคำจำกัดความที่ชัดเจนของ DevOps และการนำ DevOps ไปใช้อย่างชัดเจน ฉันพูดในการประชุมที่เมือง Yekaterinburg เมื่อ 2 ปีที่แล้ว และจนถึงตอนนี้ หัวข้อ DevOps เริ่มต้นด้วยรายงาน “What is DevOps” ในปี 2017 Devops มีอายุเกือบ 10 ปีแล้ว แต่เรายังคงถกเถียงกันอยู่ว่ามันคืออะไร และนี่เป็นสถานการณ์ที่แปลกประหลาดมากที่ Google พยายามแก้ไขเมื่อไม่กี่ปีที่ผ่านมา
ในปี 2016 Google ได้เปิดตัวหนังสือชื่อ Site Reliability Engineering และในความเป็นจริง การเคลื่อนไหวของ SRE เริ่มต้นขึ้นพร้อมกับหนังสือเล่มนี้ SRE เป็นการดำเนินการเฉพาะของกระบวนทัศน์ DevOps ในบริษัทเฉพาะ วิศวกรของ SRE มุ่งมั่นที่จะทำให้มั่นใจว่าระบบทำงานได้อย่างน่าเชื่อถือ ส่วนใหญ่มาจากนักพัฒนา บางครั้งมาจากผู้ดูแลระบบที่มีพื้นฐานด้านการพัฒนาที่แข็งแกร่ง และพวกเขาทำในสิ่งที่ผู้ดูแลระบบเคยทำ แต่ภูมิหลังที่แข็งแกร่งในการพัฒนาและความรู้เกี่ยวกับระบบในแง่ของรหัสทำให้ความจริงที่ว่าคนเหล่านี้ไม่ชอบงานธุรการประจำ แต่ชอบทำงานอัตโนมัติ
ปรากฎว่ากระบวนทัศน์ DevOps ในทีม SRE ถูกนำมาใช้โดยมีวิศวกร SRE ที่แก้ปัญหาเชิงโครงสร้าง นี่คือความเชื่อมโยงแบบเดียวกันระหว่าง Dev และ Ops ที่ผู้คนพูดถึงมาตลอด 8 ปี บทบาทของ SRE นั้นคล้ายคลึงกับของสถาปนิกตรงที่ผู้มาใหม่จะไม่กลายเป็น SRE คนที่เริ่มต้นอาชีพของพวกเขายังไม่มีประสบการณ์ใด ๆ ไม่มีความรู้ที่จำเป็น เนื่องจาก SRE ต้องการความรู้ที่ละเอียดมากเกี่ยวกับสิ่งที่ผิดพลาดและเมื่อใดที่สามารถผิดพลาดได้ ดังนั้นจึงจำเป็นต้องมีประสบการณ์ที่นี่ตามกฎทั้งใน บริษัท และภายนอก
พวกเขาถามว่าจะอธิบายความแตกต่างระหว่าง SRE และ devops หรือไม่ เธอเพิ่งได้รับการอธิบาย เราสามารถพูดคุยเกี่ยวกับสถานที่ของ SRE ในองค์กร ซึ่งแตกต่างจากแนวทาง DevOps แบบคลาสสิกตรงที่ Ops ยังคงเป็นแผนกแยกต่างหาก SRE เป็นส่วนหนึ่งของทีมพัฒนา พวกเขามีส่วนร่วมในการพัฒนาผลิตภัณฑ์ มีแม้แต่วิธีการที่ SRE เป็นบทบาทที่ส่งต่อจากนักพัฒนาคนหนึ่งไปยังอีกคนหนึ่ง พวกเขามีส่วนร่วมในการตรวจสอบโค้ดในลักษณะเดียวกับ ตัวอย่างเช่น นักออกแบบ UX, นักพัฒนาเอง, ผู้จัดการผลิตภัณฑ์ในบางครั้ง SRE ทำงานในระดับเดียวกัน เราจำเป็นต้องอนุมัติ เราจำเป็นต้องตรวจสอบ เพื่อให้การปรับใช้แต่ละครั้ง SRE จะพูดว่า: “เอาล่ะ การปรับใช้นี้ ผลิตภัณฑ์นี้จะไม่ส่งผลเสียต่อความน่าเชื่อถือ และถ้าเป็นเช่นนั้นก็อยู่ในขอบเขตที่ยอมรับได้ เราจะพูดถึงเรื่องนี้ด้วย
ดังนั้น SRE จึงมีคำสั่งยับยั้งการเปลี่ยนแปลงรหัส และโดยทั่วไป สิ่งนี้ยังนำไปสู่ความขัดแย้งเล็กๆ น้อยๆ หากนำ SRE ไปใช้อย่างไม่ถูกต้อง ในหนังสือเล่มเดียวกันเกี่ยวกับ Site Reliability Engineering หลายส่วน ไม่แม้แต่ส่วนเดียว บอกวิธีหลีกเลี่ยงความขัดแย้งเหล่านี้
พวกเขาถามว่า SRE เกี่ยวข้องกับความปลอดภัยของข้อมูลอย่างไร SRE ไม่เกี่ยวข้องโดยตรงกับความปลอดภัยของข้อมูล โดยพื้นฐานแล้ว ในบริษัทขนาดใหญ่ จะทำโดยบุคคลทั่วไป ผู้ทดสอบ นักวิเคราะห์ แต่ SRE ยังโต้ตอบกับพวกเขาในแง่ที่ว่าการดำเนินการบางอย่าง การคอมมิต การปรับใช้บางอย่างที่ส่งผลต่อความปลอดภัยอาจส่งผลต่อความพร้อมใช้งานของผลิตภัณฑ์ ดังนั้น SRE โดยรวมจึงมีปฏิสัมพันธ์กับทุกทีม รวมถึงทีมรักษาความปลอดภัย รวมถึงนักวิเคราะห์ ดังนั้น SRE จึงมีความจำเป็นเป็นหลักเมื่อพยายามนำ DevOps ไปใช้ แต่ในขณะเดียวกัน ภาระของนักพัฒนาก็ใหญ่เกินไป นั่นคือทีมพัฒนาเองไม่สามารถรับมือกับความจริงที่ว่าตอนนี้พวกเขาต้องรับผิดชอบ Ops ด้วย และมีบทบาทแยกต่างหาก บทบาทนี้มีการวางแผนไว้ในงบประมาณ บางครั้งบทบาทนี้ถูกวางลงในขนาดของทีม บุคคลที่แยกจากกันปรากฏขึ้น บางครั้งหนึ่งในนักพัฒนาก็กลายเป็นบทบาทนั้น นี่คือลักษณะของ SRE แรกในทีม
ความซับซ้อนของระบบที่ได้รับผลกระทบจาก SRE ความซับซ้อนที่ส่งผลต่อความน่าเชื่อถือของการดำเนินงานนั้นเป็นสิ่งที่จำเป็นและเกิดขึ้นโดยบังเอิญ ความซับซ้อนที่จำเป็นคือเมื่อความซับซ้อนของผลิตภัณฑ์เพิ่มขึ้นจนถึงขอบเขตที่จำเป็นสำหรับคุณสมบัติของผลิตภัณฑ์ใหม่ ความซับซ้อนแบบสุ่มคือเมื่อความซับซ้อนของระบบเพิ่มขึ้น แต่คุณสมบัติผลิตภัณฑ์และข้อกำหนดทางธุรกิจไม่ส่งผลกระทบโดยตรงต่อสิ่งนี้ ปรากฎว่านักพัฒนาทำผิดพลาดที่ไหนสักแห่งหรืออัลกอริทึมไม่เหมาะสมหรือมีการแนะนำความสนใจเพิ่มเติมที่เพิ่มความซับซ้อนของผลิตภัณฑ์โดยไม่จำเป็น SRE ที่ดีควรตัดสถานการณ์นี้ออกไปเสมอ นั่นคือ การกระทำใด ๆ การปรับใช้ใด ๆ คำขอดึงใด ๆ ที่ความยากเพิ่มขึ้นเนื่องจากการเพิ่มแบบสุ่มควรถูกบล็อก
คำถามคือทำไมไม่จ้างวิศวกร ผู้ดูแลระบบ ที่มีความรู้มากมายในทีม เราได้รับการบอกว่านักพัฒนาในบทบาทของวิศวกรไม่ใช่โซลูชันการจัดหาพนักงานที่ดีที่สุด นักพัฒนาในบทบาทของวิศวกรไม่ใช่โซลูชันการจัดหาพนักงานที่ดีที่สุดเสมอไป แต่ประเด็นคือนักพัฒนาที่มีส่วนร่วมใน Ops มีความต้องการระบบอัตโนมัติเพิ่มขึ้นเล็กน้อย มีความรู้และทักษะเพิ่มขึ้นเล็กน้อยเพื่อนำไปใช้ ระบบอัตโนมัตินี้ และด้วยเหตุนี้ เราจึงไม่เพียงแต่ลดเวลาสำหรับการดำเนินการเฉพาะบางอย่างเท่านั้น ไม่เพียงแต่งานประจำเท่านั้น แต่ยังรวมถึงพารามิเตอร์ทางธุรกิจที่สำคัญ เช่น MTTR (Mean Time To Recovery, Recovery Time) ดังนั้นเราจะพูดถึงเรื่องนี้ในภายหลัง เราประหยัดเงินสำหรับองค์กร
ตอนนี้เรามาพูดถึงเกณฑ์การดำเนินงานของ SRE และประการแรกเกี่ยวกับความน่าเชื่อถือ ในบริษัทเล็กๆ ที่เพิ่งเริ่มต้น ผู้คนมักคิดว่าหากเขียนบริการได้ดี หากเขียนผลิตภัณฑ์ได้ดีและถูกต้อง ก็จะใช้งานได้ ไม่เสียหาย นั่นคือเราเขียนโค้ดที่ดีดังนั้นจึงไม่มีอะไรจะทำลาย รหัสนั้นง่ายมากไม่มีอะไรจะทำลาย สิ่งเหล่านี้เกี่ยวกับคนกลุ่มเดียวกันที่บอกว่าเราไม่ต้องการการทดสอบ เพราะดูสิ นี่คือวิธี VPI สามวิธี ทำไมจึงหยุดที่นี่
ทั้งหมดนี้ผิดแน่นอน และคนเหล่านี้มักถูกกัดโดยรหัสดังกล่าวในทางปฏิบัติเพราะสิ่งต่าง ๆ พัง สิ่งต่าง ๆ พังทลายในบางครั้งด้วยวิธีที่คาดเดาไม่ได้มากที่สุด บางครั้งคนพูดว่าไม่ มันจะไม่มีวันเกิดขึ้น และมันเกิดขึ้นตลอดเวลา มันเกิดขึ้นบ่อยพอสมควร และนั่นเป็นสาเหตุที่ไม่มีใครพยายามแสวงหาความพร้อมใช้งาน 100% เพราะความพร้อมใช้งาน 100% ไม่เคยเกิดขึ้น นี่คือบรรทัดฐาน ดังนั้น เมื่อเราพูดถึงความพร้อมให้บริการ เรามักจะพูดถึงเก้าเสมอ 2 เก้า 3 เก้า 4 เก้า 5 เก้า ถ้าเราแปลสิ่งนี้เป็นเวลาหยุดทำงาน ตัวอย่างเช่น 5 เก้า นี่จะเป็นการหยุดทำงานมากกว่า 5 นาทีต่อปีเล็กน้อย 2 เก้าคือเวลาหยุดทำงาน 3,5 วัน
แต่ที่เห็นได้ชัดคือ ณ จุดหนึ่ง POI ผลตอบแทนจากการลงทุนลดลง การเปลี่ยนจากสองเก้าเป็นสามเก้าหมายถึงการหยุดทำงานน้อยลงกว่า 3 วัน การเปลี่ยนจากสี่เก้าเป็นห้าลดเวลาหยุดทำงานลง 47 นาทีต่อปี และปรากฎว่าสำหรับธุรกิจอาจไม่ใช่เรื่องสำคัญ และโดยทั่วไปแล้ว ความน่าเชื่อถือที่จำเป็นไม่ใช่ปัญหาทางเทคนิค ประการแรก เป็นปัญหาทางธุรกิจ แต่เป็นปัญหาเกี่ยวกับผลิตภัณฑ์ ผู้ใช้ผลิตภัณฑ์ยอมรับการหยุดทำงานในระดับใด สิ่งที่พวกเขาคาดหวัง จำนวนเงินที่ต้องจ่าย เช่น สูญเสียเงินไปเท่าใด ระบบสูญเสียเงินไปเท่าใด
คำถามสำคัญที่นี่คือความน่าเชื่อถือของส่วนประกอบที่เหลือคืออะไร เนื่องจากความแตกต่างระหว่าง 4 และ 5 เก้าจะไม่ปรากฏบนสมาร์ทโฟนที่มีความน่าเชื่อถือ 2 เก้า พูดอย่างคร่าว ๆ ว่าหากมีสิ่งใดขัดข้องบนสมาร์ทโฟนในบริการของคุณ 10 ครั้งต่อปี เป็นไปได้มากว่า 8 ครั้งที่เกิดการเสียในฝั่งระบบปฏิบัติการ ผู้ใช้คุ้นเคยกับสิ่งนี้และจะไม่สนใจอีกปีละครั้ง มีความจำเป็นต้องเชื่อมโยงราคาของการเพิ่มความน่าเชื่อถือและผลกำไรที่เพิ่มขึ้น
ในหนังสือเกี่ยวกับ SRE มีตัวอย่างที่ดีในการเพิ่มเป็น 4 เก้าจาก 3 เก้า ปรากฎว่าความพร้อมใช้งานเพิ่มขึ้นน้อยกว่า 0,1% เล็กน้อย และถ้ารายรับจากบริการคือ 1 ล้านดอลลาร์ต่อปี รายได้ที่เพิ่มขึ้นคือ 900 ดอลลาร์ หากเรามีค่าใช้จ่ายน้อยกว่า $900 ต่อปีเพื่อเพิ่มความสามารถในการจ่ายได้เก้าเท่า การเพิ่มขึ้นนี้สมเหตุสมผลทางการเงิน หากมีค่าใช้จ่ายมากกว่า 900 ดอลลาร์ต่อปี ก็ไม่สมเหตุสมผลอีกต่อไป เพราะรายได้ที่เพิ่มขึ้นไม่ได้ชดเชยต้นทุนแรงงาน ต้นทุนทรัพยากร และ 3 เก้าจะเพียงพอสำหรับเรา
นี่เป็นตัวอย่างง่ายๆ ที่คำขอทั้งหมดเท่ากัน และการเปลี่ยนจาก 3 เก้าเป็น 4 เก้านั้นง่ายพอ แต่ในขณะเดียวกัน เช่น ไปจาก 2 เก้าเป็น 3 นี่เป็นเงินที่ประหยัดได้ 9 ดอลลาร์ ซึ่งสมเหตุสมผลทางการเงิน ในความเป็นจริง ความล้มเหลวของคำขอลงทะเบียนนั้นแย่กว่าความล้มเหลวในการแสดงหน้า คำขอมีน้ำหนักต่างกัน พวกเขาอาจมีเกณฑ์ที่แตกต่างอย่างสิ้นเชิงจากมุมมองทางธุรกิจ แต่อย่างไรก็ตาม ตามกฎแล้ว หากเราไม่ได้พูดถึงบริการเฉพาะบางอย่าง นี่เป็นค่าประมาณที่ค่อนข้างน่าเชื่อถือ
เราได้รับคำถามว่า SRE เป็นหนึ่งในผู้ประสานงานในการเลือกโซลูชันสถาปัตยกรรมสำหรับบริการหรือไม่ สมมติว่าในแง่ของการรวมเข้ากับโครงสร้างพื้นฐานที่มีอยู่เพื่อไม่ให้สูญเสียเสถียรภาพ ใช่ SRE ในลักษณะเดียวกับที่ดึงคำขอ คอมมิต รีลีส ส่งผลต่อสถาปัตยกรรม การแนะนำบริการใหม่ ไมโครเซอร์วิส การนำโซลูชันใหม่ไปใช้ ทำไมฉันถึงบอกไว้ก่อนว่าต้องการประสบการณ์ ต้องการคุณสมบัติ ในความเป็นจริง SRE เป็นหนึ่งในตัวปิดกั้นเสียงในโซลูชันสถาปัตยกรรมและซอฟต์แวร์ใดๆ ดังนั้น SRE ในฐานะวิศวกร อันดับแรกต้องไม่เพียงเข้าใจเท่านั้น แต่ยังต้องเข้าใจว่าการตัดสินใจบางอย่างจะส่งผลต่อความน่าเชื่อถือ ความเสถียรอย่างไร และเข้าใจว่าสิ่งนี้เกี่ยวข้องกับความต้องการทางธุรกิจอย่างไร และจากมุมมองใดจึงจะยอมรับได้ และ ซึ่งไม่
ดังนั้น ตอนนี้เราสามารถพูดคุยเกี่ยวกับเกณฑ์ความน่าเชื่อถือ ซึ่งตามธรรมเนียมแล้ว SRE กำหนดไว้เป็น SLA (ข้อตกลงระดับการบริการ) น่าจะเป็นคำที่คุ้นเคย SLI (ตัวบ่งชี้ระดับการบริการ) SLO (วัตถุประสงค์ระดับบริการ) ข้อตกลงระดับการให้บริการอาจเป็นคำสัญลักษณ์ โดยเฉพาะอย่างยิ่งหากคุณเคยทำงานกับเครือข่าย กับผู้ให้บริการ กับโฮสติ้ง นี่คือข้อตกลงทั่วไปที่อธิบายถึงประสิทธิภาพของบริการทั้งหมดของคุณ บทลงโทษ บทลงโทษบางประการสำหรับข้อผิดพลาด เมตริก เกณฑ์ และ SLI เป็นตัววัดความพร้อมใช้งาน นั่นคือสิ่งที่ SLI สามารถเป็นได้: เวลาตอบสนองจากบริการ จำนวนข้อผิดพลาดเป็นเปอร์เซ็นต์ อาจเป็นแบนด์วิดธ์หากเป็นการโฮสต์ไฟล์บางประเภท เมื่อพูดถึงอัลกอริธึมการรู้จำ ตัวบ่งชี้สามารถเป็นได้ เช่น แม้กระทั่งความถูกต้องของคำตอบ SLO (วัตถุประสงค์ระดับบริการ) คือการรวมกันของตัวบ่งชี้ SLI ค่าและระยะเวลาตามลำดับ
สมมติว่า SLA อาจเป็นเช่นนี้ บริการนี้มีให้บริการ 99,95% ของเวลาตลอดทั้งปี หรือตั๋วสนับสนุนที่สำคัญ 99 ใบจะปิดภายใน 3 ชั่วโมงต่อไตรมาส หรือ 85% ของคำขอจะได้รับคำตอบภายใน 1,5 วินาทีทุกเดือน นั่นคือเราค่อย ๆ เข้าใจว่าข้อผิดพลาดและความล้มเหลวเป็นเรื่องปกติ นี่เป็นสถานการณ์ที่ยอมรับได้ เรากำลังวางแผน เรากำลังคาดหวังในระดับหนึ่งด้วยซ้ำ นั่นคือ SRE สร้างระบบที่สามารถทำผิดพลาดได้ ซึ่งต้องตอบสนองต่อข้อผิดพลาดตามปกติ ซึ่งต้องคำนึงถึงข้อผิดพลาดนั้นด้วย และเมื่อใดก็ตามที่เป็นไปได้ พวกเขาควรจัดการข้อผิดพลาดในลักษณะที่ผู้ใช้ไม่สังเกตเห็นหรือสังเกตเห็น แต่มีวิธีแก้ปัญหาบางอย่าง ซึ่งทุกอย่างจะไม่พังทลายลงโดยสิ้นเชิง
ตัวอย่างเช่น หากคุณอัปโหลดวิดีโอไปยัง YouTube และ YouTube ไม่สามารถแปลงได้ทันที หากวิดีโอมีขนาดใหญ่เกินไป หากรูปแบบไม่เหมาะสม คำขอจะไม่ล้มเหลวโดยธรรมชาติเมื่อหมดเวลา YouTube จะไม่แสดงข้อผิดพลาด 502 YouTube จะพูดว่า: "เราสร้างทุกอย่างแล้ว วิดีโอของคุณกำลังถูกประมวลผล จะพร้อมในอีกประมาณ 10 นาที" นี่คือหลักการของการย่อยสลายอย่างสง่างาม ซึ่งคุ้นเคย เช่น จากการพัฒนาส่วนหน้า ถ้าคุณเคยทำเช่นนี้
เงื่อนไขต่อไปที่เราจะพูดถึง ซึ่งสำคัญมากสำหรับการทำงานด้วยความน่าเชื่อถือ ข้อผิดพลาด และความคาดหวัง คือ MTBF และ MTTR MTBF คือเวลาเฉลี่ยระหว่างความล้มเหลว MTTR Mean Time To Recovery เวลาเฉลี่ยในการกู้คืน นั่นคือระยะเวลาที่ผ่านไปตั้งแต่พบข้อผิดพลาด ตั้งแต่ช่วงเวลาที่เกิดข้อผิดพลาดจนถึงช่วงเวลาที่บริการได้รับการกู้คืนเป็นการทำงานปกติเต็มรูปแบบ MTBF ได้รับการแก้ไขโดยการทำงานเกี่ยวกับคุณภาพของโค้ดเป็นหลัก นั่นคือความจริงที่ว่า SREs สามารถพูดว่า "ไม่" และคุณต้องการความเข้าใจของทั้งทีมว่าเมื่อ SRE พูดว่า "ไม่" เขาไม่ได้พูดเพราะเขาเป็นตัวอันตราย ไม่ใช่เพราะเขาไม่ดี แต่เพราะมิฉะนั้น ทุกคนจะต้องทนทุกข์ทรมาน
อีกครั้ง มีบทความมากมาย วิธีการมากมาย หลายวิธีแม้กระทั่งในหนังสือที่ผมอ้างถึงบ่อยมาก จะทำอย่างไรให้นักพัฒนารายอื่นไม่เริ่มเกลียด SRE ในทางกลับกัน MTTR นั้นเกี่ยวกับการทำงานใน SLO ของคุณ (วัตถุประสงค์ระดับบริการ) และส่วนใหญ่เป็นระบบอัตโนมัติ เนื่องจาก ตัวอย่างเช่น SLO ของเรามีเวลาทำงาน 4 เก้าต่อไตรมาส ซึ่งหมายความว่าใน 3 เดือนเราสามารถให้เวลาหยุดทำงาน 13 นาที และปรากฎว่า MTTR ต้องไม่เกิน 13 นาที หากเราตอบสนองต่อการหยุดทำงานอย่างน้อย 13 ครั้งใน 1 นาที หมายความว่าเราได้ใช้งบประมาณทั้งหมดสำหรับไตรมาสนี้หมดแล้ว เรากำลังทำลาย SLO 13 นาทีในการตอบสนองและแก้ไขข้อขัดข้องนั้นมากสำหรับเครื่องจักร แต่สั้นมากสำหรับมนุษย์ เพราะกว่าบุคคลจะได้รับการแจ้งเตือน จนกว่าเขาจะตอบสนอง จนกว่าเขาจะเข้าใจข้อผิดพลาด ก็ผ่านไปหลายนาทีแล้ว จนกว่าคนจะเข้าใจวิธีการแก้ไขสิ่งที่ต้องแก้ไขสิ่งที่ต้องทำคืออีกไม่กี่นาที และในความเป็นจริง แม้ว่าคุณเพียงแค่ต้องรีสตาร์ทเซิร์ฟเวอร์ตามที่ปรากฎ หรือเพิ่มโหนดใหม่ MTTR ด้วยตนเองก็ใช้เวลาประมาณ 7-8 นาทีแล้ว เมื่อทำกระบวนการอัตโนมัติ MTTR มักจะถึงวินาที บางครั้งก็เป็นมิลลิวินาที Google มักจะพูดถึงมิลลิวินาที แต่ในความเป็นจริงแล้ว ทุกอย่างไม่ดีนัก
ตามหลักการแล้ว SRE ควรทำงานโดยอัตโนมัติเกือบทั้งหมด เนื่องจากสิ่งนี้ส่งผลโดยตรงต่อ MTTR, เมตริก, SLO ของบริการทั้งหมด และตามมาด้วยผลกำไรของธุรกิจ หากเกินเวลา เราจะถามว่า SRE เป็นฝ่ายผิดหรือไม่ โชคดีที่ไม่มีใครถูกตำหนิ และนี่คือวัฒนธรรมที่แยกจากกันซึ่งเรียกว่าการชันสูตรพลิกศพแบบหม่องซึ่งเราจะไม่พูดถึงในวันนี้ แต่เราจะวิเคราะห์เกี่ยวกับ Slurm นี่เป็นหัวข้อที่น่าสนใจมากที่สามารถพูดถึงได้มากมาย พูดอย่างคร่าว ๆ ถ้าเกินเวลาที่กำหนดต่อไตรมาส ก็โทษทุกคนเล็กน้อย ซึ่งหมายความว่าการโทษทุกคนนั้นไม่เกิดผล แทนที่จะโทษใคร แต่แก้ไขสถานการณ์และทำงานกับสิ่งที่เรามี จากประสบการณ์ของฉัน วิธีการนี้ค่อนข้างแปลกสำหรับทีมส่วนใหญ่ โดยเฉพาะในรัสเซีย แต่ก็สมเหตุสมผลและได้ผลดี ดังนั้นฉันจะแนะนำในตอนท้ายของบทความและวรรณกรรมที่คุณสามารถอ่านได้ในหัวข้อนี้ หรือมาที่ Slurm SRE
ให้ฉันอธิบาย หากเกินเวลา SLO ต่อไตรมาส หากเวลาหยุดทำงานไม่ใช่ 13 นาที แต่เป็น 15 นาที ใครจะตำหนิเรื่องนี้ได้ แน่นอนว่า SRE อาจถูกตำหนิ เพราะเขาสร้างการกระทำหรือการปรับใช้ที่ไม่ดีอย่างชัดเจน ผู้ดูแลระบบของศูนย์ข้อมูลอาจถูกตำหนิในเรื่องนี้เพราะเขาอาจทำการบำรุงรักษาที่ไม่ได้กำหนดไว้ หากผู้ดูแลระบบของศูนย์ข้อมูลต้องตำหนิในเรื่องนี้ บุคคลจาก Ops จะต้องตำหนิในเรื่องนี้ ซึ่งไม่ได้คำนวณการบำรุงรักษาเมื่อประสานงานกับ SLO ผู้จัดการ ผู้อำนวยการด้านเทคนิค หรือผู้ที่ลงนามในสัญญาศูนย์ข้อมูลและไม่ได้ใส่ใจกับข้อเท็จจริงที่ว่า SLA ของศูนย์ข้อมูลไม่ได้ออกแบบมาสำหรับการหยุดทำงานที่จำเป็น ดังนั้น ทีละเล็กทีละน้อยในสถานการณ์นี้จะต้องถูกตำหนิ และนั่นหมายความว่าไม่มีประโยชน์ที่จะกล่าวโทษใครก็ตามในสถานการณ์นี้ แต่แน่นอนว่าต้องได้รับการแก้ไข นั่นเป็นเหตุผลที่มีการชันสูตรพลิกศพ และถ้าคุณอ่าน เช่น GitHub postmortems และนี่เป็นเรื่องที่น่าสนใจ เป็นเรื่องเล็กๆ และคาดไม่ถึงในแต่ละกรณี คุณสามารถแทนที่ได้ว่าไม่มีใครเคยพูดว่าคนๆ นี้ต้องถูกตำหนิ การตำหนิมักเกิดขึ้นจากกระบวนการที่ไม่สมบูรณ์โดยเฉพาะ
ไปที่คำถามต่อไปกันเถอะ ระบบอัตโนมัติ เมื่อฉันพูดถึงการทำงานอัตโนมัติในบริบทอื่นๆ ฉันมักจะอ้างถึงตารางที่บอกคุณว่าคุณสามารถทำงานอัตโนมัติได้นานแค่ไหนโดยไม่ต้องใช้เวลาในการทำงานอัตโนมัติมากกว่าที่คุณประหยัดจริง มีอุปสรรค์ สิ่งที่จับต้องได้คือเมื่อ SRE ทำงานโดยอัตโนมัติ พวกเขาไม่เพียงแต่ประหยัดเวลาเท่านั้น แต่ยังประหยัดเงินอีกด้วย เนื่องจากการทำงานอัตโนมัติส่งผลโดยตรงต่อ MTTR พวกเขาช่วยประหยัดขวัญกำลังใจของพนักงานและนักพัฒนาซึ่งเป็นทรัพยากรที่หมดไป พวกเขาลดกิจวัตรประจำวัน และทั้งหมดนี้มีผลในเชิงบวกต่อการทำงานและเป็นผลต่อธุรกิจ แม้ว่าดูเหมือนว่าระบบอัตโนมัติจะไม่สมเหตุสมผลในแง่ของต้นทุนเวลาก็ตาม
อันที่จริง มีเกือบทุกครั้ง และมีบางกรณีที่บางสิ่งไม่ควรทำงานอัตโนมัติในบทบาทของ SRE ต่อไปเราจะพูดถึงสิ่งที่เรียกว่าข้อผิดพลาดงบประมาณ งบประมาณสำหรับข้อผิดพลาด ในความเป็นจริงปรากฎว่าหากทุกอย่างดีสำหรับคุณมากกว่า SLO ที่คุณตั้งไว้สำหรับตัวคุณเอง มันก็ไม่ดีเช่นกัน สิ่งนี้ค่อนข้างแย่ เพราะ SLO ไม่เพียงทำงานเป็นขอบเขตล่างเท่านั้น แต่ยังเป็นขอบเขตบนโดยประมาณด้วย เมื่อคุณตั้งค่า SLO ให้ตัวเองมีความพร้อมใช้งาน 99% และในความเป็นจริงคุณมี 99,99% ปรากฎว่าคุณมีพื้นที่สำหรับการทดลองที่จะไม่ส่งผลเสียต่อธุรกิจเลย เพราะคุณเป็นคนกำหนดสิ่งนี้เองทั้งหมด และคุณคือ พื้นที่นี้ไม่ได้ใช้ คุณมีงบประมาณสำหรับความผิดพลาด ซึ่งในกรณีของคุณไม่ได้ใช้หมด
เราจะทำอย่างไรกับมัน เราใช้มันสำหรับทุกสิ่งอย่างแท้จริง สำหรับการทดสอบในสภาวะการผลิต สำหรับการเปิดตัวคุณสมบัติใหม่ที่อาจส่งผลกระทบต่อประสิทธิภาพการทำงาน สำหรับการเปิดตัว สำหรับการบำรุงรักษา สำหรับเวลาหยุดทำงานตามแผน กฎย้อนกลับยังใช้ได้: หากงบประมาณหมดแล้ว เราจะไม่สามารถเผยแพร่สิ่งใหม่ๆ ได้ เพราะมิฉะนั้น เราจะเกิน SLO งบประมาณหมดแล้ว เราได้ออกบางอย่างถ้ามันส่งผลเสียต่อประสิทธิภาพการทำงาน นั่นคือ ถ้านี่ไม่ใช่การแก้ไขบางอย่างที่เพิ่ม SLO โดยตรงในตัวเอง เราก็จะใช้จ่ายเกินงบประมาณ และนี่เป็นสถานการณ์ที่ไม่ดี จำเป็นต้องได้รับการวิเคราะห์ ชันสูตรพลิกศพ และอาจมีการแก้ไขกระบวนการบางอย่าง
นั่นคือปรากฎว่าหากตัวบริการทำงานได้ไม่ดีและ SLO ถูกใช้ไปและงบประมาณไม่ได้ถูกใช้ไปกับการทดลองไม่ใช่ในบางรุ่น แต่โดยตัวมันเองแทนที่จะเป็นการแก้ไขที่น่าสนใจแทนที่จะเป็นคุณสมบัติที่น่าสนใจ แทนการเปิดตัวที่น่าสนใจ แทนที่จะทำงานสร้างสรรค์ คุณจะต้องจัดการกับการแก้ไขโง่ๆ เพื่อให้งบประมาณกลับมาเป็นระเบียบเรียบร้อย หรือแก้ไข SLO และนี่ยังเป็นกระบวนการที่ไม่ควรเกิดขึ้นบ่อยเกินไป
ดังนั้นปรากฎว่าในสถานการณ์ที่เรามีงบประมาณมากขึ้นสำหรับข้อผิดพลาด ทุกคนสนใจ: ทั้ง SRE และนักพัฒนา สำหรับนักพัฒนา งบประมาณจำนวนมากสำหรับข้อบกพร่องหมายความว่าคุณสามารถจัดการกับการเผยแพร่ การทดสอบ การทดลอง สำหรับ SRE งบประมาณสำหรับข้อผิดพลาดและการป้อนงบประมาณนั้นหมายความว่าพวกเขาทำงานได้ดีโดยตรง และสิ่งนี้ส่งผลต่อแรงจูงใจของการทำงานร่วมกันบางประเภท หากคุณฟัง SRE ของคุณในฐานะนักพัฒนา คุณจะมีพื้นที่มากขึ้นสำหรับงานดีๆ และกิจวัตรประจำวันน้อยลง
ปรากฎว่าการทดลองในการผลิตเป็นส่วนสำคัญและเกือบจะเป็นส่วนสำคัญของ SRE ในทีมขนาดใหญ่ และโดยปกติจะเรียกว่าวิศวกรรมความโกลาหล ซึ่งมาจากทีมงานของ Netflix ที่เปิดตัวยูทิลิตี้ที่ชื่อว่า Chaos Monkey
Chaos Monkey เชื่อมต่อกับไปป์ไลน์ CI/CD และทำให้เซิร์ฟเวอร์ขัดข้องแบบสุ่มในระหว่างการผลิต อีกครั้งในโครงสร้าง SRE เรากำลังพูดถึงข้อเท็จจริงที่ว่าเซิร์ฟเวอร์ที่ล่มนั้นไม่ได้แย่ในตัวของมันเอง และถ้าอยู่ในงบประมาณก็พอรับได้และไม่ส่งผลเสียต่อธุรกิจ แน่นอนว่า Netflix มีเซิร์ฟเวอร์ที่ซ้ำซ้อนเพียงพอ มีการจำลองแบบเพียงพอ เพื่อให้สามารถแก้ไขทั้งหมดนี้ได้ และเพื่อให้ผู้ใช้โดยรวมไม่สังเกตเห็น และยิ่งกว่านั้นไม่มีใครละทิ้งเซิร์ฟเวอร์เดียวสำหรับงบประมาณใด ๆ
Netflix มีชุดยูทิลิตี้ดังกล่าวมาระยะหนึ่งแล้ว หนึ่งในนั้นคือ Chaos Gorilla ซึ่งปิดหนึ่งใน Availability Zone ของ Amazon โดยสิ้นเชิง และสิ่งเหล่านี้ช่วยเปิดเผย ประการแรก การพึ่งพาที่ซ่อนอยู่ เมื่อยังไม่ชัดเจนว่าอะไรส่งผลต่ออะไร อะไรขึ้นอยู่กับอะไร และสิ่งนี้ หากคุณกำลังทำงานกับไมโครเซอร์วิส และเอกสารไม่สมบูรณ์แบบ คุณอาจคุ้นเคยกับสิ่งนี้ และอีกครั้ง สิ่งนี้ช่วยได้มากในการตรวจจับข้อผิดพลาดในโค้ดที่คุณไม่สามารถจับได้ในการจัดเตรียม เนื่องจากการจัดเตรียมใด ๆ ไม่ใช่การจำลองที่แน่นอน เนื่องจากข้อเท็จจริงที่ว่าขนาดโหลดแตกต่างกัน รูปแบบการโหลดแตกต่างกัน อุปกรณ์ก็เช่นกัน เป็นไปได้มากว่าอื่น ๆ โหลดสูงสุดอาจไม่คาดคิดและคาดเดาไม่ได้ และการทดสอบดังกล่าวซึ่งไม่เกินงบประมาณอีกครั้งช่วยตรวจจับข้อผิดพลาดในโครงสร้างพื้นฐานได้เป็นอย่างดีซึ่งการจัดเตรียม, การทดสอบอัตโนมัติ, ไปป์ไลน์ CI / CD จะไม่มีวันตรวจจับได้ และตราบใดที่ทุกอย่างรวมอยู่ในงบประมาณของคุณ ไม่สำคัญว่าบริการของคุณจะล่ม แม้ว่ามันจะดูน่ากลัวมาก เซิร์ฟเวอร์ล่ม ช่างเป็นฝันร้าย ไม่ นั่นเป็นเรื่องปกติ เป็นเรื่องดี ที่ช่วยดักจับแมลง หากคุณมีงบประมาณคุณสามารถใช้จ่ายได้
ถาม: ฉันสามารถแนะนำวรรณกรรมอะไรได้บ้าง รายการในตอนท้าย มีวรรณกรรมมากมายฉันจะแนะนำรายงานสองสามฉบับ มันทำงานอย่างไร และ SRE ทำงานในบริษัทต่างๆ โดยไม่มีผลิตภัณฑ์ซอฟต์แวร์ของตนเองหรือมีการพัฒนาเพียงเล็กน้อย ตัวอย่างเช่น ในองค์กรที่กิจกรรมหลักไม่ใช่ซอฟต์แวร์ ในองค์กรที่กิจกรรมหลักไม่ใช่ซอฟต์แวร์ SRE ทำงานเหมือนกับที่อื่นทุกประการ เพราะในองค์กรคุณยังต้องใช้ผลิตภัณฑ์ซอฟต์แวร์แม้ว่าจะไม่ได้รับการพัฒนาก็ตาม คุณต้องเผยแพร่การอัปเดต คุณต้องเปลี่ยน โครงสร้างพื้นฐาน คุณต้องเติบโต คุณต้องปรับขนาด และ SRE จะช่วยระบุและคาดการณ์ปัญหาที่อาจเกิดขึ้นในกระบวนการเหล่านี้ และควบคุมได้หลังจากการเติบโตเริ่มขึ้นและความต้องการทางธุรกิจเปลี่ยนไป เนื่องจากไม่จำเป็นอย่างยิ่งที่จะต้องมีส่วนร่วมในการพัฒนาซอฟต์แวร์เพื่อที่จะมี SRE หากคุณมีเซิร์ฟเวอร์อย่างน้อยสองสามเครื่อง และคุณคาดว่าจะมีการเติบโตอย่างน้อย
เช่นเดียวกับโครงการขนาดเล็ก องค์กรขนาดเล็ก เนื่องจากบริษัทขนาดใหญ่มีงบประมาณและพื้นที่ในการทดลอง แต่ในขณะเดียวกัน ผลการทดลองทั้งหมดนี้สามารถใช้ได้ทุกที่ ซึ่งแน่นอนว่า SRE ปรากฏใน Google ใน Netflix ใน Dropbox แต่ในขณะเดียวกัน บริษัทขนาดเล็กและสตาร์ทอัพสามารถอ่านเนื้อหาที่ย่อ อ่านหนังสือ ดูรายงานได้อยู่แล้ว พวกเขาเริ่มได้ยินเกี่ยวกับเรื่องนี้บ่อยขึ้น พวกเขาดูตัวอย่างที่เฉพาะเจาะจง ฉันคิดว่ามันโอเค มันมีประโยชน์จริงๆ เราต้องการสิ่งนี้เช่นกัน มันดีมาก
นั่นคืองานหลักทั้งหมดในการสร้างมาตรฐานกระบวนการเหล่านี้ได้ดำเนินการให้คุณแล้ว คุณจะต้องกำหนดบทบาทของ SRE โดยเฉพาะในบริษัทของคุณ และเริ่มนำแนวทางปฏิบัติเหล่านี้ไปใช้จริง ซึ่งได้อธิบายไว้แล้วอีกครั้ง นั่นคือจากหลักการที่เป็นประโยชน์สำหรับบริษัทขนาดเล็ก นี่คือคำจำกัดความของ SLA, SLI, SLO เสมอ หากคุณไม่ได้เกี่ยวข้องกับซอฟต์แวร์ สิ่งเหล่านี้จะเป็น SLA ภายในและ SLO ภายใน ซึ่งเป็นงบประมาณภายในสำหรับข้อผิดพลาด สิ่งนี้มักจะนำไปสู่การอภิปรายที่น่าสนใจภายในทีมและภายในธุรกิจ เพราะอาจกลายเป็นว่าคุณใช้จ่ายกับโครงสร้างพื้นฐาน ในกระบวนการในอุดมคติขององค์กรบางประเภท ท่อส่งในอุดมคตินั้นเกินความจำเป็นมาก และเก้าเก้าเหล่านี้ที่คุณมีในแผนกไอที ตอนนี้คุณไม่ต้องการมันแล้ว แต่ในเวลาเดียวกัน คุณสามารถใช้เวลา ใช้งบประมาณสำหรับความผิดพลาดในสิ่งอื่น
ดังนั้น การตรวจสอบและการจัดระบบการตรวจสอบจึงมีประโยชน์สำหรับบริษัททุกขนาด และโดยทั่วไปแล้ว วิธีคิดแบบนี้ ที่ซึ่งความผิดพลาดเป็นสิ่งที่ยอมรับได้ ที่ใดมีงบประมาณ ที่มีเป้าหมาย ก็มีประโยชน์อีกครั้งสำหรับบริษัททุกขนาด โดยเริ่มจากสตาร์ทอัพสำหรับ 3 คน
ความแตกต่างทางเทคนิคสุดท้ายที่จะพูดถึงคือการตรวจสอบ เพราะถ้าเรากำลังพูดถึง SLA, SLI, SLO เราจะไม่สามารถเข้าใจได้หากไม่ได้ติดตามดูว่าเราเหมาะสมกับงบประมาณหรือไม่ เราปฏิบัติตามวัตถุประสงค์ของเราหรือไม่ และเรามีอิทธิพลต่อ SLA ขั้นสุดท้ายอย่างไร ฉันเห็นหลายครั้งที่การตรวจสอบเกิดขึ้นในลักษณะนี้: มีค่าบางอย่าง เช่น เวลาของคำขอไปยังเซิร์ฟเวอร์ เวลาเฉลี่ย หรือจำนวนของคำขอไปยังฐานข้อมูล เขามีมาตรฐานกำหนดโดยวิศวกร หากเมตริกเบี่ยงเบนไปจากบรรทัดฐาน อีเมลจะมาถึง ตามกฎแล้วทั้งหมดนี้ไร้ประโยชน์อย่างแน่นอนเพราะมันนำไปสู่การเตือนที่มากเกินไปข้อความจำนวนมากจากการตรวจสอบเมื่อบุคคลต้องตีความทุกครั้งก่อนนั่นคือกำหนดว่าค่าของเมตริกหมายถึง ความจำเป็นในการดำเนินการบางอย่าง และอย่างที่สอง เขาเพียงแค่หยุดสังเกตการแจ้งเตือนเหล่านี้ โดยพื้นฐานแล้วเขาไม่จำเป็นต้องดำเนินการใดๆ นั่นเป็นกฎการตรวจสอบที่ดีและกฎข้อแรกเมื่อนำ SRE มาใช้คือการแจ้งเตือนควรมาเมื่อจำเป็นต้องดำเนินการเท่านั้น
ในกรณีมาตรฐาน มีเหตุการณ์ 3 ระดับ มีการแจ้งเตือน มีตั๋ว มีบันทึก การแจ้งเตือนคือสิ่งที่ต้องการให้คุณดำเนินการทันที นั่นคือทุกอย่างพังคุณต้องแก้ไขทันที ตั๋วเป็นสิ่งที่ต้องดำเนินการล่าช้า ใช่ คุณต้องทำบางอย่าง คุณต้องทำบางอย่างด้วยตนเอง ระบบอัตโนมัติล้มเหลว แต่คุณไม่จำเป็นต้องทำในอีกไม่กี่นาทีข้างหน้า บันทึกคือสิ่งที่ไม่ต้องดำเนินการใดๆ และโดยทั่วไป หากทุกอย่างดำเนินไปได้ด้วยดี ก็จะไม่มีใครอ่านบันทึกเหล่านั้น คุณจะต้องอ่านบันทึกเมื่อมองย้อนกลับไป ปรากฎว่ามีบางอย่างพังในบางครั้งโดยที่เราไม่รู้ หรือคุณต้องทำวิจัยบางอย่าง แต่โดยทั่วไปแล้วทุกสิ่งที่ไม่ต้องการการดำเนินการใด ๆ จะไปที่บันทึก
จากผลข้างเคียงของทั้งหมดนี้ หากเรากำหนดว่าเหตุการณ์ใดต้องมีการดำเนินการและอธิบายได้ดีว่าควรดำเนินการอย่างไร นั่นหมายความว่าการดำเนินการจะเป็นไปโดยอัตโนมัติ นั่นคือสิ่งที่เกิดขึ้น เราไปจากการแจ้งเตือน ไปดำเนินการกันเถอะ เราไปที่คำอธิบายของการกระทำนี้ จากนั้นเราก็ไปสู่ระบบอัตโนมัติ นั่นคือ ระบบอัตโนมัติใด ๆ จะเริ่มต้นด้วยการตอบสนองต่อเหตุการณ์หนึ่ง ๆ
จากการเฝ้าติดตาม เราไปยังคำที่เรียกว่า Observability ในช่วงไม่กี่ปีที่ผ่านมามีการโฆษณาเล็กน้อยเกี่ยวกับคำนี้ และมีเพียงไม่กี่คนที่เข้าใจว่ามันหมายถึงอะไรนอกบริบท แต่ประเด็นหลักคือ Observability เป็นตัวชี้วัดความโปร่งใสของระบบ หากมีข้อผิดพลาด คุณจะทราบได้เร็วเพียงใดว่าเกิดข้อผิดพลาดอะไรขึ้น และสถานะของระบบในขณะนั้นเป็นอย่างไร ในแง่ของโค้ด: ฟังก์ชันใดล้มเหลว บริการใดล้มเหลว สถานะของอะไร เช่น ตัวแปรภายใน การกำหนดค่า ในแง่ของโครงสร้างพื้นฐาน นี่คือโซนความพร้อมใช้งานที่เกิดความล้มเหลว และหากคุณมี Kubernetes ใด ๆ ความล้มเหลวเกิดขึ้นที่พ็อดใด สถานะของพ็อดเป็นอย่างไร ดังนั้นความสามารถในการสังเกตจึงมีความสัมพันธ์โดยตรงกับ MTTR ยิ่งความสามารถในการสังเกตของบริการสูงเท่าไร การระบุข้อผิดพลาดก็จะง่ายขึ้นเท่านั้น การแก้ไขข้อผิดพลาดก็จะยิ่งง่ายขึ้นเท่านั้น การดำเนินการข้อผิดพลาดโดยอัตโนมัติก็จะยิ่งง่ายขึ้น MTTR ก็จะยิ่งต่ำลงเท่านั้น
การย้ายไปยังบริษัทขนาดเล็กอีกครั้ง เป็นเรื่องปกติมากที่จะถามว่าจะจัดการกับขนาดทีมอย่างไร และทีมขนาดเล็กจำเป็นต้องจ้าง SRE แยกต่างหากหรือไม่ พูดคุยเกี่ยวกับเรื่องนี้ก่อนหน้านี้เล็กน้อย ในขั้นตอนแรกของการพัฒนาของการเริ่มต้นหรือตัวอย่างเช่นทีม สิ่งนี้ไม่จำเป็นเลยเพราะ SRE สามารถมีบทบาทในช่วงเปลี่ยนผ่านได้ และสิ่งนี้จะช่วยฟื้นฟูทีมเล็กน้อยเพราะอย่างน้อยก็มีความหลากหลาย และนอกจากนี้ยังจะเตรียมผู้คนให้พร้อมสำหรับความจริงที่ว่าโดยทั่วไปแล้วการเติบโต ความรับผิดชอบของ SRE จะเปลี่ยนไปอย่างมาก หากคุณจ้างคน แน่นอนว่าเขามีความคาดหวังบางอย่าง และความคาดหวังเหล่านี้จะไม่เปลี่ยนแปลงเมื่อเวลาผ่านไป แต่ข้อกำหนดจะเปลี่ยนไปอย่างมาก ดังนั้นวิธีการจ้าง SRE จึงค่อนข้างยากในช่วงแรก ปลูกเองง่ายกว่าเยอะ แต่มันก็คุ้มค่าที่จะคิดเกี่ยวกับ
ข้อยกเว้นประการเดียวคือเมื่อมีข้อกำหนดการเติบโตที่เข้มงวดและกำหนดไว้อย่างดี นั่นคือในกรณีของการเริ่มต้น นี่อาจเป็นแรงกดดันจากนักลงทุน การคาดการณ์การเติบโตหลายครั้งในคราวเดียว จากนั้นการจ้าง SRE นั้นสมเหตุสมผลเพราะสามารถพิสูจน์ได้ เรามีข้อกำหนดสำหรับการเติบโต เราต้องการบุคคลที่จะรับผิดชอบต่อความจริงที่ว่าการเติบโตดังกล่าวจะไม่มีอะไรมาทำลายได้
อีกหนึ่งคำถาม จะทำอย่างไรเมื่อนักพัฒนาตัดคุณสมบัติที่ผ่านการทดสอบหลายครั้ง แต่หยุดการผลิต โหลดฐาน ทำลายคุณสมบัติอื่น ๆ ดำเนินการอย่างไร ดังนั้น ในกรณีนี้ มันคืองบประมาณสำหรับข้อผิดพลาดที่ถูกนำมาใช้ และบริการบางอย่าง คุณลักษณะบางอย่างกำลังได้รับการทดสอบในการผลิตแล้ว อาจเป็นนกขมิ้นเมื่อมีผู้ใช้จำนวนน้อย แต่อยู่ในกระบวนการผลิตแล้ว มีการปรับใช้คุณลักษณะ แต่ด้วยความคาดหวังว่าหากมีบางอย่างขัดข้อง เช่น ผู้ใช้ครึ่งหนึ่งของผู้ใช้ทั้งหมดจะยังคงตอบสนอง งบประมาณสำหรับข้อผิดพลาด ใช่จะมีข้อผิดพลาดสำหรับผู้ใช้บางคนทุกอย่างจะพัง แต่เราได้กล่าวไปแล้วว่านี่เป็นเรื่องปกติ
มีคำถามเกี่ยวกับเครื่องมือ SRE นั่นคือมีบางอย่างเป็นพิเศษที่ SREs จะใช้ซึ่งคนอื่นจะไม่ใช้ อันที่จริง มีโปรแกรมอรรถประโยชน์พิเศษบางอย่าง มีซอฟต์แวร์บางประเภทที่จำลองการโหลดหรือมีส่วนร่วมในการทดสอบ Canary A / B แต่โดยพื้นฐานแล้วชุดเครื่องมือ SRE คือสิ่งที่นักพัฒนาของคุณใช้อยู่แล้ว เนื่องจาก SRE โต้ตอบโดยตรงกับทีมพัฒนา และถ้าคุณมีเครื่องมือต่าง ๆ ปรากฎว่าต้องใช้เวลาในการซิงโครไนซ์ โดยเฉพาะอย่างยิ่งถ้า SRE ทำงานในทีมขนาดใหญ่ ในบริษัทขนาดใหญ่ที่สามารถมีหลายทีมได้ การกำหนดมาตรฐานทั่วทั้งบริษัทจะช่วยได้มากที่นี่ เพราะหากมีการใช้ยูทิลิตี้ที่แตกต่างกัน 50 ชนิดใน 50 ทีม นั่นหมายความว่า SRE จะต้องรู้จักพวกเขา ทั้งหมด. และแน่นอนว่าสิ่งนี้จะไม่เกิดขึ้น และคุณภาพงานคุณภาพการควบคุมของทีมงานอย่างน้อยบางส่วนจะลดลงอย่างเห็นได้ชัด
การสัมมนาผ่านเว็บของเรากำลังจะสิ้นสุดลง ฉันสามารถบอกสิ่งพื้นฐานบางอย่างได้ แน่นอนว่าไม่มีอะไรเกี่ยวกับ SRE ที่สามารถบอกและเข้าใจได้ภายในหนึ่งชั่วโมง แต่ฉันหวังว่าฉันสามารถถ่ายทอดวิธีคิดนี้ซึ่งเป็นประเด็นสำคัญหลักได้ จากนั้นจะเป็นไปได้หากสนใจที่จะเจาะลึกหัวข้อเรียนรู้ด้วยตัวคุณเองดูว่าคนอื่นนำไปใช้ใน บริษัท อื่นอย่างไร ดังนั้นในต้นเดือนกุมภาพันธ์ มาหาเราที่ Slurm SRE
Slurm SRE เป็นหลักสูตรเร่งรัดสามวันที่จะพูดถึงสิ่งที่ฉันกำลังพูดถึง แต่ด้วยความลึกซึ้งที่มากขึ้น ในกรณีจริงและการฝึกฝน หลักสูตรเร่งรัดทั้งหมดมุ่งเป้าไปที่การปฏิบัติงานจริง คนจะถูกแบ่งออกเป็นทีม พวกคุณทุกคนจะได้ทำงานในคดีจริง ดังนั้นเราจึงมีผู้สอนของ Booking.com Ivan Kruglov และ Ben Tyler เรามี Eugene Barabbas ที่ยอดเยี่ยมจาก Google จากซานฟรานซิสโก และฉันจะบอกคุณบางอย่างด้วย ดังนั้นโปรดเยี่ยมชมเรา
ดังนั้นบรรณานุกรม มีการอ้างอิงใน SRE ในหนังสือเล่มเดียวกันหรือมากกว่าในหนังสือ 2 เล่มเกี่ยวกับ SRE ที่เขียนโดย Google อีกอันหนึ่ง ซึ่งข้อกำหนดและการสมัครมีรายละเอียดมากกว่าเล็กน้อย 3 รายการถัดไปเป็นรายงานเกี่ยวกับ SRE ในบริษัทต่างๆ อันดับแรก - นี่คือประเด็นสำคัญจาก Ben Trainer แห่ง Google ที่สอง - . ครั้งที่สามเป็นอีกครั้ง . รายงานฉบับที่สี่จาก ซึ่งมีพนักงาน SRE ที่สำคัญเพียง 5 คนใน 190 ประเทศ เป็นเรื่องที่น่าสนใจมากที่ได้ดูทั้งหมดนี้ เพราะเช่นเดียวกับที่ DevOps มีความหมายที่แตกต่างกันมากสำหรับบริษัทต่างๆ และแม้แต่ทีมที่แตกต่างกัน SRE ก็มีความรับผิดชอบที่แตกต่างกันมาก แม้แต่ในบริษัทที่มีขนาดใกล้เคียงกัน
อีก 2 ลิงก์เกี่ยวกับหลักการของวิศวกรรมความโกลาหล: , . และในตอนท้ายมี 3 รายการจากซีรีส์ Awesome Lists เกี่ยวกับ เกี่ยวกับ และเกี่ยวกับ . รายการใน SRE นั้นใหญ่มาก ไม่จำเป็นต้องดูทั้งหมด มีประมาณ 200 บทความ ฉันขอแนะนำบทความจากที่นั่นเกี่ยวกับการวางแผนกำลังการผลิตและการชันสูตรพลิกศพอย่างไร้ตำหนิ
บทความที่น่าสนใจ:
ขอบคุณที่ฟังฉันตลอดเวลา หวังว่าคุณจะได้เรียนรู้บางสิ่งบางอย่าง หวังว่าคุณจะมีเนื้อหาเพียงพอที่จะเรียนรู้เพิ่มเติม แล้วเจอกัน. หวังว่าในเดือนกุมภาพันธ์
การสัมมนาผ่านเว็บนี้จัดทำโดย Eduard Medvedev
PS: สำหรับผู้ที่ชอบอ่าน Eduard ให้รายการอ้างอิง ผู้ที่ต้องการเข้าใจในทางปฏิบัติยินดีต้อนรับ .
ที่มา: will.com