สถานะของ DevOps ในรัสเซีย 2020

คุณจะเข้าใจสถานะของบางสิ่งบางอย่างได้อย่างไร?

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

แต่วันนั้นมาถึงเมื่อมีการศึกษาเช่นนี้และวันนี้เราจะเล่าให้คุณฟังเกี่ยวกับผลลัพธ์ที่ได้รับ สถานะของ DevOps ในรัสเซียได้รับการศึกษาร่วมกันโดยบริษัทต่างๆ "ด่วน 42"และ"ออนติโก" บริษัท Express 42 ช่วยให้บริษัทเทคโนโลยีนำไปใช้และพัฒนาแนวทางปฏิบัติและเครื่องมือ DevOps และเป็นหนึ่งในบริษัทแรกๆ ที่พูดคุยเกี่ยวกับ DevOps ในรัสเซีย ผู้เขียนงานวิจัย Igor Kurochkin และ Vitaly Khabarov มีส่วนร่วมในการวิเคราะห์และให้คำปรึกษาที่ Express 42 โดยมีพื้นฐานทางเทคนิคจากการดำเนินงานและประสบการณ์ในบริษัทต่างๆ ตลอดระยะเวลา 8 ปีที่ผ่านมา เพื่อนร่วมงานพิจารณาบริษัทและโครงการต่างๆ มากมาย ตั้งแต่สตาร์ทอัพไปจนถึงองค์กรขนาดใหญ่ ที่มีปัญหาที่แตกต่างกัน รวมถึงวุฒิภาวะทางวัฒนธรรมและวิศวกรรมที่แตกต่างกัน

ในรายงานของพวกเขา Igor และ Vitaly อธิบายว่ามีปัญหาอะไรบ้างในระหว่างกระบวนการวิจัย วิธีแก้ไขปัญหา ตลอดจนวิธีดำเนินการวิจัย DevOps ในหลักการ และเหตุใด Express 42 จึงตัดสินใจดำเนินการด้วยตนเอง คุณสามารถดูรายงานของพวกเขาได้ ที่นี่.

การวิจัย DevOps

Igor Kurochkin เริ่มการสนทนา

เราถามผู้ฟังในการประชุม DevOps เป็นประจำว่า “คุณได้อ่านรายงาน State of DevOps ปีนี้หรือยัง” มีเพียงไม่กี่คนเท่านั้นที่ยกมือขึ้น แต่การวิจัยของเราแสดงให้เห็นว่ามีเพียงหนึ่งในสามเท่านั้นที่ศึกษาพวกเขา หากคุณไม่เคยเห็นรายงานดังกล่าวมาก่อน สมมติว่าทั้งหมดคล้ายกันมาก ส่วนใหญ่มักจะมีวลีเช่น: “เมื่อเทียบกับปีที่แล้ว...”

ที่นี่เรามีปัญหาแรกของเรา ตามมาด้วยอีกสองปัญหา:

1. เราไม่มีข้อมูลสำหรับปีที่แล้ว ไม่มีใครสนใจสถานะของ DevOps ในรัสเซีย
2. ระเบียบวิธี ยังไม่ชัดเจนว่าจะทดสอบสมมติฐานอย่างไร สร้างคำถามอย่างไร ดำเนินการวิเคราะห์ เปรียบเทียบผลลัพธ์ ค้นหาความเชื่อมโยงอย่างไร
3. คำศัพท์เฉพาะทาง รายงานทั้งหมดเป็นภาษาอังกฤษ จำเป็นต้องมีการแปล กรอบงานทั่วไปสำหรับ DevOps ยังไม่ได้รับการคิดค้น และทุกคนก็คิดขึ้นมาเอง

มาดูกันว่าโดยทั่วไปแล้วการวิเคราะห์สถานะของ DevOps ในโลกนั้นดำเนินการอย่างไร

ข้อมูลทางประวัติศาสตร์

