ممارسة تسليم قواعد البيانات

DevOps لقواعد البيانات في المملكة

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

تراجع مُصمَّم مسبقًا لا مفترض لا تنحاز إلى أداة بعينها

باختصار

تغييرات قواعد البيانات، تُسلَّم كأي تغيير آخر

تقدّم إنتركي إدارة قواعد البيانات ونمذجة البيانات وهندسة DevOps، وتصف هذه الصفحة ما يحدث حين تجتمع الثلاثة في مشروع واحد: وضع المخطط والبيانات المرجعية تحت التحكم بالإصدارات، وبناء الخط الذي ينشرهما، وتصميم ما يحدث حين يلزم التراجع عن نشر.

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

اقرأ المزيد

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

الأعراض

كيف يبدو هذا قبل إصلاحه

الحالات التي تصفها الفرق، وما تدل عليه كل منها عادةً. وقليل منها يراه من يعيشه مشكلةً في قاعدة البيانات.

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

الترتيب

لماذا يجب الالتزام بالتسلسل

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

  1. حدّدوا الوضع الفعلي

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

  2. أصلحوا أنماط التغيير

    تغييرات إضافية وقابلة للعكس كقاعدة عامة: أضيفوا قبل أن تحذفوا، وافصلوا تعبئة البيانات الخلفية عن التبديل، ولا تُدرجوا أي تغيير هدّام في النشر نفسه مع الشيفرة التي تتوقف عن استخدام الشكل القديم. وهذا ما يُغني عن نافذة الصيانة.

  3. أتمتوا الفحوص

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

  4. انشروا عبر الخط

    يُرقّى المخرج نفسه عبر البيئات، ويطبّق الخط تغيير قاعدة البيانات، لا شخص يعمل من وحدة التحكم مباشرة. ويُطبَّق كل تغيير، ويُتحقّق منه، ويُسجَّل.

  5. اختبروا التراجع

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

الجزء الصعب

التراجع هو الاختبار الحقيقي للانضباط

الشيفرة تتراجع. البيانات لا تتراجع.

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

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

اقرأ المزيد

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

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

النطاق

كيف يتشكّل العمل عادةً

أربعة أشكال للعمل. كثيرًا ما يُطلب الأول وحده، وكثيرًا ما يغيّر تصور العميل للمشكلة.

التقييم والتقاط الانحراف

ما في كل بيئة فعلًا، وكم تباعدت، وأي الفروق مقصود. قصير المدة، وينتج الجرد الذي يُستند إليه في كل قرار لاحق.

بناء الخط

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

تعديل أنماط التغيير القائمة

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

التسليم والمعايير

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

السياق السعودي

ما يميّز هذا السوق

أمران يغيّران شكل هذا العمل هنا.

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

اقرأ المزيد

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

يُنفَّذ العمل من الرياض عبر فريق الهندسة نفسه الذي يبني التطبيقات المؤسسية المخصّصة، وهذا مهم هنا أكثر من المعتاد: فتسليم قواعد البيانات ليس تخصصًا منفصلًا، والخط الذي يصمّمه من لا يعمل يوميًا مع التطبيق الذي يخدمه قلّما يصمد أمام جدول الإصدارات.

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

تعريف الاكتمال

كيف يبدو المكتمل فعلًا

إعلان ممارسة لتسليم قواعد البيانات سهل، وإثباتها أصعب. وكل بند هنا إما متحقق أو غير متحقق، ويستطيع التحقق منه من لم يشارك في العمل:

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

أسئلة

أسئلة يطرحها المشترون فعلًا

سؤال شائع

أي الأدوات تستخدمون لتسليم قواعد البيانات؟

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

سؤال شائع

هل يمكن أن يعمل هذا دون نافذة صيانة؟

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

سؤال شائع

ماذا لو لم يكن عندنا تحكم بإصدارات قاعدة البيانات أصلًا؟

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

سؤال شائع

هل ينطبق هذا على NoSQL أيضًا؟

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

سؤال شائع

متى يؤتي هذا ثمره؟

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

الخطوة التالية

ابدؤوا مما في الإنتاج فعلًا

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

خانة إلزامية

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

أو مباشرةً

+966-11-2180999 [email protected]

أبراج التعاونية، البرج الشمالي، الطابق السابع، طريق الملك فهد، العليا، ص.ب. ٥٦٨٣٥، الرياض ١١٥٦٤، المملكة العربية السعودية

أو قرار المنصة بدلًا من ذلك

نشر بواسطة إنتركي. آخر تحديث . إنتركي مسجلة في الرياض بالسجل التجاري رقم 1010156897.