โครงสร้างพื้นฐานเป็นรหัส: วิธีแก้ไขปัญหาโดยใช้ XP

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

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

เราเป็นใคร เราอยู่ที่ไหน และมีปัญหาอะไรบ้าง

ขณะนี้เราอยู่ในทีม Sre Onboarding ซึ่งประกอบด้วยโปรแกรมเมอร์หกคนและวิศวกรโครงสร้างพื้นฐานสามคน เราทุกคนพยายามเขียนโครงสร้างพื้นฐานเป็นโค้ด (IaC) เราทำเช่นนี้เพราะโดยพื้นฐานแล้วเรารู้วิธีเขียนโค้ดและมีประวัติของการเป็นนักพัฒนาที่ “สูงกว่าค่าเฉลี่ย”

• เรามีข้อได้เปรียบหลายประการ: ภูมิหลังบางอย่าง, ความรู้ด้านการปฏิบัติ, ความสามารถในการเขียนโค้ด, ความปรารถนาที่จะเรียนรู้สิ่งใหม่ ๆ
• และยังมีส่วนที่หย่อนคล้อยซึ่งเป็นข้อเสียด้วย: การขาดความรู้เกี่ยวกับฮาร์ดแวร์โครงสร้างพื้นฐาน

กลุ่มเทคโนโลยีที่เราใช้ใน IaC ของเรา

• Terraform สำหรับการสร้างทรัพยากร
• Packer สำหรับประกอบภาพ นี่คืออิมเมจ Windows, CentOS 7
• Jsonnet เพื่อสร้างบิลด์ที่ทรงพลังใน drone.io รวมถึงสร้าง packer json และโมดูล Terraform ของเรา
• สีฟ้า
• สามารถแก้ไขได้เมื่อเตรียมภาพ
• Python สำหรับบริการเสริมและการจัดเตรียมสคริปต์
• และทั้งหมดนี้อยู่ใน VSCode พร้อมปลั๊กอินที่แชร์ระหว่างสมาชิกในทีม

บทสรุปจากผม. บทความสุดท้าย เป็นเช่นนี้: ฉันพยายามปลูกฝังการมองโลกในแง่ดี (ก่อนอื่นเลยในตัวฉันเอง) ฉันอยากจะบอกว่าเราจะลองใช้แนวทางและแนวปฏิบัติที่เรารู้จักเพื่อจัดการกับความยากลำบากและความซับซ้อนที่มีอยู่ในพื้นที่นี้

ขณะนี้เรากำลังดิ้นรนกับปัญหา IaC ต่อไปนี้:

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

Extreme Programming (XP) เพื่อช่วยเหลือ

นักพัฒนาทุกคนคุ้นเคยกับ Extreme Programming (XP) และแนวทางปฏิบัติที่อยู่เบื้องหลัง พวกเราหลายคนเคยใช้แนวทางนี้และประสบความสำเร็จ แล้วทำไมไม่ใช้หลักการและแนวปฏิบัติที่วางไว้เพื่อเอาชนะความท้าทายด้านโครงสร้างพื้นฐานล่ะ เราตัดสินใจใช้แนวทางนี้และดูว่าเกิดอะไรขึ้น

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

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

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

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

มาดูแนวทางปฏิบัติ XP บางประการและผลกระทบที่มีต่อความเร็วและคุณภาพของความคิดเห็นกัน

หลักการวนคำติชม XP

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

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

ในกรณีของ IaC ความคิดเห็นช่วยเราได้ ฉันจะปรับแผนภาพด้านบนเล็กน้อยทันที: แผนการเผยแพร่ไม่มีรอบเดือน แต่เกิดขึ้นหลายครั้งต่อวัน มีแนวทางปฏิบัติบางประการที่เกี่ยวข้องกับวัฏจักรระบบปฏิบัติการนี้ซึ่งเราจะดูรายละเอียดเพิ่มเติม

สิ่งสำคัญ: ความคิดเห็นสามารถแก้ปัญหาทั้งหมดที่ระบุไว้ข้างต้นได้ เมื่อรวมกับแนวทางปฏิบัติ XP มันสามารถดึงคุณออกจากนรกแห่งความสิ้นหวังได้

วิธีดึงตัวเองออกจากห้วงแห่งความสิ้นหวัง: แนวทางปฏิบัติ XNUMX ประการ

การทดสอบ

มีการกล่าวถึงการทดสอบสองครั้งในลูปผลตอบรับ XP มันไม่ใช่แค่แบบนั้น สิ่งเหล่านี้มีความสำคัญอย่างยิ่งสำหรับเทคนิค Extreme Programming ทั้งหมด

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