การวิจัย DevOps ดำเนินการมาตั้งแต่ปี 2011 คนแรกที่ดำเนินการคือ Puppet ผู้พัฒนาระบบการจัดการการกำหนดค่า ในเวลานั้นมันเป็นหนึ่งในเครื่องมือหลักในการอธิบายโครงสร้างพื้นฐานในรูปแบบของโค้ด จนถึงปี 2013 การศึกษาเหล่านี้เป็นเพียงการสำรวจในรูปแบบปิดและไม่มีการรายงานต่อสาธารณะ

ในปี 2013 IT Revolution ได้ปรากฏตัวขึ้น โดยเป็นผู้จัดพิมพ์หนังสือหลักๆ ทั้งหมดเกี่ยวกับ DevOps พวกเขาร่วมกับ Puppet เพื่อเตรียมสิ่งพิมพ์เรื่อง “State of DevOps” ฉบับแรก ซึ่งมีเมตริกหลัก 4 รายการปรากฏขึ้นเป็นครั้งแรก ในปีต่อมา บริษัทที่ปรึกษา ThoughtWorks ซึ่งเป็นที่รู้จักในด้านเรดาร์เทคโนโลยีเกี่ยวกับแนวทางปฏิบัติและเครื่องมือในอุตสาหกรรมได้เข้ามามีส่วนร่วม และในปี 2015 ได้มีการเพิ่มส่วนที่มีระเบียบวิธี และทำให้ชัดเจนว่าพวกเขาดำเนินการวิเคราะห์อย่างไร

ในปี 2016 ผู้เขียนงานวิจัยนี้ได้ก่อตั้งบริษัท DORA (DevOps Research and Assessment) ขึ้น ซึ่งตีพิมพ์รายงานประจำปี ในปีต่อมา DORA และ Puppet ได้ออกรายงานร่วมกันครั้งสุดท้าย

แล้วเรื่องก็น่าสนใจ:

ในปี 2018 บริษัทต่างๆ ได้แยกทางกันและมีการเผยแพร่รายงานอิสระ 2019 ฉบับ โดยฉบับหนึ่งมาจาก Puppet และฉบับที่สองจาก DORA ด้วยความร่วมมือกับ Google DORA ยังคงใช้วิธีการของตนกับตัวชี้วัดหลัก โปรไฟล์ประสิทธิภาพ และแนวปฏิบัติทางวิศวกรรมที่ส่งผลกระทบต่อตัวชี้วัดหลักและประสิทธิภาพทั่วทั้งบริษัท และ Puppet ได้เสนอแนวทางพร้อมคำอธิบายกระบวนการและวิวัฒนาการของ DevOps แต่เรื่องราวไม่เข้าใจ ในปี XNUMX Puppet ละทิ้งวิธีการนี้และเผยแพร่รายงานเวอร์ชันใหม่โดยระบุแนวทางปฏิบัติหลักและผลกระทบต่อ DevOps จากมุมมองของพวกเขาอย่างไร แล้วอีกอย่างหนึ่งก็เกิดขึ้น: Google ซื้อ DORA และพวกเขาก็ร่วมกันเผยแพร่รายงานอีกฉบับหนึ่ง บางทีคุณอาจเคยเห็นมัน

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

แต่ยังไม่มีประกาศจาก DORA และ Google ในเดือนพฤษภาคม เมื่อการสำรวจมักจะเริ่มต้นขึ้น มีข้อมูลมาว่า Nicole Forsgren หนึ่งในผู้ก่อตั้ง DORA ได้ย้ายไปที่บริษัทอื่น ดังนั้นเราจึงสันนิษฐานว่าในปีนี้คงไม่มีการวิจัยหรือรายงานจาก DORA

สถานการณ์ในรัสเซียเป็นอย่างไรบ้าง?

เรายังไม่ได้ทำการวิจัยใดๆ เกี่ยวกับ DevOps เราได้พูดคุยในการประชุมเพื่อเล่าข้อสรุปของผู้อื่น และ Raiffeisenbank ได้แปล "สถานะของ DevOps" ประจำปี 2019 (คุณสามารถดูประกาศของพวกเขาได้ใน Habré) ขอขอบคุณพวกเขามาก และนั่นคือทั้งหมด

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

