لماذا يستمر مسؤولو قواعد البيانات ومهندسو الأمن في عرقلة إصداراتك (وكيفية حل المشكلة)
لديك ميزة جاهزة. المطورون أنهوا الكود. فريق ضمان الجودة وقع على الموافقة. بيئة الاختبار تبدو جيدة. تحدد موعد الإصدار لهذه الليلة.
ثم ينظر مسؤول قاعدة البيانات (DBA) إلى التغيير ويقول: "هذا الترحيل سيغلق الجدول لمدة خمس دقائق. بيئة الإنتاج مشغولة في ذلك الوقت. لا يمكننا فعل هذا."
أو يراجع مهندس الأمن ميزة رفع الملفات ولا يجد أي تحقق من نوع الملف، أو حد للحجم، أو وصول عام مباشر للملفات المرفوعة. يقول: "هذا لا يمكن أن يُنشر."
يتأخر الإصدار. مرة أخرى.
يتكرر هذا السيناريو عبر الفرق كل أسبوع. رد الفعل الشائع هو إلقاء اللوم على مسؤول قاعدة البيانات أو مهندس الأمن باعتبارهم معرقلين. لكن المشكلة الحقيقية هي كيف ومتى يتم إشراكهم.
مشكلة مسؤول قاعدة البيانات مع التغييرات المتأخرة
مسؤولو قواعد البيانات مسؤولون عن الحفاظ على استقرار قاعدة البيانات وتوفرها وأدائها. يعرفون سلوك بيئة الإنتاج: أي الجداول لديها حركة مرور عالية، ومتى تبلغ الأحمال ذروتها، وأي العمليات تسبب أقفالاً. المطور الذي يختبر تغيير مخطط (schema) على حاسوبه المحمول ببضع مئات من الصفوف لا يختبر ما يحدث عندما يعمل نفس الترحيل على ملايين الصفوف تحت معاملات نشطة.
عندما يرى مسؤول قاعدة البيانات تغييراً لأول مرة عند بوابة الإصدار، تكون خياراته الوحيدة هي الموافقة أو الرفض. ليس لديه سياق حول مدى أهمية الميزة، أو ما إذا كان هناك حل بديل، أو إذا كان يمكن تقسيم الترحيل إلى خطوات أكثر أماناً. لذلك يلجأ إلى الحذر. يطلب مزيداً من الوقت. يطلب نهجاً مختلفاً. يتوقف الإصدار.
مسؤول قاعدة البيانات لا يحاول عرقلتك. إنه يحاول منع حادث سيتعين عليه إصلاحه في الساعة الثانية صباحاً.
معضلة مهندس الأمن
يواجه مهندسو الأمن نفس النمط. يتم إشراكهم في اللحظة الأخيرة، ويُعطون ميزة ويُطلب منهم الموافقة عليها بسرعة. لكنهم يرون أشياءً فاتت الفريق أثناء التطوير: مدخلات غير موثقة، تحققات مفقودة من المصادقة، نقاط نهاية مكشوفة، مخاطر تسرب البيانات.
إذا وافقوا دون مراجعة، يتحملون المخاطرة. إذا رفضوا، يصبحون المعرقل. لا يوجد خيار جيد.
مهندسو الأمن لا يستمتعون بقول لا. يريدون أن تُنشر الميزات بأمان. لكن عندما يتم استشارتهم فقط في النهاية، فإن أداة الضغط الوحيدة لديهم هي حق النقض (الفيتو). يستخدمونه لأن البديل هو نشر ثغرة أمنية.
السبب الجذري: الإشراك المتأخر
كلا الدورين يصبحان عنق زجاجة لنفس السبب: يتم التعامل معهما كحراس بوابة في نهاية خط الأنابيب بدلاً من متعاونين طوال العملية. يبني الفريق الميزة، ويختبرها، وعندها فقط يطلب الموافقة. عند تلك النقطة، أي مشكلة تعني إعادة عمل، أو تأخير، أو استثناء محفوف بالمخاطر.
هذه ليست مشكلة أشخاص. إنها مشكلة سير عمل.
التحول لليسار: نقل المراجعة إلى وقت أبكر
الحل هو إشراك مسؤولي قواعد البيانات ومهندسي الأمن قبل كتابة الكود، وليس بعد أن يصبح جاهزاً للنشر. يُسمى هذا النهج غالباً "التحول لليسار" (Shift Left) -- نقل الفحوصات إلى وقت أبكر في تدفق التسليم.
الفرق بين التدفق القديم والجديد واضح:
لتغييرات قاعدة البيانات، هذا يعني أن المطور يناقش تغيير المخطط المخطط له مع مسؤول قاعدة البيانات أثناء التصميم. يمكن لمسؤول قاعدة البيانات أن يقول:
- هذا الترحيل آمن للتشغيل المباشر.
- هذا التغيير يحتاج إلى استراتيجية تعبئة خلفية (backfill) أولاً.
- هذا الجدول يحتاج إلى نافذة صيانة.
- يجب تقسيم هذا إلى عدة ترحيلات أصغر.
يعدل المطور الخطة قبل كتابة الكود. عندما يصل التغيير إلى مرحلة الإصدار، يكون مسؤول قاعدة البيانات على علم به بالفعل وقد وافق على النهج. لا مفاجآت، لا تأخير.
بالنسبة للأمن، ينطبق نفس المبدأ. قبل بناء ميزة رفع الملفات، يسأل الفريق: "ما مخاطر الأمن التي تقدمها هذه الميزة؟" يقدم مهندس الأمن التوجيه مبكراً: تحقق من أنواع الملفات، فرض حدود الحجم، تخزين الملفات خارج جذر الويب، طلب المصادقة للوصول. يطبق المطور هذه الأمور من البداية. عندما تكون الميزة جاهزة، تكون مراجعة الأمن مجرد إجراء شكلي، وليست جلسة اكتشاف.
اجعلها غير متزامنة
إشراك مسؤولي قواعد البيانات ومهندسي الأمن مبكراً لا يعني أنهم يحضرون كل اجتماع يومي أو يجلسون في كل اجتماع تصميم. هذا لا يتناسب مع الحجم. بدلاً من ذلك، يمكنهم تقديم أصول قابلة لإعادة الاستخدام:
- ينشر مسؤول قاعدة البيانات إرشادات لتغييرات المخطط الآمنة: أي العمليات آمنة للتشغيل المباشر، وأيها تتطلب نافذة صيانة، وكيفية تقدير مدة القفل.
- يحتفظ مهندس الأمن بقائمة تحقق أمنية لأنواع الميزات الشائعة: رفع الملفات، المصادقة، نقاط نهاية API، تصدير البيانات.
- يقدم كلا الدورين ساعات مكتبية أو فتحات مراجعة غير متزامنة حيث يمكن للمطورين طرح الأسئلة قبل كتابة الكود.
يستخدم المطورون هذه الموارد للفحص الذاتي قبل طلب مراجعة رسمية. يحتاج مسؤول قاعدة البيانات أو مهندس الأمن فقط لمراجعة الحالات الحدودية أو التغييرات عالية المخاطر. الباقي يتبع الأنماط المقررة.
قائمة التحقق العملية
قبل إصدارك القادم، اطرح هذه الأسئلة:
- هل رأى مسؤول قاعدة البيانات تغييرات قاعدة البيانات قبل بدء التطوير؟
- هل راجع مهندس الأمن تصميم الميزة بحثاً عن المخاطر؟
- هل توجد إرشادات مكتوبة للترحيلات الآمنة والفحوصات الأمنية؟
- هل يمكن للمطورين الفحص الذاتي مقابل تلك الإرشادات قبل طلب المراجعة؟
- هل توجد عملية للاستشارة غير المتزامنة، وليس فقط بوابات اللحظة الأخيرة؟
إذا كانت الإجابة على أي من هذه الأسئلة لا، فقد وجدت عنق الزجاجة التالي.
مسؤولو قواعد البيانات ومهندسو الأمن هم حماة، ليسوا معرقلين
هم موجودون لمنع حوادث الإنتاج وخرق البيانات. هذا شيء جيد. المشكلة هي عندما يُجبرون على القيام بذلك في أسوأ لحظة ممكنة. عندما تشركهم مبكراً، يمكنهم التوجيه والنصح والحماية دون إيقاف الإصدار. عندما تشركهم متأخراً، ليس لديهم خيار سوى إيقافه.
أصلح التوقيت، ويختفي المعرقل.