لماذا يفشل السماح لكل فريق ببناء خط أنابيب خاص به

تخيل هذا: مؤسستك لديها خمسة فرق محاذية للتيار. كل فريق يبني خط أنابيب CI/CD خاص به من الصفر. فريق يختار Jenkins، وآخر يذهب مع GitLab CI، وثالث يقسم بـ GitHub Actions. كل فريق له طريقته الخاصة في إدارة بيئات التدريج، والنشر إلى الإنتاج، وتخزين الأسرار مثل مفاتيح API أو كلمات مرور قواعد البيانات.

في البداية، يبدو هذا كحرية. الفرق تتحرك بسرعة. تختار ما يناسبها. لا أحد عالق في انتظار فريق مركزي.

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

هذه ليست حرية. هذا تجزئة متنكرة في زي استقلالية.

المشكلة في بناء كل شيء من الصفر

عندما يبني كل فريق خط أنابيبه الخاص بشكل مستقل، تدفع المؤسسة ضريبة خفية. تظهر الضريبة بعدة طرق:

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

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

ما يفعله فريق المنصة فعلاً

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

يمكن أن تشمل المنصة:

• خطوط أنابيب CI/CD موحدة
• قوالب لبيئات التطوير والتدريج
• أدوات النشر
• مراقبة وتسجيل مركزين
• نظام مشترك لإدارة الأسرار

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

فريق المنصة يبني الأساس. الفرق المحاذية للتيار تبني فوقه.

فخ الاختناق

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

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

النموذج الصحيح هو الخدمة الذاتية. فريق المنصة يوفر قدرات يمكن للفرق المحاذية للتيار استخدامها بأنفسهم. فريق المنصة يحدد الواجهة، الـ API، القالب. الفريق المحاذي للتيار يشغل خط الأنابيب، يتخذ القرار، ويمتلك النتيجة.

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

كيف يتطور فريق المنصة

فريق المنصة لا يمكن أن يكون ثابتاً. احتياجات الفرق المحاذية للتيار تتغير بمرور الوقت.

في البداية، قد يكون خط أنابيب بسيط يبني ويختبر وينشر كافياً. لكن مع نمو المؤسسة، تبدأ الفرق في الاحتياج للمزيد. فريق يحتاج اختبارات تكامل مع قاعدة بيانات حقيقية. آخر يحتاج بيئة تدريج تعكس الإنتاج بشكل وثيق. ثالث يحتاج نشراً تدريجياً (canary deployment) لطرح التغييرات تدريجياً.

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

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

ما الذي يتغير عندما تفعلها بشكل صحيح

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

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

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

قائمة مراجعة سريعة لبدء فريق منصة

إذا كنت تفكر في تشكيل فريق منصة، إليك بعض الأشياء للتحقق منها مبكراً:

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

الخلاصة

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

الفرق هو ما إذا كنت تبني أساساً أم بوابة. ابنِ أساساً.