عند انتهاء عقد مهندس DevOps المستقل أو اكتمال مرحلة إعداد البنية التحتية، يُصبح تطبيق قائمة تحقق تسليم مهام DevOps أمراً حاسماً لنقل الملكية كاملة وحماية استمرارية أعمال شركتك. بينما يركز الإعداد الأولي للمشروع على تحديد متطلبات التوظيف، فإن التسليم المنظم للأنظمة السحابية والبرمجية يضمن عدم بقاء أي ثغرات أمنية أو اعتماد دائم على شخص المطور المغادر. يمكنك الاطلاع على دليل التوظيف للاستفادة من استراتيجيات إدارة التعاقدات التقنية.
تختلف قائمة تحقق التسليم النهائي (Offboarding Handover) عن تحديد ما المهام التي يجب إسنادها لمهندس DevOps المستقل أثناء فترة العمل، أو طرق كيف تقيّم مهندس DevOps دون خلفية تقنية في مرحلة المقابلات. تتكامل هذه القائمة أيضاً مع مفاهيم التسليم العامة الموضحة في مقالنا حول قائمة تحقق قبل تسليم مشروعك البرمجي لمطور Full Stack، لكنها تتخصص في معايير البنية التحتية والاستضافة والأمن السحابي عبر المستقلين المحترفين.
1. نقل الملكية الكاملة للحسابات السحابية وإدارة الوصول
أهم خطوة في التسليم النهائي هي ضمان نقل الملكية الجذرية (Root Ownership) لكافة الحسابات السحابية وإدارات النطاقات إلى الشركة مباشرة. ينبغي ألّا تظل أي سيرفرات أو خدمات مدارة تحت الحساب الشخصي لمهندس DevOps أو بطاقته الائتمانية الشخصية.
- حسابات مزودي السحابة (AWS / GCP / Azure): التأكد من نقل حساب المالك الرئيسي (Account Root User) إلى بريد إلكتروني رسمي يخص الشركة.
- إدارة النطاقات وDNS: استلام لوحات تحكم Cloudflare أو مراكز تسجيل النطاقات (Domain Registrars) والتحقق من تحديث بيانات الاتصال الإدارية.
- التوافق مع المعايير الأمنية: تتطلب الممارسات الأفضل لإدارة الوصول والحسابات في AWS احتفاظ العملاء بالملكية المطلقة للحساب الرئيسي وتطبيق إدارة صارمة للصلاحيات أثناء تسليم المشاريع.
2. استلام كود البنية التحتية بالكامل (Infrastructure as Code)
لا يكفي أن تكون السيرفرات والتطبيقات تعمل بنجاح على البيئة الحية؛ بل يجب أن تمتلك الشركة كود البنية التحتية (IaC) كاملاً داخل مستودع الأكواد (Repository) الخاص بها. يتيح ذلك إعادة بناء وتنسيق البيئة السحابية مجدداً في أي وقت دون الحاجة لتهيئة يدوية.
- ملفات الأتمتة والتهيئة: استلام جميع ملفات Terraform وAnsible وشبكات Docker Compose ومخططات Kubernetes/Helm.
- الربط مع مستودع الشركة: دفع كافة التحديثات إلى المستودع الرئيسي المعتمد والتأكد من عدم وجود أكواد أو سكريبتات محتفظ بها محلياً لدى المستقل. ويمكنك الاطلاع على تفاصيل مشابهة في ماذا يتضمن تسليم مطور Backend لمشروع API.
- التوافق المعياري والاستجابة: يضمن تطبيق مبادئ البنية التحتية ككود من AWS قدرة الشركة على إعادة نشر وإعادة بناء البيئات السحابية بشكل موثوق ومكرر من مستودعات الأكواد المعتمدة.
3. توثيق أدلة التشغيل واستجابة الطوارئ (Operational Runbooks)
ينبغي أن يتضمن التسليم أدلة تشغيلية مكتوبة بوضوح تنظم كيفية التعامل مع العمليات اليومية وحالات التعطل الطارئة، بحيث يستطيع مهندس جديد استلام العمل فوراً دون الحاجة للرجوع للمهندس المغادر.
- خطوات النشر والإلغاء (Deploy & Rollback): توثيق خطوات إطلاق التحديثات وكيفية التراجع السريع عند حدوث خلل برمجي.
- إجراءات التعافي من الانقطاع: تحديد الخطوات التفصيلية لإعادة تشغيل الخدمات، واستعادة النسخ الاحتياطية لقواعد البيانات.
- جاهزية استجابة الطوارئ: تتطلب خطوط الاستجابة للطوارئ بحسب إرشادات هندسة موثوقية الأنظمة من Google توفير أدلة تشغيل واضحة تمكّن أي مهندس بديل من إدارة الأعطال دون الاعتماد على المستقلين السابقين.
4. تدوير وتغيير كافة مفاتيح الوصول والكلمات السرية
فور الانتهاء من مراجعة البنود وإقرار التسليم، يجب تنفيذ عملية تدوير شاملة (Credential Rotation) لكافة المفاتيح والكلمات السرية التي كانت متاحة لمهندس DevOps خلال فترة التعاقد.
- مفاتيح SSH ورموز الوصول: إلغاء مفاتيح SSH الخاصة بالمهندس المغادر وتغيير رموز الوصول (API Tokens) وكلمات سر قواعد البيانات.
- حسابات الخدمات (Service Accounts): إعادة إصدار مفاتيح الحسابات البرمجية وتحديثها في منصات التسليم المستمر (CI/CD).
- إلغاء الوصول لـ VPN والمستودعات: سحب صلاحيات الوصول لمستودعات الأكواد وبيئات العمل عبر المنصات الحرة في تصفح المشاريع والوظائف.
5. نقل ملكية أنظمة المراقبة والتنبيهات للشركة
يجب التأكد من أن جميع التنبيهات التشغيلية واللوحات التحليلية المخصصة لمراقبة أداء السيرفرات موجهة إلى قنوات الاتصال الرسمية الخاصة بالشركة وليس لبريد أو هاتف المهندس المغادر.
- قنوات التنبيه: ربط تنبيهات الأعطال والضغط العالي بقنوات Slack أو PagerDuty أو بريد فريق العمل الإداري.
- لوحات المراقبة (Dashboards): نقل حسابات Grafana وDatadog وPrometheus لملكية الشركة واستبعاد البريد الشخصي للمستقل.
- الربط الفني للتنبيهات: يضمن ضبط تنبيهات الإنتاج وفق وثائق المراقبة والتنبيه من Grafana توجيه مؤشرات النظام وإشعارات الانقطاع مباشرة إلى قنوات الاتصال المدارة بوساطة الشركة.
6. جلسة التوضيح المباشر وااختبار التسليم (Live Walkthrough)
لا تكتفي باستلام الملفات عبر البريد؛ بل اطلب جلسة توضيحية مباشرة عبر الفيديو (Live Walkthrough) يقدم فيها مهندس DevOps عرضاً حياً لكافة مكونات التسليم.
- محاكاة عملية النشر: قيام المهندس بنشر تحديث تجريبي على بيئة الاختبار وتطبيق التراجع الحركي أمامه.
- اختبار استعادة النسخة الاحتياطية: إجراء تجربة حية لاستعادة نسخة احتياطية من قاعدة البيانات والتأكد من سلامة البيانات.
- الإجابة عن الاستفسارات: الإجابة عن أسئلة الفريق الفني للشركة وتوثيق أي ملاحظات ختامية قبل إنهاء الصفقة.
جدول ملخص بنود قائمة تحقق تسليم DevOps
يوضح الجدول التالي البنود الرئيسية لقائمة التسليم، المخرجات المطلوبة، آلية التحقق، ومخاطر إهمال البند عند إنهاء التعاقد:
| بند التسليم | المخرج المطلوب | آلية التحقق الفعالة | مخاطر الإهمال |
|---|---|---|---|
| ملكية السحابة والوصول | حساب المالك الرئيسي Root Account | تسجيل الدخول بالبريد الرسمي وتأكيد 2FA | فقدان السيطرة على البنية التحتية |
| كود البنية التحتية IaC | ملفات Terraform / Ansible بالمستودع | بناء بيئة اختبار كاملة من الكود | عجز الشركة عن تعديل السيرفرات مستقبلاً |
| أدلة التشغيل Runbooks | وثيقة خطوات Deploy وRollback والأعطال | مراجعة الخطوات وااختبارها مع مهندس آخر | توقف العمل عند حدوث أي طارئ تشغيلي |
| تدوير المفاتيح السرية | تغيير مفاتيح SSH وAPI وتصاريح IAM | فحص سجلات الوصول وإلغاء المفاتيح القديمة | تعرض النظام لااختراقات أو وصول غير مصرح |
| قنوات المراقبة والتنبيه | تحويل تنبيهات Grafana برسمياً للشركة | إرسال تنبيه تجريبي واستلامه في Slack/Mail | تأخر اكتشاف انقطاع الخدمة والأعطال |
| جلسة العرض المباشر | فيديو توضيحي واختبار حي للتسليم | حضور الجلسة وتجربة استعادة Backup حي | استلام ملفات ناقصة أو غير قابلة للتشغيل |
الأسئلة الشائعة
ماذا تفعل إذا رفض مهندس DevOps تسليم كود البنية التحتية (IaC)؟
يجب أن يتضمن عقد العمل بوضوح أن جميع أكواد البنية التحتية والملفات البرمجية هي ملكية فكرية مطلقة للعميل. إذا رفض المهندس التسليم، يمكنك اللجوء لنظام الضمان والوساطة عبر المنصة وحجب الدفعة النهائية حتى استلام كافة الأصول المطلوبة.
كم تستغرق عملية تسليم مهام DevOps في المتوسط؟
تستغرق عملية التسليم الشاملة عادة من 3 إلى 7 أيام عمل بحسب حجم البنية التحتية وتعدد الخدمات السحابية، وتتضمن مراجعة المستودعات، وتدوير المفاتيح، وعقد جلسة العرض المباشر.
هل يمكن الاستعانة بمهندس DevOps آخر لمراجعة التسليم؟
نعم، من الممارسات الموصى بها توظيف مهندس DevOps آخر لمدة ساعات معدودة لإجراء مراجعة مستقلة (Peer Review) على الملفات المسلمة والتأكد من إمكانية تشغيل البنية التحتية دون مشاكل.
الخلاصة
يعد تطبيق قائمة تحقق تسليم مهام DevOps ضمانتك الأساسية للحفاظ على استقرار مشروعك السحابي وحماية أصولك التقنية عند إنهاء التعاقد مع المستقلين. عبر نقل الملكية الجذرية، واستلام أكواد IaC كاملة، وتوثيق أدلة التشغيل، وتدوير المفاتيح الأمنية، تحمي شركتك من الاعتماد الفردي وتضمن انتقالك السلس لأي مرحلة تطوير مستقبلي.
عن الكاتب
سارة محمود — استشارية تصميم وتجربة المستخدم: متخصصة في تحليل كفاءة العمليات الرقمية، وتصميم رحلات المستخدم، وتحسين آليات تسليم المشاريع التقنية بين الشركات والمستقلين لضمان أعلى مستويات الأمان والجودة التشغيلية.
