ฉันจะโน้มน้าวให้ผู้พัฒนาในทีมของฉันยอมรับ“ คุณสร้างมันขึ้นมาได้หรือไม่”

ฉันจะโน้มน้าวให้ผู้พัฒนาในทีมของฉันยอมรับว่า "คุณสร้างมันขึ้นมาได้หรือไม่" โดยที่ฉันมีคำพูดนี้จาก Werner Vogelsในใจ:

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

ฉันกำลังคิดถึงชุดนักพัฒนาซอฟต์แวร์ที่:

• ได้รับการว่าจ้างให้เป็นนักพัฒนาบทบาทโดยไม่มีการกล่าวถึงงานที่เกี่ยวข้องกับ ops
• ตามเนื้อผ้ามี "โยนรหัสข้ามกำแพง" ให้กับทีม ops
• ตามเนื้อผ้ามีตารางการทำงาน 9-5 และเป็นปฏิปักษ์ต่อความคิดของ "หน้าที่วิทยุติดตามตัว" การมีส่วนร่วมในการกู้คืนความเสียหายการเขียนโพสต์ชันสูตร ฯลฯโดยเฉพาะนอกเวลาทำการปกติ (หมายเหตุ: ฉันมีปัญหาที่เกิดขึ้นไม่บ่อยนักในเรื่องนี้เท่านั้นฉันไม่ได้เสนอให้เราเพิ่มการสนับสนุนลูกค้านอกเวลางานให้กับปริมาณงานของทีมนี้)
• ปัจจุบันไม่รับผิดชอบในการเขียน / สนับสนุนการตรวจสอบหรือการแจ้งเตือนเกี่ยวกับการใช้งานของพวกเขา

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

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

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

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

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

ก่อนอื่นเริ่มต้นด้วยการแนะนำงานใหม่หนึ่งหรือสองงานเท่านั้นที่จะดำเนินการในช่วงเวลาทำการปกติ พวกเขาจำเป็นต้องเรียนรู้วิธีการทำ devops ซึ่งอาจเป็นกระบวนการเรียนรู้สำหรับ dev (ถึงจุดนี้) ที่เป็นโค้ดเท่านั้นและอาจต้องมีการควบคุมดูแล พวกเขายังมีแนวโน้มที่จะเป็นศัตรูกับความคิดในการเปลี่ยนสมดุลชีวิตการทำงานของพวกเขาเนื่องจากคุณพูดถึงพวกเขาเคยชินกับ 9-5 ณ จุดนี้บันทึกข้อมูลเกี่ยวกับกระบวนการใหม่เพื่อใช้ในภายหลัง (ให้พวกเขาเขียนรหัสนี้ข้อมูลมีประโยชน์เสมอ)

ต่อมาเมื่อคุณไม่มีภารกิจ devops-y ใหม่ที่จะแนะนำ (ดังนั้นกระสุนที่หนึ่ง, ที่สอง, และที่สี่ใกล้จะเสร็จสมบูรณ์) ให้นำงานแรกที่คุณแนะนำมาเป็นผู้สมัครเพื่อทำงานนอกเวลางานมาตรฐาน . คุณอาจเห็นว่ามีฟันเฟืองบ้างและคุณอาจเห็นการขัดสีบางอย่างขึ้นอยู่กับว่าคุณทำแบบนี้มากแค่ไหนและวัฒนธรรมที่จบลงด้วยการทำงานห้าอย่างฝังแน่นแค่ไหน เพื่อปกป้องสิ่งนี้หวังว่าข้อมูลของคุณจะสนับสนุนความคิดที่ว่าการทำงานนอกเวลามาตรฐานจะเป็นของหายากเกิดขึ้นในสถานการณ์ที่รุนแรงและจะเป็นประโยชน์อย่างมากต่อทั้งธุรกิจและลูกค้า หากข้อมูลของคุณไม่รองรับสิ่งนี้แสดงว่าคุณพร้อมที่จะรับมือกับผลที่ตามมาของตัวเลือกนี้

แม้จะมีข้อมูล แต่ก็ยังง่ายกว่าที่นักพัฒนาจะเขียนรหัสการตรวจสอบ / การแจ้งเตือน (ดังนั้นพวกเขาจึงกลายเป็นdev ops แต่ยังคงเป็น dev ส่วนใหญ่) และทำให้ทีม ops สำรองเป็นแนวหน้า (เหมือนที่คนอื่นแนะนำ) อย่างที่ฉันพูดการเปลี่ยนแปลงเล็กน้อยมีความสำคัญเพื่อหลีกเลี่ยงการย้อน การรวมงานสำหรับผู้พัฒนาเกินเวลามาตรฐานจะเป็นเรื่องที่ท้าทายเพราะพวกเขาอาจรู้ว่าพวกเขาสามารถหางานทำที่อื่นได้หากพวกเขาไม่ชอบงานนี้เนื่องจากตลาดสำหรับนักพัฒนานั้นแข็งแกร่งในขณะนี้โดยเฉพาะอย่างยิ่งหากพวกเขามีทักษะ Caveat emptor!