กระบวนการวิจัย

รายงานเป็นเพียงส่วนสุดท้ายเท่านั้น กระบวนการวิจัยทั้งหมดประกอบด้วยสี่ขั้นตอนใหญ่:

ในระหว่างขั้นตอนการเตรียมการ เราได้สัมภาษณ์ผู้เชี่ยวชาญในอุตสาหกรรมและเตรียมรายการสมมติฐาน จากข้อมูลดังกล่าว เราได้รวบรวมคำถามและเปิดตัวแบบสำรวจตลอดเดือนสิงหาคม จากนั้นเราก็วิเคราะห์และจัดทำรายงานเอง สำหรับ DORA กระบวนการนี้ใช้เวลา 6 เดือน เราดำเนินการเสร็จสิ้นภายใน 3 เดือน และตอนนี้เราเข้าใจแล้วว่าเราแทบไม่มีเวลาเพียงพอ เพียงแค่ทำการวิเคราะห์เท่านั้นที่ทำให้คุณเข้าใจคำถามที่ต้องถาม

เข้าร่วม

รายงานจากต่างประเทศทั้งหมดจะเริ่มต้นด้วยรูปถ่ายของผู้เข้าร่วม และส่วนใหญ่ไม่ได้มาจากรัสเซีย เปอร์เซ็นต์ของผู้ตอบแบบสอบถามชาวรัสเซียผันผวนจาก 5 เป็น 1% ทุกปี และสิ่งนี้ทำให้เราไม่สามารถสรุปผลได้

แผนที่จากรายงาน Accelerate State of DevOps 2019:

ในการศึกษาของเรา เราสามารถสัมภาษณ์ผู้คนได้ 889 คน ซึ่งถือว่าค่อนข้างมาก (ในรายงานของ DORA สำรวจผู้คนประมาณพันคนต่อปี) และที่นี่เราก็บรรลุเป้าหมาย:

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

อุตสาหกรรมและตำแหน่ง

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

ทุกวินาทีทำงานในบริษัทขนาดกลาง บุคคลที่สามทุกคนทำงานในบริษัทขนาดใหญ่ ส่วนใหญ่ทำงานเป็นทีมไม่เกิน 9 คน เราถามแยกกันเกี่ยวกับกิจกรรมหลักและส่วนใหญ่เกี่ยวข้องกับการดำเนินงานไม่ทางใดก็ทางหนึ่งและประมาณ 40% เกี่ยวข้องกับการพัฒนา:

นี่คือวิธีที่เรารวบรวมข้อมูลเพื่อการเปรียบเทียบและวิเคราะห์ตัวแทนจากอุตสาหกรรม บริษัท และทีมงานต่างๆ Vitaly Khabarov เพื่อนร่วมงานของฉันจะบอกคุณเกี่ยวกับการวิเคราะห์

การวิเคราะห์และการเปรียบเทียบ

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

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

ตัวชี้วัดที่สำคัญ

เราใช้วิธี DORA เป็นพื้นฐาน ซึ่งอธิบายไว้โดยละเอียดในหนังสือ “Accelerate State of DevOps” เราตรวจสอบว่าตัวชี้วัดหลักนั้นเหมาะสมกับตลาดรัสเซียหรือไม่ สามารถนำมาใช้ในลักษณะเดียวกับที่ DORA ใช้เพื่อตอบคำถาม: “อุตสาหกรรมในรัสเซียสอดคล้องกับอุตสาหกรรมต่างประเทศอย่างไร”

ตัวชี้วัดที่สำคัญ:

1. ความถี่ในการใช้งาน แอปพลิเคชันเวอร์ชันใหม่ถูกปรับใช้กับสภาพแวดล้อมการใช้งานจริงบ่อยแค่ไหน (การเปลี่ยนแปลงที่วางแผนไว้ ไม่รวมโปรแกรมแก้ไขด่วนและการตอบสนองต่อเหตุการณ์)
2. เวลาจัดส่ง. เวลาเฉลี่ยระหว่างการดำเนินการเปลี่ยนแปลง (การเขียนฟังก์ชันการทำงานเป็นโค้ด) และการปรับใช้การเปลี่ยนแปลงกับสภาพแวดล้อมการใช้งานจริงคือเท่าใด
3. เวลาการกู้คืน. ใช้เวลานานเท่าใดโดยเฉลี่ยในการกู้คืนแอปพลิเคชันในสภาพแวดล้อมการใช้งานจริงหลังจากเหตุการณ์ ความเสื่อมของบริการ หรือการตรวจจับข้อผิดพลาดที่ส่งผลกระทบต่อผู้ใช้แอปพลิเคชัน
4. การเปลี่ยนแปลงที่ไม่สำเร็จ เปอร์เซ็นต์ของการปรับใช้ในสภาพแวดล้อมของผลิตภัณฑ์ที่นำไปสู่ความเสื่อมของแอปพลิเคชันหรือเหตุการณ์ และจำเป็นต้องกำจัดผลกระทบที่ตามมา (การย้อนกลับการเปลี่ยนแปลง การพัฒนาโปรแกรมแก้ไขด่วนหรือแพตช์)

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

แต่เพื่อให้แน่ใจว่าตัวชี้วัดหลักทั้งสี่สามารถมีอิทธิพลต่อบางสิ่งบางอย่างได้ คุณต้องเข้าใจก่อนว่าตัวชี้วัดเหล่านั้นมีความเกี่ยวข้องกันหรือไม่ DORA ตอบว่าใช่ โดยมีข้อแม้ประการหนึ่ง นั่นคือ ความสัมพันธ์ระหว่างอัตราความล้มเหลวในการเปลี่ยนแปลงกับตัวชี้วัดอีกสามตัวนั้นอ่อนกว่าเล็กน้อย เราก็ได้ภาพเดียวกัน หากเวลาในการจัดส่ง ความถี่ในการใช้งาน และเวลาฟื้นตัวมีความสัมพันธ์กัน (เราสร้างความสัมพันธ์นี้ผ่านความสัมพันธ์แบบ Pearson และผ่านระดับ Chaddock) แสดงว่าไม่มีความสัมพันธ์ที่แข็งแกร่งดังกล่าวกับการเปลี่ยนแปลงที่ไม่ประสบผลสำเร็จ

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

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

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

เท่าไหร่ที่จะแขวนในกรัม?

เราใช้การวิเคราะห์คลัสเตอร์แบบลำดับชั้น:

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

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

แต่มีปัญหาที่ซ่อนอยู่ที่นี่: เราไม่มีข้อ จำกัด เกี่ยวกับจำนวนคลัสเตอร์ - เราสามารถรับ 2, 3, 4, 10 คลัสเตอร์ และแนวคิดแรกคือ - ทำไมไม่แบ่งผู้ตอบแบบสอบถามของเราทั้งหมดออกเป็น 4 กลุ่มเหมือนที่ DORA ทำ แต่เราพบว่าความแตกต่างระหว่างกลุ่มเหล่านี้ไม่มีนัยสำคัญ และเราไม่สามารถแน่ใจได้ว่าผู้ถูกกล่าวหาอยู่ในกลุ่มของเขาจริงๆ ไม่ใช่ของกลุ่มใกล้เคียง เรายังไม่สามารถแบ่งตลาดรัสเซียออกเป็นสี่กลุ่มได้ ดังนั้นเราจึงตัดสินในสามโปรไฟล์ ซึ่งมีความแตกต่างที่มีนัยสำคัญทางสถิติ:

ต่อไป เรากำหนดโปรไฟล์ตามคลัสเตอร์: เรานำค่ามัธยฐานสำหรับแต่ละตัวชี้วัดสำหรับแต่ละกลุ่ม และรวบรวมตารางโปรไฟล์ประสิทธิภาพ อันที่จริง ได้รับโปรไฟล์ผลการปฏิบัติงานสำหรับผู้เข้าร่วมโดยเฉลี่ยในแต่ละกลุ่ม เราได้ระบุโปรไฟล์ประสิทธิภาพสามแบบ: ต่ำ ปานกลาง สูง:

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

