النشر وتوفير الموارد والأتمتة

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

يحمل هذا المجال 22% من درجات اختبار SOA-C03، وهو يغيّر قيمة ما تعلمته قبله. المراقبة تخبرك أن هناك خللاً، والموثوقية تبقي الحمل يعمل. أما توفير الموارد فيحدد ما إذا كان الإصلاح سيصل كتعديل مراجَع على template أم كتغيير يدوي في الـ Console لا يستطيع أحد تكراره.

ما الذي يغطيه هذا المجال

• صور AMI الذهبية مع EC2 Image Builder، وصور الحاويات في ECR مع فحص الصور وسياسات دورة حياتها
• كتابة قوالب CloudFormation: parameters وconditions وintrinsic functions وoutputs
• عمليات stack الآمنة عبر change sets وdrift detection وstack policies، وتشخيص عملية نشر فشلت أو تراجعت
• AWS CDK، وموضع Terraform وGit داخل سير عمل CloudOps
• توفير الموارد عبر حسابات ومناطق متعددة مع StackSets، ومشاركة الموارد عبر AWS RAM، والكتالوجات المحكومة مع Service Catalog وControl Tower
• استراتيجيات النشر rolling وblue/green وcanary وin-place، وكيف تنطبق كل منها على مجموعات Auto Scaling وECS وLambda
• أتمتة التشغيل اليومي مع Systems Manager: إدارة الأسطول دون SSH، وPatch Manager وState Manager، وParameter Store، والعمليات المستندة إلى الأحداث

لماذا هذا مهم

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

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