ข้อดี / ข้อเสียของการหยุดเวิร์กโฟลว์ DevOps หรือไม่

ฉันพยายามประเมินว่าเป็นความคิดที่ดีหรือไม่ที่จะย้ายจากเวิร์กโฟลว์แบบ devops ไปเป็นแบบ dev-then-ops แบบดั้งเดิม (ไม่แน่ใจว่าสิ่งที่คุณเรียกว่า)

เราเป็นแผนกเล็ก ๆ 5 คนซ่อนตัวอยู่ในสื่อดั้งเดิมของพนักงาน 4,000 คน (เช่นไม่ใช่ซอฟต์แวร์) สองปีที่ผ่านมาเราเริ่มสร้างซอฟต์แวร์เพื่อให้แผนกของเราสามารถขยายการผลิตได้อย่างมีนัยสำคัญ เราประสบความสำเร็จเป็นอย่างดีและ บริษัท ที่ยิ่งใหญ่กว่าเริ่มที่จะสังเกตเห็นได้ จนถึงวันนี้เรารับผิดชอบ แต่เพียงผู้เดียวในการออกแบบพัฒนาและปรับใช้สิ่งที่กลายเป็นแพลตฟอร์มบริการไมโครไฟเบอร์ AWS ~ 10 ทีมของเราไม่ได้ระบุว่าเป็น DevOps แต่หากไม่มีคำถามเรากำลังใช้ชีวิตของ DevOps โดยที่นักพัฒนาแต่ละคนคุ้นเคยกับทั้งรหัสและระบบที่ทำงานอยู่

หนึ่งในคำถามที่เราจะเผชิญในไม่ช้าก็คือสิ่งที่ "ประสิทธิภาพ" ร่วมกันระหว่างเราและแผนกไอทีสำหรับ บริษัท แม่ของเรา เจ้าของโครงการของเรามักจะชอบจ้างมากกว่าการเรียนรู้ภายในองค์กรดังนั้นในกรณีของเราประสิทธิภาพเหล่านี้อาจหมายถึงการทำงานด้านไอทีให้มากที่สุด "หลุดออกจากจานของเรา" เท่าที่จะทำได้ ขณะนี้ฉันจะบอกว่าทีมของเรามีการแบ่ง 70/30% ระหว่างประสบการณ์ในการเขียนโปรแกรมและโครงสร้างพื้นฐาน แผนกไอทีอยู่ในขอบเขตด้านไอทีอย่างแน่นหนาโดยไม่ต้องมองข้ามการพัฒนาซอฟต์แวร์

เจ้าของโครงการของเรา (บุคคลที่ไม่ใช่ด้านเทคนิค) หวังว่าด้วยการมอบงานให้มากที่สุดเท่าที่จะเป็นไปได้ให้กับทีมงานด้านไอทีเราจะเห็นการเพิ่มผลผลิตประมาณ 1: 1 สำหรับการปฏิบัติการแต่ละชั่วโมงที่เราทำ ฉันสงสัยเกี่ยวกับเรื่องนี้แม้ว่า ผลิตภัณฑ์ของเรายังคงเป็นรุ่นเบต้าล่วงหน้า (แม้จะเป็นสินทรัพย์ทางธุรกิจที่สำคัญแล้ว) และจากประสบการณ์ที่ จำกัด ของเรากับแผนกไอทีมักจะมีความล่าช้าที่สำคัญสำหรับสิ่งต่าง ๆ ที่ง่ายเหมือนการเปลี่ยนแปลงการอนุญาตให้ใช้ระบบไฟล์

ตอนนี้ทางออกที่ดีที่สุดของฉันคือฝ่ายไอทีที่จะ "ยอมรับ" เราและอนุญาตให้เราปรับใช้งานของเราเองต่อไปในขณะที่มั่นใจว่าเราตรงตามมาตรฐานและข้อกำหนดของสำนักงานไอที ฉันไม่แน่ใจว่าเป็นจริงแค่ไหน นอกจากนี้ยังเป็นแนวทางที่ตรงกันข้ามกับที่เจ้าของโครงการของเราให้การสนับสนุนเนื่องจากจะเพิ่มการดำเนินงานเพิ่มเติมในระยะสั้น