แล้วคำถามก็เกิดขึ้น: จะใช้ทั้งหมดนี้ได้อย่างไร?

วิธีใช้

หากเรานำทีมใดทีมหนึ่งซึ่งมี 4 ตัวชี้วัดหลักมาประยุกต์ใช้กับตาราง ในกรณี 85% เราจะไม่ได้การแข่งขันแบบสมบูรณ์ - นี่เป็นเพียงผู้เข้าร่วมโดยเฉลี่ย ไม่ใช่สิ่งที่อยู่ในความเป็นจริง เราทุกคน (และทุกทีม) แตกต่างกันเล็กน้อย

เราตรวจสอบแล้ว: เรานำผู้ตอบแบบสอบถามและโปรไฟล์ประสิทธิภาพของ DORA ของเรา และดูว่ามีผู้ตอบแบบสอบถามกี่คนที่ตรงกับโปรไฟล์หนึ่งหรือโปรไฟล์อื่น เราพบว่ามีเพียง 16% ของผู้ตอบแบบสอบถามเท่านั้นที่ตกอยู่ในโปรไฟล์ใดโปรไฟล์หนึ่งอย่างแม่นยำ ที่เหลือทั้งหมดกระจัดกระจายอยู่ที่ไหนสักแห่งระหว่าง:

ซึ่งหมายความว่าโปรไฟล์ประสิทธิภาพมีขอบเขตที่จำกัด หากต้องการทราบตำแหน่งคร่าวๆ เป็นครั้งแรก คุณสามารถใช้ตารางนี้: “โอ้ ดูเหมือนว่าเราเข้าใกล้ระดับปานกลางหรือสูงแล้ว!” หากคุณเข้าใจว่าคุณกำลังจะไปไหนต่อไปนั่นอาจจะเพียงพอแล้ว แต่หากเป้าหมายของคุณคือการปรับปรุงอย่างต่อเนื่องและต่อเนื่อง และคุณต้องการทราบอย่างแม่นยำมากขึ้นว่าจะพัฒนาตรงไหนและต้องทำอะไร ก็จำเป็นต้องมีเงินทุนเพิ่มเติม เราเรียกพวกมันว่าเครื่องคิดเลข:

• เครื่องคิดเลขดอร่า
• เครื่องคิดเลข Express 42* (อยู่ระหว่างการพัฒนา)
• การพัฒนาของคุณเอง (คุณสามารถสร้างเครื่องคิดเลขภายในของคุณเองได้)

พวกเขาต้องการอะไร? เข้าใจไหม:

• ทีมงานภายในองค์กรของเราเป็นไปตามมาตรฐานของเราหรือไม่?
• ถ้าไม่ เราสามารถช่วยเธอได้หรือไม่ - เร่งดำเนินการภายในกรอบความเชี่ยวชาญที่บริษัทของเรามี
• ถ้าเป็นเช่นนั้น เราจะทำได้ดีกว่านี้อีกไหม?

คุณยังสามารถใช้เพื่อรวบรวมสถิติภายในบริษัท:

• เรามีทีมประเภทไหน?
• แบ่งทีมออกเป็นโปรไฟล์
• ดู: โอ้ ทีมเหล่านี้มีประสิทธิภาพต่ำกว่า (ช้านิดหน่อย) แต่ทีมเหล่านี้ยอดเยี่ยมมาก พวกเขาปรับใช้ทุกวันโดยไม่มีข้อผิดพลาด ระยะเวลารอคอยสินค้าน้อยกว่าหนึ่งชั่วโมง

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

