คำถามติดแท็ก metrics

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

24 metrics  roi 

ในโครงการ Phoenixเมื่อหนึ่งในทัวร์ของโรงงานเราบอกว่าแต่ละเวิร์กสเตชันเป็นการรวมกันของบุคคลเครื่องจักรการวัดและกระบวนการ สิ่งนี้สมเหตุสมผลมากหลังจากเรามีผู้คนเซิร์ฟเวอร์ตัวชี้วัดและคำแนะนำ อย่างไรก็ตามเมื่อใดก็ตามที่ฉันสร้างแบบจำลองกระบวนการ (วงจรชีวิตของตั๋วสนับสนุนเป็นต้น) ฉันพยายามพิจารณาเรื่องนี้ โดยทั่วไปสถานะเวิร์กโฟลว์ของฉันรวมถึง: ความช่วยเหลือบรรทัดแรก ความช่วยเหลือด้านเทคนิค / Dev / ทีมเทคนิคเพิ่มเติม ตรวจสอบรหัส การทดสอบ เอือด การปรับใช้ ฉันสามารถวัดวัฏจักรรอบปริมาณงานและเวลาในคิวของแต่ละรัฐเหล่านี้ได้อย่างง่ายดาย แต่ฉันไม่รู้สึกว่านี่เป็นความยุติธรรมต่อแนวคิด Man, Machine, Method มันเป็นความคิดที่บอกใบ้อย่างน่าหงุดหงิดในหนังสือ แต่ไม่ได้ขยาย ... เรารู้ว่าเวลารอเป็นหน้าที่ของการใช้ประโยชน์ดังนั้นการตรวจสอบว่าผู้คนและเซิร์ฟเวอร์ไม่ว่าง (ทรัพยากร จำกัด ) มีความสำคัญอย่างไร มีกระบวนการที่กำหนดไว้สำหรับการขยายการวัดของฉันจากเครื่องสถานะ จำกัด อย่างง่ายไปยัง Man, Machine, Method, Process idea ในหนังสือหรือไม่

17 metrics  systems  the-phoenix-project 

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

13 culture  metrics  kpi 

ฉันพบคำนิยาม Firehose จากภาพรวมของเอกสาร Log Foundator System Cloud Foundry Firehose เป็นจุดปลาย WebSocket ที่ส่งข้อมูลเหตุการณ์ทั้งหมดที่มาจากการปรับใช้ Cloud Foundry สตรีมข้อมูลประกอบด้วยบันทึกเหตุการณ์ HTTP และเมตริกคอนเทนเนอร์จากแอปพลิเคชันทั้งหมดและตัวชี้วัดจากส่วนประกอบระบบ Cloud Foundry ทั้งหมด บันทึกจากองค์ประกอบของระบบเช่น Cloud Controller ไม่รวมอยู่ใน firehose และโดยทั่วไปจะเข้าถึงได้ผ่านการกำหนดค่า rsyslog เนื่องจากข้อมูลที่มาจาก Firehose อาจมีข้อมูลที่ละเอียดอ่อนเช่นข้อมูลลูกค้าในบันทึกของแอปพลิเคชันเฉพาะผู้ใช้ที่มีสิทธิ์ที่ถูกต้องเท่านั้นจึงสามารถเข้าถึง Firehose คำนี้มีรากฐานมาจากไหนและทำไมจึงเรียกว่าเป็นอย่างนั้น แนวคิดนี้เหมือนกันสำหรับข้อเสนอและแพลตฟอร์มคลาวด์อื่น ๆ หรือไม่? มันตลกเมื่อฉันแปลคำนี้เป็นภาษาของฉัน

10 monitoring  metrics  logging 

TL; DR คุณจะพิสูจน์ได้อย่างไรว่า devops โดยเฉพาะอย่างยิ่งการปรับใช้อัตโนมัติจะปรับปรุงอัตราความล้มเหลวในการเปลี่ยนแปลงได้อย่างไร เราทุกคนพยายามรวบรวมตัวชี้วัดใน 'ความล้มเหลวในการนำไปใช้งาน' โดยใช้วิธีการปัจจุบัน (ส่วนใหญ่เป็นคู่มือ) น่าเสียดายที่ 'ล้มเหลว' ไม่ค่อยเกิดขึ้นใช่ไหม เนื่องจากเมื่อมีบางอย่างผิดปกติทีมจะรวมตัวกัน (โดยทั่วไปจะมีฮีโร่) เพื่อแก้ไขปัญหา (โดยทั่วไปคือการอนุญาตการตั้งค่าที่ไม่ได้รับ ดังนั้น ... เมื่อเราถามว่าการปรับใช้เป็นอย่างไรคำตอบคือ "ใช้ได้" แต่เรารู้โดยสัญชาตญาณว่าไม่ดี รายงานสถานะ devops ประจำปี 2560 ระบุว่ามีอัตราการเปลี่ยนแปลงความล้มเหลว 31-45% ในขณะที่ฟังดูมีเหตุผลอย่างถูกต้องพวกเขาจะถูกติดตามเป็นเหตุการณ์หรือไม่ Nah เพราะพวกเขาได้รับการแก้ไขอย่างรวดเร็วโดยปกติในระหว่างการตรวจสอบ เป็นการยากยิ่งกว่าที่จะย้อนกลับการปรับใช้จริง ดังนั้นจึงต้องใช้วินัยในการรายงานอัตราความล้มเหลวอย่างแม่นยำ เราไม่อยากให้รายงานแบบนั้นเพราะเราต้องการให้สิ่งต่าง ๆ ทำงานและเราทำสิ่งที่จะทำให้มันเกิดขึ้น ดังนั้นคุณจะพิสูจน์ได้อย่างไรว่า devops โดยเฉพาะอย่างยิ่งการปรับใช้อัตโนมัติจะปรับปรุงอัตราความผิดพลาดที่เปลี่ยนแปลง (PS พยายามติดแท็กด้วย "# devops-Ability-model")

9 metrics