มีปิระมิดการทดสอบแบบคลาสสิกซึ่งแสดงให้เห็นว่าควรมีการทดสอบเพิ่มเติม

กรอบการทำงานนี้นำไปใช้กับเราในโครงการ IaC ได้อย่างไร จริงๆแล้ว... ไม่ใช่เลย

• การทดสอบหน่วยแม้ว่าจะควรมีจำนวนมาก แต่ก็ไม่สามารถมีมากเกินไปได้ หรือพวกเขากำลังทดสอบบางสิ่งทางอ้อมมาก จริงๆ แล้ว เราสามารถพูดได้ว่าเราไม่ได้เขียนมันเลย แต่นี่คือแอปพลิเคชันบางส่วนสำหรับการทดสอบที่เราสามารถทำได้:
  1. ทดสอบโค้ด jsonnet ตัวอย่างเช่น นี่คือไปป์ไลน์การประกอบโดรนของเรา ซึ่งค่อนข้างซับซ้อน รหัส jsonnet ได้รับการคุ้มครองอย่างดีจากการทดสอบ
     เราใช้สิ่งนี้ กรอบการทดสอบหน่วยสำหรับ Jsonnet.
  2. ทดสอบสคริปต์ที่ดำเนินการเมื่อทรัพยากรเริ่มทำงาน สคริปต์เขียนด้วยภาษา Python ดังนั้นจึงสามารถเขียนการทดสอบลงไปได้
• อาจเป็นไปได้ที่จะตรวจสอบการกำหนดค่าในการทดสอบ แต่เราไม่ทำเช่นนั้น นอกจากนี้ยังสามารถกำหนดค่าการตรวจสอบกฎการกำหนดค่าทรัพยากรผ่านทาง ฟลินท์. อย่างไรก็ตาม การตรวจสอบมีพื้นฐานเกินไปสำหรับ Terraform แต่มีสคริปต์ทดสอบจำนวนมากที่เขียนขึ้นสำหรับ AWS และเราอยู่บน Azure ดังนั้นจึงใช้ไม่ได้อีกครั้ง
• การทดสอบการรวมส่วนประกอบ: ขึ้นอยู่กับวิธีการจำแนกประเภทและตำแหน่งที่คุณจัดวาง แต่โดยทั่วไปแล้วพวกมันใช้งานได้

  นี่คือลักษณะของการทดสอบการรวมระบบ

  
  
  นี่คือตัวอย่างเมื่อสร้างภาพใน Drone CI ในการเข้าถึงพวกเขา คุณต้องรอ 30 นาทีเพื่อให้อิมเมจ Packer ก่อตัว จากนั้นรออีก 15 นาทีเพื่อให้รูปภาพผ่านไป แต่พวกเขามีอยู่จริง!

  อัลกอริธึมการตรวจสอบรูปภาพ

  1. Packer ต้องเตรียมอิมเมจให้ครบถ้วนก่อน
  2. ถัดจากการทดสอบจะมีรูปแบบพื้นผิวที่มีสถานะท้องถิ่น ซึ่งเราใช้ในการปรับใช้อิมเมจนี้
  3. เมื่อกางออก จะใช้โมดูลขนาดเล็กที่วางอยู่ใกล้ๆ เพื่อให้ทำงานกับรูปภาพได้ง่ายขึ้น
  4. เมื่อปรับใช้ VM จากอิมเมจแล้ว การตรวจสอบก็สามารถเริ่มต้นได้ โดยทั่วไปการตรวจสอบจะดำเนินการโดยรถยนต์ ตรวจสอบวิธีการทำงานของสคริปต์เมื่อเริ่มต้นและวิธีการทำงานของ daemons ในการดำเนินการนี้ ผ่าน ssh หรือ winrm เราจะลงชื่อเข้าใช้เครื่องที่เพิ่งยกขึ้นมาใหม่ และตรวจสอบสถานะการกำหนดค่าหรือบริการพร้อมใช้งานหรือไม่

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

  
  
  ข้อเสนอแนะเกี่ยวกับไปป์ไลน์ใช้เวลาประมาณ 40 นาที ทุกอย่างเกิดขึ้นเป็นเวลานานมาก สามารถใช้สำหรับการถดถอยได้ แต่สำหรับการพัฒนาใหม่ โดยทั่วไปแล้วจะไม่สมจริง หากคุณพร้อมมากสำหรับสิ่งนี้ ให้เตรียมสคริปต์ที่กำลังทำงานอยู่ จากนั้นคุณสามารถลดเวลาลงเหลือ 10 นาทีได้ แต่สิ่งเหล่านี้ยังไม่ใช่ Unit Test ที่ทำ 5 ชิ้นใน 100 วินาที