หรือถ้าคุณเข้าใจว่าคุณรู้สึกดีกับบริษัท และเก่งกว่าหลายๆ คน คุณก็สามารถมองให้กว้างขึ้นอีกหน่อยได้ นี่คืออุตสาหกรรมของรัสเซียอย่างชัดเจน: เราจะรับความเชี่ยวชาญที่จำเป็นในอุตสาหกรรมรัสเซียเพื่อเร่งตัวเองได้หรือไม่? เครื่องคิดเลข Express 42 จะช่วยได้ที่นี่ (อยู่ระหว่างการพัฒนา) หากคุณโตเกินตลาดรัสเซียแล้วลองดูสิ เครื่องคิดเลขดอร่า และสู่ตลาดโลก

ดี. และถ้าคุณอยู่ในกลุ่ม Elit ตามเครื่องคิดเลข DORA แล้วคุณจะทำอย่างไร? ไม่มีวิธีแก้ปัญหาที่ดีที่นี่ เป็นไปได้มากว่าคุณจะอยู่ในระดับแนวหน้าของอุตสาหกรรม และการปรับปรุงการเร่งความเร็วและความน่าเชื่อถือเพิ่มเติมสามารถทำได้ผ่านการวิจัยและพัฒนาภายในและการใช้จ่ายทรัพยากรขนาดใหญ่

เรามาดูส่วนที่หอมหวานที่สุดกันดีกว่า - การเปรียบเทียบ

การเปรียบเทียบ

ในตอนแรกเราต้องการเปรียบเทียบอุตสาหกรรมของรัสเซียกับอุตสาหกรรมตะวันตก ถ้าเราเปรียบเทียบโดยตรง เราจะเห็นว่าเรามีโปรไฟล์น้อยกว่า และพวกมันปะปนกันมากกว่าเล็กน้อย ขอบเขตจะเบลอมากขึ้นเล็กน้อย:

นักแสดงชั้นนำของเราซ่อนตัวอยู่ในหมู่นักแสดงที่มีประสิทธิภาพสูง แต่พวกเขาอยู่ที่นั่น - เหล่านี้คือยูนิคอร์นระดับหัวกะทิที่ก้าวไปสู่จุดสูงสุดที่สำคัญ ในรัสเซียความแตกต่างระหว่างโปรไฟล์ Elite และ High ยังมีนัยสำคัญไม่เพียงพอ เราคิดว่าในอนาคตแผนกนี้จะเกิดขึ้นเนื่องจากวัฒนธรรมทางวิศวกรรมที่เพิ่มขึ้น คุณภาพการดำเนินงานด้านวิศวกรรม และความเชี่ยวชาญภายในบริษัทต่างๆ

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

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

• สินค้าใหม่ออกบ่อยขึ้น 1,5-2 เท่า
• เพิ่มความน่าเชื่อถือและ/หรือประสิทธิภาพของโครงสร้างพื้นฐานแอปพลิเคชันบ่อยขึ้น 2 เท่า

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

มีอะไรอีกบ้างที่ช่วยทีมของเรา?

การปฏิบัติงานด้านวิศวกรรม

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

แพลตฟอร์มเป็นบริการ

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

โครงสร้างพื้นฐานเป็นรหัส

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

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

บูรณาการและการส่งมอบ

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

สถาปัตยกรรม

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

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

เราค้นพบทั้งหมดนี้ได้อย่างไร?

เรามีแผนอันทะเยอทะยานที่จะจำลองวิธีการ DORA อย่างสมบูรณ์ แต่ยังขาดทรัพยากร หาก DORA ใช้การสนับสนุนจำนวนมากและการศึกษาใช้เวลาหกเดือน เราก็จะดำเนินการศึกษาของเราในเวลาอันสั้น เราต้องการสร้างโมเดล DevOps เหมือนที่ DORA ทำ และเราจะทำเช่นนั้นในอนาคต สำหรับตอนนี้ เราจำกัดตัวเองอยู่แค่แผนที่ความร้อน:

เราพิจารณาการกระจายแนวทางปฏิบัติด้านวิศวกรรมระหว่างทีมในแต่ละโปรไฟล์ และพบว่าโดยเฉลี่ยแล้วทีมที่มีโปรไฟล์สูงจะใช้แนวทางปฏิบัติด้านวิศวกรรมบ่อยกว่า คุณสามารถอ่านเพิ่มเติมเกี่ยวกับทั้งหมดนี้ได้ในของเรา รายงาน.

