معالجة مشكلة اكتشاف التحول وتحليل سبب التحول

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

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

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

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

لماذا تقصر أدوات اكتشاف الانحراف

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

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

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

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

الكشف يلتقي بالسياق

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

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

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

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

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

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

 

ما وراء إدارة IaC

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

الاتجاه الذي أرى أن هذا التطور يتحرك نحوه هو إدارة الأصول السحابية (CAM)، التي تتعقب وتدير جميع الموارد في بيئة سحابية — سواء تم توفيرها عبر IaC أو APIs أو عمليات يدوية — مما يوفر رؤية موحدة للأصول ويساعد المنظمات على فهم التكوينات والاعتمادات والمخاطر، وكلها ضرورية للامتثال، وتحسين التكاليف، وكفاءة العمليات.

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

1+1 يساوي ثلاثة

يجمع مزيج إدارة IaC وCAM الفرق للسيطرة على التعقيد بوضوح وتحكم. مع اقتراب نهاية السنة، حان وقت التوقعات — لذا إليكم توقعاتي. بعد أن قضيت الجزء الأكبر من العقد الماضي في بناء وتطوير واحدة من أكثر منصات إدارة IaC شعبية (إن جاز لي أن أقول ذلك)، أرى أن هذه هي التطور الطبيعي لصناعتنا: دمج إدارة IaC، والأتمتة، والحكومة مع رؤية محسنّة للأصول غير المبرمجة.

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

الحدود التالية، إذن، هي مساعدة الفرق على توسيع الرؤية للأصول غير المبرمجة، مع ضمان أنه مع تطور البنية التحتية، تستمر في العمل بسلاسة — واحدة واحدة من الانجراف المتصالح وما بعدها.