พูดตามตรงอีวานมักจะหัวเราะเยาะความพยายามอันไร้ประโยชน์ของเพื่อนร่วมงานของเขาจากแผนกติดตาม พวกเขาใช้ความพยายามอย่างยิ่งยวดในการปรับใช้ตัวชี้วัดที่ฝ่ายบริหารของบริษัทสั่งให้บรรลุ พวกเขายุ่งมากจนไม่อยากให้ใครทำอะไรอีก
แต่ยังไม่เพียงพอสำหรับฝ่ายบริหาร พวกเขาสั่งเมตริกใหม่ๆ มากขึ้นเรื่อยๆ และหยุดใช้สิ่งที่เคยทำก่อนหน้านี้อย่างรวดเร็วมาก
ช่วงนี้ใครๆ ก็พูดถึง LeadTime - เวลาในการนำเสนอฟีเจอร์ทางธุรกิจ ตัวชี้วัดแสดงตัวเลขที่บ้ามาก - 200 วันในการส่งมอบหนึ่งงาน ทุกคนฮือฮาและยกมือขึ้นฟ้า!
หลังจากนั้นสักพัก เสียงนั้นก็ค่อยๆ ลดลง และฝ่ายบริหารได้รับคำสั่งให้สร้างตัวชี้วัดใหม่
Ivan เป็นที่ชัดเจนอย่างยิ่งว่าหน่วยวัดใหม่ก็จะตายไปอย่างเงียบๆ ในมุมมืดเช่นกัน
อันที่จริง อีวานคิดว่าการรู้ตัวเลขไม่ได้บอกอะไรใครเลย 200 วันหรือ 2 วันไม่มีความแตกต่างเพราะไม่สามารถระบุเหตุผลด้วยตัวเลขและเข้าใจว่าดีหรือไม่ดี
นี่เป็นกับดักของตัวชี้วัดทั่วไป: ดูเหมือนว่าตัวชี้วัดใหม่จะบอกแก่นแท้ของการดำรงอยู่และอธิบายความลับบางอย่าง ทุกคนคาดหวังสิ่งนี้มาก แต่ด้วยเหตุผลบางอย่างไม่มีอะไรเกิดขึ้น ใช่ เพราะไม่ควรพบความลับในการวัด!
สำหรับอีวาน นี่เป็นช่วงที่ผ่านไปแล้ว เขาเข้าใจเรื่องนั้น สำหรับการวัดและต้องค้นหาความลับทั้งหมด , เช่น. คือว่าหน่วยเมตริกนี้ถูกสร้างขึ้น
สำหรับร้านค้าออนไลน์ เป้าหมายที่มีอิทธิพลคือลูกค้าที่นำเงินเข้ามา และสำหรับ DevOps จะเป็นทีมที่สร้างและเผยแพร่การจัดจำหน่ายโดยใช้ไปป์ไลน์
วันหนึ่ง ขณะที่นั่งอยู่บนเก้าอี้แสนสบายในห้องโถง Ivan ตัดสินใจคิดอย่างรอบคอบว่าเขาต้องการดูตัววัด DevOps อย่างไร โดยคำนึงถึงข้อเท็จจริงที่ว่าเป้าหมายของการมีอิทธิพลคือทีม
วัตถุประสงค์ของการวัด DevOps
เป็นที่ชัดเจนว่าใครๆ ก็ต้องการลดเวลาในการจัดส่ง แน่นอนว่า 200 วันนั้นไม่ดีเลย
แต่นั่นคือคำถามได้อย่างไร?
บริษัทจ้างทีมงานหลายร้อยทีม และมีการแจกจ่ายหลายพันทีมผ่านท่อส่ง DevOps ทุกวัน เวลาจัดส่งจริงจะปรากฏเป็นการกระจาย แต่ละทีมจะมีเวลาและลักษณะเฉพาะของตัวเอง คุณจะพบอะไรในระเบียบนี้ได้อย่างไร?
คำตอบเกิดขึ้นตามธรรมชาติ - เราจำเป็นต้องค้นหาทีมที่มีปัญหาและค้นหาว่าเกิดอะไรขึ้นกับพวกเขา และเหตุใดจึงใช้เวลานานมาก และเรียนรู้จากทีมที่ "ดี" ว่าจะทำทุกอย่างอย่างรวดเร็วได้อย่างไร และในการดำเนินการนี้ คุณจะต้องวัดเวลาที่ใช้โดยทีมในแต่ละจุดของ DevOps:
“จุดประสงค์ของระบบคือการเลือกทีมตามเวลาที่พวกเขาผ่านอัฒจันทร์ เช่น ด้วยเหตุนี้ เราควรได้รับรายการคำสั่งพร้อมเวลาที่เลือก ไม่ใช่ตัวเลข
ถ้าเราพบว่าใช้เวลาทั้งหมดบนอัฒจันทร์และใช้เวลาเท่าไรในการหยุดทำงานระหว่างอัฒจันทร์ เราจะสามารถค้นหาทีม โทรหาพวกเขา และเข้าใจเหตุผลโดยละเอียดยิ่งขึ้น และกำจัดพวกมันออกไป” อีวานคิด
วิธีการคำนวณเวลาจัดส่งสำหรับ DevOps
ในการคำนวณ จำเป็นต้องเจาะลึกกระบวนการ DevOps และสาระสำคัญของมัน
บริษัทใช้ระบบจำนวนจำกัด และสามารถรับข้อมูลจากระบบเหล่านี้เท่านั้นและไม่มีที่อื่นอีก
งานทั้งหมดในบริษัทจดทะเบียนไว้ที่จิระ เมื่องานถูกดำเนินการ สาขาจะถูกสร้างขึ้นสำหรับงานนั้น และหลังจากการใช้งานแล้ว จะมีการคอมมิตกับ BitBucket และ Pull Request เมื่อยอมรับ PR (คำขอดึง) การแจกจ่ายจะถูกสร้างขึ้นและจัดเก็บไว้ในที่เก็บ Nexus โดยอัตโนมัติ
ต่อไป มีการเผยแพร่การจัดจำหน่ายบนอัฒจันทร์หลายแห่งโดยใช้ Jenkins เพื่อตรวจสอบความถูกต้องของการเปิดตัว การทดสอบอัตโนมัติและด้วยตนเอง:
อีวานอธิบายว่าระบบใดที่สามารถใช้ข้อมูลใดในการคำนวณเวลาที่อัฒจันทร์:
- จาก Nexus – เวลาในการสร้างการแจกจ่ายและชื่อของโฟลเดอร์ที่มีรหัสคำสั่ง
- จาก Jenkins – เวลาเริ่มต้น ระยะเวลาและผลลัพธ์ของแต่ละงาน ชื่อย่อ (ในพารามิเตอร์งาน) ขั้นตอน (ขั้นตอนของงาน) ลิงก์ไปยังการแจกจ่ายใน Nexus
- Ivan ตัดสินใจที่จะไม่รวม Jira และ BitBucket ไว้ในไปป์ไลน์ เนื่องจาก... พวกเขาเกี่ยวข้องกับขั้นตอนการพัฒนามากกว่า และไม่กระจายการแจกจ่ายที่เสร็จแล้วบนอัฒจันทร์
จากข้อมูลที่มีอยู่ ไดอะแกรมต่อไปนี้ถูกวาดขึ้น:
เมื่อรู้ว่าต้องใช้เวลานานเท่าใดในการสร้างการแจกแจงและใช้เวลาเท่าไรกับแต่ละการแจกแจง คุณสามารถคำนวณต้นทุนรวมในการดำเนินการไปป์ไลน์ DevOps ทั้งหมด (เต็มรอบ) ได้อย่างง่ายดาย
นี่คือตัวชี้วัด DevOps ที่ Ivan ลงเอยด้วย:
- จำนวนการแจกแจงที่สร้างขึ้น
- ส่วนแบ่งการกระจายที่ “มา” ยืนและ “ผ่าน” ยืน
- เวลาที่ใช้บนขาตั้ง (รอบการยืน)
- เต็มรอบ (เวลารวมสำหรับทุกอัฒจันทร์)
- ระยะเวลางาน
- การหยุดทำงานระหว่างอัฒจันทร์
- การหยุดทำงานระหว่างการเปิดตัวงานบนแท่นเดียวกัน
ในด้านหนึ่ง ตัววัดกำหนดลักษณะของไปป์ไลน์ DevOps ได้ดีมากในแง่ของเวลา ในทางกลับกัน ถือว่าเรียบง่ายมาก
หลังจากพอใจกับงานที่ทำออกมาได้ดี อีวานจึงนำเสนอและนำเสนอต่อฝ่ายบริหาร
เขากลับมามืดมนและเอามือลง
“นี่คือความล้มเหลวครับพี่ชาย” เพื่อนร่วมงานที่น่าขันยิ้ม...
อ่านเพิ่มเติมในบทความ “'
ที่มา: will.com