การไม่มีการทดสอบหน่วยเมื่อประกอบรูปภาพหรือโมดูลพื้นผิวกระตุ้นให้เกิดการเปลี่ยนงานไปยังบริการแยกกันที่สามารถเรียกใช้ผ่าน REST หรือสคริปต์ Python

ตัวอย่างเช่น เราต้องแน่ใจว่าเมื่อเครื่องเสมือนเริ่มทำงาน เครื่องจะลงทะเบียนตัวเองในบริการ สเกลFTและเมื่อเครื่องเสมือนถูกทำลาย เครื่องก็จะลบตัวเองออกไป

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

เราสามารถเขียนการทดสอบปกติสำหรับสิ่งนี้ได้เนื่องจากมันไม่ต่างจากซอฟต์แวร์ทั่วไป: apiha บางประเภทถูกล้อเลียน คุณดึงมันขึ้นมาแล้วดูว่าเกิดอะไรขึ้น

ผลลัพธ์ของการทดสอบ: การทดสอบหน่วยซึ่งควรให้ระบบปฏิบัติการภายในหนึ่งนาทีไม่ได้ให้ และการทดสอบประเภทที่สูงกว่าในปิระมิดนั้นมีประสิทธิภาพ แต่ครอบคลุมปัญหาเพียงบางส่วนเท่านั้น

การเขียนโปรแกรมจับคู่

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

เมื่อเขียนโค้ด คุณต้องการรับคำติชมเกี่ยวกับคุณภาพของโค้ดโดยเร็วที่สุด ใช่ คุณสามารถเขียนทุกอย่างใน Feature Branch (เพื่อไม่ให้ใครทำลายสิ่งใดๆ) สร้างคำขอดึงใน Github มอบหมายให้กับบุคคลที่ความคิดเห็นมีน้ำหนัก และรอการตอบกลับ

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

ด้านล่างนี้คือรูปแบบการเขียนโปรแกรมคู่และการนำไปใช้ในการทำงานกับ IaC:

1. คลาสสิก มีประสบการณ์+มีประสบการณ์ เลื่อนตามเวลา สองบทบาท - คนขับและผู้นำทาง สองคน. พวกเขาใช้โค้ดเดียวกันและสลับบทบาทหลังจากระยะเวลาที่กำหนดไว้ล่วงหน้า

พิจารณาความเข้ากันได้ของปัญหาของเรากับสไตล์:

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

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

สรุป: ในรูปแบบที่บริสุทธิ์มันไม่เหมาะกับเรา

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

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

สรุป: อนิจจา ความเร็วของการทำงานไม่อนุญาตให้ใช้ปิงปองเป็นแบบฝึกหัดการเขียนโปรแกรมคู่ใน IaC

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

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

สรุป : ใช้ได้ เราไม่ทิ้งความพยายาม

4. การรุมเร้า การรุมเร้า และรูปแบบที่เป็นที่รู้จักแต่ไม่อยู่ในรายการ เราไม่ถือว่าเพราะ เราไม่ได้ลองและเป็นไปไม่ได้ที่จะพูดถึงมันในบริบทของงานของเรา

ผลลัพธ์ทั่วไปเกี่ยวกับการใช้การเขียนโปรแกรมคู่:

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

5. อย่างไรก็ตามเรื่องนี้ก็ประสบความสำเร็จ เราคิดวิธีการของเราเองขึ้นมาว่า "Convergence - Divergence" ฉันจะอธิบายสั้น ๆ ว่ามันทำงานอย่างไร

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

การวางแผนและการสื่อสาร

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

1. วัตถุประสงค์ผ่านแผนผังเป้าหมาย เราจัดการจัดการโดยรวมของโครงการผ่านแผนผังที่มุ่งสู่อนาคตอย่างไม่มีที่สิ้นสุด ในทางเทคนิคแล้ว การติดตามเสร็จสิ้นใน Miro มีภารกิจหนึ่งคือ - เป็นเป้าหมายระดับกลาง จากนั้นไปที่เป้าหมายเล็ก ๆ หรือกลุ่มงาน งานเองก็มาจากพวกเขา งานทั้งหมดถูกสร้างขึ้นและดูแลรักษาบนบอร์ดนี้

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

