ทำไมการพัฒนาจึงต่อต้านการดำเนินงาน

ฉันยังเป็นนักเรียนอยู่ แต่ฉันไม่มีความรู้เกี่ยวกับการปฏิบัติงานและภาษาอังกฤษของฉันก็ยังไม่ดี

คำถามของฉันคือทำไมการพัฒนาจึงต่อต้านการดำเนินงาน ? การพัฒนาต่อต้านการปฏิบัติงานเมื่อใด?

ประเด็นของ DevOps คือการพัฒนาไม่ควรต่อต้านการดำเนินการ แต่ควรสนับสนุนซึ่งกันและกัน

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

ในทางกลับกัน DevOps ทำงานเพื่อลดขนาดการอัปเดตลดสภาพแวดล้อมที่เข้มงวดและโดยทั่วไปปรับปรุง handoff ของแอปพลิเคชันระหว่างการพัฒนาและการดำเนินงานโดยการเพิ่มจำนวนครั้งที่แฮนด์ออฟเกิดขึ้นในแต่ละปี ด้วยจำนวนการใช้งานที่เพิ่มขึ้นทำให้ปวดหัวน้อยลงสำหรับการดำเนินการเนื่องจากมีทั้งงานอัตโนมัติจำนวนมากที่จำเป็นต้องใช้ในการอัปเดตผลิตภัณฑ์หรือคาดการณ์ได้ดีขึ้นและเตรียมความพร้อมสำหรับการปรับปรุง

Tldr: DevOps มีวัตถุประสงค์เพื่อลบล้างทฤษฎีที่การพัฒนาต่อต้านการดำเนินการโดยการสร้างความคิดที่การดำเนินงานและการพัฒนาทำงานร่วมกันเพื่อปรับใช้ผลิตภัณฑ์บ่อยครั้งอย่างรวดเร็วและทำซ้ำได้อย่างง่ายดาย

ฉันคิดว่าคุณได้รับคำตอบที่ครอบคลุมแล้ว แต่คุณพูดว่าภาษาอังกฤษของคุณไม่ค่อยดีนักดังนั้นฉันจะพยายามให้คำตอบที่สั้นและเข้าใจง่ายมาก:

• เป้าหมายหลักของการพัฒนาคือการเปลี่ยนแปลง
• เป้าหมายหลักของการดำเนินงานคือการรักษาสิ่งแวดล้อมให้มั่นคง

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

ความตึงเครียดระหว่างการพัฒนาและการดำเนินงานมักเกิดจากการเยื้องแนวของสิ่งจูงใจและพยายามเพิ่มประสิทธิภาพภายในทีม

นักพัฒนามักจะตัดสินจากความเร็วและปริมาณของปัญหาที่พวกเขาสามารถผ่านและรวมเข้ากับที่เก็บรหัสและรางวัลของพวกเขามักจะไม่เชื่อมโยงกับรหัสนั้นทำงานจริงหรือทำงานอย่างถูกต้อง การปรับขนาดประสิทธิภาพและปัจจัยอื่น ๆ น้อยลง

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

สิ่งนี้สร้างปัญหาที่นักพัฒนาได้รับแรงจูงใจเพื่อสร้างรหัสจำนวนมากและส่งต่อไปยังทีมปฏิบัติการและทีมงานมีแรงจูงใจที่จะยอมรับการเปลี่ยนแปลงเล็กน้อยที่สุดเพื่อสร้างความมั่นคงของสภาพแวดล้อม

DevOps เป็นวิธีการแก้ปัญหาชุดนี้:

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

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

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

เมื่อผู้จัดการของแต่ละไซโลทำงานได้รับคำสั่งให้ปรับปรุงโดยลดต้นทุนหรือเพิ่มความเร็วปฏิกิริยาของพวกเขามักจะ:

• ฉันรู้สึกท่วมท้นในการแก้ไขปัญหาจากการปรับปรุงครั้งล่าสุด ทิ้งฉันไว้คนเดียว
• คุณต้องการให้ฉันทำอะไรตอบสนองความรับผิดชอบของฉันหรือทำงานในโครงการปรับปรุง ฉันไม่มีเวลาทำทั้งสองอย่าง
• ไม่มีอีกครั้ง! ที่นี่โปรแกรมอื่นของเดือนมา