การมองออกไปข้างนอกของ DevOps โดยเฉพาะถ้าคุณกำลังพูดถึงสภาพแวดล้อมขององค์กรขนาดใหญ่ (ish) วิธีการSAFeมีวิธีที่ดีพอสมควรในการส่งเสริมพฤติกรรมเช่นนี้

เป็นหลักมันเดือดลงไปในไม่กี่ขั้นตอนสำคัญ:

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

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

• ฉันมักจะเห็นรถไฟวิ่งเพิ่มขึ้นเป็นครั้งแรกของพวกเขาเป็น 100% โครงการ / ทีมเปลี่ยนเพิ่มขึ้นครั้งที่สองพวกเขาจัดสรรร้อยละของเวลาในการทำงาน การจัดการที่เพิ่มขึ้นลำดับที่ 3 ตระหนักว่าพวกเขากำลังมีปัญหาและเริ่มเพิ่มทีมเพื่อลองและจัดการ Run ล้นเพื่อให้นักพัฒนาและวิศวกรที่มีประสบการณ์ในขณะนี้เพื่อทำงานตามข้อกำหนดใหม่

• หากยอดคงเหลือถูกต้องของทีมงานโครงการที่สามารถส่งมอบผลลัพธ์ของโครงการโดยไม่ต้องจมอยู่กับงานบำรุงรักษามากและทีมใหม่ที่เข้าร่วมรถไฟไม่คาดว่าจะเป็นทีมสนับสนุน 100% ทันที แต่แทนที่จะเข้าร่วม ส่วนที่ยุติธรรมของงานการเปลี่ยนแปลงที่จะได้รับการจัดการจากนั้นคุณก็จบลงด้วยทีมจัดส่งที่เป็นเจ้าของผลิตภัณฑ์ที่พวกเขากำลังสร้างตามค่าเริ่มต้นไม่จำเป็นต้องมาที่พวกเขาทั้งหมดทันทีที่ตอนนี้พวกเขาเป็นทีม Run แทนที่จะรวมเข้ากับกิจกรรมประจำวันของพวกเขาอย่างช้าๆ

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

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

IMHO You build it, you run itไม่ควรดำเนินการอย่างแท้จริง เพื่อเริ่มต้น - มันเกือบจะฟังดูเหมือนเป็นการลงโทษ;)

ไม่มีคนเพียงคนเดียวหรือแม้กระทั่งทีมงานของนักพัฒนาซอฟต์แวร์ขนาดเล็กสามารถมีเหตุผลสนับสนุนเครื่องมือหรือชุดเครื่องมือที่ใช้ในกระบวนการพัฒนาซอฟต์แวร์ (เช่นในการผลิต!) สำหรับระยะเวลานาน เคยไปทำแบบนั้น :)

หน้าที่สนับสนุนมีแนวโน้มที่จะขยายตัวเมื่อฐานลูกค้าของเครื่องมือ (ชุด) เติบโตขึ้น ถ้าสมมติว่าหน้าที่เหล่านั้นโดยเฉพาะทีมพัฒนาสามารถลงเอยด้วยการสนับสนุนเป็นส่วนใหญ่โดยไม่มีเวลาเหลือพอสำหรับการพัฒนา Dead-end อย่างมีประสิทธิภาพ - มีนักพัฒนากี่คนที่ต้องการติดอยู่ในสภาพแวดล้อมเช่นนี้?

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

แน่นอนว่าทีมสนับสนุนบรรทัดที่ 1 จะเป็นทางเลือกให้กับทีมนักพัฒนาซอฟต์แวร์ (อีกครั้งคือทีมไม่ใช่คนเดียว!) สำหรับปัญหาที่ไม่สามารถครอบคลุมได้โดยตรง ใช่มันอาจจะยากในตอนแรก แต่ทุกอย่างจะดีขึ้น มันควรจะเป็นความร่วมมือ - นั่นเป็นส่วนหนึ่งของ DevOps

ในที่สุดนี้ขึ้นอยู่กับขนาดและโครงสร้างของ บริษัท มีสามขั้นตอนที่ บริษัท ของคุณสามารถทำได้:

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

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

