الحوسبة السحابية وDevOps

لماذا أصبحت الحوسبة السحابية وDevOps ضرورة تشغيلية؟

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

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

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

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

من «نقل الخادم» إلى «بناء منصة تشغيل»

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

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

الضغط التنظيمي: البيانات والامتثال في السياق السعودي

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

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

ضغط التكلفة والكفاءة على الشركات الصغيرة والمتوسطة

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

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

من يحتاج هذه الخدمات؟

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

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

ما الذي يشمله قسم الحوسبة السحابية وDevOps؟

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

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

مبادئ نبني عليها

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

ما لا يشمله القسم

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

كيف نحدد أولوية البداية؟

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

الفروع والخدمات الثمانية

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

حالات استخدام عملية

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

1. متجر إلكتروني ينتقل من استضافة مشتركة إلى AWS

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

نبدأ بتقييم التطبيق وحركة الزوار وحجم الصور والاعتماديات. ثم نصمم بيئة AWS مناسبة: Route 53 للنطاق، وCloudFront وS3 لخدمة الصور والملفات الثابتة، وALB لتوزيع الطلبات، وتشغيل التطبيق على ECS Fargate أو مجموعة EC2 قابلة للتوسع، وقاعدة بيانات RDS MySQL بنسخة احتياطية متعددة المناطق، وElastiCache للجلسات، وWAF للحماية. ننشئ بيئة staging مطابقة، ونختبر مسار الشراء والدفع عبر مدى والبطاقات والخصومات، ثم ننتقل تدريجيًا مع خفض TTL للنطاق وخطة رجوع.

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

2. فريق SaaS يريد إصدارات أسبوعية بدلًا من إصدار شهري

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

نبني خط CI/CD على GitHub Actions: فحص الكود، وتشغيل اختبارات الوحدة والتكامل، وبناء صورة Docker، وفحص الاعتماديات، ونشر إلى بيئة staging تلقائيًا عند الدمج. ثم نضيف نشرًا تدريجيًا إلى الإنتاج مع feature flags، ونفصل ترحيلات قاعدة البيانات عن نشر الكود، ونضع سياسة تراجع. نربط التنبيهات بمؤشرات الخدمة، ونجعل كل إصدار يحمل رقمًا واضحًا يمكن تتبعه في السجلات.

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

3. شركة لوجستية تحتاج إلى تعافٍ من الكوارث

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

نبدأ بتحليل أثر الأعمال: ما الأجزاء التي يجب أن تعود أولًا؟ نتفق على RPO وRTO واقعيين لكل نظام، ثم نصمم نسخًا احتياطية مشفرة إلى حساب منفصل مع حماية من الحذف، وننسخ قاعدة البيانات إلى منطقة ثانية. نبني بيئة احتياطية صغيرة عبر Terraform تعمل عند الحاجة (Pilot Light)، ونكتب runbook يحدد من يعلن الحادث، ومن يحوّل حركة المرور، وكيف نتحقق من سلامة البيانات بعد الاستعادة.

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

4. شركة ناشئة تتبنى Kubernetes بفريق صغير

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

نقيّم الحاجة أولًا: هل التعقيد مبرر؟ في هذه الحالة، وجود خمس خدمات وتوسع غير متوقع يجعل Kubernetes المُدار خيارًا معقولًا، بشرط تقليل الإضافات. نستخدم EKS أو GKE مع عُقد عمل مُدارة، وArgo CD للنشر، وPrometheus وGrafana للمراقبة، وHPA للتوسع. نبدأ دون service mesh، ونضيف فقط ما يحتاجه الفريق: ingress، وإدارة أسرار، وسياسات شبكة أساسية، ونسخًا احتياطية للحالة الدائمة.

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

5. شركة تريد خفض فاتورة السحابة دون تعطيل الأعمال

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

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

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

أخطاء شائعة ترفع التكلفة وتضعف الاعتمادية

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