ในสถานการณ์ของเราข้อดี / ข้อเสียของการเข้าพักด้วยวิธี DevOps คืออะไรเมื่อเทียบกับการส่งมอบไอที

มันไม่ใช่ความคิดที่ดี

จากประสบการณ์ของฉันคุณจะได้รับข้อเสียของทั้งคู่ในขณะที่ข้อได้เปรียบที่คาดการณ์ไว้ก็จะล้มเหลว

แยก:

1. คุณจะสูญเสียความเร็ว
   ไอทีจะปฏิบัติตามมาตรฐานของตนเอง งานใหม่ (สำหรับพวกเขา) จะเป็นไปตามเทมเพลต 'เฉื่อยชา' ที่เหมือนกันทั้งหมดที่งานของพวกเขามีอยู่ตอนนี้ เตรียมพร้อมพวกเขาจะพบว่ามันท้าทาย - ดังนั้นความเร็วที่น้อยลงกว่าการกระทำง่ายๆแบบมาตรฐาน
2. คุณจะไม่ถ่ายสินค้าออก
   มันจะพึ่งพาคุณทุกความผิดปกติ คุณจะพยายามทำให้ผู้ชายเร็วขึ้น - และสิ่งต่อไปที่คุณจะทำซ้ำตัวเองเพราะงาน / ปัญหา / วันต่อไปนี้จะมีผู้ชายคนใหม่อีกครั้ง
3. เอกสารจะต้อง แต่มันจะไม่ช่วย
   พฤติกรรมของเทมเพลตจะเป็นอีกครั้งที่คู่มือสั้น ๆ จะไม่สามารถจับความผิดปกติได้ทุกตัวและข้อความที่ละเอียดจะไม่ถูกอ่านเพราะยาวเกินไป ดังนั้นการลงทุนใด ๆ ที่นี่จะเป็นการสูญเสียเช่นเดียวกันกับความพยายามมหาศาลที่จำเป็นในการใช้การปรับปรุงเพื่อให้เครื่องมือของคุณมีคุณภาพ 'หดตัว'

สุดท้าย แต่ไม่ท้ายสุดปัญหาใด ๆ ที่จะสะท้อนกับพวกคุณ น้ำมันดินหลักการ tarbrush

ถ้าเสียงข้างบนดูถูกเหยียดหยามฉันกลัวว่าฉันเคยไปที่นั่นมาแล้ว ซ้ำแล้วซ้ำเล่า

จะทำอย่างไรแทน

ไปช้อปปิ้งในแผนก IT ค้นหาตัวคุณเองว่าเป็นผู้สมัครที่มีประโยชน์และให้ผู้ชายคนนี้ 'ยืมตัว' เพื่อลดภาระงานของคุณ

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

โดยเฉลี่ยคุณจะต้องมีนักพัฒนา 1 คนสำหรับทุก ๆ 4 คนเพื่อให้การพัฒนาคุณลักษณะอยู่ในระดับเดียวกัน (38% เทียบกับเวลาที่ใช้ในการทำงานใหม่ 49%) เวลาเฉลี่ยของคุณในการกู้คืนจากความล้มเหลวจะลดลงถึง 25 เท่า งานของคุณจะสนุกน้อยลง 20% และคุณจะเป็น 40% ที่จะแนะนำงานของคุณให้เพื่อน ข้อเท็จจริงสามข้อนั้นเพียงพอแล้ว

สิ่งที่คุณจะสูญเสียจากการปรับตัวให้เข้ากับองค์กรไอทีคือส่วน "Dev" ของทีม DevOps ตัวน้อยของคุณ เมื่อทีมถูกแบ่งเป็นบทบาทประดิษฐ์ของ NetOps, SysOps และ Dev คุณแนะนำปัญหาต่อไปนี้:

