Abduaziz Abdukhalimov: "ระบบเดิมมักจะล้มเหลวภายใต้การเปลี่ยนแปลงก่อนที่จะล้มเหลวภายใต้ขนาด"

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

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

Abduaziz ได้สร้างวิธีการเพื่อปรับปรุงระบบการวางแผนทรัพยากรองค์กร (ERP) และระบบการเงินเก่าให้ทันสมัยที่ SoftClub Company โดยการเปลี่ยนพวกเขาให้เป็นไマイโครเซอร์วิสแบบโมดูลาร์ ที่ Barso LLC เขาได้พัฒนาแพลตฟอร์มองค์กรแบบคลาวด์เนทีฟที่ให้บริการผู้ใช้มากกว่า 100,000 คน เขายังเป็นผู้นำในการปรับใช้แพลตฟอร์มการเรียนรู้ระดับชาติที่ใช้ Moodle ในอุซเบกิสถาน ซึ่งช่วยให้นักเรียนและครูสามารถทำงานออนไลน์ผ่านระบบที่ต้องการประสิทธิภาพที่เสถียร การเผยแพร่ที่เชื่อถือได้ และการพัฒนาซ้ำที่รวดเร็วแต่ปลอดภัย ในการสนทนาของเรากับ Abdukhalimov เราได้พูดคุยเกี่ยวกับสิ่งที่ต้องใช้ในการปรับปรุงแพลตฟอร์มเก่าให้ทันสมัย วิธีที่ทีมวิศวกรรมสามารถขยายระบบองค์กรโดยไม่สูญเสียความน่าเชื่อถือและความสามารถในการบำรุงรักษาระบบ และเหตุใดวินัยทางสถาปัตยกรรมจึงมักมีความสำคัญมากกว่าการเลือกเทคโนโลยี

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

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

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

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

คุณได้รับอันดับหนึ่งใน Open Data Challenge และได้รับการจัดอันดับสูงสุดใน Best Soft Challenge ในช่วงต้นของอาชีพของคุณ ประสบการณ์เหล่านั้นได้หล่อหลอมวิธีที่คุณเข้าหาปัญหาวิศวกรรมขนาดใหญ่ในภายหลังอย่างไร?

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

ที่ SoftClub Company คุณทำงานเกี่ยวกับการปรับปรุงองค์กรให้ทันสมัยและช่วยย้ายระบบ ERP การเงิน และ HR เก่าไปยังไماイโครเซอร์วิสแบบโมดูลาร์ งานของคุณนำไปสู่แอปพลิเคชันองค์กรที่ขยายได้มากขึ้น ความสามารถในการบำรุงรักษาที่ดีขึ้น และการนำคลาวด์มาใช้อย่างกว้างขวาง คุณกำหนดอย่างไรว่าโมโนลิธควรได้รับการปรับปรุงแบบค่อยเป็นค่อยไปหรือไม่?

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

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

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

ในฐานะ Senior Full-Stack Developer ที่ Barso LLC คุณช่วยสร้างแพลตฟอร์มองค์กรแบบคลาวด์เนทีฟ ซึ่งปรับปรุงประสิทธิภาพระบบได้ 40% จากประสบการณ์นั้น ปัจจัยทำลายประสิทธิภาพที่เงียบๆ ที่คุณเห็นบ่อยที่สุดในสภาพแวดล้อม Spring Boot คืออะไร?

ปัญหาประสิทธิภาพหลายอย่างไม่ได้เกิดจากอัลกอริทึมแต่เกิดจากการตัดสินใจด้านสถาปัตยกรรม

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

คุณได้พัฒนาสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์โดยใช้ Apache Kafka และ RabbitMQ เพื่อสนับสนุนแพลตฟอร์มที่ให้บริการผู้ใช้งานมากกว่า 100,000 คน ปรับปรุงความสามารถในการขยาย ความทนทานต่อความผิดพลาด และความน่าเชื่อถือของระบบ จากประสบการณ์ของคุณ ภายใต้สถานการณ์ใดสถาปัตยกรรมที่ขับเคลื่อนด้วยเหตุการณ์จะเสริมสร้างความยืดหยุ่นและความสามารถในการขยายอย่างแท้จริง?

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

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

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

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

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

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

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

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

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

ประการแรก ลงทุนในการสังเกตได้ก่อนการเปลี่ยนแปลงสถาปัตยกรรมขนาดใหญ่ เมตริก บันทึก และการติดตามที่ชัดเจนช่วยให้ทีมเข้าใจว่าระบบปัจจุบันทำงานอย่างไรและที่ไหนต้องการการปรับปรุงมากที่สุด

ประการที่สอง ออกแบบเวิร์กโฟลว์การปรับใช้ใหม่แต่เนิ่นๆ ไปป์ไลน์ CI/CD ที่เชื่อถือได้ช่วยให้การทดลองเร็วขึ้นและลดความกลัวต่อการเปลี่ยนแปลง

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

เมื่อรากฐานเหล่านั้นอยู่ในที่ การปรับปรุงให้ทันสมัยจะกลายเป็นกระบวนการที่มีโครงสร้างมากกว่าการกระโดดที่มีความเสี่ยง