(เวลาไปตลาด).
แม้กระทั่งวันหยุดสุดสัปดาห์ เขาก็คิดถึงการวัด: “แล้วถ้าฉันวัดเวลาล่ะ? มันจะให้อะไรฉัน?
แท้จริงแล้วความรู้เรื่องเวลาจะให้อะไร? สมมติว่าการจัดส่งใช้เวลา 5 วัน แล้วจะเป็นอย่างไรต่อไป? มันดีหรือไม่ดี? แม้ว่านี่จะแย่ แต่คุณก็ต้องลดเวลานี้ลง แต่อย่างไร?
ความคิดเหล่านี้หลอกหลอนเขา แต่ไม่มีวิธีแก้ปัญหาเกิดขึ้น
อีวานเข้าใจว่าเขามาถึงแก่นแท้แล้ว กราฟตัวชี้วัดจำนวนนับไม่ถ้วนที่เขาเคยเห็นมาก่อนทำให้เขาเชื่อมั่นมานานแล้วว่าแนวทางมาตรฐานจะไม่ได้ผล และหากเขาเพียงแค่วางแผน () จะไม่มีประโยชน์อะไร
จะเป็นอย่างไร?…
หน่วยเมตริกก็เหมือนกับไม้บรรทัดไม้ธรรมดา การวัดที่ทำด้วยความช่วยเหลือจะไม่บอกเหตุผล ทำไม วัตถุที่กำลังวัดคือความยาวที่เธอแสดงอย่างแน่นอน ไม้บรรทัดจะแสดงขนาดของมันและไม่มีอะไรเพิ่มเติม เธอไม่ใช่ศิลาของปราชญ์ แต่เป็นเพียงกระดานไม้ที่ใช้วัด
“หนูเหล็กสแตนเลส” ของนักเขียนคนโปรดของเขา แฮร์รี่ แฮร์ริสัน พูดเสมอว่า ความคิดจะต้องไปถึงก้นบึ้งของสมองและนอนอยู่ที่นั่น ดังนั้น หลังจากทนทุกข์ทรมานอยู่หลายวันแต่ก็ไม่เกิดประโยชน์ใดๆ อีวานจึงตัดสินใจทำภารกิจอื่น...
สองสามวันต่อมา ขณะอ่านบทความเกี่ยวกับร้านค้าออนไลน์ ทันใดนั้น Ivan ก็ตระหนักได้ว่าจำนวนเงินที่ร้านค้าออนไลน์ได้รับนั้นขึ้นอยู่กับพฤติกรรมของผู้เข้าชมเว็บไซต์ พวกเขา ผู้เยี่ยมชม/ลูกค้า เป็นผู้ให้เงินแก่ร้านค้าและเป็นแหล่งที่มาของร้านค้า ผลกำไรที่ร้านค้าได้รับจะขึ้นอยู่กับการเปลี่ยนแปลงพฤติกรรมของลูกค้า ไม่ใช่สิ่งอื่นใด
ปรากฎว่าในการเปลี่ยนค่าที่วัดได้จำเป็นต้องมีอิทธิพลต่อผู้ที่สร้างค่านี้เช่น ในการเปลี่ยนแปลงจำนวนเงินของร้านค้าออนไลน์จำเป็นต้องมีอิทธิพลต่อพฤติกรรมของลูกค้าของร้านค้านี้และในการเปลี่ยนแปลงเวลาจัดส่งใน DevOps จำเป็นต้องมีอิทธิพลต่อทีมที่ "สร้าง" ในครั้งนี้เช่น ใช้ DevOps ในการทำงาน
Ivan ตระหนักดีว่าการวัด DevOps ไม่ควรแสดงด้วยกราฟเลย พวกเขาจะต้องเป็นตัวแทนตนเอง เครื่องมือค้นหา ทีมที่ “โดดเด่น” ที่กำหนดเวลาในการส่งมอบขั้นสุดท้าย
ไม่มีหน่วยวัดใดที่จะแสดงเหตุผลว่าทำไมทีมนี้หรือทีมนั้นจึงใช้เวลานานในการส่งมอบการแจกจ่าย Ivan คิด เพราะในความเป็นจริงอาจมีรถเข็นคันเล็กจำนวนหนึ่งล้านคัน และพวกเขาอาจไม่ใช่ด้านเทคนิค แต่เป็นองค์กร เหล่านั้น. สิ่งที่คุณคาดหวังได้มากที่สุดจากการวัดคือการแสดงทีมและผลลัพธ์ของพวกเขา จากนั้นคุณยังคงต้องติดตามทีมเหล่านี้ด้วยเท้าของคุณและค้นหาว่ามีอะไรผิดปกติกับพวกเขา
ในทางกลับกัน บริษัทของ Ivan มีมาตรฐานที่กำหนดให้ทุกทีมทดสอบการประกอบบนม้านั่งหลายตัว ทีมไม่สามารถย้ายไปยังอัฒจันทร์ถัดไปได้จนกว่าอัฒจันทร์ก่อนหน้าจะเสร็จสมบูรณ์ ปรากฎว่าถ้าเราจินตนาการว่ากระบวนการ DevOps เป็นลำดับของการผ่านอัฒจันทร์ ตัวชี้วัดก็สามารถแสดงเวลาที่ทีมใช้บนอัฒจันทร์เหล่านี้ได้ เมื่อทราบจุดยืนและเวลาของทีมแล้ว จึงเป็นไปได้ที่จะพูดคุยกับพวกเขาเกี่ยวกับเหตุผลอย่างเจาะจงมากขึ้น
โดยไม่ลังเล Ivan หยิบโทรศัพท์ขึ้นมาและกดหมายเลขของบุคคลที่รอบรู้เกี่ยวกับ DevOps:
— เดนิส โปรดบอกฉันหน่อยว่าเป็นไปได้ไหมที่จะเข้าใจว่าทีมผ่านจุดยืนนี้หรือจุดนั้นแล้ว?
- แน่นอน. Jenkins ของเราจะทิ้งธงหากโครงสร้างได้สำเร็จ (ผ่านการทดสอบ) บนม้านั่งสำรอง
- สุด ๆ ธงคืออะไร?
- นี่คือไฟล์ข้อความปกติเช่น "stand_OK" หรือ "stand_FAIL" ซึ่งระบุว่าชุดประกอบผ่านหรือไม่ผ่านการทดสอบ คุณก็เข้าใจใช่ไหม?
- ฉันคิดว่าใช่ มีการเขียนลงในโฟลเดอร์เดียวกันในพื้นที่เก็บข้อมูลที่มีชุดประกอบอยู่หรือไม่
- ใช่
— จะเกิดอะไรขึ้นหากชุดประกอบไม่ผ่านแท่นทดสอบ? ฉันจะต้องสร้างใหม่หรือไม่?
- ใช่
- อืม โอเค ขอบใจนะ และอีกคำถามคือ เข้าใจถูกต้องหรือไม่ว่าสามารถใช้วันที่สร้างธงเป็นวันที่ยืนได้?
- อย่างแน่นอน!
- สุด!
ด้วยแรงบันดาลใจ อีวานจึงวางสายและตระหนักว่าทุกอย่างเข้าที่แล้ว เมื่อทราบวันที่สร้างไฟล์บิลด์และวันที่สร้างแฟล็ก จึงสามารถคำนวณจนถึงวินาทีที่ทีมใช้เวลาในแต่ละอัฒจันทร์และทำความเข้าใจว่าพวกเขาใช้เวลามากที่สุดที่ไหน
“การทำความเข้าใจว่าใช้เวลาส่วนใหญ่ไปที่ไหน เราจะระบุทีม ไปหาพวกเขา และเจาะลึกปัญหา” อีวานยิ้ม
สำหรับวันพรุ่งนี้ เขามอบหมายงานให้ตัวเองร่างสถาปัตยกรรมของระบบที่กำลังวาด
จะยังคง ...
ที่มา: will.com