1. الرفع والنقل دون إعادة تصميم

نقل الخادم كما هو إلى السحابة (Lift and Shift) قد يكون خطوة أولى مشروعة عند الحاجة إلى سرعة الخروج من مركز بيانات، لكنه ليس نهاية الطريق. النتيجة غالبًا خادم سحابي كبير يعمل بنفس الطريقة القديمة، بلا توسع تلقائي، وبنسخ احتياطي يدوي، وفاتورة أعلى. ننصح بتحديد التطبيقات التي تستفيد من إعادة التصميم، وترحيل الباقي تدريجيًا، ومراجعة المعمارية بعد الاستقرار.

2. أسرار داخل المستودع أو في متغيرات مكشوفة

كلمة مرور قاعدة بيانات في ملف `.env` مرفوع إلى Git، أو مفتاح سحابي دائم داخل إعدادات خط النشر، أو رمز وصول في سجل بناء. هذه الأخطاء تنتشر لأنها تعمل بسرعة، لكنها تمنح أي شخص لديه وصول إلى المستودع أو السجلات قدرة على اختراق البيئة. الحل ليس فقط حذف الملف من آخر commit؛ يجب إبطال المفتاح، ومراجعة السجلات، والانتقال إلى إدارة أسرار مركزية وهوية مؤقتة، وإضافة فحص تلقائي يمنع تكرار الخطأ.

3. غياب الرؤية عن التكلفة وملكيتها

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

4. التعديل اليدوي من لوحة التحكم

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

5. نسخة احتياطية لم تُختبر

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

6. مراقبة كل شيء وتنبيه لا يقرأه أحد

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

7. تبنّي Kubernetes قبل الحاجة

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

8. غياب الملكية وخطة الاستدعاء

من يملك الخدمة بعد الإطلاق؟ من يرد على التنبيه في الثانية صباحًا؟ من يقرر التراجع؟ إذا لم تكن الإجابات واضحة، فستتأخر الاستجابة حتى يجد شخص ما المشكلة. نحدد مالكًا لكل خدمة، وخطة on-call واقعية، وقناة تصعيد، وحدود صلاحية. الملكية ليست عقابًا لفريق، بل شرط لاتخاذ القرار بسرعة.

مؤشرات نقيسها معك

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

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

كيف نعمل؟ منهجية من ست مراحل

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

حوكمة المشروع والتواصل

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

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

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

المخرجات والتسليمات

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

• تقييم الجاهزية وخطة الترحيل: جرد التطبيقات والاعتماديات، والمخاطر، والموجات المقترحة.
• تصميم المعمارية: مخطط البيئات والحسابات والشبكة والهوية والبيانات، مع قرارات موثقة.
• بنية تحتية ككود: مستودع Terraform منظم بوحدات وبيئات، وسياسات ومراجعة تغيير.
• خطوط نشر: CI/CD موثق، مع اختبارات وبوابات جودة ومسار تراجع.
• بيئات جاهزة: تطوير واختبار وإنتاج منفصلة، وقوالب لإضافة خدمة جديدة.
• مراقبة وتنبيهات: لوحات Grafana، وتنبيهات مرتبطة بـrunbooks، وتقرير SLO.
• خطة نسخ احتياطي وتعافٍ: سياسات احتفاظ وتشفير، وتقرير اختبار استعادة.
• تقرير تكلفة: توزيع الإنفاق، والفرص المقترحة، والميزانيات والتنبيهات.
• دليل تشغيل: إجراءات النشر والتراجع والاستجابة للحوادث والصيانة.
• تدريب وتسليم: جلسات عملية مع الفريق، وخطة تحسين لما بعد المشروع.

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

كيف نسلّم؟

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

التسعير ونماذج التعاون

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

العوامل التي ترفع أو تخفض التكلفة

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

ما لا يشمله العرض عادة

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

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

الأسئلة الشائعة

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

خدمات ذات صلة

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