ฐานข้อมูลของคุณพร้อมที่จะรองรับการพัฒนาที่เพิ่มขึ้นเป็นเท่าใด?

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

ในช่วงสิบปีที่ผ่านมา คำตอบสำหรับ “เราจะย้ายเร็วได้อย่างไร?” คือการสร้าง파イป์ไลน์ที่ดีขึ้น ลงทุนใน CI/CD และเลื่อนการตรวจสอบไปทางซ้าย อย่างไรก็ตาม การลงทุนเหล่านี้ไม่ได้ให้ผลตอบแทนที่เท่าเทียมกันทั่วทั้งเทคโนโลยีสแต็ก ฐานข้อมูลมักถูกมองว่าเป็นกรณีพิเศษ สินทรัพย์ที่ได้รับการคุ้มครองซึ่งต้องการมาตรฐานการดูแลที่แตกต่าง กระบวนการที่ช้าลง และการกำกับดูแลด้วยตนเอง มีเหตุผลที่ดีสำหรับการพัฒนารูปแบบนี้ เนื่องจากฐานข้อมูลมีข้อมูลที่ธุรกิจดำเนินงาน และข้อผิดพลาดอาจเป็นอันตรายได้ ในขณะที่ความระมัดระวังครั้งหนึ่งอาจรู้สึกสมเหตุสมผล แต่ต้นทุนของความระมัดระวังได้เปลี่ยนไป โดยการเพิ่มความกดดันต่อทีม DBA และทีมปฏิบัติการเพื่อทำการเปลี่ยนแปลงฐานข้อมูลในอัตราที่นักพัฒนาสามารถเขียนโค้ดได้ ความแตกต่างในเทคโนโลยีสแต็กได้กลายเป็นภาระ ทีมเหล่านี้ไม่สามารถตามทัน และการเปลี่ยนแปลงฐานข้อมูลกำลังฆ่าความเร็วที่ได้รับจากการใช้เครื่องมือที่ได้รับการสนับสนุนจาก AI

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

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

คำตอบไม่ใช่การชะลอการขนส่ง แต่เป็นการย้ายการกำกับดูแลเข้าไปข้างใน

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

AI กำลังเพิ่มความเร่งด่วน

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

องค์กรส่วนใหญ่ทำให้สิ่งนี้ยากขึ้นกว่าที่ควร

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

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

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

นั่นคือปัญหาที่คุ้มค่าที่จะแก้ไข และมันสามารถแก้ไขได้