พื้นฐาน AI
DevOps คืออะไร? การพัฒนาและการดำเนินงานอธิบาย
เพิ่ม Unite.AI ลงในแหล่งข้อมูลที่คุณต้องการบน Google
DevOps คือแนวทางสังคม-เทคนิคที่นำการพัฒนาซอฟต์แวร์และการดำเนินงานมารวมเป็นระบบข้อเสนอแนะเดียว ทีมใช้ความเป็นเจ้าของร่วม, การควบคุมเวอร์ชัน, การอัตโนมัติ, การมองเห็นระบบและการเปลี่ยนแปลงขนาดเล็กที่สามารถย้อนกลับได้ เพื่อปรับปรุงความเร็วในการส่งมอบและความเชื่อถือของบริการ
DevOps ไม่ใช่ตำแหน่งงานหรือชุดเครื่องมือโดยตัวเอง เซิร์ฟเวอร์การรวมต่อเนื่องไม่สามารถแก้ไขแรงจูงใจที่ให้รางวัลแก่นักพัฒนาที่ปล่อยซอฟต์แวร์โดยทำให้ผู้ปฏิบัติงานต้องรับผิดชอบต่อความล้มเหลวทุกกรณี
ประเด็นสำคัญ
- การทำงานเป็นชุดเล็กและการรับข้อเสนอแนะที่รวดเร็วช่วยลดต้นทุนและความเสี่ยงของการเปลี่ยนแปลง
- การส่งมอบต่อเนื่องทำให้ซอฟต์แวร์พร้อมปล่อย; การปรับใช้ต่อเนื่องจะปล่อยการเปลี่ยนแปลงโดยอัตโนมัติเมื่อผ่านเกตที่กำหนด
- การมองเห็นระบบและการเรียนรู้จากเหตุการณ์เชื่อมพฤติกรรมการผลิตกับการวางแผนและวิศวกรรม
- เมตริกที่มีประโยชน์จะสมดุลระหว่างอัตราการทำงานกับความเสถียร แทนการเพิ่มความถี่ของการปรับใช้เพียงอย่างเดียว
ความเป็นเจ้าของร่วมและการไหลของงาน
ทีมข้ามหน้าที่เป็นเจ้าของบริการตั้งแต่การออกแบบจนถึงการดำเนินงาน งานเป็นที่มองเห็นได้ การเปลี่ยนแปลงได้รับการตรวจสอบและการพึ่งพาถูกลดลงเพื่อให้ฟีเจอร์สามารถเคลื่อนผ่านระบบได้โดยไม่ต้องมีคิวยาวหรือการส่งต่อหลายขั้นตอน
เป้าหมายคือการไหลของคุณค่าอย่างยั่งยืน ไม่ใช่ความเร่งเร้าอย่างต่อเนื่อง จำกัดงานที่กำลังทำอยู่, ทำให้การตรวจสอบซ้ำอัตโนมัติ และทำให้การเปลี่ยนแปลงมีขนาดเล็กพอที่จะเข้าใจและย้อนกลับได้
การควบคุมเวอร์ชัน, CI และการทดสอบอัตโนมัติ
โค้ดแอปพลิเคชัน, คำจำกัดความของโครงสร้างพื้นฐาน, การกำหนดค่าและนโยบายควรสามารถตรวจสอบและทำซ้ำได้ การรวมต่อเนื่องจะผสานการเปลี่ยนแปลงขนาดเล็กบ่อยครั้งและรันการสร้างอัตโนมัติ, การทดสอบและการตรวจสอบความปลอดภัย
pipeline ที่เป็นสีเขียวเป็นหลักฐานเฉพาะสำหรับการตรวจสอบที่อยู่ในนั้นเท่านั้น การทดสอบหน่วย, การรวม, สัญญา, ความปลอดภัยและประสิทธิภาพครอบคลุมความเสี่ยงที่แตกต่างกัน สภาพแวดล้อมที่คล้ายการผลิตและข้อมูลทดสอบที่ควบคุมช่วยลดความประหลาดใจโดยไม่ทำให้สเตจจิงเหมือนความเป็นจริงอย่างสมบูรณ์
การส่งมอบต่อเนื่องและการปรับใช้ที่ปลอดภัย
การส่งมอบต่อเนื่องสร้างผลลัพธ์ที่พร้อมปล่อยผ่าน pipeline อัตโนมัติ กลยุทธ์การปรับใช้เช่น canary, การปล่อยแบบสีน้ำเงิน‑เขียว และฟีเจอร์ฟล็อกจำกัดการเปิดเผยขณะเฝ้าดูข้อมูล telemetry การย้อนกลับอัตโนมัติต้องการสัญญาณที่เชื่อถือได้และไม่ควรทำลายหลักฐานที่จำเป็นสำหรับการวินิจฉัย
Infrastructure as code ทำให้สภาพแวดล้อมสามารถตรวจสอบได้ แต่สถานะ, ข้อมูลประจำตัวและพฤติกรรมของผู้ให้บริการยังคงต้องการการควบคุม ผสานรวม ความปลอดภัยไซเบอร์ ตั้งแต่ต้นผ่านการสร้างแบบจำลองภัยคุกคาม, การควบคุมการพึ่งพา, ต้นกำเนิดของผลลัพธ์และหลักการน้อยที่สุด
ปฏิบัติ, สังเกตและเรียนรู้
เมตริก, บันทึก, ร่องรอยและสัญญาณผู้ใช้แสดงว่าบริการบรรลุตามวัตถุประสงค์หรือไม่ แจ้งเตือนเมื่อพบอาการที่ต้องดำเนินการ กำหนดวัตถุประสงค์ระดับบริการและเตรียมบทบาทเหตุการณ์ก่อนเกิดการหยุดทำงาน
การเรียนรู้โดยไม่โทษตรวจสอบผู้มีส่วนร่วมทางเทคนิคและองค์กรโดยไม่ละทิ้งความรับผิดชอบ งานต่อเนื่องควรปรับปรุงการตรวจจับ, การบรรเทา, การสื่อสารและการออกแบบระบบ เชื่อม DevOps กับ ITOps และการวิศวกรรมความเชื่อถือของไซต์
วัดผลลัพธ์และจัดการการแลกเปลี่ยน
งานวิจัยของ DORA มักใช้ความถี่การปรับใช้, เวลาแฝงสำหรับการเปลี่ยนแปลง, อัตราการล้มเหลวของการเปลี่ยนแปลงและเวลาที่ใช้ในการฟื้นฟูบริการ โดยพิจารณาความเชื่อถือร่วมกับการส่งมอบ เมตริกควรเปิดเผยข้อจำกัด ไม่ใช่เป็นเป้าหมายที่ทีมพยายามทำให้บรรลุ
แนวปฏิบัติที่ประสบความสำเร็จช่วยปรับปรุงผลลัพธ์ของลูกค้า, ความปลอดภัยและการฟื้นฟูพร้อมลดภาระงาน ระบบที่ถูกควบคุมอาจต้องการการอนุมัติและหลักฐานอย่างชัดเจน; DevOps สามารถทำให้กระบวนการเหล่านั้นเป็นอัตโนมัติและบันทึกเอกสารแทนการข้ามผ่าน
หลักการ DevOps และกระแสการส่งมอบ
DevOps ทำให้การพัฒนาซอฟต์แวร์และการดำเนินงานสอดคล้องกันโดยมุ่งเน้นการส่งมอบที่เร็วและเชื่อถือได้พร้อมความเป็นเจ้าของร่วม มันรวมวัฒนธรรม, การคิดเชิงผลิตภัณฑ์, การอัตโนมัติ, การวัดผลและการเรียนรู้อย่างต่อเนื่อง; ทีม, เครื่องมือ หรือชื่อตำแหน่งงานอย่างเดียวไม่ใช่ DevOps. วางแผนกระแสคุณค่าตั้งแต่แนวคิดจนถึงการเปลี่ยนแปลงที่ทำงานอยู่ รวมถึงการอนุมัติ, คิว, สภาพแวดล้อม, การปรับใช้และการฟื้นฟู ลดการส่งต่อและขนาดชุดงาน ทำให้งานเป็นที่มองเห็นและให้ทีมผลิตภัณฑ์รับข้อเสนอแนะจากการผลิตพร้อมคงการตรวจสอบอิสระเมื่อความเสี่ยงต้องการ
การรวมต่อเนื่องผสานการเปลี่ยนแปลงขนาดเล็กบ่อยครั้งและรันการสร้างและการทดสอบอัตโนมัติ การส่งมอบต่อเนื่องทำให้ผลลัพธ์พร้อมปล่อย; การปรับใช้ต่อเนื่องปล่อยอัตโนมัติหลังจากผ่านเกต Infrastructure as code, การจัดการการกำหนดค่า, ผลลัพธ์ที่ไม่เปลี่ยนแปลงและความเท่าเทียมของสภาพแวดล้อมช่วยเพิ่มความสามารถในการทำซ้ำ ผลลัพธ์ควรเวอร์ชันเพียงครั้งเดียวและส่งต่อแทนการสร้างใหม่ตามสภาพแวดล้อม ฟีเจอร์ฟล็อกแยกการปรับใช้จากการเปิดเผยแต่ต้องมีเจ้าของและการยกเลิก การเปลี่ยนแปลงฐานข้อมูลต้องรองรับความเข้ากันได้ย้อนหลังและต้องทดสอบการย้อนกลับหรือการเลื่อนต่อไป
ความเชื่อถือ, การมองเห็น, และการเรียนรู้จากเหตุการณ์
การมองเห็นเชื่อมโยงบันทึก, เมตริก, ร่องรอย, โปรไฟล์, การปรับใช้และความเป็นเจ้าของกับคำถามเกี่ยวกับพฤติกรรมของระบบ กำหนดตัวชี้วัดระดับบริการและวัตถุประสงค์จากประสบการณ์ผู้ใช้ แล้วใช้งบประมาณข้อผิดพลาดเพื่อสมดุลระหว่างงานความเชื่อถือและการเปลี่ยนแปลง การอัตโนมัติควรรวมถึงการหมดเวลา, การลองใหม่พร้อม jitter, ความเป็นอิดิโมพอเทนท์, การตรวจสอบสุขภาพ, ขีดจำกัดความจุและการลดประสิทธิภาพอย่างนุ่มนวล ทดสอบความล้มเหลวผ่านวันเกมและการฝึกฟื้นฟู ไม่ใช่เพียง pipeline ที่เป็นเส้นทางราบรื่น
การตอบสนองต่อเหตุการณ์ต้องการบทบาทการอยู่บนสาย, ความรุนแรง, การสื่อสาร, เอกสารปฏิบัติการ, อำนาจและการตรวจสอบโดยไม่โทษ การตรวจสอบหลังเหตุการณ์จะสร้างสภาพแวดล้อมทางเทคนิคและองค์กรที่มีส่วนร่วมและติดตามงานแก้ไข เวลาเฉลี่ยในการฟื้นฟูอาจดีขึ้นแม้การเกิดซ้ำยังสูง ดังนั้นจึงวัดการตรวจจับ, การเปลี่ยนแปลงที่ล้มเหลว, การฟื้นฟู, งานที่ทำซ้ำและสาเหตุที่เกิดซ้ำ หลีกเลี่ยงการใช้เมตริกเพื่อจัดอันดับบุคคล; เมตริกบรรยายระบบสังคม-เทคนิค
ความปลอดภัยและการวัดผล
รักษาความปลอดภัยของห่วงโซ่อุปทานซอฟต์แวร์ด้วยอัตลักษณ์ CI ที่ให้สิทธิ์น้อยที่สุด, การสร้างแยกส่วน, การควบคุมการพึ่งพา, SBOMs, ลายเซ็น, ต้นกำเนิด, การจัดการความลับและเกตนโยบายพร้อมข้อยกเว้นที่กำกับ การวัดเวลาแฝง, ความถี่การปรับใช้, ความล้มเหลวของการเปลี่ยนแปลง, การฟื้นฟู, ความเชื่อถือ, การเปิดเผยความปลอดภัยและประสบการณ์ของนักพัฒนาพร้อมกัน การเพิ่มจำนวนการปรับใช้ในขณะที่เพิ่มการหยุดทำงานไม่ใช่ความก้าวหน้า DevOps ประสบความสำเร็จเมื่อทีมสามารถทำการเปลี่ยนแปลงขนาดเล็ก, ปลอดภัย, มองเห็นได้และเรียนรู้อย่างรวดเร็ว—โดยไม่โอนภาระการดำเนินงานหรือความเสี่ยงให้กับผู้ใช้
ตัวอย่างการทำงาน: การปรับใช้บริการอย่างปลอดภัย
ทีมผสานการเปลี่ยนแปลง API ขนาดเล็กผ่านโค้ดที่ได้รับการตรวจสอบและการทดสอบหน่วย, การรวม, ความปลอดภัยและสัญญาแบบอัตโนมัติ การสร้างแยกส่วนผลิตผลลัพธ์ที่ลงลายเซ็นหนึ่งรายการพร้อม SBOM และต้นกำเนิด ผลลัพธ์ถูกส่งต่อไปยังสเตจจิ้ง จากนั้น canary รับทราฟฟิกการผลิตที่จำกัด แดชบอร์ดเปรียบเทียบข้อผิดพลาด, ความหน่วง, ความอิ่มตัวและผลลัพธ์ทางธุรกิจกับเวอร์ชันเก่า ในขณะที่ฟีเจอร์ฟล็อกควบคุมการเปิดเผยแยกจากการปรับใช้
หากงบประมาณข้อผิดพลาดหรือเกณฑ์การป้องกันถูกเกิน, ระบบอัตโนมัติจะหยุดการปล่อยและย้อนกลับหรือปิดฟีเจอร์ การเปลี่ยนแปลงฐานข้อมูลยังคงเข้ากันได้ย้อนหลังจนกว่าโค้ดเก่าจะถูกยกเลิก ช่องทางเหตุการณ์เชื่อมโยงบันทึก, ร่องรอย, เจ้าของและการเปลี่ยนแปลง หลังจากการดำเนินงานที่เสถียร ทีมจะลบฟล็อกและสคีมาที่ล้าสมัย เมตริกครอบคลุมเวลาแฝง, การเปลี่ยนแปลงที่ล้มเหลว, การฟื้นฟู, ความเชื่อถือและผลลัพธ์ของผู้ใช้ Pipeline ทำให้เส้นทางที่ปลอดภัยเร็วขึ้นพร้อมคงหลักฐานและอำนาจของมนุษย์สำหรับข้อยกเว้น
หลักฐานการดำเนินการและความพร้อมเชิงปฏิบัติการ
การตัดสินใจผลิตต้องการมากกว่าการสาธิตที่ประสบความสำเร็จ กำหนดผู้ใช้เป้าหมาย, สภาพแวดล้อมการดำเนินงาน, อินพุต, เอาต์พุต, การพึ่งพา, เจ้าของและผลของความล้มเหลวสำคัญแต่ละรายการ สร้างฐานข้อมูลที่ทำซ้ำได้และชุดการประเมินที่เวอร์ชันก่อนการปรับแต่ง ทดสอบกรณีทั่วไป, เงื่อนไขขอบเขต, อินพุตที่ผิดรูปหรือขาดหาย, การเปลี่ยนแปลงการกระจาย, การหยุดทำงานของการพึ่งพา, การใช้งานผิดวิธี, และกลุ่มหรือสภาพแวดล้อมที่อาจไม่ได้รับการสนับสนุนอย่างเพียงพอ วัดคุณภาพงานพร้อมกับการสอบเทียบหรือความไม่แน่นอน, ความหน่วง, อัตราการทำงาน, ต้นทุนทรัพยากร, การเข้าถึง, ความเป็นส่วนตัวและความปลอดภัย บันทึกการแปลงและเกณฑ์ทุกอย่างเพื่อให้ผู้ตรวจสอบอิสระสามารถทำซ้ำผลลัพธ์และแยกแยะหลักฐานจากต้นแบบที่ดึงดูด
ก่อนการเปิดใช้งาน ให้มอบอำนาจสำหรับการปล่อย, ข้อยกเว้น, การเปลี่ยนแปลง, การย้อนกลับและการยกเลิก ใช้การปล่อยแบบขั้นตอน, คงการสำรองที่ปลอดภัยและตรวจสอบการเฝ้าระวังด้วยการฉีดความล้มเหลวโดยเจตนา เทเลเมทรีการปฏิบัติงานควรเปิดเผยคุณภาพอินพุต, พฤติกรรมเอาต์พุต, รุ่นโมเดลหรือกฎ, สถานะการพึ่งพา, การแทรกแซงของมนุษย์และผลลัพธ์ที่ยืนยันโดยไม่เก็บข้อมูลที่ละเอียดอ่อนที่ไม่จำเป็น กำหนดเกณฑ์การแจ้งเตือนและผู้รับผิดชอบการตอบสนอง แล้วตรวจสอบหลักฐานจากโลกจริงหลังการปรับใช้แทนการสันนิษฐานว่าประสิทธิภาพออฟไลน์จะคงอยู่ ประเมินใหม่เมื่อแหล่งข้อมูล, ผู้ใช้, โมเดล, ผู้ขาย, นโยบาย, ฮาร์ดแวร์หรือวัตถุประสงค์เปลี่ยนแปลง ระบบที่ดูแลต้องมีการบันทึกการฟื้นฟู, การเรียนรู้จากเหตุการณ์, ขั้นตอนการลบและการเก็บรักษา และจุดชัดเจนที่ควรปิดใช้งานหรือแทนที่
คำถามที่พบบ่อย
DevOps คือเดียวกับการพัฒนาซอฟต์แวร์แบบ Agile หรือไม่?
ไม่. แม้ว่าจะมีการทับซ้อนในเรื่องข้อเสนอแนะและการเพิ่มขึ้นเป็นขั้นตอนเล็ก ๆ แต่ DevOps ขยายความเป็นเจ้าของและการอัตโนมัติผ่านการปรับใช้และการดำเนินการในสภาพแวดล้อมการผลิต
DevOps หมายความว่านักพัฒนาทุกคนต้องอยู่ในสายเรียกตลอดเวลาใช่หรือไม่?
ไม่. ทีมต้องการความเป็นเจ้าของบริการที่ชัดเจนและข้อเสนอแนะจากการผลิต แต่การจัดสรรบุคลากร, การหมุนเวียนและการยกระดับควรเป็นไปอย่างยั่งยืนและเหมาะสมกับบริการ
แหล่งอ้างอิงหลัก
