การแปลบทความจัดทำขึ้นเฉพาะสำหรับนักศึกษาของหลักสูตร ซึ่งเริ่มแล้ววันนี้!
คุณเคยออกบริการใหม่เข้าสู่การผลิตหรือไม่? หรือบางทีคุณอาจมีส่วนร่วมในการสนับสนุนบริการดังกล่าว? ถ้าใช่ อะไรเป็นแรงบันดาลใจให้คุณ? อะไรดีต่อการผลิต อะไรไม่ดี? คุณจะฝึกอบรมสมาชิกในทีมใหม่เกี่ยวกับการเปิดตัวหรือการบำรุงรักษาบริการที่มีอยู่ได้อย่างไร
บริษัทส่วนใหญ่ลงเอยด้วยการนำแนวทาง "Wild West" มาใช้เมื่อพูดถึงแนวทางปฏิบัติในการดำเนินงานทางอุตสาหกรรม แต่ละทีมจะตัดสินใจเกี่ยวกับเครื่องมือและแนวปฏิบัติที่ดีที่สุดของตนเองผ่านการลองผิดลองถูก แต่สิ่งนี้มักส่งผลกระทบไม่เพียงแต่ความสำเร็จของโครงการเท่านั้น แต่ยังส่งผลต่อวิศวกรด้วย
การลองผิดลองถูกทำให้เกิดสภาพแวดล้อมที่การชี้นิ้วและการโยนความผิดเป็นเรื่องปกติ ด้วยพฤติกรรมนี้ การเรียนรู้จากข้อผิดพลาดจึงยากขึ้นเรื่อยๆ และจะไม่ทำซ้ำอีก
องค์กรที่ประสบความสำเร็จ:
- ตระหนักถึงความต้องการแนวทางการผลิต
- ศึกษาแนวทางปฏิบัติที่ดีที่สุด
- เริ่มการอภิปรายเกี่ยวกับปัญหาความพร้อมในการผลิตเมื่อมีการพัฒนาระบบหรือส่วนประกอบใหม่
- ตรวจสอบให้แน่ใจว่าปฏิบัติตามกฎการเตรียมการผลิต
การเตรียมการผลิตรวมถึงกระบวนการ "ทบทวน" การทบทวนอาจอยู่ในรูปแบบของรายการตรวจสอบหรือชุดคำถาม การตรวจทานสามารถทำได้ด้วยตนเอง โดยอัตโนมัติ หรือทั้งสองอย่าง แทนที่จะสร้างรายการข้อกำหนดคงที่ คุณสามารถสร้างเทมเพลตรายการตรวจสอบที่สามารถปรับให้เข้ากับความต้องการเฉพาะได้ ด้วยวิธีนี้ วิศวกรจะได้รับวิธีการสืบทอดความรู้และความยืดหยุ่นที่เพียงพอเมื่อจำเป็น
จะต้องตรวจสอบความพร้อมในการผลิตเมื่อใด?
การดำเนินการตรวจสอบความพร้อมในการผลิตไม่เพียงแต่ในทันทีก่อนที่จะปล่อยเท่านั้น แต่ยังมีประโยชน์เมื่อโอนไปยังทีมปฏิบัติการอื่นหรือพนักงานใหม่ด้วย
ตรวจสอบเมื่อ:
- คุณกำลังเปิดตัวบริการใหม่สู่การใช้งานจริง
- คุณถ่ายโอนการดำเนินงานของบริการการผลิตไปยังทีมอื่น เช่น SRE
- คุณโอนการดำเนินงานของบริการการผลิตให้กับพนักงานใหม่
- จัดให้มีการสนับสนุนด้านเทคนิค
รายการตรวจสอบความพร้อมในการผลิต
เมื่อไม่นานมานี้ฉันเป็นตัวอย่าง รายการตรวจสอบเพื่อทดสอบความพร้อมในการผลิต แม้ว่ารายการนี้มาจากลูกค้า Google Cloud แต่จะมีประโยชน์และนำไปใช้ได้ภายนอก Google Cloud
การออกแบบและพัฒนา
- พัฒนากระบวนการสร้างที่ทำซ้ำได้ซึ่งไม่จำเป็นต้องเข้าถึงบริการภายนอก และไม่ขึ้นอยู่กับความล้มเหลวของระบบภายนอก
- ในช่วงการออกแบบและพัฒนา ให้กำหนดและตั้งค่า SLO สำหรับบริการของคุณ
- บันทึกความคาดหวังเกี่ยวกับความพร้อมใช้งานของบริการภายนอกที่คุณต้องพึ่งพา
- หลีกเลี่ยงจุดล้มเหลวเพียงจุดเดียวโดยลบการพึ่งพาทรัพยากรส่วนกลางเพียงจุดเดียว จำลองทรัพยากรหรือใช้ทางเลือกเมื่อทรัพยากรไม่พร้อมใช้งาน (เช่น ค่าฮาร์ดโค้ด)
การจัดการการตั้งค่า
- การกำหนดค่าแบบคงที่ ขนาดเล็ก และไม่เป็นความลับสามารถส่งผ่านพารามิเตอร์บรรทัดคำสั่งได้ สำหรับอย่างอื่นทั้งหมด ให้ใช้บริการจัดเก็บข้อมูลการกำหนดค่า
- การกำหนดค่าแบบไดนามิกจะต้องมีการตั้งค่าทางเลือกในกรณีที่บริการการกำหนดค่าไม่พร้อมใช้งาน
- การกำหนดค่าสภาพแวดล้อมการพัฒนาไม่ควรเกี่ยวข้องกับการกำหนดค่าการใช้งานจริง มิฉะนั้นอาจนำไปสู่การเข้าถึงจากสภาพแวดล้อมการพัฒนาไปยังบริการที่ใช้งานจริง ซึ่งอาจทำให้เกิดปัญหาความเป็นส่วนตัวและการรั่วไหลของข้อมูล
- บันทึกสิ่งที่สามารถกำหนดค่าได้แบบไดนามิกและอธิบายพฤติกรรมทางเลือกหากระบบการนำส่งการกำหนดค่าไม่พร้อมใช้งาน
การจัดการการปล่อย
- บันทึกขั้นตอนการเผยแพร่โดยละเอียด อธิบายว่าการเผยแพร่ส่งผลต่อ SLO อย่างไร (เช่น เวลาแฝงที่เพิ่มขึ้นชั่วคราวเนื่องจากการพลาดแคช)
- เอกสารเผยแพร่นกคีรีบูน
- พัฒนาแผนการตรวจสอบการปล่อยนกคีรีบูน และกลไกการย้อนกลับอัตโนมัติ หากเป็นไปได้
- ตรวจสอบให้แน่ใจว่าการย้อนกลับสามารถใช้กระบวนการเดียวกับการทำให้ใช้งานได้
ความสามารถในการสังเกต
- ตรวจสอบว่ามีการรวบรวมชุดเมตริกที่จำเป็นสำหรับ SLO
- ตรวจสอบให้แน่ใจว่าคุณสามารถแยกความแตกต่างระหว่างข้อมูลไคลเอนต์และเซิร์ฟเวอร์ได้ นี่เป็นสิ่งสำคัญในการค้นหาสาเหตุของความผิดปกติ
- ตั้งค่าการแจ้งเตือนเพื่อลดต้นทุนค่าแรง เช่น ลบการแจ้งเตือนที่เกิดจากการดำเนินการตามปกติ
- หากคุณใช้ Stackdriver ให้รวมเมตริกแพลตฟอร์ม GCP ไว้ในแดชบอร์ด ตั้งค่าการแจ้งเตือนสำหรับการพึ่งพา GCP
- เผยแพร่การติดตามที่เข้ามาเสมอ แม้ว่าคุณจะไม่เกี่ยวข้องกับการติดตาม สิ่งนี้จะช่วยให้บริการระดับล่างสามารถแก้ไขปัญหาในการผลิตได้
การป้องกันและความปลอดภัย
- ตรวจสอบให้แน่ใจว่าการเชื่อมต่อภายนอกทั้งหมดได้รับการเข้ารหัส
- ตรวจสอบให้แน่ใจว่าโปรเจ็กต์การผลิตของคุณมีการตั้งค่า IAM ที่ถูกต้อง
- ใช้เครือข่ายเพื่อแยกกลุ่มของอินสแตนซ์เครื่องเสมือน
- ใช้ VPN เพื่อเชื่อมต่อกับเครือข่ายระยะไกลอย่างปลอดภัย
- จัดทำเอกสารและติดตามการเข้าถึงข้อมูลของผู้ใช้ ตรวจสอบให้แน่ใจว่าการเข้าถึงข้อมูลของผู้ใช้ทั้งหมดได้รับการตรวจสอบและบันทึก
- ตรวจสอบให้แน่ใจว่าจุดสิ้นสุดการแก้ไขจุดบกพร่องถูกจำกัดโดย ACL
- ฆ่าเชื้ออินพุตของผู้ใช้ กำหนดค่าขีดจำกัดขนาดเพย์โหลดสำหรับการป้อนข้อมูลของผู้ใช้
- ตรวจสอบให้แน่ใจว่าบริการของคุณสามารถเลือกบล็อกการรับส่งข้อมูลขาเข้าสำหรับผู้ใช้แต่ละรายได้ วิธีนี้จะบล็อกการละเมิดโดยไม่ส่งผลกระทบต่อผู้ใช้รายอื่น
- หลีกเลี่ยงอุปกรณ์ปลายทางภายนอกที่เริ่มต้นการดำเนินการภายในจำนวนมาก
วางแผนกำลังการผลิต
- บันทึกว่าบริการของคุณขยายขนาดอย่างไร ตัวอย่างเช่น จำนวนผู้ใช้ ขนาดของเพย์โหลดที่เข้ามา จำนวนข้อความที่เข้ามา
- บันทึกข้อกำหนดทรัพยากรสำหรับบริการของคุณ ตัวอย่างเช่น จำนวนอินสแตนซ์เครื่องเสมือนเฉพาะ จำนวนอินสแตนซ์ Spanner ฮาร์ดแวร์พิเศษ เช่น GPU หรือ TPU
- ข้อจำกัดของทรัพยากรเอกสาร: ประเภททรัพยากร ภูมิภาค ฯลฯ
- ข้อจำกัดโควต้าเอกสารสำหรับการสร้างทรัพยากรใหม่ เช่น การจำกัดจำนวนคำขอ GCE API หากคุณใช้ API เพื่อสร้างอินสแตนซ์ใหม่
- พิจารณาดำเนินการทดสอบโหลดเพื่อวิเคราะห์ประสิทธิภาพที่ลดลง
นั่นคือทั้งหมดที่ เจอกันในชั้นเรียน!
ที่มา: will.com