ข้อดีของการมองเห็นงาน:

• สาเหตุ แต่ละงานนำไปสู่เป้าหมายระดับโลก งานจะถูกจัดกลุ่มเป็นเป้าหมายเล็กๆ โดเมนโครงสร้างพื้นฐานนั้นค่อนข้างทางเทคนิค ยังไม่ชัดเจนเสมอไปว่าผลกระทบเฉพาะเจาะจงเช่น การเขียน runbook เกี่ยวกับการโยกย้ายไปยัง nginx อื่นมีต่อธุรกิจอย่างไร การมีการ์ดเป้าหมายอยู่ใกล้ๆ จะทำให้ชัดเจนยิ่งขึ้น
  
  สาเหตุเป็นคุณสมบัติสำคัญของปัญหา มันตอบคำถามโดยตรง: “ฉันกำลังทำสิ่งที่ถูกต้องหรือไม่?”
• ความเท่าเทียม พวกเรามีกันเก้าคน และเป็นไปไม่ได้เลยที่จะให้ทุกคนมาทำงานเดียว งานจากด้านหนึ่งอาจไม่เพียงพอเสมอไปเช่นกัน เราถูกบังคับให้ทำงานแบบขนานระหว่างคณะทำงานเล็กๆ ในเวลาเดียวกัน กลุ่มต่างๆ นั่งทำงานอยู่ระยะหนึ่ง และคนอื่นสามารถเสริมกำลังได้ บางทีคนก็หลุดจากคณะทำงานนี้ไป มีคนไปเที่ยวพักผ่อน มีคนรายงานการประชุม DevOps มีคนเขียนบทความเกี่ยวกับ Habr การรู้ว่าเป้าหมายและงานใดที่สามารถทำได้ควบคู่กันไปเป็นสิ่งสำคัญมาก

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

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

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

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

ในระหว่างการสาธิตจำเป็นต้องเปิดเผยรายละเอียดของงานและต้องแน่ใจว่าได้สาธิตการปฏิบัติงานแล้ว

รายงานสามารถดำเนินการได้โดยใช้รายการตรวจสอบ1. เข้าสู่บริบท งานมาจากไหนทำไมถึงจำเป็น?

2. ก่อนหน้านี้ปัญหาได้รับการแก้ไขอย่างไร? ตัวอย่างเช่น จำเป็นต้องคลิกเมาส์อย่างหนัก หรือไม่สามารถทำอะไรได้เลย

3. เราจะปรับปรุงมันอย่างไร ตัวอย่างเช่น: “ดูสิ ตอนนี้มี scriptosik แล้วนี่คือ readme”

4. แสดงวิธีการทำงาน ขอแนะนำให้ใช้สถานการณ์ผู้ใช้บางสถานการณ์โดยตรง ฉันต้องการ X ฉันทำ Y ฉันเห็น Y (หรือ Z) ตัวอย่างเช่น ฉันปรับใช้ NGINX สูบ URL และได้รับ 200 OK หากการดำเนินการใช้เวลานาน ให้เตรียมไว้ล่วงหน้าเพื่อที่คุณจะได้แสดงในภายหลัง ขอแนะนำว่าอย่าทำลายมันมากเกินไปหนึ่งชั่วโมงก่อนการสาธิต ถ้ามันเปราะบาง

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

ขอแนะนำให้ผู้พูดแต่ละคนเก็บไว้เป็นเวลา 5-10 นาที หากคำพูดของคุณมีความสำคัญอย่างเห็นได้ชัดและจะใช้เวลานานกว่านี้ ให้ประสานงานล่วงหน้าในช่อง sre-takeover

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

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

บทสรุปที่ยาวนานและจะเป็นอย่างไรต่อไป

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

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

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

วิธีการมีอิทธิพลต่อระบบปฏิบัติการในระดับที่สูงขึ้น - การวางแผนและการทำงานกับงานต่างๆ จะสร้างผลลัพธ์ที่แม่นยำ: การแลกเปลี่ยนความรู้คุณภาพสูงและคุณภาพการพัฒนาที่ดีขึ้น

บทสรุปสั้นๆ ในบรรทัดเดียว

• ผู้ปฏิบัติงานด้านทรัพยากรบุคคลทำงานใน IaC แต่มีประสิทธิภาพน้อยกว่า
• เสริมสร้างสิ่งที่ได้ผล
• คิดกลไกและแนวปฏิบัติในการชดเชยของคุณเอง

ที่มา: will.com