7 เทคนิคการแก้จุดบกพร่องเพื่อเพิ่มความเร็วในการแก้ไขปัญหาในการผลิต

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

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

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

เคล็ดลับ #1: ลบหรือทำให้การกำหนดค่าทั้งหมดที่จำเป็นสำหรับแอปพลิเคชันทำงานโดยอัตโนมัติ

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

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

ในทำนองเดียวกัน ทำให้การตั้งค่านักพัฒนาง่ายขึ้น ดังนั้นจึงใช้เวลาไม่นานในการติดตั้งและใช้งาน รวมถึงการตั้งค่า IDE นักพัฒนาซอฟต์แวร์ควรเปลี่ยนจากศูนย์เป็นฮีโร่ได้ภายในเวลาไม่ถึง 30 นาที

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

เคล็ดลับ #2: อย่าตกหลุมพรางของกองเทคโนโลยี

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

• อย่าเพิ่มการพึ่งพาเฟรมเวิร์กใหม่เพียงเพราะคุณต้องการคลาส StringUtils
• อย่าเพิ่มภาษาใหม่ทั้งหมดเพียงเพราะคุณจำเป็นต้องเขียนสคริปต์ด่วนเพื่อย้ายไฟล์

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

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

เคล็ดลับ #3: การบันทึกจะต้องแนะนำให้คุณค้นหาปัญหา ไม่ใช่ทำให้คุณจมอยู่กับรายละเอียดที่ไร้ประโยชน์

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

เคล็ดลับ #4: จัดการกับสถานการณ์ที่ไม่คาดคิด

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

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

เคล็ดลับ #5: การจำลองปัญหาที่เกิดขึ้นกับลูกค้าควรตรงไปตรงมา

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

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

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

เคล็ดลับ #6: ควรชัดเจนว่าจะวางเบรกพอยต์ในแอปพลิเคชันไว้ที่ใด

หากคุณมีหน้าจอลูกค้า ควรมีออบเจ็กต์ Customer ที่คุณสามารถวางจุดสั่งหยุดเพื่อแก้ปัญหาบนหน้าจอนั้นได้ บางครั้งนักพัฒนาตกอยู่ในภาวะนามธรรมและเกิดแนวคิดที่ชาญฉลาดอย่างไม่น่าเชื่อเกี่ยวกับวิธีจัดการกับเหตุการณ์อินเทอร์เฟซผู้ใช้ เราควรพึ่งพาหลักการ KISS เสมอ (Keep it Simple, St— er, Silly) และมีวิธีการที่ค้นหาได้ง่ายเพียงวิธีเดียวต่อเหตุการณ์ UI ในทำนองเดียวกัน สำหรับงานการประมวลผลแบบกลุ่มและงานที่กำหนดเวลาไว้ ควรจะมีวิธีง่ายๆ ในการระบุว่าจุดสั่งหยุดของสถานที่ใดเพื่อประเมินว่ารหัสนั้นใช้งานได้หรือไม่

เคล็ดลับ #7: ตรวจสอบให้แน่ใจว่ามีการจัดทำเอกสารการพึ่งพาภายนอกทั้งหมดไว้อย่างชัดเจน

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

นอกเหนือจากเทคนิคการดีบัก

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