“ การแปลง DevOps” ประกอบด้วยอะไร?

บริษัท ที่ปรึกษาบางแห่งกำลังส่งเสริมบริการที่เรียกว่า "DevOps Transformation" บริษัท ขนาดใหญ่หลายแห่งกำลังพูดถึงเรื่องนี้ในการประชุมและพบปะทั่วโลก

"การเปลี่ยนแปลง DevOps" เช่นนี้นำมาซึ่งอะไร? มันมีลักษณะอย่างไรในเงื่อนไขที่สามารถดำเนินการได้ทั้งการแปลงที่สำเร็จและการล้มเหลว

ฉันต้องตอบคำถามนี้ในบริบทของ DevOps ที่เฉพาะเจาะจงมากขึ้นในการแปลง DevOps ที่ฉันได้เข้าร่วม DevOps เป็นกรรมสิทธิ์ของวัฏจักรการพัฒนาซอฟต์แวร์เต็มรูปแบบ ทั้งหมดของการปฏิบัติในแผนภูมิที่มีส่วนสำคัญในการ DevOps และพวกเขาเปิดใช้งานและหนุนทั้งการคิดเชิงระบบและการขยายของลูปผลตอบรับ

อย่างไรก็ตามความแตกต่างที่สำคัญระหว่าง CI / CD และ DevOps คือการทำงานจริงของซอฟต์แวร์ในสภาพแวดล้อมการผลิตซึ่งสามารถส่งมอบคุณค่าให้กับลูกค้าและธุรกิจที่ให้บริการ

ในฐานะที่ปรึกษาที่เข้าร่วมหรือเป็นผู้นำการเปลี่ยนแปลง DevOps ฉันมีแง่มุมต่อไปนี้ในด้านหน้าของใจของฉัน:

• วัฒนธรรม : เดฟชี้ให้เห็นอย่างถูกต้องว่าวัฒนธรรมแห่งการทดลองอย่างต่อเนื่องและการเรียนรู้มีความสำคัญต่อความสำเร็จของการเปลี่ยนแปลงใด ๆ จากมุมมองของ DevOps สิ่งนี้เกิดขึ้นได้อย่างไรเราสร้างวัฒนธรรมที่สนับสนุนรูปแบบ DevOps ที่เลือกรูปแบบนี้อาจเป็น "คุณสร้างมันคุณเรียกใช้" หรืออาจเป็นไปตามแนวปฏิบัติด้านวิศวกรรมเว็บไซต์ของความน่าเชื่อถือของ Google .

• รูปแบบการดำเนินงาน : นี่เป็นส่วนหนึ่งของข้อเสนอทางธุรกิจที่กำหนดวิธีการที่องค์กรจะส่งมอบคุณค่าโดยทั่วไปโดยการสื่อสารกับประชาชนกระบวนการและเครื่องมือที่ใช้เชื่อมโยงกันในระดับสูง หากไม่มีรูปแบบการดำเนินงานคุณไม่มีพิมพ์เขียวสำหรับวิธีที่องค์กรนำมาใช้ในการปฏิบัติที่วัฒนธรรมกำหนดซึ่งจะนำไปสู่การขาดความชัดเจนและพฤติกรรมที่แตกต่าง

• C-Level Aircover : มันมักจะเป็นงานของเราในฐานะที่ปรึกษาที่ทำงานในโปรแกรมการเปลี่ยนแปลงเพื่อเปลี่ยนแปลงอย่างรุนแรงต่อวิธีการทำงานของธุรกิจ คุณกำลังจะอารมณ์เสียคนและบางคนไม่ชอบการเปลี่ยนแปลงมันเป็นสิ่งสำคัญที่คุณต้องมี "air cover" จากด้านบนเพื่อเปลี่ยนสิ่งต่าง ๆ และย้ายไปข้างหน้า

เมื่ออยู่ในระดับสูงแล้วสิ่งสำคัญคือการค้นหาสิ่งที่คุณสามารถส่งมอบได้แนบเนียน:

1. เริ่มต้นเล็กที่สุดเท่าที่จะเป็นไปได้เมื่อคุณมีบางคนที่เข้าใจวัฒนธรรมภาพร่างของรูปแบบการดำเนินงานและบายอินจากผู้บริหารสร้าง "โครงการที่มีศักยภาพขั้นต่ำ" อย่าพยายามต้มมหาสมุทรโดยการแนะนำ DevOps ถึงผู้ชมนับพัน กำหนดเป้าหมายที่ทำได้:
   • สร้างโครงสร้างพื้นฐานโดยอัตโนมัติจาก Product X
   • ทำการส่งมอบผลิตภัณฑ์ X ไปยัง Azure โดยอัตโนมัติในทุกสภาพแวดล้อม
   • การสนับสนุนหลังมือจาก outsourcer Y ถึงทีมพัฒนาในลอนดอน
   • สร้างชุดการทดสอบรอบ ๆ คุณลักษณะที่มีความเสี่ยงที่สุดของเราและดำเนินการในการรวมอย่างต่อเนื่อง
