هل سيكون مصنع قاعدة البيانات الخاص بك جاهزًا إذا زادت سرعة التطوير بمقدار عشرة أضعاف؟

أدوات المساعدة بالذكاء الاصطناعي قد زادت من سرعة وخفضت تكلفة إنتاج الكود. ومع ذلك ، يتساءل قادة الأعمال عن سبب عدم ترجمة هذه الكفاءة إلى ابتكار متفوق ووقت تسليم أسرع. بدلاً من تسريع الدورة الكاملة للتسليم ، أظهرت هذه الزيادة في السرعة ضعف Processes التغيير الحالي لقاعدة البيانات.

لمعظم العقد الماضي ، كانت الإجابة على “كيف ننتقل أسرع؟” هي بناء أنابيب أفضل ، والاستثمار في CI / CD ، والانتقال إلى اليسار في الاختبار. هذه الاستثمارات أدت إلى نتائج ملموسة – يتحرك كود التطبيق بسرعة مذهلة في المنظمات الهندسية الناضجة. ومع ذلك ، لم تشعر هذه المكاسب بالتأثير بالتساوي عبر كافة مكدس التكنولوجيا. غالبًا ما تم التعامل مع قاعدة البيانات على أنها حالة خاصة ؛ أصل محمي يتطلب معيارًا مختلفًا للرعاية ، وعمليات أبطأ ، ومراقبة يدوية. كانت هناك أسباب جيدة لتطوير هذا النمط ، حيث تحتوي قواعد البيانات على البيانات التي تعمل عليها الأعمال ، ويمكن أن تكون الأخطاء مدمرة. في حين أن الحذر كان يبدو معقولًا ، تغيرت تكلفة هذا الحذر. من خلال زيادة الضغط على مسؤولي قواعد البيانات وفرق العمليات لتغيير قواعد البيانات بنفس السرعة التي يمكن للمطورين كتابة الكود الآن ، أصبحت الفجوة في المكدس مسؤولية. لا يمكن لهذه الفرق مواكبة ، وتغيرات قاعدة البيانات تقتل الآن ميزة السرعة التي توفرها أدوات المساعدة بالذكاء الاصطناعي. حل أحد القيود – الوقت المطلوب لكتابة الكود – قد أبرز فقط الحاجز التالي في العملية. هذا هو التفكير النظم على قيد الحياة ، والاحتكاك الناتج يصبح أكثر إيلامًا للمؤسسات.

السرعة والسيطرة ليستا متنافيان. لكن الطريقة التي تحكم بها معظم المنظمات التغيير لقاعدة البيانات تعاملهما على أنهما متنافيان.

كان نموذج الحوكمة التقليدي لقاعدة البيانات مصممًا ل世界 الإصدارات الربع سنوية. طلبات التغيير ، ولجان الموافقة ، ودورات المراجعة اليدوية ، وخطط التراجع المكتوبة مسبقًا قبل التوزيعات التي حدثت أربع مرات في السنة. لا شيء من ذلك بشكل nộiزي خاطئ. كان إدارة المخاطر التي نمت لتناسب الوقت المتاح في الوقت بين الإصدارات. المشكلة هي أن إيقاع التوزيع قد تغير ، ولم تتبع معظم المنظمات نهج الحوكمة. من المتوقع أن تشحن الفرق بشكل مستمر ، ومع ذلك ، لا تزال توجيه تغييرات قاعدة البيانات من خلال عمليات بنيت لera مختلفة. النتيجة ليست أمانًا. النتيجة هي احتكاك ، وطرق ، وفئة متزايدة من “التغييرات الصغيرة” لقاعدة البيانات التي تتجاوز الحوكمة بالكامل لأن العملية الرسمية بطيئة جدًا لدرجة أن تكون عمليًا.

هنا يعيش المخاطر الحقيقي.

عندما تكون الحوكمة بطيئة جدًا لاستخدامها ، يتوقف الناس عن استخدامها. يتم تطبيق تغييرات مخطط مباشرة في الإنتاج. يتم إصدار تصحيحات ساخنة بدون سيطرة على الإصدار ، ومن ثم يتم إصدارها بشكل رسمي مع الإصدار التالي ، ولكن ذلك لا يحدث لأن الناس مشغولون. تصبح الخطوات اليدوية التي كان من المفترض أن تكون شبكة الأمان هي الشيء الذي يتنقل الناس حوله عندما يكونون تحت ضغط. والضغط ، في تسليم البرمجيات ، هو الحالة الافتراضية.

الإجابة ليست في إبطاء الأنابيب. إنها نقل الحوكمة داخلها.

المنظمات التي حلتت هذه المشكلة لم تفعل ذلك من خلال تخفيف معاييرها. لقد قامت بالعمل الأصعب لإجعل الحوكمة سريعة بما يكفي لتكون مسار أقل مقاومة. التغييرات المخططية الخاضعة للسيطرة على الإصدار ، وكشف الانحراف التلقائي ، والتحقق من السياسات الحتمية المضمنة في أنابيب CI / CD بدلاً من تطبيقها كبوابة في النهاية. بينما تكون الأدوات التي تعمل بالذكاء الاصطناعي احتمالية – تقدم اقتراحات بناءً على الأنماط – يجب أن تظل الحوكمة حتمية لتكون فعالة. من خلال استخدام التحقق القابل للتكرار ، تضمن أن كل تغيير يمكن تمييزه ويلبي معايير الأمان قبل أن يصل إلى الإنتاج. لا تزال الموافقة تحدث. لا تزال سجل المراجعة موجود. لكنها تحدث في نفس التدفق مثل كل شيء آخر ، وليس كعملية منفصلة أبطأ تقع خارجها.

