أبرز النقاط
- الثقة في المنصة تُبنى بالسلوك المتوقع يومياً لا بالميزات الجديدة
- المصدر المفتوح وفّر لغة مشتركة بين الفرق والموردين والأدوات في بيئة مصرفية متحفظة
- إشراك المطورين مبكراً وتحويلهم من مستهلكين إلى مساهمين يغيّر ديناميكية الفريق
في مؤتمر KubeCon Europe الأخير، قدّم كلٌّ من مارسي بارامونوفا وستيفان كوزان تجربتهما في بناء منصة سحابية داخل بيئة مصرفية — بيئة تتطلب مستويات ثقة وامتثال لا تتسامح مع الغموض. الخلاصة التي خرجا بها واضحة: المصدر المفتوح لم يكن خياراً تقنياً بحتاً، بل كان البوصلة التي أعادت تشكيل طريقة تعاون الفرق.
لماذا لا تكفي الميزات لكسب ثقة المطورين؟
أوضح كوزان أن المطورين لا يثقون بمنصة لأنها تحتوي ميزات متقدمة، بل لأنها تتصرف بشكل متوقع مرة بعد مرة. هذه الثقة لا تُقرَّر في اجتماع، بل تُبنى بالتشغيل اليومي والاتساق. في بيئة مصرفية، حيث الأسئلة الأولى تدور حول الدعم والمسؤولية، كان اختيار المصدر المفتوح غير بديهي — لكنه وفّر ما كان الفريق بأمسّ الحاجة إليه: معيار مشترك ولغة موحدة بين الفرق الداخلية والموردين والأدوات.
المنصة كنظام تعاون لا كمنتج منفصل
وصفت بارامونوفا المنصة بأنها نظام تعاون: فريق المنصة يعتمد على فرق التطبيقات، وفرق التطبيقات تعتمد على فريق المنصة، وكلاهما يحتاج معايير مشتركة للتقدم معاً. هذا التبادل لا يحدث تلقائياً، بل يتطلب آليات واعية.
من الآليات التي ابتكرها الفريق ما أسموه جلسات Genius Bar — جلسات دعم مفتوحة يأتي فيها المطورون بمشكلاتهم ويحلّها فريق المنصة معهم مباشرة، بدلاً من الاكتفاء بتذاكر دعم تقليدية. مع الوقت، انضمت فرق بنية تحتية أخرى إلى هذه الجلسات، فتحوّلت إلى منتدى تبادل معرفي غير رسمي.
كيف يقلّل الفريق العبء الذهني على المطورين؟
أشار كوزان إلى أن الفريق استثمر بكثافة في التوحيد والأتمتة والتميز التشغيلي. الهدف: أن يحصل المطور على التجربة ذاتها سواء نشر في بيئة التطوير أو الاختبار أو الإنتاج. بدلاً من كشف كل قدرات Kubernetes للمطورين، وفّر الفريق إعدادات افتراضية معقولة ومسارات عمل واضحة الرأي — ليركّز المطور على تطبيقه لا على تعقيدات البنية التحتية.
- توضيح مسؤوليات فريق المنصة وما يمكن للفرق توقّعه من مستويات الخدمة
- تحديد أين تبدأ مسؤولية الفرق التطبيقية التشغيلية
- تقليل الخيارات المعقدة عبر إعدادات افتراضية مدروسة
الشفافية المبكرة أفضل من المنتج المصقول
أوضحت بارامونوفا أن الفريق لم ينتظر الكمال قبل مشاركة المكونات الجديدة مع المستخدمين. بدلاً من ذلك، منحهم رؤية مبكرة لما يُبنى ولماذا. هذه الشفافية حوّلت المستخدمين من مستهلكين سلبيين إلى مختبرين مبكرين ومساهمين فعليين — علاقة لا يمكن لإعلان إصدار أن يبنيها.
ما الذي تغيّر في الثقافة الهندسية؟
أشارت بارامونوفا إلى أن مجتمعات المصدر المفتوح تمتلك ثقافة خاصة: توثيق القرارات، المساهمة العكسية، توضيح الملكية — من يصون مكوّناً ما، من يتخذ القرارات، وأين تذهب للمساعدة. الفريق حاول استيعاب هذه الممارسات داخلياً.
حين تتبنى Kubernetes، أنت لا تتبنى منسّق حاويات فحسب، بل تنضم إلى مجتمع له معاييره وتوقعاته وطريقة عمله المشتركة. هذا دفع الفريق نحو مزيد من الشفافية والتوثيق والتعاون عبر الحدود التنظيمية.
الملكية غيّرت الانخراط بين المهندسين — لم يعودوا موثوقين فقط لتنفيذ المهام، بل لاتخاذ قرارات حقيقية وإحداث أثر فعلي. كما أكدت بارامونوفا أن تطوير المهارات الناعمة — التواصل والتعاون — يساعد الجميع على العمل معاً بشكل أفضل.
المصدر المفتوح بوصلة لا عقيدة
أكد كوزان أن المصدر المفتوح ليس مجرد خيار برمجي، بل التزام. إذا غيّرت الأدوات فقط دون تغيير طريقة تفكير الناس وتعاونهم وبنائهم، ستصطدم بجدار. المصدر المفتوح لم يكن أبداً توجيهاً إدارياً أو عقيدة — لم يُخبرنا أحد بأن علينا استخدام المصدر المفتوح. كان بوصلة تساعدنا على توجيه هذا المسار.
رأي Logicity
تجربة هذا البنك تُظهر أن التحدي الحقيقي في platform engineering ليس تقنياً — Kubernetes وأدوات CNCF متاحة للجميع — بل ثقافي وتنظيمي. الفرق التي تبني منصات داخلية تواجه منافسة ضمنية من حلول مُدارة مثل Google GKE Autopilot أو AWS App Runner أو Azure Container Apps، والتي تُقلّل العبء التشغيلي مقابل تكلفة أعلى وتحكّم أقل. الفارق الذي يبرره فريق منصة داخلي هو بالضبط هذا النوع من الثقة والتخصيص — وهو ما لا يُشترى جاهزاً.
الأسئلة الشائعة
ما الفرق بين فريق المنصة وفريق DevOps التقليدي؟
فريق المنصة يبني منتجاً داخلياً يخدم المطورين ويوفر لهم خدمة ذاتية، بينما DevOps التقليدي غالباً ما يعمل كبوابة أو فريق دعم يتعامل مع طلبات فردية.
هل المصدر المفتوح مناسب للبيئات المصرفية المنظّمة؟
نعم، لكنه يتطلب استثماراً في بناء الثقة عبر التشغيل المتسق والتوثيق الواضح للمسؤوليات، كما فعل الفريق في هذه الحالة.
كيف أبدأ ببناء منصة داخلية لفريقي؟
ابدأ بفهم احتياجات المطورين الفعلية، وفّر إعدادات افتراضية معقولة بدلاً من كشف كل التعقيدات، وأشرك المستخدمين مبكراً كمساهمين لا كمستهلكين.
ما أبرز أدوات CNCF المستخدمة في بناء المنصات؟
Kubernetes كأساس، إضافة إلى أدوات مثل Argo CD للنشر المستمر، Prometheus للمراقبة، وCrossplane لإدارة البنية التحتية كشيفرة.
هل تحتاج مساعدة في التطبيق؟
إذا كنت تخطط لبناء منصة داخلية لفريقك أو تقييم أدوات CNCF لبيئتك، تواصل مع فريق Logicity للحصول على استشارة تقنية مخصصة.
عمر حسن
كاتب تقني وابتكار
أُنتِج هذا المقال بمساعدة الذكاء الاصطناعي وراجعه فريق التحرير في لوجيسيتي. اعرف المزيد في سياسة التحرير.
