อุตสาหกรรมเทคโนโลยีกำลังเผชิญกับการตระหนักรู้ที่เพิ่มขึ้นว่า DevOps ซึ่งเคยได้รับการยกย่องว่าเป็นแนวทางปฏิวัติสำหรับการพัฒนาซอฟต์แวร์และการดำเนินงาน อาจจะหลงทางไปแล้ว สิ่งที่เริ่มต้นเป็นการเคลื่อนไหวเพื่อเสริมพลังให้นักพัฒนาเป็นเจ้าของสภาพแวดล้อมการผลิตของตนเอง ได้พัฒนาไปเป็นสิ่งที่หลายคนโต้แย้งว่าทำลายวัตถุประสงค์เดิมของมัน
วิสัยทัศน์เดิมเทียบกับความเป็นจริงในปัจจุบัน
DevOps เริ่มต้นด้วยแนวคิดง่ายๆ นักพัฒนาควรปรับใช้โค้ดของตนเองและรับผิดชอบในการรักษาให้มันทำงานต่อไป นี่หมายถึงการตรวจสอบระบบ การตอบสนองต่อปัญหา และการใช้ทักษะการเขียนโปรแกรมเพื่อทำให้การปรับใช้เป็นไปโดยอัตโนมัติอย่างปลอดภัย แนวทางนี้สมเหตุสมผลมาก โดยเฉพาะอย่างยิ่งเมื่อบริการคลาวด์ทำให้การเปิดเซิร์ฟเวอร์ง่ายเหมือนการเรียก API
อย่างไรก็ตาม ในขณะที่แนวปฏิบัตินี้ได้รับชื่อเป็นทางการ ทุกอย่างก็เปลี่ยนไป บริษัทต่างๆ เริ่มสร้างทีม DevOps เฉพาะและจ้างวิศวกร DevOps ซึ่งดึงนักพัฒนาที่มีความคิดด้านการผลิตออกจากทีมผลิตภัณฑ์ สิ่งนี้ทำให้ทีมพัฒนาไม่มีใครที่มุ่งเน้นไปที่ความกังวลด้านการผลิต และสร้างไซโลเดิมที่ DevOps ตั้งใจจะกำจัดขึ้นมาใหม่
ปัญหาช่องว่างด้านทักษะ
หนึ่งในปัญหาที่สำคัญที่สุดที่รบกวนการใช้งาน DevOps สมัยใหม่คือความไม่ตรงกันของทักษะพื้นฐาน ผู้เชี่ยวชาญหลายคนในบทบาท DevOps มาจากพื้นฐานการบริหารระบบแบบดั้งเดิมโดยไม่มีความสามารถด้านการเขียนโปรแกรมที่แข็งแกร่ง สิ่งนี้สร้างคอขวดที่ทีมต่างๆ ต่อสู้กับงานดีบักและระบบอัตโนมัติพื้นฐานที่ต้องการทักษะการพัฒนาจริงๆ
ความคาดหวังที่ว่าคนเดียวสามารถจัดการกับการพัฒนา การดำเนินงาน การสังเกตการณ์ และการสนับสนุนได้นั้นไม่สามารถขยายในทางปฏิบัติ สิ่งที่มักเกิดขึ้นคือคนด้านการดำเนินงานที่มีตำแหน่งใหม่ที่ฟังดูดี หรือนักพัฒนาที่ถูกผลักไปสู่ดินแดนที่ไม่คุ้นเคย ไม่ค่อยบรรลุการผสมผสานทักษะที่แท้จริงที่บทบาทต้องการ
ปัญหาทั่วไปในการนำ DevOps มาใช้งาน
- ทักษะไม่ตรงกัน: ผู้เชี่ยวชาญ DevOps หลายคนขาดความสามารถด้านการเขียนโปรแกรมที่แข็งแกร่ง เนื่องจากมาจากพื้นฐานการดูแลระบบแบบดั้งเดิม
- การแบ่งแยกองค์กร: การสร้างทีม DevOps แยกต่างหากทำให้ความเชี่ยวชาญด้านการผลิตถูกดึงออกไปจากทีมพัฒนา
- ปัญหาความไว้วางใจ: การนำมาใช้ในยุคปัจจุบันมักจะจำกัดมากกว่าเสริมพลังให้กับนักพัฒนา
- ภาระงานด้านการปฏิบัติตามกฎระเบียบ: ข้อกำหนดด้านความปลอดภัยที่นำมาใช้ผ่านการจำกัดมากกว่าความโปร่งใส
- ความซับซ้อนของเครื่องมือ: การสร้างนามธรรมภายในที่ล้าหลังกว่าความสามารถของผู้ให้บริการคลาวด์
ปัญหาความไว้วางใจและการควบคุม
ทีม DevOps สมัยใหม่มักดำเนินงานภายใต้สมมติฐานที่ว่านักพัฒนาไม่สามารถไว้วางใจให้เข้าถึงการผลิตได้ กรอบความคิดนี้นำไปสู่ชั้นของข้อจำกัดและกระบวนการอนุมัติที่ทำให้การพัฒนาช้าลงแทนที่จะเอื้อให้เกิดขึ้น ทีมต่างๆ สร้างเครื่องมือภายในที่ออกแบบมาเพื่อจำกัดมากกว่าเสริมพลัง โดยห่อหุ้ม API ของคลาวด์ด้วยการแยกส่วนที่สร้างเองซึ่งล้าหลังกว่าสิ่งที่ผู้ให้บริการเสนออยู่แล้ว
วิศวกรทีมผลิตภัณฑ์ในปัจจุบันรู้สึกเหมือนเด็กที่ถูกตามใจ พวกเขาไม่รู้ว่าเซิร์ฟเวอร์ทำงานอย่างไร และขอสิ่งที่ไม่สมเหตุสมผล
สิ่งนี้สร้างวงจรอุบาทว์ที่นักพัฒนาถูกตัดขาดจากความเป็นจริงของการผลิตมากขึ้น ในขณะที่ทีม DevOps กลายเป็นผู้เฝ้าประตูมากกว่าผู้เอื้ออำนวย
กับดักการปฏิบัติตามกฎระเบียบ
ข้อกำหนดการปฏิบัติตามกฎระเบียบมักถูกโทษสำหรับแนวปฏิบัติที่เข้มงวด แต่ปัญหาที่แท้จริงอยู่ที่การใช้งาน ความปลอดภัยควรมาจากการมองเห็นและความโปร่งใส ไม่ใช่ประตูที่ล็อค เมื่อทีม DevOps เป็นเจ้าของรายการตรวจสอบการปฏิบัติตามกฎระเบียบ พวกเขามักอบความไม่ไว้วางใจเข้าไปในกฎเกณฑ์ โดยสมมติว่านักพัฒนาเป็นนักแสดงที่ไม่ดีที่อาจเกิดขึ้นแทนที่จะเป็นผู้ร่วมงาน
สิ่งที่ทำงานได้ดีกว่า
องค์กรที่ประสบความสำเร็จกำลังเปลี่ยนจากทีม DevOps แยกต่างหากไปสู่โมเดลฝังตัว บริษัทบางแห่งมีวิศวกรที่มีความคิดด้านการผลิตทำงานโดยตรงกับทีมพัฒนา โดยใช้ตำแหน่งเช่นวิศวกรระบบแทนที่จะเป็นวิศวกร DevOps แนวทางนี้รักษาความเชี่ยวชาญด้านการดำเนินงานให้อยู่ใกล้กับผลิตภัณฑ์ในขณะที่รักษาจิตวิญญาณการร่วมมือที่ทำให้ DevOps มีค่าตั้งแต่แรก
ทีมที่มีประสิทธิภาพที่สุดผสมผสานนักพัฒนาที่มุ่งเน้นคุณลักษณะกับสมาชิกทีมที่เชี่ยวชาญด้านการดำเนินงานที่สามารถปรับใช้งานของตนเองได้ โดยได้รับการสนับสนุนจากทีมวิศวกรรมแพลตฟอร์มเฉพาะที่ให้เครื่องมือและโครงสร้างพื้นฐานโดยไม่กลายเป็นคอขวด
แนวทางทางเลือกที่ประสบความสำเร็จ
- โมเดลแบบฝังตัว: วิศวกรที่มีความคิดเชิงการผลิตทำงานโดยตรงกับทีมพัฒนา
- วิศวกรระบบ: บทบาททางเทคนิคที่เน้นโครงสร้างพื้นฐานโดยไม่มีภาระของ " DevOps "
- วิศวกรรมแพลตฟอร์ม: ทีมเฉพาะทางที่ให้เครื่องมือและโครงสร้างพื้นฐานโดยไม่กลายเป็นคอขวด
- ความรับผิดชอบร่วม: การรวมนักพัฒนาที่เน้นฟีเจอร์เข้ากับสมาชิกทีมที่เชี่ยวชาญด้าน ops
มองไปข้างหน้า
อุตสาหกรรมดูเหมือนจะเรียนรู้จากความผิดพลาดเหล่านี้ แม้ว่าจะช้า Platform Engineering กำลังเกิดขึ้นเป็นวิวัฒนาการครั้งต่อไป แม้ว่าบางคนจะกังวลว่าอาจทำซ้ำรูปแบบเดิม กุญแจสำคัญดูเหมือนจะเป็นการรักษาจิตวิญญาณการร่วมมือและความรับผิดชอบร่วมกันที่ทำให้ DevOps มีค่า ในขณะที่หลีกเลี่ยงไซโลขององค์กรที่บ่อนทำลายมัน
ความสำเร็จต้องการความเป็นผู้นำทางเทคนิคที่แข็งแกร่งที่เข้าใจทั้งการพัฒนาและการดำเนินงาน วัตถุประสงค์ที่ชัดเจน และวัฒนธรรมที่ให้ความสำคัญกับการร่วมมือมากกว่าการเมือง หากไม่มีรากฐานเหล่านี้ โมเดลองค์กรใดๆ จะต่อสู้ดิ้นรนไม่ว่าจะเรียกว่าอะไร