هذا يهم لأسباب تتجاوز إنتاجية المطور. متطلبات الامتثال لا تصبح أخف. الجمع بين GDPR و DORA (قانون القوة التشغيلية الرقمية للاتحاد الأوروبي) ومجموعة متزايدة من اللوائح المحددة للقطاع يعني أن حوكمة قاعدة البيانات أصبحت مسألة قانونية وتنظيمية ، وليس فقط مسألة تشغيلية. المنظمات التي لا يمكنها إثبات تاريخ قابل للتتبع وتمييز للتغيير لقاعدة البيانات معرضة للخطر بطرق أصبحت ملموسة. حجة دمج الحوكمة في الأنابيب ليست فقط أن تسليم أسرع. إنها ما يجعل الامتثال قابلًا للتتبع على نطاق واسع.

الذكاء الاصطناعي يزيد من الإلحاح.

موجة التطوير المدعومة بالذكاء الاصطناعي الحالية تجعل هذه المشكلة أكثر حدة ، وليس أقل. عندما يمكن للمطورين إنشاء وتكرار كود التطبيق بمقدار عشرة أضعاف ما كانوا قادرون عليه من قبل ، تصبح قاعدة البيانات حجر عثرة أكثر وضوحًا بالنسبة إلى كل شيء حولها. لكن هناك تأثيرًا ثانويًا أقل انتشارًا. الأدوات التي تعمل بالذكاء الاصطناعي جيدة جدًا في إنشاء منطق التطبيق. أنها أقل جودة في فهم العواقب طويلة الأمد لتغييرات المخطط في قاعدة بيانات复杂ة ومباشرة. الجمع بين سرعة التطوير التطبيقية واقتراحات تغيير المخطط التي تعمل بالذكاء الاصطناعي دون حوكمة ناضجة هو بالضبط نوع الضغط الذي ينتج حوادث. السرعة بدون حواجز هيكلية تخلق ظروفًا لحدوث الأخطاء بشكل أسرع.

المنظمات التي ستتجاوز هذه المشكلة جيدًا هي تلك التي تعامل حوكمة قاعدة البيانات على أنها مسألة هندسية من الدرجة الأولى وليس فقط مسألة امتثال. هذا يعني أن سيطرة الإصدار على مخطط قاعدة البيانات هو افتراض لا يمكن المساومة عليه ، وتدقيق تلقائي يعالج الفحوصات الروتينية حتى تتمكن المراقبة اليدوية من التركيز على التغييرات عالية الخطورة وذات الحكم ، بدلاً من أن تصبح عائقًا في مرحلة متأخرة. وأخيرًا ، يعني ذلك كشف الانحراف الذي يعرف الانحراف قبل أن يسبب حادثًا.

معظم مزارع الشركات تجعل الأمور أكثر صعوبة مما ينبغي.

هناك واقع مركب يقع جنبًا إلى جنب مع معظم هذه الملاحظات. معظم مزارع قواعد البيانات للشركات ليست خضراء. إنها تمثل عقودًا من التغييرات المتراكمة على المخطط ، وتعمل على منصات DBMS متعددة ، بعضها على الموقع وبعضها في السحابة ، مع درجات مختلفة من الوثائق والمعرفة القبلية موزعة على فرق تم استبدالها عدة مرات. غالبًا ما تفترض محادثة تحديث افتراض نقطة بداية نظيفة التي لا يمتلكها معظم المنظمات. هنا يصبح التحدي حادًا وغالبًا ما يمنع التقدم. سواء كان الهدف هو دعم الابتكار أو تنظيف وتنقل البيانات من أجل الذكاء الاصطناعي أو تحسين المرونة التشغيلية ؛ يعود إلى نفس الأشياء. السؤال ليس كيف تبني ممارسة DevOps المثالية لقاعدة البيانات على نظام جديد. السؤال هو كيف تقدم حوكمة ذات معنى على مزرعة تراثية معقدة دون إيقاف العمل أثناء فعل ذلك.

الحوكمة المركبة في الأنابيب هي الإجابة العملية الوحيدة على هذا السؤال. لا تحتاج إلى إعادة منصة المزرعة بأكملها قبل أن تتمكن من تحسين ممارسات إدارة التغيير الخاصة بك. توجد أدوات حديثة مثل Redgate Flyway لتخفيف قاعدة البيانات كحجر عثرة وبدء التغييرات التي يتم إجراؤها اليوم ، في الأنابيب التي توجد بالفعل ، والبناء من هناك.

المنظمات التي ستفوز في النمو في السنوات الخمس القادمة لن تكون تلك التي لديها مزارع نظيفة. سيكونون أولئك الذين وجدوا كيفية جعل التغيير موثوقًا به ، بسرعة الأعمال المطلوبة ، عبر المزرعة التي لديهم بالفعل.

هذه هي المشكلة التي تستحق حلها. ومن الممكن حلها.