เพื่อการเปลี่ยนแปลง เรามาเปลี่ยนจากสถิติที่ซับซ้อนไปเป็นสถิติง่ายๆ กันดีกว่า

เราค้นพบอะไรอีกบ้าง?

เครื่องมือ

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

ในบรรดาผู้เรียบเรียง Kubernetes เป็นผู้นำนั้นไม่มีความลับ (52%) ผู้จัดลำดับถัดไปคือ Docker Swarm (ประมาณ 12%) ระบบ CI ที่ได้รับความนิยมมากที่สุดคือ Jenkins และ GitLab ระบบการจัดการการกำหนดค่าที่ได้รับความนิยมมากที่สุดคือ Ansible ตามมาด้วย Shell อันเป็นที่รักของเรา

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

ฉันยกพื้นให้อิกอร์ซึ่งจะให้สถิติเพิ่มเติม

การแพร่กระจายของการปฏิบัติ

Igor Kurochkin: นอกจากนี้ เราขอให้ผู้ตอบแบบสอบถามระบุว่าแนวทางปฏิบัติด้านวิศวกรรมที่ได้รับการพิจารณานั้นถูกเผยแพร่ในบริษัทอย่างไร บริษัทส่วนใหญ่มีแนวทางแบบผสมผสานซึ่งประกอบด้วยชุดรูปแบบที่แตกต่างกัน และโครงการนำร่องก็ได้รับความนิยมอย่างมาก เรายังเห็นความแตกต่างเล็กน้อยระหว่างโปรไฟล์อีกด้วย ตัวแทนระดับสูงมักจะใช้รูปแบบ “ความคิดริเริ่มจากด้านล่าง” เมื่อทีมผู้เชี่ยวชาญกลุ่มเล็กๆ เปลี่ยนกระบวนการทำงาน เครื่องมือ และแบ่งปันการพัฒนาที่ประสบความสำเร็จกับทีมอื่นๆ ที่ Medium นี่เป็นโครงการริเริ่มจากบนลงล่างที่เข้าถึงทั้งบริษัทผ่านการสร้างชุมชนและศูนย์ความเป็นเลิศ:

Agile และ DevOps

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

โทโพโลยีของทีม

เมื่อปลายปีที่แล้ว หนังสือ “โทโพโลยีของทีม"ซึ่งเสนอกรอบการทำงานสำหรับการอธิบายโทโพโลยีของทีม เราสงสัยว่าสิ่งนี้จะนำไปใช้กับบริษัทรัสเซียหรือไม่ และเราถามคำถามว่า “คุณเห็นรูปแบบอะไรบ้าง”

ผู้ตอบแบบสอบถามครึ่งหนึ่งมีทีมโครงสร้างพื้นฐาน เช่นเดียวกับทีมพัฒนา ทดสอบ และปฏิบัติการแยกกัน ทีม DevOps แต่ละทีมสังเกตเห็น 45% ซึ่งในจำนวนนี้ตัวแทนระดับสูงนั้นพบได้ทั่วไปมากกว่า ถัดมาเป็นทีมข้ามสายงาน ซึ่งพบได้บ่อยในระดับสูงเช่นกัน คำสั่ง SRE แยกจะปรากฏในโปรไฟล์สูง ปานกลาง และไม่ค่อยพบในโปรไฟล์ต่ำ:

อัตราส่วน DevQaOps

เราเห็นคำถามนี้บน FaceBook จากหัวหน้าทีมของทีมแพลตฟอร์ม Skyeng เขาสนใจอัตราส่วนของนักพัฒนา ผู้ทดสอบ และผู้ดูแลระบบในบริษัทต่างๆ เราถามและดูคำตอบโดยคำนึงถึงโปรไฟล์: ตัวแทนของโปรไฟล์ High มีวิศวกรทดสอบและปฏิบัติการจำนวนน้อยกว่าสำหรับนักพัฒนาแต่ละคน:

วางแผนสำหรับ 2021 ปี