2. ยอดเยี่ยมที่คุณประสบความสำเร็จภายใต้เข็มขัดของคุณตอนนี้ถึงเวลาที่จะเริ่มต้นการอบให้เป็นทีมมากขึ้นเพิ่มอีกสองสามทีมในการผสมและทำให้พวกเขาขึ้นและทำงาน อย่ากลัวที่จะเสนอ "White Glove Support" ในตอนแรกเพื่อช่วยเหลือพวกเขาในช่วงการเปลี่ยนภาพ พวกเขาจะต้องจับมือกันมากในช่วงสัปดาห์และเดือนที่จะมาถึง
3. ตอนนี้คุณมีผู้รับช่วงเริ่มต้นหลายคนที่ติดตามวิธีการทำงานใหม่ คุณมีความสำคัญอย่างยิ่งมันถึงเวลาที่จะเริ่มประกาศการทำงานที่คุณทำกับผู้ชมที่กว้างขึ้น:
   • จัดให้มีการแสดงและบอกเล่าเป็นประจำขอให้ผู้ใช้ต้น ๆ แสดงให้เห็นว่าพวกเขาประสบความสำเร็จได้อย่างไร
   • เสนอเซสชันแบบเลื่อนลงเพื่อให้ส่วนอื่น ๆ ขององค์กรสามารถสำรวจว่าพวกเขาจะมาร่วมงานกับทีมของคุณได้อย่างไร
   • เปิดใช้งานการสร้างชุมชนการปฏิบัติที่เน้นไปที่สาขาวิชาเฉพาะ: การปรับใช้อย่างต่อเนื่อง, การทดสอบอัตโนมัติ, การสื่อสารทางธุรกิจ, การบริหารความเสี่ยง, การตรวจสอบและการแจ้งเตือน ฯลฯ

4. อยู่ที่หลักสูตรและปิดการเปลี่ยนแปลงโดยการลงทะเบียนส่วนที่เหลือขององค์กร เข้าใจความสัมพันธ์ระหว่างGartner วงจร Hypeและยอมรับ Lifecycle เตรียมความพร้อมสำหรับโครงการการเปลี่ยนแปลงที่จะตกอยู่ใน "รางแห่งความท้อแท้" อยู่ในเส้นทางและรักษาเป้าหมายสุดท้ายให้ได้

   

สำหรับการสำรวจลึกของจุดสุดท้ายอ่านเจฟฟรีย์เอมัวร์ข้ามเหว ฉันสามารถเขียนหนังสือเกี่ยวกับวิธีการส่งมอบการเปลี่ยนแปลง DevOps ได้อย่างแท้จริงอย่างไรก็ตามเมื่อฉันเสร็จมันอาจจะไม่มีการเปลี่ยนแปลง DevOps อีกต่อไปสำหรับฉันที่จะทำ

DevOps มีแนวโน้มที่จะพังทลายในสามมิติหลัก:

วัฒนธรรมวัฒนธรรม
DevOps เน้นระดับสูงของความไว้วางใจการทำงานร่วมกันและการสื่อสารระหว่างผู้มีส่วนได้ส่วนเสียทั้งหมดโดยเฉพาะ Dev, Ops และความปลอดภัย ความตึงเครียดตามธรรมชาติและการแข่งขันระหว่างกลุ่มเหล่านี้สร้างแรงเสียดทานและมักจะผิดปกติ DevOps เป็นสิ่งแรกและสำคัญที่สุดเกี่ยวกับการจัดแนวความพยายามระหว่างทีมเหล่านี้

Process
DevOps กระบวนการพัฒนาสอดคล้องกับกระบวนการ Agile Ops ได้รับการสนับสนุนให้ใช้แนวทางปฏิบัติแบบ Agile เพื่อให้สอดคล้องกับความพยายามของ Dev มากขึ้น กระบวนการที่จัดชิด DevOps ออกแบบมาเพื่อรองรับลูปความเร็วสูงและข้อเสนอแนะที่รวดเร็วตลอดวงจรการพัฒนา / การส่งมอบ การรวมอย่างต่อเนื่องการส่งมอบอย่างต่อเนื่องและการปรับปรุงอย่างต่อเนื่อง (ไคเซ็น) เป็นส่วนสำคัญของกระบวนการ DevOps

เทคโนโลยี
DevOps ไม่ใช่เครื่องมือ แต่ได้รับการสนับสนุนจากเครื่องมือ มีเครื่องมือทั้งครอบครัวที่สนับสนุนขอบเขตของพื้นที่รวมถึงการรวมอย่างต่อเนื่อง, การควบคุมแหล่งที่มาและการจัดการวงจรชีวิตของแอพลิเคชัน

"การเปลี่ยนแปลง DevOps" ต้องระบุองค์ประกอบของทั้งสาม แต่ไม่จำเป็นต้องเท่ากันทั้งหมดในเวลาเดียวกัน มีความก้าวหน้าตามธรรมชาติและ "เส้นทางวิกฤต" สำหรับการเปลี่ยนแปลง การโต้แย้งสามารถทำได้เช่น DevOps ขึ้นอยู่กับรูปแบบของการฝึกฝนแบบ Agile อย่างน้อยภายในทีมพัฒนา / ทีม ปัญหาเกี่ยวกับวัฒนธรรมอาจต้องได้รับการแก้ไขก่อนการลงทุนในการสร้างเครื่องมือ

ข้อมูลอ้างอิง:
วัฒนธรรม: https://www.andykelk.net/devops/using-the-westrum-typology-to-measure-culture
เทคโนโลยี: https://xebialabs.com/periodic-table-of-devops-tools/