تسريع التسليم باستخدام المسارات الذهبية والسياسات ككود

By Mirko Peters · 2026-08-13

مرحبًا بعودتكم إلى حلقة جديدة من الغوص العميق في واقع هندسة البرمجيات الحديثة. إذا كنتم تتابعون بودكاستنا، فأنتم تعلمون أننا نتناول كثيرًا الـ…

Automatically translated with AI from the original post. Read the English original

أهلاً بكم مجدداً في تعمّق آخر في واقع هندسة البرمجيات الحديثة. إذا كنتم تستمعون إلى بودكاستنا، فأنتم تعرفون أننا نناقش باستمرار العوائق التي يواجهها المطورون كل يوم. في منشور المدونة المصاحب هذا، نتوسع في حوار مهم من حلقتنا الأخيرة. نبحث في سبب شعور المطورين بأن تسليم البرمجيات الحديث أثقل وأعقد مما ينبغي، والأهم من ذلك، كيف تحل المؤسسات الهندسية ذات الرؤية المستقبلية هذه الأزمة باستخدام المسارات الذهبية والحوكمة الآلية. إذا لم تستمعوا إلى الحلقة بعد، فتأكدوا من الاستماع إلى الحلقة التأسيسية على The DevOps Tax: Why Your Platform is Failing للاطلاع على الملخص الصوتي الكامل.

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

مقدمة عن الضريبة على DevOps والحمل المعرفي للهندسة

لفهم سبب تباطؤ خطوط التسليم في بيئات المؤسسات فهماً حقيقياً، يجب أولاً أن ننظر إلى ما يستهلك وقت المطورين وانتباههم. لم تعد هندسة البرمجيات الحديثة تقتصر على كتابة منطق الأعمال، أو تصميم النماذج العلائقية، أو إنشاء واجهات مستخدم مبهرة. يُتوقع من المطورين اليوم أن يفهموا مجموعة هائلة من مفاهيم الأنظمة الموزعة. عليهم أن يُهيئوا الحاويات، ويتقنوا تنسيق Kubernetes، ويديروا شبكات الحوسبة السحابية، ويطبقوا التحكم في الوصول المستند إلى الأدوار (RBAC)، ويوفروا البنية التحتية السحابية باستخدام الكود، ويُعدّوا خطوط التكامل المستمر والنشر المستمر المعقدة، ويهيئوا منظومات المراقبة، وينفذوا التتبع الموزع، ويضمنوا الامتثال الأمني، ويحسّنوا تكاليف الحوسبة السحابية، ويخططوا للتعافي من الكوارث.

لا تُترجم أيٌّ من مهام البنية التحتية هذه مباشرةً إلى قيمة للعميل. لا يسجّل المستخدم الدخول إلى التطبيق ليُثني على المؤسسة لأنها تملك تعريفات Kubernetes Custom Resource Definitions الذكية. ومع ذلك، تستهلك هذه المهام التشغيلية نسبة مدهشة من طاقة الهندسة. تشير الأبحاث وملاحظات الصناعة إلى أن ما يصل إلى أربعة وسبعين بالمئة من طاقة المطورين قد تُستنزف في الأعمال الروتينية المتعلقة بالبنية التحتية. وهذا يخلق أزمة حمل معرفي حادة. يُطلب من المطورين الاحتفاظ بعشرات المفاهيم المتباينة للبنية التحتية في أذهانهم قبل أن يتمكنوا حتى من نشر خدمة مصغّرة أساسية. ويؤدي هذا التبديل المستمر للسياق مباشرةً إلى إرهاق المطورين، واضطراب جداول التسليم، وفي النهاية، تراجع كبير في العائد على الاستثمار الهندسي.

لماذا يتعثر DevOps التقليدي على نطاق المؤسسات

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

غير أنه على نطاق المؤسسات، تبدأ الفرق المستقلة بالتباعد عن بعضها بشكل طبيعي. فمن دون ضوابط مركزية ومنصات داخلية موحّدة، تعتمد الفرقة A منصة CI/CD معينة، بينما تختار الفرقة B منصة أخرى. وتنفّذ الفرقة C المراقبة باستخدام Prometheus وGrafana، في حين تستخدم الفرقة D أداة مراقبة SaaS مختلفة تمامًا. تتخذ كل فرقة قرارات تبدو منطقية وفعّالة عند النظر إليها بمعزل عن غيرها. لكنها مجتمعةً تخلق متاهة من التعقيد التنظيمي. تتباين الوثائق عبر الويكيات، وتبقى المعرفة غير الرسمية حبيسة عقول المهندسين الأقدم، ويستغرق تأهيل الكفاءات الجديدة أشهرًا بدلًا من أيام. وهكذا تتوقف المؤسسات عن بناء البرمجيات، وتجد نفسها غارقة في إدارة فوضى تشغيلية.

فهم آليات المسارات الذهبية

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

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

تحويل الحوكمة بالبنية التحتية كشيفرة وسياسات كشيفرة

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

تعالج هندسة المنصات هذه المشكلة من خلال نقل الحوكمة إلى مراحل أبكر من دورة التطوير، عبر البنية التحتية كشيفرة (IaC) والسياسات كشيفرة. فالبنية التحتية كشيفرة تحوّل إدارة البنية التحتية من النقر اليدوي في البوابات إلى برمجيات قابلة للتحكم بالإصدارات والاختبار. يُتتبَّع كل تغيير في طوبولوجيا الشبكات أو مجموعات الحوسبة أو حاويات التخزين في مستودعات git، ويخضع لمراجعة الأقران، ويُنشر عبر خطوط أتمتة. وهذا يضمن قابلية إعادة الإنتاج الكاملة ويحافظ على مسار تدقيق نظيف ودقيق.

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

تسريع التسليم واستعادة إنتاجية المطورين

يمثّل تلاقي هندسة المنصات والمسارات الذهبية المُوجَّهة (Golden Paths) والبنية التحتية ككود (Infrastructure as Code) والسياسات ككود (Policy as Code) نضجاً جوهرياً في طريقة تسليم البرمجيات الحديثة. فمن خلال تجميع خبرات البنية التحتية في فريق منتج منصة مخصص، تستطيع المؤسسات تحرير مطوّري المنتجات من العبء الثقيل لـ DevOps Tax. فبدلاً من قضاء أيام في ضبط ملفات Kubernetes أو التعامل مع أذونات الشبكات السحابية، يستطيع المطوّرون التركيز كلياً على حل مشكلات الأعمال وتقديم الميزات التي تُسعد عملاءهم.

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

لاستكشاف هذه المفاهيم بعمق والاستماع إلى أمثلة واقعية عن كيفية تحوّل هندسة المنصات لديناميكيات المؤسسة، تأكّد من الاطلاع على النقاش الكامل في البودكاست. يمكنك الاستماع إلى الحلقة مباشرةً وقراءة ملاحظات العرض الكاملة بزيارة The DevOps Tax: Why Your Platform is Failing. تبنَّ قوة المنصات، وأزِل الفوضى الذهنية، وابدأ اليوم في تسريع خط أنابيب التسليم لديك!