تسلّم نظام من مطوّر رحل: من أين تبدأ

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

ما الذي تجردونه قبل أن تقرأوا شيئًا؟

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

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

لماذا تأتي الاستعادة قبل المراجعة؟

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

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

ما الذي تقرأونه أولًا، وما الذي تتركونه؟

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

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

كيف تجمّدون النطاق في الشهر الأول؟

الأسبوع	ما تفعلونه	ما تتركونه
1	جرد الحسابات، ونسخ البيانات، واختبار استعادة	كل تعديل في الكود
2	قراءة مسار النشر والمهام والربط	إعادة الهيكلة والترقيات
3	إصلاح ما يوقف المال فقط	ميزات جديدة
4	كتابة الملاحظات وقائمة المخاطر	وعود بمواعيد

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

ما الذي تكتبونه، ولمن؟

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

اكتبوا أثناء التعلّم لا بعده. ملاحظات الأسبوع الثاني هي التوثيق الذي لا يملكه أحد غيركم، وهي أيضًا الدليل على أن التسليم جرى كما يجب.

ما الذي يحوّل التسليم إلى انقطاع؟

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

والثاني تغيير شيء مبكرًا لإظهار تقدّم. نشر يسوء في الأسبوع الأول، قبل أن تعرفوا كيف يتعافى النظام القديم، يحوّل تسلمًا هادئًا إلى حادثة علنية تحمل اسمكم.

وثالث أخفض صوتًا: أن يصبح غياب المطوّر السابق تفسيرًا لكل فشل. بعض ما سينكسر الأسبوع القادم كان مكسورًا أصلًا.

ترتيب الثلاثين يومًا الأولى

1. خذوا نسخة للقراءة فقط من قاعدة البيانات والمستودع قبل أن تلمسوا شيئًا.
2. اجردوا كل حساب وبيانات دخول وعلاقة فوترة، وأشيروا إلى ما لا تصلون إليه.
3. تأكدوا من دفع التجديدات: النطاق، والاستضافة، وخطط الأطراف الثالثة. البطاقة المنتهية أسرع انقطاع متاح.
4. استعيدوا أحدث نسخة في مكان آخر وقيسوا المدة من أولها إلى آخرها.
5. بدّلوا بيانات الدخول التي صارت تحت يدكم، واحدة في كل مرة، وسجّلوا كل تبديل.
6. اقرأوا مسار النشر والمهام المجدولة.
7. اكتبوا تجميد النطاق لثلاثين يومًا وأرسلوه إلى صاحب القرار.
8. سلّموا وثيقة النتائج وقائمة المخاطر في نهاية الشهر.

أين يخطئ هذا؟

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

ما لا يغطيه هذا المقال

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

نتسلّم الأنظمة بهذا الترتيب — وصول، فاستعادة، فتجميد، فتوثيق — ونترك النتائج وراءنا، لأن التسليم التالي يجب أن يكون أقصر من هذا.