ในแผนงานในปีหน้า ผู้ตอบแบบสอบถามตั้งข้อสังเกตถึงกิจกรรมต่อไปนี้:

คุณจะเห็นจุดตัดกับการประชุม DevOps Live 2020 ที่นี่ เราได้ตรวจสอบโปรแกรมอย่างรอบคอบแล้ว:

• โครงสร้างพื้นฐานเป็นผลิตภัณฑ์
• การเปลี่ยนแปลง DevOps
• การเผยแพร่แนวปฏิบัติ DevOps
• DevSecOps
• ชมรมกรณีและการอภิปราย

แต่คำปราศรัยของเราจะไม่มีเวลามากพอที่จะครอบคลุมหัวข้อทั้งหมด เบื้องหลัง:

• แพลตฟอร์มเป็นบริการและเป็นผลิตภัณฑ์
• โครงสร้างพื้นฐาน เช่น โค้ด สภาพแวดล้อม และคลาวด์
• การบูรณาการและการส่งมอบอย่างต่อเนื่อง
• สถาปัตยกรรม;
• รูปแบบ DevSecOps;
• แพลตฟอร์มและทีมงานข้ามสายงาน

รายงาน ของเรามีขนาดใหญ่ มีความยาว 50 หน้า และคุณสามารถดูรายละเอียดเพิ่มเติมได้

ข้อสรุปถึง

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

ผลการศึกษาสถานะ DevOps ครั้งแรกในรัสเซีย:

• ตัวชี้วัดที่สำคัญ เราพบว่าตัวชี้วัดที่สำคัญ (เวลาการส่งมอบ อัตราการปรับใช้ เวลาการกู้คืน และความล้มเหลวในการเปลี่ยนแปลง) มีความเหมาะสมสำหรับการวิเคราะห์ประสิทธิภาพของกระบวนการพัฒนา การทดสอบ และการดำเนินงาน
• โปรไฟล์สูง ปานกลาง ต่ำ จากข้อมูลที่รวบรวมไว้ สามารถระบุกลุ่มที่แตกต่างกันทางสถิติได้: สูง ปานกลาง ต่ำ โดยมีคุณสมบัติที่โดดเด่นตามตัวชี้วัด แนวทางปฏิบัติ กระบวนการ และเครื่องมือ ตัวแทนระดับสูงแสดงผลลัพธ์ได้ดีกว่าต่ำ พวกเขามีแนวโน้มที่จะบรรลุและเกินเป้าหมายมากขึ้น
• ตัวชี้วัด การระบาดใหญ่ และแผนงานปี 2021 ตัวบ่งชี้พิเศษในปีนี้คือวิธีที่บริษัทต่างๆ รับมือกับการแพร่ระบาด High ทำงานได้ดีกว่า มีกิจกรรมผู้ใช้เพิ่มขึ้น และเหตุผลหลักที่ทำให้เกิดความสำเร็จคือกระบวนการพัฒนาที่มีประสิทธิภาพและวัฒนธรรมทางวิศวกรรมที่แข็งแกร่ง
• แนวทางปฏิบัติ DevOps เครื่องมือ และการพัฒนา แผนหลักของบริษัทในปีหน้า ได้แก่ การพัฒนาแนวทางปฏิบัติและเครื่องมือ DevOps การแนะนำแนวทางปฏิบัติ DevSecOps และการเปลี่ยนแปลงโครงสร้างองค์กร และการดำเนินการและการพัฒนาแนวทางปฏิบัติ DevOps อย่างมีประสิทธิผลนั้นดำเนินการผ่านโครงการนำร่อง การจัดตั้งชุมชนและศูนย์ความสามารถ โครงการริเริ่มในระดับบนและล่างของบริษัท

เรายินดีที่จะรับฟังคำวิจารณ์ เรื่องราว และข้อเสนอแนะของคุณ เราขอขอบคุณทุกคนที่เข้าร่วมในการศึกษานี้ และหวังว่าจะเข้าร่วมในปีหน้า

ที่มา: will.com