ฐานข้อมูลของคุณพร้อมหรือไม่ หากความเร็วในการพัฒนาเพิ่มขึ้นหลายเท่าตัว?

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

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

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

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

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

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

ความเสี่ยงที่แท้จริงอยู่ตรงนี้

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

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

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

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

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

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

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

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

สภาพแวดล้อมฐานข้อมูลขององค์กรส่วนใหญ่ทำให้เรื่องนี้ยากเกินความจำเป็น

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

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

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

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

นี่คือปัญหาที่ควรค่าแก่การแก้ และเป็นปัญหาที่แก้ได้