อะไรคือสัญญาณและสัญญาณทั่วไปของทีม DevOps ที่มีสัญญาณไม่เพียงพอ? คุณจะแสดงเหตุผล / อธิบายคำขอให้เพิ่มทีมใหม่ได้อย่างไร

ฉันชอบที่จะเก็บคำถามทั่วไป แต่นี่คือข้อมูลเพิ่มเติมบางส่วน:

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

มีสี่เหตุผลหลักที่ทำให้คุณรู้สึกว่าทีมของคุณไม่พอ:

1. องค์กรไม่ดีและการวางแผนการทำงาน
2. การทำงานคนอื่นควรทำ
3. ทำงานที่ไม่ควรทำเลย
4. ความเป็นจริงไม่เพียงพอ

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

ตรวจสอบงานสี่ประเภทที่กล่าวถึงในโครงการฟีนิกซ์:

1. โครงการธุรกิจ - สิ่งที่คุณทำเพื่อทีมอื่น ๆ ในองค์กร
2. โครงการภายใน - สิ่งที่คุณทำเพื่อทำให้งานของคุณง่ายขึ้นในอนาคต
3. การบำรุงรักษาตามกำหนดการ - สิ่งที่คุณต้องทำเพื่อให้ไฟติดสว่าง
4. การขัดจังหวะโดยไม่ได้วางแผน - สิ่งที่คุณทำเพราะมีบางอย่างผิดปกติ

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

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

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

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

มันง่ายสุด ๆ เพียงแค่ติดตามงานประจำวัน แต่ฉันเชื่อว่ามันสำคัญมาก (แม้แต่เดือนละครั้ง) เพื่อถอยกลับและประเมินสิ่งนี้

ฉันใช้หน้าหนึ่งจาก SRE Handbook กับหน้านี้ซึ่งฉันคิดว่ามีความเกี่ยวข้องมาก พิเศษ DevOps ไม่ได้หมายถึงการเติบโตในแนวนอนกับองค์กร แต่ถ้าคุณเห็นว่าสิ่งต่าง ๆ ไม่ได้เกิดขึ้นมันก็เป็นสัญญาณว่าคุณไม่ได้เสริมศักยภาพให้กับนักพัฒนาเพื่อการบริการตนเอง

ประเมินกระบวนการของคุณและดูว่าพวกเขาสอดคล้องกับหลักการ DevOps ที่ยอมรับกันอย่างไรและคุณปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรมได้ดีเพียงใด

ฉันคิดว่าทีมสองคนนี้กำลังทำโครงการและสร้างสิ่ง DevOps ที่นั่น (สร้างท่อ CI / CD สนับสนุน devs อื่น ๆ ที่สร้าง Dockerfiles หรือเทคโนโลยีที่คุณใช้อยู่) ในคำอื่น ๆ ประเภท 3, 4, 5 หรือ 6 ตามhttp://web.devopstopologies.com/

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

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

ในทั้งสองกรณีเหตุผลที่ลึกกว่าว่าทำไมการมี DevOps ในตอนแรกนั้นเป็นสิ่งที่ดี (สิ่งที่ดีทั่วไป) ควรจะชัดเจนสำหรับผู้บริหารระดับสูง หากคุณไม่สามารถนำข้อความนั้นไปใช้งานได้โปรดลดขนาดงานที่ทีมของคุณกำลังทำอยู่โดยขยับไปที่ Devs / Ops ปกติ (ตามที่ควรจะเป็นในกรณีใด ๆ )

ฉันอยู่ภายใต้ความประทับใจที่ DevSecOps เป็นความคิดไม่ใช่ทีม - ถ้าคุณมี "ทีม" Dev (Sec) Ops คุณกำลังทำผิด ... ร่วมกันและเรียกพวกเขาว่า "ทีม DevOps"

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

สิ่งนี้ไม่เกี่ยวข้องกับวิศวกร "devOps" ใด ๆ

การจัดกลุ่มของงาน

วิธีที่เราใช้ในอดีตในสถานการณ์ที่คล้ายกันคือการจัดระเบียบงานของทีมใน 4 กลุ่มงานหลักและจัดสรรเทียบเท่า 2 FTE (Full Time Equivalents) เพื่อ (ลอง) ทำงานให้สำเร็จ ในกรณีของเรามันเกี่ยวข้องกับการเรียกใช้ฝ่ายช่วยเหลือ SCM ในสภาพแวดล้อมเมนเฟรมโดยมีนักพัฒนาประมาณ 300 คนที่ขอความช่วยเหลือ / การแทรกแซงจาก 2 FTE เหล่านั้น กลุ่มของงานถูกจัดเรียงใน 4 ลำดับความสำคัญที่เป็นไปได้:

• ภารกิจของลำดับความสำคัญ 1 และ 2 จะต้องเสร็จสิ้น (ไม่สามารถแก้ตัว / เจรจาต่อรองได้)
• ลำดับความสำคัญ 3 งานจะต้องเสร็จ " เร็วที่สุดเท่าที่เวลาอนุญาต"
• ลำดับความสำคัญ 4 งานจะเสร็จสมบูรณ์ " ถ้าเวลาอนุญาต"

อ่านรายละเอียดเพิ่มเติมเกี่ยวกับประเภทของงานในแต่ละกลุ่มเหล่านั้น ...

คำอธิบายงาน

ลำดับความสำคัญ 1 - ดำเนินการช่วยเหลือ

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

ลำดับความสำคัญ 2 - ดูการปฏิบัติหน้าที่บริการ

• มีให้บริการตลอด 24 ชั่วโมง 7 วันต่อสัปดาห์
• สอดคล้องกับ SLA ที่กำหนดไว้ล่วงหน้า
• การรายงานการเรียกใช้หน้าที่เฝ้าดูทั้งหมด
• การยกระดับการจัดการในกรณีที่จำเป็น

ลำดับความสำคัญ 3 - การบำรุงรักษาตามปกติ

• การบริหาร
• แอพลิเคชันขึ้นเครื่อง
• การเรียน
• การปรับปรุงประสิทธิภาพ
• การจัดการพื้นที่
• การปรับการใช้ทรัพยากร
• แนะนำการปรับปรุงสำหรับการปรับแต่งเพื่อลดจำนวนการโทรฝ่ายช่วยเหลือและ / หรือดูการแทรกแซงการปฏิบัติหน้าที่

ลำดับความสำคัญ 4 - การแก้ไขและการปรับปรุง

• สร้างและบำรุงรักษาเอกสารผู้ใช้
• การทดสอบ QA ของการปรับแต่งใหม่
• พัฒนาและดำเนินการตามคำขอการปรับปรุง
• มีส่วนร่วมในการทดสอบ DRP

การประเมินผล

หากคุณกำลังใช้วิธีการตามที่อธิบายไว้ข้างต้นสิ่งต่าง ๆ อาจ (จะ!) เริ่มเกิดขึ้น:

• หากทีมไม่เข้าใจอาจใช้เวลาส่วนใหญ่ไปที่ภารกิจที่มีความสำคัญ 1 และ 2 ในขณะที่อาจต้องใช้เวลาสักครู่เพื่อให้ได้งานที่มีลำดับความสำคัญ 3 ... และงานที่มีลำดับความสำคัญ 4 อาจได้รับความอดอยาก งานเหล่านั้น)
• ยิ่งมีเวลา (กลายเป็น) สำหรับ " ลงทุน " ในลำดับความสำคัญ 4 งานยิ่งเวลาที่จำเป็นสำหรับลำดับความสำคัญ 1 และ 2 จะลดลงเพื่อให้เวลามากขึ้น (จากงบประมาณที่มีอยู่ของ 2 FTE) สามารถ "ลงทุนได้" "ในลำดับความสำคัญ 4 งาน
• คุณจะประหลาดใจเมื่อเห็นว่าหลังจากผ่านไประยะหนึ่งจำนวนของลำดับความสำคัญ 1 และ 2 จะลดลง และถ้าคุณรายงานเกี่ยวกับงานเหล่านั้นอย่างเพียงพอนั่นคือสิ่งที่ฝ่ายบริหารชอบที่จะได้ยิน ในกรณีของเราหมายเลขนั้นลดลงจากประมาณ 300 / เดือนไปต่ำกว่า 100 / เดือน ...
• หากอย่างไรก็ตาม 2 FTE นั้นดูเหมือนจะไม่มีเวลา (หรือแทบจะไม่) มีเวลาสำหรับงานที่มีลำดับความสำคัญ 4 คุณก็มีคำอธิบายและหลักฐานที่สมบูรณ์แบบสำหรับการจัดการของคุณ ... ซึ่งคุณไม่ได้ทำ