لكي نتمكن من تصميم حلول رقمية سحابية يجب أن تعزز ببنيان تقني متميز، ولكي يكون البنيان التقني متميز يجب أن نأخذ بعين الاعتبار الكثير من الجوانب التي تؤثر في تصميم هذا البنيان،إطار العمل Azure Well-Architected يجمع كل هذه الجوانب ضمن خمسة ركائز أساسية للبنيان المتميز.
هذه التدوينة تشمل مراجعة عامة لهذه الركائز الأساسية، لو رغبت في معرفة المزيد من التفاصيل، لابد من الرجوع للتوثيق الرسمي الخاص بإطار العمل (Azure Well-Architected) على موقع مايكروسوفت.
لقد بذلت جهدي أن تحوي هذه التدوينة على :
- شرح وافي للركائز الأساسية
- ذكر أمثلة عملية من خدمات Azure السحابية الرئيسية التي قد تستخدم مثل خدمات تخزين الملفات و قواعد البيانات و المخدمات الافتراضية
- مناقشة أفضل الممارسات و الأدوات (best practices and tools)
إن كنت مطور برمجيات، محلل أعمال، مدير منتج رقمي، أو أي شخص يقوم بالمساهمة في بناء منتج رقمي بأي اختصاص كان، أعتقد أن الشرح العام في هذه التدوينة سيكون مفيد لك. لأن كل الفريق على اختلاف اختصاصاته يجب أن يمتلك فهم واضح للصورة الكبيرة للبنيان التقني للمنتج الرقمي.
باعتقادي مختلف الاختصاصات يجب أن تملك فهم مشترك واضح للبنية التقنية للمشروع، فهذا سيعزز من التواصل الفعال بينهم ووجود لغة مشتركة بين جميع أفراد الفريق.
لعل هذه التدوينة تساعد كل الأفراد التقنيين وغير التقنيين من تعزيز الفهم المشترك واللغة المشتركة فيما بينهم
هيا بنا لنبدأ في إطار العمل Azure Well-Architected!
الموثوقية (Reliability)
الموثوقية تدل على قدرة البنية التقنية على تفادي حدوث فشل وتوقف عن العمل ثم الاستمرارية بالقيام بالوظيفة المتوقعة منها. بعبارة أخرى:
كلما كان مجمل زمن تعطل (توقف) الخدمة أقل كلّما كانت أكثر موثوقية ويمكن الاعتماد عليها.
هناك جانب آخر من الموثوقية وهو متعلق بمدى سرعة عودة البنية التقنية للحالة السليمة في حال حدوث تعطل ولم يتم تفاديه
أي أن صفة الموثوقية تطلق على الأنظمة التي صمّمت بطريقة تأخذ بعين الاعتبار احتمالية حدوث فشل. لنقل أن صمموا البنية التقنية قد جعلوا إجراءات واحتياطات حدوث الفشل هي جزء من البنية نفسها (designed for failure).
يمكن تحقيق هذا المرتكز الهام ،الموثوقية، بطرق مختلفة بحسب طبيعة المتطلبات، فكل منتج رقمي أو نظام تقني له المتطلبات الخاصة وعليه التزامات مختلفة تجاه الزبائن . معنى آخر ليس كل الأنظمة الرقمية ذات حساسية عالية وخطورة في حال توقف، فليس متوقع من كل نظام رقمي أن يكون متاح ب99.999% من وقته.
الجدول التالي يوضح مستويات التوفر (Availability) المتنوعة وماذا تعني كل نسبة
جدول مستويات توفر الخدمة الرقمية (Availability Table)
| مستوى التوفر Availability Level | زمن توقف النظام المتوقع و المقبول على مدار السنة |
|---|---|
| 90% | 36.5 يوم |
| 95% | 18.25 يوم |
| 99% | 3.65 يوم |
| 99.5% | 1.83 يوم |
| 99.9% | 8.76 ساعة |
| 99.95% | 4.38 ساعة |
| 99.99% | 52.6 دقيقة |
| 99.999% | 5.26 دقيقة |
مثال عن الموثوقية في خدمة أزور للمخدم الافتراضي (Azure Virtual Machine)
لنفرض أن لدينا تطبيق ويب قديم (legacy) ونخطط لترحيله (migrate) إلى الخدمة السحابية. من أكثر الطرق شيوعاً لهذه الحالة هي طريقة ال (lift and shift) أي باختصار نقوم بنقل هذا التطبيق إلى الخدمة السحابية بدون تغييرات في بنية التطبيق، حيث سنقوم بمايلي:
- إنشاء مخدم افتراضي (VM) على مايكروسوفت Azure
- ضبط إعدادات برمجية مخدم الويب مثل (IIS, Apache) أوغيرها ضمن المخدم الافتراضي
- تحميل ملفات تطبيق الويب على المخدم
- ضبط السماحيات المطلوبة لكي يتمكن المستخدمين من الوصول للتطبيق مثل وجود (public IP) و فتح المنفذ رقم 80
لنتجنب الحديث عن عملية نقل قاعدة البيانات فقط لكي نختصر ونركز على المخدم الافتراضي كمثال رئيسي سنكمل به هذه التدوينة.
مخطط التصميم سيكون كالتالي:
الآن لنفكر كيف يمكن أن نطبق الموثوقية (Reliability) بما يتلائم مع حاجتنا من هذا التطبيق، أيضاً أؤكد أن الموثوقية لها مستويات مختلفة:
- ماذا لو توقف المخدم الافتراضي عن العمل بسبب فشل محرك القرص الصلب (disk drive failure) ؟
- ماذا لو فشل النطاق أو الرف الذي يتواجد به المخدم (Server Rack or Fault Domain) ؟
- ماذا لو فشل مركز البيانات (Data Center) بشكل كامل، كانقطاع التيار الكهربائي مثلاً بسبب فشل عام؟ (على الرغم أننا نتكلم عن الخدمة السحابية ولكن لا ننسى أنها مؤلفة من مراكز بيانات موزعة على الأرض وليس السحاب 🙂 )
- ماذا لو فشلت المنطقة السحابية (Azure Region) بشكل كامل بسبب كارثة طبيعية كزلزال مثلاً
إذن بناء على المتطلبات ومدى خطورة وحساسية عمل هذا التطبيق سنقوم بمايلي:
- سنطبق حلاً أو إجراءً ما لكل نوع من أنواع الفشل والتوقف المذكورة أعلاه، وبالتالي نزيد من موثوقية النظام
- ربما لن نقوم بأي إجراء لبعض أنواع الفشل والتوقف المذكورة أعلاه عندما يكون النظام متسامح مع هذا النوع من الفشل والتوقف
النتيجة النهائية هي تطبيق الموثوقية بماينسجم مع ماهو متوقع من النظام ضمن المتطلبات، وبعارة أخرى سنقلل من زمن الفشل والتوقف الذي قد يتعرض له النظام.
يوجد عدة مستويات من الفشل والتوقف التي قد تواجه النظام، ولكل مستوى سيكون هناك خيارات وحلول معينة.
ماذا لو توقف المخدم الافتراضي عن العمل بسبب فشل محرك القرص الصلب (disk drive failure) ؟
كما ذكرت سابقاً، أن اتفاقية مستوى الخدمة (SLA) التي تقدمها لزبائنك ستكون مبنية على اتفاقية مستوى الخدمة التي تحصل عليها من مايكروسوفت Azure كمزود خدمة سحابية لك. لذلك عندما نستخدم خدمة سحابية يجب أن نطلع على اتفاقية مستوى الخدمة الخاصة بها،
في مثالنا عن المخدم الافتراضي (Azure Virtual Machine) يمكن الاطلاع على الـ (SLA) الخاصة به من هنا.
كما تلاحظ من الصورة أعلاه، لتقليل احتمالية فشل القرص الصلب، يمكن استخدام النوع (Premium SSD) بدلا من الأنواع الأخرى (Standard SSD) أو (HDD). حيث أن النوع (Premium SSD Ultra Disk) يضمن 99.9% (Availability) توفر وإتاحية على مدار العام للمخدم الافتراضي المرتبط به.
| Premium SSD 99.9% | 8.76 ساعة فقط احتمالية التوقف والفشل على مدار العام |
| Standard SSD 99.5% | 43.92 ساعة = 1.83 يوم احتمالية التوقف والفشل على مدار العام |
| Standard HDD 95% | 438 ساعة = 18.25 يوم احتمالية التوقف والفشل على مدار العام |
إذا أردت استخدام الـ (Premium SSD) للحصول على أعلى توفر (Availability)، فإنك ستحصل على احتمالية توقف لمدة 8.76 ساعات في العام. ولكن ماذا لوكان النظام لا يتسامح حتى مع هذه الفترة القليلة نسبياً؟
لكي نوفر (Availability) أعلى، لننتقل إلى المستوى الثاني من سيناريوها الفشل والتوقف المحتملة ولنر هل يمكن تقليل زمن الفشل والتوقف أكثر من ذلك؟
ماذا لو فشل النطاق أو الرف الذي يتواجد به المخدم (Server Rack or Fault Domain) ؟
لتقليل زمن التوقف والفشل الناتج عن فشل النطاق أو رف المخدمات يجب أن نستخدم مخدمين افتراضيين أو أكثر ويتم وضع كل مخدم في نطاق منفصل ومستقل في نفس مجموعة التوفر (availability set) أو في مجموعات منفصلة
وذلك بناء على الـ (SLA) الخاصة بهذه الحالة سنحصل على 99.95% وبالتالي نكون خفضنا احتمالية الفشل والتوقف على مدار العام إلى 4.38 ساعات فقط
يمكن توفير وجود مخدمين افتراضيين أو أكثر عن طريق استخدام خدمة (Virtual Machine Scale Set) بدلاً من إنشاء كل نسخة من المخدم الافتراضي بشكل يدوي.
عندما نستخدم أكثر من نسخة من المخدم الافتراضي يلزمنا موزع الحمل (Load Balancer) لكي يوزع الطلبات القادمة (Http Requests) إلى نسخ المخدمات.
لننظر إلى مخطط التصميم بعد التعديلات اللازمة واستخدام أكثر من نسخة من المخدم الافتراضي!
ماذا لو فشل مركز البيانات (Data Center) بشكل كامل، كانقطاع التيار الكهربائي مثلاً بسبب فشل عام؟
لتقليل احتمالية الفشل والتوقف من جراء فشل مركز البيانات، يجب أن نستخدم مخدمين افتراضيين أو أكثر موزعين على أكثر من منقطة توفر (availability zones). هذا الإجراء سيزيد من التوفر (availability) لتصبح 99.99% والذي يعني 52.6 دقيقة من احتمالية التوقف والفشل على مدار العام.
عندما نقوم بإنشاء (Virtual Machine Scale Set) في مايكروسوفت Azure نستطيع تحديد أكثر من منطقة توفر (availability zones).
ماذا لو فشلت المنطقة السحابية (Azure Region) بشكل كامل بسبب كارثة طبيعية كزلزال مثلاً
لتقليل احتمالية الفشل والتوقف من جراء فشل عام في المنطقة السحابية (Azure Regions) لابد من استخدام مخدمين افتراضيين أو أكثر موزعين على أكثر من منطقة سحابية (different regions).
لننظر كيف يمكن أن يكون مخطط التصميم بهذه الحالة!
بعد الاطلاع على أكثر من مستوى من حالات الفشل والتوقف التي قد تواجه البرمجية، وبعد الاطلاع على الحلول الممكنة لرفع موثوقية البنية التقنية، لابج من التأكيد أنه لايوجد خيار مثالي ، عند تقييم أي حل يجب أن نأخذ بعين الاعتبار الركائز الأخرى وخاصة التكلفة.
لنناقش إذن الركيزة الثانية من إطار العمل Azure Well-Architected وهو الأمان.
الأمان (Security)
الأمان والموثوقية مرتبطان ببعضهما البعض، فمثلاً إن لم تكن البنية التقنية للبرمجية آمنة بما فيه الكفاية فالمخترقين قد يسببون خرقاً أمنياً، والخرق الأمني سيقلل من مستوى الموثوقية التي يتمتع بها النظام.
لذا فركيزة الأمان يجب أن تكون حاضرة في كامل رحلة تطوير البنية التقنية للحل السحابي الذي نقدمه للمستخدمين، بدئاً من التصميم، والتطوير وآليات النشر (deployment)، والتشغيل والعمليات (operations).
ركيزة الأمان تغطي جوانب عدة، كحماية البيانات والنظام من المخترقين، وكذلك إجراءات الحفاظ على الخصوصية و الامتثال للقوانين (compliance).
فيمايلي الجوانب الرئيسة :
- الحوكمة والامتثال (Governance and Compliance)
- الهوية وإدارة الوصول (Identity and Access Management)
- حماية المعلومات والتخزين (Information protection and Storage)
- أمن الشبكان الرقمية والاحتواء (Network Security and Containment)
- العمليات التشغيلية المتعلقة بالأمان (Security Operations)
الأمان موضوع ضخم، لذلك سأذكر هنا بعض الخدمات التي توفرها Azure من أجل كل جانب من الجوانب المذكورة أعلاه. ثم سأقوم بتحديث المخطط الخاص بالتصميم لتضمين بعض هذه الخدمات.
الحوكمة والامتثال (Governance and Compliance)
Azure Policy توفر القدرة على السياسات المناسبة لإدارة الموارد السحابية وضمان أنها ممتثلة للقوانين أو المعايير الخاصة بنطاق العمل وكذلك سياسات المنظمة التي يصمم النظام لأجلها.
كمايوجد سياسات عديدة جاهزة (Built-in) في Azure ويمكن تفعيلها بسهولة. أيضاً من الممكن إنشاء السياسات المخصصة . فمثلاً يوجد هناك سياسة جاهزة متعلقة بالنسخ الحتياطي للمخدمات الافتراضية، Azure Backup should be enabled for Virtual Machines. عند تفعيل هذه السياسة سيتم ضمان أن كل مخدم افتراضي لديه آلية نسخ احتياطي مفعلة.
ألا يزيد هذا الأمر من أمان المعلومات وكذلك الموثوقية؟ بالطبع نعم، فهذا مثال بسيط على مدى ارتباط الموثوقية بالأمان.
الهوية وإدارة الوصول (Identity and Access Management)
البنية التقنية (architecture) ستحوي العديد من خدمات البنية التحتية. أعضاء فريقك وكذلك المستخدمين النهائيين يجب أن يتمكنوا من الوصول بطريقة آمنة لموارد النظام المختلفة وبياناته. خدمة Azure AD (Active Directory) توفر ما يتعلق بأمان الهوية وإدارة الوصول.
مثال آخر عن خدمة سحابية لتأمين وإدارة الوصول للمخدمات الافتراضية وهي خدمة Azure Bastion. Azure Bastion هي خدمة ستضمن الوصول الآمن للمخدمات الافتراضية (Virtual Machines) بالبروتوكولات المعهودة (RDP/SSH) ولكن من خلال مستعرض الانترنت من بوابة Azure.
هذه الطريقة ستؤمن حماية للمخدمات الافتراضية وتجنبها كشف المنافذ الخاصة ببروتوكولات التواصل (RDP/SSH) وجعل هذه المنافذ متاحة للوصول من الانترنت.
إذن لنقم الآن بإضافة بعض الخدمات السحابية المقدمة من Azure إلى مخطط التصميم.
Bastion تؤمن الوصول الآمن لكل المخدمات الافتراضية المتواجدة ضمن نفس الشبكة الافتراضية أو ضمن شبكان افتراضية أخرى متصلة (Peered) بالشبكة الافتراضية التي يقع ضمنها ال Bastion. بالمناسبة المخطط أعلاه يحقق أحد أشكال بنى الشبكات ويسمى hub-spoke network topology.
حماية المعلومات والتخزين (Information protection and Storage)
أحدى الميزات التي تقدمها خدمة السحابة Azure هي (Data Protection at Rest) والتي توفر تشفير كامل للبيانات و تضمن سريتها. البيانات يتم تشفيرها باستخدام مفاتيح تشفير. يتم إدارة هذه المفاتيح بالحالة الافتراضية من قبل مزود الخدمة Azure، ولكن يمكن أن نقوم بوضع المفاتيح الخاصة بنا لو أردنا وإدارتها بأنفسنا.
يوجد خدمة أخرى واسمها (Key Vault). تتيح هذه الخدمة إدارة وحماية كل المعلومات السرية والمفاتيح والشهادات المستخدمة في النظام. يقصد بالمعلومات السرية كمعلومات الاتصال بقواعد البيانات، كلمات المرور، الشهادات(Certificates).
لنقم بتحديث مخطط التصميم لكي نضيف خدمة الـ Key Vault للتصميم!
أمن الشبكان الرقمية والاحتواء (Network Security and Containment)
Azure توفر العديد من الخدمات التي تؤمن حركة البيانات في الشبكة (network traffic)، تحمي نقاط الوصول العامة (public endpoints) تخفف من الهجمات السبرانية (mitigate attacks)، وتبقي على أجزاء نظامك مخفية ضمن الشبكة وغيرها من الخدمات.
فيمايلي بعض الخدمات المتاحة:
- مجموعة الأمان في الشبكة NSG (Network Security Group) وهي طريقة لتجميع كل إعدادات الأمن المتعلقة بالشبكات ثم يتم تطبيقها على شبكة فرعية أو أكثر (network subnet)
- موزع الحمل Application Gateway وهو نوع من أنوع الـ Load Balancer الذي يوفر آلية توزيع الحمل وكذلك الحماية من هجمات الانترنت التقليدية
- جدار ناري WAF (Web Application Firewall)
- حماية من الهجمات الموزعة لمنع الخدمة DDOS Protection (Distributed Denial of Service)
العمليات التشغيلية المتعلقة بالأمان (Security Operations)
العمليات التشغيلية يجب أن تتضمن الإجراءات المتعلقة بالأمان لتساعد على كشف (detect) أي خرق أمني أو عمل عدائي سيبراني، ثم تستجيب (respond) بأسرع ما يمكن، ثم تستعيد(recover) وتعود إلى الحالة الأمنية السليمة خلال وبعد عملية الخرق التي حصلت.
إذن العمليات التشغليلة المتعلقة بالأمان يجب أن تكشف وتستجيب وتستعيد الحالة.
يوجد في Azure خدمات عديدة للعمليات الأمنية:
- Azure Advisor
- Microsoft Defender for Cloud Recommendations
- تقييم الأمان من إطار العمل Azure Well-Architected
لننتقل إلى الركيزة الثالثة تحسين التكلفة!
تحسين التكلفة (Cost Optimization)
إحدى أهم الفوائد من خدمات السحابة هو القدرة على تقليل التكلفة، تجنب شراء وحجز الموارد الزائدة عن الحاجة واستخدام الموارد بحسب الحاجة فقط.
استخدام الخدمات السحابية بحكمة، والتحكم بحجم الانفاق، وتقليل الهدر بموارد السحابة، كل ماسبق هي أكثر النقاط شيوعاً لأي شركة تستخدم الخدمات السحابية. ركيزة تحسين التكلفة ستساعد على تحسين استخدام الموارد والحصول على أعلى قيمة تفيد العمل بأقل الموارد الممكنة.
ستكون ركيزة تحسين التكلفة موجودة في مراحل مختلفة من مراحل بناء البنية التقنية لمنتجك الرقمي، في كل مرحلة سيتم إتباع بعض الإجراءات، المبادئ، وكذلك بعض الأدوات المفيدة.
التصميم (التصميم مع أخذ التكلفة بعين الاعتبار)
التصميم مع أخذ التكلفة بعين الاعتبار (Design for Cost) أمر هام جداً ويبدأ من مناقشة المتطلبات، لذا لابد من التأكد من وجود متطلبات عمل (business requirements) واضحة:
- التكلفة المبدئية Initial cost
- الأداء (Performance)
- الأمان و الامتثال (Security and compliance)
- التوفر (Availability)
- المناطق السحابية (Regions) التي نحتاجها لاستضافة البنية التقنية لنظامنا
- اختيار نوع الاشتراك المناسب Azure Subscription(s)
- استطاعة الفريق و خبرته
لابد من الاطلاع على العوامل والجوانب الأخرى التي تشكل المتطلبات، هذه العوامل تمت مناقشتها بشكل مفصل في موقع إطار العمل Azure Well-Architected.
بعد ذلك يوجد العديد من الأدوات التي تساعدنا في نحسين التكلفة:
- بإمكانك استخدام حاسبة الأسعار لخدمات Azure السحابية Pricing Calculator لكي تقدر التكلفة للخدمات التي تنوي استخدامها. هذه الأداة تحوي الكثير من الخيارات التي تتيح لك الحصول على أدق تقدير تكلفة ممكن بحسب المتطلبات التي تحتاج تحقيقها.
- عليك أن تقوم بتطوير استراتيجية حوكمة وسياسات محددة لكي تستطيع من التحكم بالتكلفة وذلك من خلال Azure Policy.
- يجب عليك أيضاً أن تقوم بتعريف الميزانية والتنبيهات حتى تقوم Azure بإرسال الإشعارات لك عند الوصول إلى استهلاك الميزانية المحددة مسبقاً.
لنقم بتطبيع بعض ما سبق على مخطط التصميم الذي تمت مناقشته مسبقاً، ولنفترض أن التطبيق القديم الخاص بنا (legacy website):
- لديه ميزانية شهرية أولية بحوالي $1000، وبحسب المتطلبات من المفيد جداً لو تمكنا من تقليلها أيضاً.
تقدير التكلفة الأول للموارد المخطط استخدامها
بعد استخدام الآلة الحاسبة لأسعار خدمات Azure، تمكنت من الحصول على التقدير الأولي التالي:
- طبعاً التقدير يتضمن استخدام موارد في منطقتين سحابيتين Regions لكي نوفر أعلى درجة ممكنة من الموثوقية.
- أيضاً أضفنا للتقدير خدمة Bastion وخدمة Key Vault
طبعاً هذا التقدير ليس مكتمل أيضاً، حيث يجب أن نضمن قواعد البيانات وآليات النسخ الأوتوماتيكي للبيانات replications. ولكن عموماً نحن تجاوزنا الميزانية المحددة ويجب أن نحاول التقليل منها.
تقدير التكلفة الثاني للموارد المخطط استخدامها
وبعد نقاش آخر مع أصحاب القرار والبت في المتطلبات، توصلنا إلى قرار أن نستخدم منطقة سحابية واحدة بدلاً من اثنتين. لذا قمت بحذف الموارد الزائدة من القائمة. وبناء على الاطلاع على أسعار الخدمات في كل منطقة، فضلنا اعتماد منطقة شمال الإمارات UAE North Region بدل من وسط الإمارات. السبب أن هناك فروقات بالأسعار المتاحة وهذه المنطقة أرخص بقليل.
كما هو ملحوظ في الصورة أعلاه، التكلفة التقديرية تناقصت بشكل ملحوظ للنصف تقريباً. هذا الأمر متوقع بما أننا استخدمنا تقريباً نصف كمية الموارد بعد الاعتماد على منطقة سحابية واحدة.
إذن بعد هذا التقدير المبدئي وكونه ضمن الميزانية المتوقعة من الممكن اعتماد التقدير، ماذا بعد؟
بعد إنشاء الموارد (provision/deploy) ضمن حسابنا على الخدمة السحابية سنقوم بمراقبة الاستهلاك.
المراقبة (Monitor)
بعد إنشاء الموارد، يجب أن نستمر بمراقبة الاستهلاك والميزانية المحددة. من أجل نستطيع استخدام إدارة التكلفة (Cost Management) ضمن اشتراك الخدمة السحابية والذي سيمكن من:
- تحليل التكلفة
- التحقق من كمية الانفاق ضمن فترة زمنية محددة
- تفصيل التكلفة وتوزيعها على كل خدمة مستخدمة وضمن كل موقع جغرافي
- مقارنة ماتم انفاقه مع الميزانية في حال تم تحديدها مسبقاً
- سرد قائمة بكل الموارد وبتكلفة كل واحد منها.
التحسين (Optimize)
بناء على مراقبة التكلفة، نستطيع تحسين كفاءة التكلفة بطرق متعددة:
- تقليل الهدر (Cloud Waste)
- إيقاف الموارد غير المستخدمة
- تقليص حجم الموارد المستخدمة بشكل أقل من التوقع (Scale down)
- رفع كفاءة استخدام الموارد من خلال تفعيل ميزة الإيقاف التلقائي
- رفع كفاءة استخدام الموارد بحسب الحاجة من خلال التوسع التلقائي (auto scale)
- الاستفادة من عروض الـ Hybrid benefits التي تتيح الاستفادة من رخص منتجات مايكروسوفت التي تم شراؤها من قبل
- الاستفادة من حجز كمية موارد بشكل مسبق (Reservations)
- تحديث البنية التقنية باستمرار والنظر في استخدام الخدمات Paas و Serverless
تميز العمليات التشغيلية (Operational Excellence)
رابع ركيزة من إطار العمل Azure Well-Architected هو تميز العمليات التشغيلية. لا شك أن إجراءات الأتمتة هي صلب تحسين العمليات التشغيلية.
الأتمتة (automation) يمكن أن تتم بعدة مستويات:
- أتمتة إنشاء البنية التحتية وإعدادها (Infrastructure deployment and configuration) باستخدام ARM, Bicep Templates, وخدمة Terraform
- أتمتة المهمات العملياتية الدورية من خلال Azure Automation, Azure DevOps (CI/CD) pipelines
- تحسين كفاءة العمليات التشغيلية المتعلقة بالأمان من خلال استخدام DevSecOps
DevSecOps
هذا المصطلح يشير إلى تضمين إجراءات الأمان والاختبارات المتعلقة به كجزء من آلية عمل الـ DevOps. وهذا كبديل عن جعل إجراءات واختبارات الأمان كمرحلة تأتي في النهاية قبل نقل البرمجية المنجزة إلى البيئة الحية الانتاجية (Production).
هذا سوف يسرع من العمليات التشغيلية ويتيح استكشاف الأخطاء و الثغرات الأمنية بمرحلة باكرة، وبالتالي سيتاح أعادة ضبط الأولويات و معرفة مالذي يجب حله أولاً بوقت باكر، وهذا بالنهاية يعني اتخاذ قرار أفضل وبوقت أبكر.
الأمان سيتم تضمينه في مختلف مراحل الـ DevOps
إدارة آليات النشر البرمجي (Release Management)
الغرض الأول من آليات النشر البرمجي هو تحويل الفكرة إلى برمجية صالحة للاستخدام بأسرع وقت ممكن. هذا الأمر سيحسن جداً من وقت الوصول للسوق (time to market). كذلك سرعة وثبات آليات النشر سيعطي القدرة على اختبار أي فكرة مع المستخدم النهائي والحصول على رأيه (early feedback).
للحصول على آليات النشر المتطورة، على الفريق أن يستثمر في:
- النشر المستمر (Continuous Deployment)
- دمج الشفرة البرمجية المستمر (Continuous Integrations)
- استراتيجيات تفريعات الشفرة البرمجية (Branching Strategy)
- إدارة التبعيات (Managing Dependencies)
- تأمين وجود أكثر من بيئة لنشر البرمجية (Supporting multiple deployment environments)
المراقبة (Monitoring)
المراقبة هي جزء أساسي من العمليات التشغيلية، من خلال المراقبة المستمرة سنتمكن من الحصول على رؤية شاملة لكل جوانب البرمجية:
- حالة البرمجية وتوفرها لكل جزء من أجزائها (health status and availability)
- حالة الأمان
- حالة الأداء
- حالة الانفاق من الميزانية
- تتبع الأخطاء واستكشافها (Tracing and debugging)
Azure لديها العديد من الخدمات المتعلقة بالمراقبة :
- Azure Monitor
- Log Analytics Workspace
- Application Insights
كفاءة الأداء (Performance Efficiency)
خامس ركيزة من ركائز إطار العمل Azure Well-Architected هو كفاءة الأداء. لاشك أن الأداء أصبح هاماً جداً أكثر من أي وقت مضى. ففي هذه الأيام هناك مقولة تعتبر البطء هو أشبه بتوقف الخدمة (Slow is the new down).
التصميم من أجل الكفاءة (Design for Performance)
أداء البنية التقنية و استجابتها لازدياد الاستخدام للنظام هو أمر أساسي في تصميم أي بنية تقنية. ولكن من جهة أخرى ليس علينا أن نبالغ باستخدام التقنيات (over engineering) في تصميمنا. ربما نقوم بتصميم بنية تقنية متمازجة (monolithic) وتكون كافية للاستخدام، هذا مقبول حتماً طالما يكفي المتطلبات ويلبي كمية الحمل المتوقعة (expected load).
لكن يجب أن يتم تصميم البنية لتكون قابلة للتوسع (scale out) والنشر على اكثر من نسخة (instance) حتى لوكانت متمازجة (monolithic). فمثلاً يجب أن نأخذ بعين الاعتبار أثناء تصميم البرمجية أن تكون (stateless) ونتجنب ما يمسى (affinity session) لو استطعنا. هذا مجرد مثال بسيط كيف يمكن أن نصمم البنية التقنية مع أخذ الكفاءة بعين الاعتبار.
استخدام ميزة التوسع التلقائي (autoscaling) في خدمات السحابة هو مثال آخر على التصميم من أجل الكفاءة، مثلاً يمكن ضبط أي مخدم افتراضي على أن يتوسع أو يتقلص بحسب نسبة استخدام المعالج CPU.
كما أن هذه الميزة تتيح وضع حد أعلى لعدد النسخ الممكن إنشائها وذلك لتفادي تكلفة غير متوقعة
هناك أيضاً طرق أخرى للتصميم من أجل الكفاءة:
- استخدام بنية الخدمات الأصغرية Microservices Architecture
- جعل العمليات التي تستهلك زمن طويل عمليات مجدولة في الخلفية (Background jobs)
- استخدام تقنيات مثل الـ Queue لتنظيم الحمل الموجه للمخدمات و جدولته. يوجد في الرابط التالي مثال عن كيفية الاستفادة من هذه الطريقة Azure Functions, Service Bus, and Redis Cache to improve the architecture.
اختبارات الأداء (Performance Testing)
يوجد نوعين رئيسين من اهتبارات الأداء :
- Load Test سيساعد على معرفة أعلى نقطة ممكن من الطلبات التي يستطيع أن يعالجها النظام بشكل ناجح
- Stress Test سيساعد في معرفة النقطة التي سيفشل فيها النظام في معالجة الطلبات
هذا ما نحتاج إليه بشكل رئيسي لكي نرفع من كفاءة البنية التقنية والتحتية من أجل أداء أفضل.
خدمة Azure Load Testing هي خدمة سحابية تساعد على تأمين محاكاة لمستخدمين وهميين ويقومون بتوجيه الطلبات للنظام بهدف اختبار كفائته. تمكن الخدمة من القيام باختبار الكفاءة بشكل بسيط من خلال تحديد الرابط الذي سيتم استدعاءه من قبل المستخدمين الوهميين، أو يمكن القيام باختبارات أكثر تعقيداً من خلال JMeter test.
ملاحظة: خلال اختبارات الكفاءة للأداء ليس الهدف فقط التأكد أن النظام قابل للتوسع (scale up) بل يجب التأكد أن النظام يستطيع أن يتقلص (scale down) مع تناقص عدد الطلبات وانتهاء الاختبار.
ملاحظة: على أفراد الفريق في قسم الأعمال (business team) التواصل مع الفريق التقني وتوضيح كل الأحداث المجدولة والأنشطة المخطط لها والتي من شأنها أن تؤثر على عدد الطلبات والحمل المتوقع (load) المحتمل مثلاً كالتخطيط لحملة تسويقية.
مراقبة الأداء (Performance Monitoring)
لمراقبة الأداء نحن بحاجة للأدوات التي تساعد على:
- تجميع سجلات العمليات (application logs) من الخدمات الموزعة التي تكون النظام
- الربط بين مختلف الأحداث و سجلات التعقب (events and traces) من مختلف الخدمات الموزعة الأمر الذي سيساعد على فهم ترابط الخطوات المنفذة مع كل طلب
- الحصول على مؤشرات وعدادات الأداء (performance counters and metrics) من مختلف الخدمات
كل الميزات المذكورة أعلاه مؤمنة من خلال خدمة Application insights كجزء من خدمة Azure Monitor.
مراجعة لركائز إطار العمل Azure Well-Architected
- إطار العمل Azure Well-Architected مؤلف من خمس ركائز: الموثوقية، الأمان، تحسين التكلفة، تميز العمليات التشغيلية، كفاءة الأداء.
- التحدي الرئيس في تصميم البنية التقنية الصحيحة هو الموازنة بين كل هذه الركائز الخمسة.
- الاستثمار في قدرات أفراد الفريق المعرفية وخبراتهم أم أساسي.
- أي مطور برمجيات هو مساهم بالبنية التقنية، عند بناء نظام على الخدمة السحابية يجب على مطور البرمجيات أن يفهم البنية التقنية لكي يعرف كيف ستكون الشفرة البرمجية جزء من هذا البنيان
- مزودي الخدمة السحابية كأمازن (AWS) و غوغل (GCP) لديهم أيضاً نفس إطار العمل بنفس الركائز، أحد الفروق هو أن كل خدمة سحابية تقوم بتطبيق الركائز بادوات مختلفة، أيضاً يزودون زبائنهم بأدوات الـ(cloud native platforms) مثل كوبرنيتيز (Kubernetes).
لذلك إن دراسة هذه الركائز ستساهم في تعزيز القدرة على بناء بنية تقنية متميزة سواء على مزودة خدمة سحابية واحد أو أكثر (multi-clouds).