السحابة و DevOps: قدرة تشغيل مستمرة، لا إعداد لمرة واحدة

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

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

لاحظ الكلمة المفتاحية في التعريف: طريقة عمل. لا يمكن شراء طريقة عمل كإعداد يُسلَّم مرة ثم يُنسى. البنية التحتية لا تُعدّ وتُترك: الفاتورة ترتفع، والشهادات تنتهي، والحزم تتقادم، والنسخة الاحتياطية التي لم تُختبر ليست نسخة. من يبني لك خط CI/CD ثم يغادر يترك لك آلة لا يعرف أحد كيف يصلحها يوم تتوقف.

لماذا يهمّك هذا كصاحب عمل سعودي؟ لأن الفرق ملموس في المال والوقت. الشركة التي تعتمد بنية سحابية و DevOps ناضجين تطلق ميزة جديدة في أيام بدل أسابيع، وتكتشف الأعطال قبل أن يشتكي العميل، وتدفع فاتورة بنية تحتية تتناسب مع نموها الفعلي لا مع تخميناتها. ومع تسارع التحول الرقمي، صارت هذه القدرة فارقاً تنافسياً حقيقياً بين من يتحرك بسرعة ومن يتعثّر عند كل تحديث.

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

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

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

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

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

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

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

• البنية التحتية كرمز (Infrastructure as Code): تُكتب بنيتك التحتية كملفات يمكن مراجعتها وإعادة إنشائها بالكامل، فلا توجد خوادم 'سحرية' لا يعرف أحد كيف أُعدّت
• خطوط CI/CD: أتمتة كاملة من لحظة دفع الكود حتى وصوله للإنتاج، مع فحوص واختبارات تلقائية تمنع الكود المعطوب من المرور
• المراقبة والتنبيهات: لوحات حيّة وتنبيهات ذكية تخبرك بالمشكلة قبل أن يكتشفها عميلك، مع مقاييس للأداء وزمن الاستجابة ومعدّل الأخطاء
• النسخ الاحتياطي: نسخ منتظمة ومؤتمتة ومُختبَرة فعلياً. النسخة التي لم تُختبر استعادتها ليست نسخة احتياطية بل وهم
• التعافي من الكوارث: خطة واضحة وموثّقة لاستعادة الخدمة بعد عطل كبير، بأهداف محددة لزمن الاستعادة (RTO) وحجم البيانات المقبول فقدانه (RPO)
• الأمان: ترسيخ الأمان داخل خط التطوير نفسه عبر فحص الثغرات وإدارة الأسرار وضبط الصلاحيات بدل معالجته كخطوة أخيرة منفصلة

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

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

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

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

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

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

أما الإيقاع فثابت: Sprint أسبوعي ينتهي بـ demo لما بُني فعلًا، وتقدير مكتوب قبل أي مهمة، وموافقتك قبل تجاوزه، وتقرير أسبوعي بما أُنجز وما استُهلك وما التالي، بما في ذلك ما تغيّر في الفاتورة ولماذا. يقود الفريق Tech PM من كادر، ويضمّ مهندسي DevOps و backend. المهندسون موظفون لدى كادر ويعملون تحت إشرافها، وأنت تشتري تسليماً مُداراً ونتائج. وتحكم العلاقة اتفاقية إطارية (MSA) وبيان عمل (SOW) يُتفق عليهما قبل بدء العمل، وفيهما النطاق والصلاحيات وشروط الملكية الفكرية.

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

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

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

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

أي نموذج يناسبك؟ إن كانت لديك بنية قائمة تعمل وتحتاج تشغيلاً ومراقبة وتعديلات متفرّقة بلا خارطة طريق مستمرة، فـ ساعات كادر (/services/hours) هي المناسبة. وإن كانت لديك خارطة طريق منتج تحتاج فريقاً كل أسبوع يبني ويشغّل معاً، فـ فرق كادر (/services/squads). وإن كنت تبني قسماً هندسياً طويل الأمد بعدة تخصصات، فـ مركز كادر للتطوير (/services/offshore). تواصل معنا وصف وضعك الحالي، ونرشّح لك الأنسب دون أن نبيعك أكبر مما تحتاج.