มีวิธีใดบ้างในการวัด ROI สำหรับ DevOps

DevOps นั้นซับซ้อนและเกี่ยวข้องกับแง่มุมที่ไม่สามารถกำหนดได้มากมายเช่นวัฒนธรรมและกระบวนการ
มีวิธีใดบ้างในการวัดความคิดริเริ่ม DevOps เพื่อความสำเร็จ
คุณพิสูจน์ให้เห็นถึงธุรกิจที่การลงทุนที่พวกเขาทำนั้นคืน (หรือบันทึก) ดอลลาร์จริงหรือไม่?

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

หมายเหตุ : นี่เป็นคำถามที่ได้รับความเห็นชอบและคำตอบของฉันก็เช่นกัน

Tensibai แนะนำอย่างชาญฉลาดเราพบตัวชี้วัดที่เหมาะสมและเขาใช้เวลาในการตลาดเป็นตัวอย่าง นี่เป็นวิธีภาพรวมขนาดใหญ่

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

นี่เป็นเพียงการชนะทางการเงินไม่กี่:

• คำนวณค่าใช้จ่ายเซิร์ฟเวอร์ที่บันทึกโดยใช้ประโยชน์จากการปรับขนาดอัตโนมัติในคลาวด์
• สำหรับไซต์ที่สร้างรายได้ให้คาดการณ์ต้นทุนต่อนาทีของการหยุดทำงานจากนั้นแสดงการปรับปรุงในMTTI และ MTTR
• อีกครั้งสำหรับไซต์ที่สร้างรายได้ให้ประเมินต้นทุนต่อนาทีที่บันทึกไว้โดยใช้ประโยชน์จากสถาปัตยกรรมที่มีความพร้อมใช้งานสูงตามเหตุการณ์ในอดีต
• หากคุณได้รับการปรับปรุงในการสร้างและปรับใช้ไปป์ไลน์แสดงว่าคุณได้ลดการถดถอยและข้อผิดพลาดในการผลิตซึ่งเกิดจากความผิดพลาดที่ติดตามไปแล้ว
• หากคุณได้ทำการปรับปรุงสภาพแวดล้อมการทดสอบของนักพัฒนาซอฟต์แวร์หรือแม้กระทั่งเครื่องมือและการกำหนดค่าบนแล็ปท็อปของนักพัฒนาให้ดูประวัติความเป็นมาเพื่อดูว่าวิศวกรใหม่กำลังมีส่วนร่วมครั้งแรกหลังจากเข้าร่วม
• ทำการเปรียบเทียบค่าใช้จ่ายเต็มรูปแบบระหว่างคลาวด์และในสถานที่เช่นเดียวกับGitlab ที่ทำเมื่อเร็ว ๆ นี้เพื่อปรับการใช้จ่ายโครงสร้างพื้นฐานของคุณ (ประหยัดออม!)

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

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

ความถี่ในการปรับใช้มีประโยชน์เช่นกัน เราต้องการให้มีการใช้งานบ่อยครั้งในขั้นตอนการพัฒนา DevOps ไม่มีเวทย์ "1 วันดี 2 วันแย่" การวัด สิ่งนี้จะต้องบริบททางประวัติศาสตร์ในโครงการของคุณจะมีความหมาย

ขนาดการปรับใช้ : วัดในอย่างไรก็ตามนักพัฒนาของคุณจะวัดงาน - เรื่องราวของผู้ใช้, จุดเรื่องราว, quatloos หรืออะไรก็ตาม อีกครั้งคุณต้องการดูแนวโน้มเมื่อเวลาผ่านไปไม่ใช่ค่าสัมบูรณ์

ระหว่างความถี่และขนาดมีเรื่องเล่าให้เล่า การเปิดตัวของเราไม่บ่อยนักและมีขนาดใหญ่ขึ้นหรือไม่? ทำไม? พวกมันเล็กลงและบ่อยขึ้นหรือไม่? อีกครั้งทำไม

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

ที่ชื่นชอบส่วนตัวของฉันแม้ว่ามันจะเป็นตัวชี้วัดที่โต๊ะเครื่องแป้งเป็นเวลาสำหรับการปรับใช้เล็กน้อย หากคุณพบสิ่งที่เล็กที่สุดเท่าที่จะเป็นไปได้การปรับใช้ทั้งไซต์ซ้ำไปซ้ำมา ... อาจเป็นพิมพ์ผิดในชื่อของ CEO ... คุณจะไปจากโทรศัพท์ที่ตื่นตกใจไปยังไซต์ที่ถูกปรับใช้ได้เร็วแค่ไหน? ฉันพูดว่า 'ความไร้สาระ' เพราะมันไม่ได้เป็นการคาดการณ์ที่เกินกว่าที่ตัวชี้วัดอื่น ๆ ข้างต้นพูดถึง แต่ทำให้ฉันรู้สึกดีเมื่อฉันชอบคุณค่า

