ตัวชี้วัด DORA และสุขภาพของ CI/CD

ยินดีต้อนรับสู่เมตริก DORA! ในการพัฒนาซอฟต์แวร์สมัยใหม่ การนำโค้ดไปใช้งานเพียงอย่างเดียวไม่เพียงพอ เราจำเป็นต้องเข้าใจว่ากระบวนการพัฒนาและการปฏิบัติการของเราทำงานได้ดีเพียงใด

เมตริก DORA มอบกรอบการทำงานที่ทรงพลังสำหรับวัดและปรับปรุงความสมบูรณ์ของ CI/CD และประสิทธิภาพ DevOps โดยรวม

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

• ความถี่ในการนำไปใช้งาน (DF)
• ระยะเวลารอคอยสำหรับการเปลี่ยนแปลง (LTFC)
• เวลาเฉลี่ยในการกู้คืน (MTTR)
• อัตราความล้มเหลวของการเปลี่ยนแปลง (CFR)

มาดูรายละเอียดของแต่ละรายการกัน

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

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

หากต้องการติดตามความถี่ในการนำไปใช้งาน เพียงนับจำนวนครั้งที่นำไปใช้งานจริงได้สำเร็จในช่วงเวลาที่กำหนด (เช่น รายวัน รายสัปดาห์ หรือรายเดือน)

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

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

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

LTFC เริ่มต้นเมื่อผู้พัฒนาคอมมิตโค้ด และสิ้นสุดเมื่อผู้ใช้สามารถใช้งานโค้ดนั้นได้จริง โดยมักวัดเป็นชั่วโมงหรือวัน

• ตัวอย่าง: ฟีเจอร์ที่คอมมิตในเช้าวันจันทร์และใช้งานจริงได้ภายในเย็นวันอังคาร มี LTFC ประมาณ 36 ชั่วโมง
• เป้าหมาย: ลดเวลานี้ ระยะเวลารอคอยที่สั้นลงหมายถึงการส่งมอบที่เร็วขึ้นและการปรับปรุงซ้ำที่รวดเร็วขึ้น

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

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

MTTR คำนวณตั้งแต่ตรวจพบเหตุขัดข้องจนกู้คืนบริการได้อย่างสมบูรณ์ โดยทั่วไปวัดเป็นนาทีหรือชั่วโมง

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

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

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

CFR คำนวณโดยนำจำนวนการนำไปใช้งานที่ล้มเหลวหารด้วยจำนวนการนำไปใช้งานทั้งหมดในช่วงเวลาหนึ่ง แล้วคูณด้วย 100

• ตัวอย่าง: หากจากการนำไปใช้งาน 100 ครั้ง มี 5 ครั้งทำให้เกิดเหตุขัดข้องในสภาพแวดล้อมจริง CFR ของคุณคือ 5%
• เป้าหมาย: รักษาจำนวนนี้ให้ต่ำที่สุด ทีมที่มีประสิทธิภาพระดับสูงมักมี CFR ต่ำกว่า 15%

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

ยินดีด้วยครับ/ค่ะ! คุณได้เรียนรู้เกี่ยวกับเมตริก DORA ทั้งสี่รายการแล้ว:

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

การติดตามเมตริกเหล่านี้ช่วยให้คุณเข้าใจสถานะ CI/CD ได้อย่างลึกซึ้ง และผลักดันการปรับปรุงอย่างต่อเนื่องในแนวทางปฏิบัติด้าน DevOps ของคุณ