تُعد عملية التسليم التشغيلي (Operational Handoff) اللحظة التي يتحول فيها النظام -الذي تم بناؤه في موقع العميل- من نظام يديره المهندس الميداني (FDE) بناءً على خبرته وحدسه الشخصي، إلى نظام يديره فريق العميل بوعي وفهم كامل. يعني التسليم التشغيلي أن العميل قادر على تشغيل النظام بشكل يومي، وإصلاح الأعطال عند حدوثها، وإجراء تعديلات آمنة دون الحاجة لوجودك معهم.
لنتأمل الموقف التالي: لقد قمت ببناء خدمة داخلية لفرز مطالبات التأمين بمساعدة الذكاء الاصطناعي لصالح شركة “HarborView Insurance”. تعمل هذه الخدمة على منصة Kubernetes وتستخدم قاعدة بيانات PostgreSQL وذاكرة تخزين مؤقت Redis، وتتم فيها استدعاءات النماذج (model calls) عبر بوابة داخلية. سارت المرحلة التجريبية بنجاح، وترغب الإدارة في الانتقال إلى مرحلة التشغيل الفعلي (الإنتاج)، ومن المقرر أن تغادر موقع العمل خلال ثلاثة أسابيع.
في هذه المرحلة النهائية، لا يكمن السؤال الحقيقي في ما إذا كان النظام يعمل اليوم، بل في قدرة شركة “HarborView” على الحفاظ على استمرارية عمل النظام عند وقوع حادثة تقنية في ليلة ما (مثل ليلة الثلاثاء)، وقدرتهم على تعديله في الربع القادم دون التسبب عن غير قصد في ثغرة أمنية أو مشكلة تتعلق بالموثوقية.
غالباً ما تفشل عملية التسليم لأن الأطراف المعنية تستخدم مصطلح “تم الإنجاز” (Done) بمعانٍ مختلفة؛ فقد تقصد أنت أن قائمة المهام المتراكمة (backlog) قد أُنجزت وأن مؤشرات لوحات التحكم تظهر باللون الأخضر (تشير للسلامة)، بينما قد يقصد العميل قدرتهم على نشر التحديثات دون الحاجة لاستدعائك، وأن فريق الأمن لديهم قد وافق على إجراءات الوصول وتسجيل الأحداث (logging).
لذا، يجب تعريف “الإنجاز التام” كمجموعة من معايير النجاح التي تغطي جوانب الموثوقية والأمن ومسؤولية التسليم. أنت لا تسعى لضمان عدم وقوع أي حوادث تقنية إطلاقاً، بل تسعى لضمان أنه عند وقوع حادثة ما، يكون العميل قادراً على اكتشافها وتشخيصها والتعافي منها دون الاعتماد على معرفتك أو سياقك الخاص (الذي لا يملكه غيرك).
تعرّف على طريقة بسيطة لتقييم ما إذا كانت عملية التسليم قد اكتملت بالفعل.
المبدأ الأساسي هنا هو أن كل معيار للنجاح يتطلب وجود “مسؤول” و"دليل إثبات". ودليل الإثبات هو شيء ملموس يمكن الإشارة إليه، مثل رابط لدليل التشغيل (runbook)، أو طلب صلاحيات مكتمل، أو إدراج اسم في جدول المناوبات، أو عملية نشر ناجحة للنظام يقوم بها فريق العميل تحت إشرافك.
الدليل أقوى من الوعود إذا تعذر التحقق من متطلب تسليم العمل خلال مراجعة سريعة، فهو لا يُعد متطلباً مكتملاً بعد.
عندما تكون عملية تسليم العمل (handoff) ضعيفة، فإن أول انقطاع في الخدمة يولد مشكلة ثانية. فبينما يكون الانقطاع تقنياً بطبيعته، تتمثل المشكلة الثانية في الارتباك بشأن المسؤولية، مما يطيل أمد الانقطاع ويشعل دوامة من تبادل الاتهامات.
تخيل أن نظام HarborView يتلقى تنبيهاً يفيد بتضاعف زمن الاستجابة (عند الشريحة المئوية 95 أو p95) وحدوث تجاوز للمهلة الزمنية (timeout) في الطلبات. يفتح المهندس المناوب لوحة التحكم فيرى عشرة تنبيهات متلاحقة تظهر في آن واحد؛ فهو لا يعرف أيها المهم، ولا يملك صلاحية إعادة تشغيل عملية النشر في بيئة الإنتاج (Kubernetes)، ولا يجد دليلاً للتشغيل يوضح طبيعة الأداء “الطبيعي” لبوابة النموذج (model gateway).
يقومون بالتواصل معك، فتزودهم بثلاث حقائق تعلمتها أثناء مرحلة البناء، فيعود النظام للعمل. وبعد أسبوعين، تتكرر المشكلة، لكنك تكون حينها على متن رحلة جوية، فيستمر الانقطاع لفترة أطول بثلاث ساعات. قد يكون السبب الجذري هو “اندفاع التخزين المؤقت” (cache stampede) أو سوء تقدير حجم مجمع اتصالات قاعدة البيانات، إلا أن طول فترة الانقطاع كان ناتجاً عن غياب أساسيات التشغيل، وليس عن الخلل البرمجي نفسه.
لاحظ كيف تتحول العناصر المفقودة في عملية تسليم العمل إلى حوادث تستغرق وقتاً أطول وتخلق فوضى في تحديد المسؤوليات.