หากเราเข้าสู่การตรวจสอบมีสิ่งต่าง ๆ มากมายที่เราสามารถติดตามได้ ... จากสิ่งที่ครอบคลุมเช่น 'ช่วงเวลา ' จนถึงระดับต่ำจริงๆเช่นเวลาที่ใช้สร้าง HTML แบบกำหนดเองในวงจรคำขอตอบกลับ ... แต่สิ่งเหล่านี้ไม่เฉพาะเจาะจงในการสร้างวัฒนธรรม DevOps

สิ่งเหล่านี้ไม่ผูกติดกับดอลลาร์โดยตรง ... การทำเช่นนั้นจะต้องการความรู้เพิ่มเติมเกี่ยวกับองค์กรของคุณมากกว่าที่ฉันสามารถเสนอในฟอรัมเช่นนี้ แต่พวกเขาคือกุญแจสำคัญในการเริ่มต้น BEGIN เพื่อตอบคำถามนั้น เมื่อคุณรู้ว่าคุณสามารถเผยแพร่ผลงานการผลิตเป็นประจำโดยไม่เกิดเหตุการณ์คุณสามารถเริ่มต้นดูว่าความพยายามที่คุณเคยสูญเสียมาก่อน ในขณะที่หนังสือ "เป้าหมาย" สอน (เกี่ยวกับการผลิตท่อ - มันมีความเกี่ยวข้อง) การปรับให้เหมาะสมในท้องถิ่นสามารถดูเหมือนว่าคุณกำลังประหยัดเงิน แต่ในที่สุดมันก็สร้างมูลค่าที่ผูกไว้กับสินค้าคงคลัง (คุณสมบัติที่ไม่ได้ปรับใช้)

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

กัปตันชัดเจน: ด้วยการลดเวลาในการทำตลาดและข้อผิดพลาดในการเผยแพร่

หากต้องการขยายสายการบินนี้ข้อผิดพลาดทั่วไปคือการเปลี่ยนแปลงองค์กรโดยไม่มีการอ้างอิงใด ๆ

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

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

การวัด ROI (เร็วแค่ไหนที่คุณครอบคลุมค่าใช้จ่ายในการฝึกอบรม) หมายความว่าคุณสามารถนำเสนอวิวัฒนาการในการวัดเหล่านั้นได้ดังนั้นก่อนที่จะทำการเปลี่ยนแปลงใด ๆ คุณจะต้องกำหนดตัวชี้วัดเหล่านั้น
เมื่อคุณมีวิวัฒนาการที่แท้จริงที่จะแสดงคุณสามารถบอกได้ว่าคุณได้ปรับปรุงบางอย่างในแบบที่ครอบคลุมค่าใช้จ่ายในการฝึกอบรมและมีผลกำไรมากขึ้นกว่าเมื่อก่อน

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

ผลผลิตอาจเป็นตัวชี้วัด แต่โดยทั่วไปการวัดนั้นยากมากที่จะทำตามวัตถุประสงค์และไม่ควรเป็นตัวชี้วัดชั้นหนึ่งสำหรับการศึกษาประเภทนี้

สายไปที่เกม แต่คิดว่าฉันจะพูดสอด

คุณไม่สามารถจัดการสิ่งที่คุณไม่ได้วัดดังนั้นสำหรับผู้เริ่มต้นนี่คือตัวชี้วัดหลักที่ทีมผู้ดูแลควรติดตามเพื่อตอบสนองเหตุการณ์:

• Uptime% : เวลาทั้งหมดที่มี = = [เวลาทั้งหมด - หยุดทำงาน] / [เวลาทั้งหมด]
• MTTR : เวลาเฉลี่ยในการแก้ไข = [หยุดทำงาน] / [# เหตุการณ์]
• MTTA : เวลาเฉลี่ยในการรับทราบ = [เวลาทั้งหมดในการรับทราบ] / [# ของเหตุการณ์]
• MTBF : เวลาเฉลี่ยระหว่างความล้มเหลว = [เวลาทั้งหมด - หยุดทำงาน] / [# ของเหตุการณ์]

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

ลองดูที่ไวท์บอร์ดอนิเมชั่นที่นี่เพื่อดูหัวข้อเชิงลึก

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