أسس سحابية موثوقة لا تلفت الانتباه

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

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

ونحن نبني على أربعة أسس، سواء كان الهدف Azure أو AWS أو بيئة هجينة.

1. البنية التحتية كرمز (IaC)

ينبغي تعريف كل مورد، من الشبكات وقواعد البيانات إلى سجلات DNS وقواعد التنبيه، في شيفرة تُراجَع كما تُراجَع شيفرة التطبيق، وتُطبَّق عبر خط نشر. نستخدم Terraform (أو نسخته مفتوحة المصدر OpenTofu) حين تريد الفرق أداة واحدة عبر المزودين، وBicep حين يلتزم الفريق بـ Azure ويريد أدوات المزود الرسمية. أما AWS CDK أو CloudFormation فخياران معقولان للفرق التي تعمل على AWS وحدها.

وما يهم أكثر من الأداة:

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

2. المراقبة من اليوم الأول

لا يمكنك تشغيل ما لا تراه. لذا يجب أن تكون المراقبة جاهزة قبل وصول أول مستخدم، لا بعد أول انقطاع.

عمليًا نُعدّ ما يلي:

• سجلات منظمة بحقول متسقة (معرّف الطلب، والمستخدم أو المستأجر، والخدمة، والبيئة)، تُجمع مركزيًا في Azure Monitor وLog Analytics أو Amazon CloudWatch أو منظومة مفتوحة المصدر مثل Grafana مع Loki وPrometheus.
• مقاييس وتتبعات، ويُفضَّل أن تكون عبر OpenTelemetry، ليمكن تتبع الطلب البطيء عبر الخدمات وقواعد البيانات.
• فحوص سلامة وتنبيهات مرتبطة بأثرها على المستخدم، مثل معدلات الأخطاء وزمن الاستجابة والمهام الخلفية الفاشلة، بدل التنبيه عند كل ارتفاع في استهلاك المعالج.
• أدلة تشغيل مرتبطة بالتنبيهات، ليعرف المناوب الخطوات الأولى.

كما تفيد السجلات والمقاييس في ضبط التكلفة؛ فمعرفة ما تستهلكه كل خدمة تجعل النقاش حول الميزانيات وتحجيم الموارد قائمًا على الوقائع لا على التخمين.

3. الهوية بأقل الصلاحيات

الهويات ذات الصلاحيات المفرطة من أكثر نقاط الضعف السحابية شيوعًا وخطورة. وأساسنا في ذلك:

• الهويات المُدارة في Azure وأدوار IAM في AWS لأحمال العمل، بدل مفاتيح وصول طويلة الأمد في ملفات الإعداد.
• الأسرار في Key Vault أو Secrets Manager، لا في الشيفرة المصدرية ولا في متغيرات خط النشر نصًّا صريحًا، مع تدويرها حيث تدعم الخدمة ذلك.
• أدوار ضيقة ومحددة الغرض. يستطيع التطبيق قراءة حاوية التخزين الخاصة به، لا كل الحاويات في الاشتراك أو الحساب.
• وصول البشر عبر تسجيل دخول موحّد مع مصادقة متعددة العوامل، ورفع مؤقت للصلاحيات في المهام الإدارية، ومراجعات دورية لمن يملك حق الوصول إلى ماذا.
• هويات خطوط النشر عبر اتحاد هوية أحمال العمل (OIDC) حيث يكون مدعومًا، كي لا تحتفظ أنظمة CI/CD ببيانات اعتماد سحابية ثابتة.

4. مسارات ترقية ذات بوابات موافقة

ينبغي بناء بيئات التطوير والتجريب والإنتاج من الشيفرة نفسها بمعاملات مختلفة، بحيث يكون ما نجح في التجريب هو نفسه ما يعمل في الإنتاج.

ويبدو مسار الترقية السليم على هذا النحو:

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

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

Azure أم AWS؟

تنطبق هذه المبادئ على المزودين كليهما. أما الخيارات الخاصة بكل مزود، مثل AKS أو EKS، وAzure SQL أو RDS، وApp Service أو ECS، فتعتمد على مهارات فريقك وتراخيصك وعقودك الحالية والتوفر الإقليمي ومتطلبات إقامة البيانات. وكثير من أحمال العمل لا تحتاج إلى Kubernetes أصلًا؛ فمنصة حاويات مُدارة مثل Azure Container Apps أو ECS على Fargate تكون غالبًا أبسط تشغيلًا. ونوصي باختيار أبسط منصة تلبي متطلباتك، ثم تطبيق الأسس الأربعة باتساق.

أسس تتيح للفرق التركيز على المنتج

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