السحابة السيادية هي فرز لمحفظة الأنظمة، لا استبدال مورّد

أكبر خطأ أراه في نقاشات “السحابة السيادية” هو التعامل معها كتمرين مشتريات: استبدل AWS بمزوّد أوروبي، حدّث العرض التقديمي، واعتبر المهمة منجزة.

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

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

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

التعريف الوحيد المفيد: السيادة هي تحكم قابل للتدقيق

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

هذا الإثبات يأتي من control plane. ليس “منصة”، ولا “landing zone”، ولا “أفضل ممارسات”. بل مجموعة محددة من الآليات التي تقيّد السلوك يومياً.

إذا أردت نموذجاً ذهنياً، استعره من التشغيل الصناعي: المصنع ليس “آمناً” لأن الآلات أوروبية. هو آمن لأن إجراءات lockout-tagout، وضبط التغيير، وسجلات الصيانة، وتمارين السلامة موجودة ومطبَّقة. وضع السحابة السيادية لديك يحتاج الانضباط نفسه.

الخطوة الأولى هي الفرز: صنّف المحفظة قبل لمس أي شيء

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

1. أعباء مرساة (يجب نقلها). أنظمة تفرض قيوداً صارمة بفعل التعرض القانوني، أو ضوابط التصدير، أو عقود العملاء. غالباً: أدلة الهوية، إدارة المفاتيح، القياس الأمني (security telemetry)، وجزء من منصات البيانات. نقلها مكلف، لكن إبقاءها حيث هي يجعل السيادة مجرد قصة.
2. أعباء مترابطة (تُنقل لاحقاً بعد فك الارتباط). “حرجتها” غالباً نتاج التكاملات. خدمات محاذية لـ ERP، ووسيط التكامل، وقواعد بيانات مشتركة، وmessage brokers. إذا نفذتها lift-and-shift فسوف تنقل الهشاشة إلى البيئة الجديدة.
3. أعباء سلعية (تبقى، لكن تُقيَّد). أدوات التعاون، وأدوات المطورين، والتحليلات العامة. هنا تتحقق السيادة عبر السياسات وتقليل البيانات، لا عبر النقل. تأكد فقط أنك لا تخزّن بيانات منظَّمة حيث لا ينبغي، وتوقف عند ذلك.
4. مرشحو الإيقاف (لا تُرحّل). أسرع مكسب سيادي هو إيقاف أنظمة كان يجب إنهاؤها قبل ثلاث سنوات. الترحيل ذريعة ممتازة للحذف.

هذا الفرز ليس workshop تقني. إنه قرار قيادة. يفرض مفاضلات: التكلفة، ومخاطر التسليم، ومعنى “الحرج” فعلياً.

أنماط control plane التي تجعل السيادة واقعية

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

1) الهوية هي أصل التحكم

تنهار السيادة إذا كانت طبقة الهوية لديك خاضعة عملياً لجهة خارجية. النمط بسيط:

• هوية واحدة مُعتمَدة لهويات الموظفين والآلات. لا استثناءات محلية لكل سحابة.
• عزل الوصول المميّز. هويات إدارية منفصلة، رفع صلاحيات قصير الأمد، ومسارات موافقة صريحة.
• حسابات break-glass موجودة وتُختبر، لا تُوثَّق فقط.

إذا لم تستطع الإجابة عن: “من يمكنه تولّي صلاحيات admin في البيئة السيادية، وما الاعتماد الخارجي الذي يمنح هذه الصلاحية؟” فأنت لا تملك سيادة. أنت تملك استضافة.

2) المفاتيح ليست ميزة، بل حيازة

كل مزوّد يدّعي التشفير. سؤال المشغّل هو الحيازة: من يستطيع فرض الوصول، وأين تُدار المفاتيح فعلياً؟

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

هنا تتوقف “السيادة الرقمية” عن كونها خطاباً سياسياً وتصبح ممارسة تشغيلية.

3) التسجيل هو أثر التدقيق، لا بنداً ثانوياً

في جودة التشغيل الصناعي: إن لم يُسجَّل الحدث فكأنه لم يحدث. وفي السحابة: إن لم يُسجَّل الوصول فلا يمكن حوكمته.

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

هذا ينسجم مع طريقة تفكيري في تطبيقات الذكاء الاصطناعي أيضاً. يمكن لـ AI أن يساعدك في التلخيص والفرز، لكن طبقة الحقيقة هي أثر الأحداث. إذا أردت منظوراً مرتبطاً، فمقالتي AI leadership is workflow leadership تنطبق هنا. السيادة أيضاً سلسلة من عمليات التسليم، لا خياراً تقنياً.

4) جاذبية البيانات هي التي تحدد ما يمكن نقله

تفشل معظم برامج السيادة بسبب جاذبية البيانات، لا بسبب القدرة الحاسوبية. البيانات تسحب التطبيقات والتكاملات وسير العمل معها.

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

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

5) اختبارات الخروج هي KPI السيادة الوحيد الموثوق

كل مزوّد يعد بإمكانية النقل. مهمتك أن تحوّل الوعد إلى ممارسة روتينية.

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

هذا الجزء يتجنبه كثير من القادة لأنه يبدو “عملاً مهدوراً”. ليس مهدوراً. إنه تأمين، وهو أيضاً ورقة قوة في كل تفاوض مع المزوّدين.

درس من الواقع: الترحيلات تعاقب الغموض لا التعقيد

عندما أعدت بناء مؤسسة R&D ووسّعتها عبر البرمجيات المضمنة والسحابة والإلكترونيات والميكانيك وQA، تعلمت أن البرامج العابرة للمجالات تتعطل عندما تتداخل المسؤوليات. الناس يفعلون ما يمكنهم قياسه، ويتجاهلون ما لا يمكنهم قياسه.

برامج السحابة السيادية عابرة للمجالات بطبيعتها. الأمن يريد ضوابط. الشؤون القانونية تريد قابلية الدفاع. الهندسة تريد استمرارية. المالية تريد قابلية التنبؤ. إذا لم تترجم “السيادة” إلى control plane قابل للقياس، فسيفسرها كل فريق بطريقة مختلفة، ويتحول التسليم إلى جدل بدل تنفيذ.

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

رأيي: السحابة السيادية تُكتسب بانضباط التشغيل

السيادة ليست المزوّد. إنها الدليل.

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

هكذا تتجنب “المسرح”، وهكذا تجعل عبارة “تحت السيطرة الأوروبية” ذات معنى عندما تضرب الأزمة التالية.