3. องค์กรขนาดใหญ่ที่มีหน่วยธุรกิจหลายแห่ง (ซึ่งแต่ละแห่งมีทีมปฏิบัติการของตัวเอง): ในขั้นตอนนี้คุณสามารถย้อนกลับไปสู่รูปแบบของอเมซอนที่ทุกทีมจำเป็นต้องพัฒนาและดำเนินการบริการของตนเอง หน่วยธุรกิจแต่ละหน่วยจะต้องมีขนาดเล็กพอที่ทุกคนจะรู้จักกันดังนั้นภายใต้วิศวกรประมาณ 150 คนและคุณดำเนินธุรกิจโดยเริ่มแรก Amazon มีบริการ AWS แต่ละอย่างที่ทำงานแยกกันไม่มากก็น้อย

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

สิ่งที่ฉันทำในเรื่องนี้ (ถ้าฉันต้องเผชิญกับบัญญัติเช่นนั้นหรืออะไรก็ตามที่คุณเรียกว่า) จะเป็นแบบ " What else would you expect?!?!" เพราะโดยไม่ตั้งใจ:

• ฉันจะไม่สามารถอยู่ได้โดยปราศจากมันและ
• ฉันชอบกินอาหาร (สุนัข) ของตัวเอง

ให้ฉันอธิบายเพิ่มเติมเล็กน้อย ...

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

• ฉันแทบจะไม่บันทึกสิ่งที่ฉันทำเพื่อให้ระบบทำงานต่อไป หากมีคำถามใด ๆ ถามฉันเพียงสอบถามระบบ (และสอนลูกค้าเกี่ยวกับวิธีสอบถามระบบโดยไม่ช่วยฉัน)
• ถ้าฉันถูกเรียกตัวใน X เดือน / ปี (เพื่ออัพเกรดเป็นรีลีสใหม่?) ฉันต้องการรู้ (จำ) สิ่งที่ "ฉัน" ได้ทำมาก่อน (และสิ่งเดียวที่ฉันไว้วางใจคือสิ่งที่ระบบบอกฉันอาคา เตือนฉันเกี่ยวกับ)
• ฉันต้องถามลูกค้าเพียงครั้งเดียวเกี่ยวกับวิธีการทำสิ่งที่เฉพาะเจาะจงในไซต์ของพวกเขา (แบบแผนการตั้งชื่อนั้นยากที่จะจำได้) หรือเพื่อโน้มน้าวให้พวกเขาอนุญาตให้ใช้สิทธิ์ที่จำเป็นสำหรับ "ระบบ" (ไม่ใช่กับฉัน ... )
• คุณกำลังcontinuouslyทดสอบระบบคุณภาพของคุณเอง ... ในการผลิต โอกาสที่คุณจะพบข้อผิดพลาดข้อผิดพลาดเชิงตรรกะหรือคุณสมบัติที่ขาดหายไป และสิ่งเหล่านี้เป็นแรงบันดาลใจอย่างมากที่จะได้รับการแก้ไขโดยเร็ว ... เช่นเพื่อให้มีประสิทธิผลมากขึ้น
• ... และหากคุณต้องการฉันสามารถเพิ่มเหตุผลอีกหลายสิบ ...

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

• คุณต้องการให้ทุกคนเข้าร่วมปาร์ตี้ (ใช้ระบบ) เพราะมีเพียง 1 "ข้อยกเว้น" (aka ผู้จัดการ / เจ้าของ บริษัท หรือไม่) อาจทำลายพรรค (คุณคิดว่าคุณสามารถเชื่อถือระบบของคุณได้ แต่บางคนทำอะไรบางอย่าง โดยไม่ต้องขอ / ใช้ระบบ) กรณีเหล่านี้อาจทำให้คุณเสียเวลาในการค้นหา ...
• ผู้ใช้รายใหม่อาจบ่นว่าการใช้ระบบ (ใหม่) นี้จะทำให้พวกเขาใช้เวลานานขึ้นในการทำงานให้เสร็จ (เทียบกับสิ่งที่เคยใช้มาก่อน) และทุกที่ที่เหมาะสมพวกเขาจะใช้เป็นข้ออ้างว่าทำไมพวกเขาถึงทำงานสายจนเสร็จ ณ จุดนี้คุณควรมีผู้บริหารระดับสูงที่ครอบคลุมคุณเพราะมิฉะนั้นโครงการ / ระบบของคุณอาจได้รับการตำหนิ
• ตรวจสอบให้แน่ใจว่าคุณรู้ระบบของคุณเองและวิธีกำหนดค่าให้เหมาะสมกับความต้องการของคุณ เป็นตัวอย่าง (ในกรณีของฉัน): คุณต้องการกำหนดค่าระบบเพื่อให้คุณใช้สภาพแวดล้อมการดำเนินงานเพื่อส่งมอบให้กับสภาพแวดล้อมการทดลองของคุณและไม่ใช่วิธีอื่น ๆ ... ฉันเคยเห็นสิ่งที่เกิดขึ้นในอดีต ... การใช้ (เหยียดหยาม) ระบบทดสอบเพื่อส่งไปยังสภาพแวดล้อมที่ปลอดภัยสูง