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