1. เทปและการแยกสีแดงที่ไม่ต้องการ - ในการทำสิ่งใดก็ตามที่ผู้พัฒนาจะต้องส่งตั๋วให้กับฝ่ายไอทีและรอให้พวกเขานำไปใช้ พวกเขาจะไม่สามารถใช้งานและโต้ตอบกับมันได้อีกต่อไปซึ่งรวมถึงกรณี Dev และ QA ซึ่งจะ จำกัด โครงสร้างพื้นฐานที่พวกเขาสามารถใช้รหัสได้ พวกเขาติดอยู่ที่สิ่งกีดขวาง VM แทนที่จะสามารถเขียนโค้ดบนสแต็กเต็ม หากสิ่งที่พวกเขาส่งให้กับไอทีดูเหมือนว่ารหัส DevOps พวกเขาจะไม่สามารถจัดการได้และอาจกลับไปใช้การปรับใช้ด้วยตนเอง
2. ละเลย - อีกวิธีหนึ่งคือพวกเขาอาจปรับใช้ตามที่เป็นอยู่แล้วละเลยสัตว์ร้ายเพราะพวกเขาไม่รู้วิธีโต้ตอบกับมัน - และพวกเขาไม่ใช่นักพัฒนาดังนั้นรหัสไม่ใช่ปัญหาของพวกเขา
3. การหยุดทำงาน - หนึ่งในข้อดีที่มองข้ามไปของ DevOps คือลักษณะการเขียนโปรแกรม แน่นอนว่าอาจใช้เวลานานกว่าในการปรับใช้เซิร์ฟเวอร์นั้นโดยถือเป็นรหัส แต่สิ่งนี้จะทำให้ความผิดพลาดของมนุษย์โดยอัตโนมัติ วิธีที่มันเข้าสู่ dev ก็คือพวกเขาจะเข้าสู่ QA / Test เป็นวิธีที่มันจะเข้าสู่กระบวนการผลิต เมื่อนักพัฒนาไม่สามารถเข้าถึงอุปกรณ์เครือข่ายพวกเขาจำเป็นต้องปรับใช้บริการของพวกเขาหรือโครงสร้างพื้นฐานการคำนวณไม่เพียง แต่จะใช้เวลานานขึ้นเท่านั้น
4. เอกสาร - ในบางกรณีรหัส DevOps คือการทำเอกสารด้วยตนเอง คุณรู้วิธีการสร้างและปรับใช้เซิร์ฟเวอร์เนื่องจากรหัสบอกคุณ ใน 5 ปีเมื่อถึงเวลาอัพเกรดเป็น CentOS 8 หรืออะไรก็ตามจะไม่มีใครรู้วิธีปรับใช้แอปพลิเคชันของคุณอีกต่อไป - รวมถึงที่เครือข่ายพื้นที่เก็บข้อมูลการตรวจสอบและชั้นการสำรองข้อมูล

ในระยะสั้นคุณควรแนะนำให้เจ้าของโครงการของคุณใช้เวลาในการอ่าน The Mythical Man-Monthเพื่อทำลายความคิดที่ว่าคุณจะเห็นความสัมพันธ์แบบ 1: 1 ในการทำงานและThe Phoenix Projectซึ่งเป็นนิยายที่ดี สนุกสนาน) ภาพประกอบของสิ่งที่ได้รับและสูญหายโดยใช้ DevOps ในภาษาที่ไม่ใช่ด้านเทคนิคสำหรับคนที่ไม่ใช่ด้านเทคนิค หากเจ้าของโครงการมีหนังสือเสียง Audible ของ The Phoenix Project สามารถใช้ได้

ฉันขอแนะนำให้คุณนำทีม IT มาใช้และฝึกอบรมอย่างละเอียดในระบบใหม่

เมื่อพวกเขาเข้าใจระบบโดยสมบูรณ์แล้ว

มิฉะนั้นคุณจะกลายเป็นศูนย์สนับสนุนสำหรับไอที - และใช้เวลาในการดับเพลิงมากเพราะพวกเขาเรียนรู้ถึงความซับซ้อนของระบบใหม่