สวัสดีฮับ! ก่อนหน้านี้ ฉันบ่นเกี่ยวกับชีวิตใน 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 ได้อย่างไร จริงๆแล้ว... ไม่ใช่เลย
- การทดสอบหน่วยแม้ว่าจะควรมีจำนวนมาก แต่ก็ไม่สามารถมีมากเกินไปได้ หรือพวกเขากำลังทดสอบบางสิ่งทางอ้อมมาก จริงๆ แล้ว เราสามารถพูดได้ว่าเราไม่ได้เขียนมันเลย แต่นี่คือแอปพลิเคชันบางส่วนสำหรับการทดสอบที่เราสามารถทำได้:
- ทดสอบโค้ด jsonnet ตัวอย่างเช่น นี่คือไปป์ไลน์การประกอบโดรนของเรา ซึ่งค่อนข้างซับซ้อน รหัส jsonnet ได้รับการคุ้มครองอย่างดีจากการทดสอบ
เราใช้สิ่งนี้กรอบการทดสอบหน่วยสำหรับ Jsonnet . - ทดสอบสคริปต์ที่ดำเนินการเมื่อทรัพยากรเริ่มทำงาน สคริปต์เขียนด้วยภาษา Python ดังนั้นจึงสามารถเขียนการทดสอบลงไปได้
- ทดสอบโค้ด jsonnet ตัวอย่างเช่น นี่คือไปป์ไลน์การประกอบโดรนของเรา ซึ่งค่อนข้างซับซ้อน รหัส jsonnet ได้รับการคุ้มครองอย่างดีจากการทดสอบ
- อาจเป็นไปได้ที่จะตรวจสอบการกำหนดค่าในการทดสอบ แต่เราไม่ทำเช่นนั้น นอกจากนี้ยังสามารถกำหนดค่าการตรวจสอบกฎการกำหนดค่าทรัพยากรผ่านทาง
ฟลินท์ . อย่างไรก็ตาม การตรวจสอบมีพื้นฐานเกินไปสำหรับ Terraform แต่มีสคริปต์ทดสอบจำนวนมากที่เขียนขึ้นสำหรับ AWS และเราอยู่บน Azure ดังนั้นจึงใช้ไม่ได้อีกครั้ง - การทดสอบการรวมส่วนประกอบ: ขึ้นอยู่กับวิธีการจำแนกประเภทและตำแหน่งที่คุณจัดวาง แต่โดยทั่วไปแล้วพวกมันใช้งานได้
นี่คือลักษณะของการทดสอบการรวมระบบ
นี่คือตัวอย่างเมื่อสร้างภาพใน Drone CI ในการเข้าถึงพวกเขา คุณต้องรอ 30 นาทีเพื่อให้อิมเมจ Packer ก่อตัว จากนั้นรออีก 15 นาทีเพื่อให้รูปภาพผ่านไป แต่พวกเขามีอยู่จริง!อัลกอริธึมการตรวจสอบรูปภาพ
- Packer ต้องเตรียมอิมเมจให้ครบถ้วนก่อน
- ถัดจากการทดสอบจะมีรูปแบบพื้นผิวที่มีสถานะท้องถิ่น ซึ่งเราใช้ในการปรับใช้อิมเมจนี้
- เมื่อกางออก จะใช้โมดูลขนาดเล็กที่วางอยู่ใกล้ๆ เพื่อให้ทำงานกับรูปภาพได้ง่ายขึ้น
- เมื่อปรับใช้ VM จากอิมเมจแล้ว การตรวจสอบก็สามารถเริ่มต้นได้ โดยทั่วไปการตรวจสอบจะดำเนินการโดยรถยนต์ ตรวจสอบวิธีการทำงานของสคริปต์เมื่อเริ่มต้นและวิธีการทำงานของ daemons ในการดำเนินการนี้ ผ่าน ssh หรือ winrm เราจะลงชื่อเข้าใช้เครื่องที่เพิ่งยกขึ้นมาใหม่ และตรวจสอบสถานะการกำหนดค่าหรือบริการพร้อมใช้งานหรือไม่
- สถานการณ์จะคล้ายคลึงกับการทดสอบการรวมในโมดูลสำหรับพื้นผิว ต่อไปนี้เป็นตารางสั้นๆ ที่อธิบายคุณลักษณะของการทดสอบดังกล่าว
ข้อเสนอแนะเกี่ยวกับไปป์ไลน์ใช้เวลาประมาณ 40 นาที ทุกอย่างเกิดขึ้นเป็นเวลานานมาก สามารถใช้สำหรับการถดถอยได้ แต่สำหรับการพัฒนาใหม่ โดยทั่วไปแล้วจะไม่สมจริง หากคุณพร้อมมากสำหรับสิ่งนี้ ให้เตรียมสคริปต์ที่กำลังทำงานอยู่ จากนั้นคุณสามารถลดเวลาลงเหลือ 10 นาทีได้ แต่สิ่งเหล่านี้ยังไม่ใช่ Unit Test ที่ทำ 5 ชิ้นใน 100 วินาที
การไม่มีการทดสอบหน่วยเมื่อประกอบรูปภาพหรือโมดูลพื้นผิวกระตุ้นให้เกิดการเปลี่ยนงานไปยังบริการแยกกันที่สามารถเรียกใช้ผ่าน REST หรือสคริปต์ Python
ตัวอย่างเช่น เราต้องแน่ใจว่าเมื่อเครื่องเสมือนเริ่มทำงาน เครื่องจะลงทะเบียนตัวเองในบริการ
เนื่องจากเรามี 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