ด้วยปฏิกิริยาทั่วไปเหล่านี้ผู้บริหารที่พยายามปรับปรุงเล็กน้อยจะไม่ค่อยได้รับการต้อนรับด้วยความกระตือรือร้น ผู้จัดการพบว่าตัวเองแข่งขันกันอย่างดุเดือดกับส่วนงานอื่น ๆ มากกว่าทรัพยากรที่จำเป็นในการปรับปรุง ดังนั้นไม่น่าแปลกใจที่คำสั่งให้ปรับปรุงการต่อสู้ข้ามสายพันธุ์ให้เข้มข้นขึ้น!

แม้ว่าผู้จัดการจะเป็นส่วนหนึ่งของโครงการปรับปรุงเขาก็พบกับหน้าที่การทำงานอื่น ๆ และองค์กรอื่น ๆ (ซัพพลายเออร์ผู้รับจ้าง ฯลฯ ... ) ที่ไม่ได้ทำงาน สิ่งนี้จะลดน้อยลงหรือขัดแย้งกับผลลัพธ์โดยสิ้นเชิง

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

ผู้จัดการฝ่ายการเงินได้รับแจ้งว่า "ปรับปรุง" เขาตัดสินใจปิดกั้นการจ้างผู้รับเหมาที่มีราคาสูงกว่าราคาที่ยอมรับในตลาด เขาใช้นโยบายใหม่และอ้างว่าได้ประหยัด 1 ล้านดอลลาร์ในปีนี้ กับนักพัฒนาและไอทีไม่สามารถจ้างผู้รับเหมาเพื่อช่วยให้พวกเขาใช้การจัดวางตู้คอนเทนเนอร์และตู้คอนเทนเนอร์เนื่องจากผู้รับเหมาเหล่านี้มีราคาแพง ผู้จัดการฝ่ายปฏิบัติการด้านไอทีใน บริษัท เดียวกันคำนวณว่าการไม่ปรับปรุงโครงสร้างพื้นฐานของพวกเขานั้นทำให้ บริษัท มีค่าใช้จ่ายเพิ่มเติมเกิน 100,000 ดอลลาร์ในแต่ละเดือน ในอัตราดังกล่าวเงินออมรายปีในการจ้างผู้รับเหมาถูกกินหมดก่อนสิ้นปี

คุณสามารถจินตนาการได้ว่าความสัมพันธ์ระหว่างสองหน้าที่นี้ไม่ใช่ความรักอย่างแท้จริง

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

ในกรอบการอ้างอิงนี้ต้นทุนถูกมองว่าเป็นไปตามกฎ "เพิ่มเติม" ต้นทุนของแต่ละไซโลรวมกันเท่ากับต้นทุนทั้งหมดขององค์กร ดังนั้นผู้จัดการจึงเห็นว่าการลดต้นทุนในพื้นที่ของพวกเขาเป็น "ดี" เนื่องจากพวกเขาเห็นการแปลโดยตรงไปยังการประหยัดต้นทุนสำหรับ บริษัท โดยรวม ในกรอบอ้างอิงนี้ความพยายามในการปรับปรุงจะกระจายไปทุกหนทุกแห่งเพื่อโจมตีค่าใช้จ่ายและของเสียทั่วทั้งองค์กร

ตัวอย่างที่ดีเมื่อทีมพัฒนาเริ่มทำงาน Agile และส่งรหัสไปยัง QA และการดำเนินงานทุกสองสัปดาห์แทนที่จะเป็นทุกไตรมาสเหมือนที่เคยทำ การควบคุมคุณภาพและการปฏิบัติงานยังไม่พร้อมสำหรับการเปลี่ยนแปลงดังกล่าวและถูกตำหนิสำหรับการเฉื่อย อีกครั้งสิ่งนี้ไม่ได้มีส่วนช่วยอะไรมากมายกับความรักระหว่างผู้คนในการพัฒนาและการดำเนินงาน