لماذا يمكن أن يكون الإعداد الخاطئ أكثر خطورة من الكود الخاطئ
يغير مطور حرفًا واحدًا في ملف إعدادات. يتحول الرابط db-prod.internal.company.com إلى db-prod.intrnal.company.com. حرف واحد ناقص. يتم نشر التغيير. في غضون دقائق، كل تطبيق يحاول الاتصال بقاعدة البيانات يفشل. يتوقف تسجيل الدخول عن العمل. لا يعود البحث بنتائج. تتجمد المعاملات. ينهار التطبيق بالكامل.
لم يكن هناك خطأ في الكود. لا خطأ منطقي. لا فشل في الخوارزمية. مجرد حرف واحد ناقص في ملف إعدادات.
هذا السيناريو يحدث في الفرق أكثر مما يعترف به معظم المهندسين. ويكشف شيئًا غير مريح: إعداد خاطئ يمكن أن يسبب ضررًا أكبر وبسرعة أكبر من كود خاطئ.
سرعة التأثير
عندما يحتوي الكود على خطأ، عادةً ما يمر عبر طبقات قبل أن يتسبب في ضرر مرئي. قد يلتقطه التحقق من المدخلات. قد يمنع فحص شرطي تنفيذ المسار الخاطئ. قد يلتقط معالجة الأخطاء الفشل ويعيد استجابة مهذبة. حتى عندما يصل خطأ في الكود إلى الإنتاج، غالبًا ما يستغرق وقتًا ليظهر.
الإعدادات مختلفة. يتم تحميل قيم الإعدادات عند بدء تشغيل التطبيق. تتحكم في الاتصالات، والمهلات، والنقاط النهائية، وبيانات الاعتماد، ومفاتيح الميزات. بمجرد تحميل قيمة إعداد خاطئة، يتصرف التطبيق بناءً عليها فورًا. لا توجد شبكة أمان. لا يوجد تدهور مهذب عندما يكون رابط قاعدة البيانات خاطئًا. لا يوجد خيار احتياطي عندما تكون قيمة المهلة منخفضة جدًا.
فكر في مثال آخر: يغير شخص مهلة الاتصال من 30 ثانية إلى 3 ثوانٍ. كان القصد معقولًا—الفشل بسرعة عندما يكون هناك خطأ ما. لكن في الإنتاج، تستغرق قاعدة البيانات أحيانًا 5 ثوانٍ للاستجابة تحت الحمل. الآن كل طلب شرعي ينتهي بانتهاء المهلة. يبدو التطبيق غير مستقر. يقول فريق قاعدة البيانات أن كل شيء على ما يرام. يقضي فريق الهندسة ساعات في تصحيح كود لا يحتوي على مشاكل. كانت المشكلة في رقم واحد في ملف إعدادات.
أخطاء الإعدادات أصعب في التتبع
عندما ينكسر الكود، لدى المطورين أدوات. تشير تتبعات المكدس إلى السطر المحدد. تظهر السجلات تسلسل الأحداث. غالبًا ما تصف رسائل الأخطاء ما حدث بشكل خاطئ. عملية التصحيح لها نقطة بداية واضحة.
أخطاء الإعدادات لا تترك أي أثر تقريبًا. يتوقف التطبيق عن العمل. لا يوجد تتبع مكدس لأنه لم يتم تنفيذ أي كود بشكل غير صحيح. لا توجد رسالة خطأ لأن التطبيق لم يتمكن حتى من الوصول إلى النقطة التي يوجد فيها معالجة الأخطاء. التطبيق يجلس فقط، رافضًا الاتصال، رافضًا الاستجابة، رافضًا إعطاء أي فكرة عن الخطأ.
يمكن للفرق قضاء أيام في مطاردة الأخطاء في قاعدة الكود، وتشغيل الاختبارات، ومراجعة التغييرات الأخيرة، فقط ليكتشفوا أن المشكلة كانت في ملف إعدادات تم تغييره قبل أسبوعين من قبل شخص لم يعد يتذكر إجراء التغيير.
أيادٍ متعددة، لا تنسيق
يلمس العديد من الأشخاص ملفات الإعدادات. يغير المطورون روابط قاعدة البيانات للاختبار المحلي. يعدل مهندسو DevOps المنافذ لتكوينات النشر. يدير مسؤولو قواعد البيانات بيانات الاعتماد للامتثال الأمني. يضبط مهندسو المنصة حدود الموارد. يبدو كل تغيير صغيرًا وغير ضار في الوقت الحالي. يتم كل تغيير دون نفس الدقة المطبقة على تغييرات الكود.
لا أحد يراجع تغيير الإعدادات بالطريقة التي يراجعون بها تغيير الكود. لا أحد يتحقق مما إذا كانت القيمة الجديدة منطقية في السياق. لا أحد يتحقق مما إذا تم اختبار التغيير في بيئة التدريج. يصبح ملف الإعدادات مجموعة من الافتراضات غير المؤكدة، كل منها ينتظر الفشل في أسوأ لحظة ممكنة.
الخطر الحقيقي هو الاختفاء
الجانب الأكثر خطورة في أخطاء الإعدادات هو أنها غالبًا ما تمر دون أن يلاحظها أحد حتى تسبب ضررًا حقيقيًا. قد يظل رابط خاطئ في ملف إعدادات التطوير لأسابيع. لا أحد يلاحظ لأن بيئة التطوير ليست تحت حمل مستمر. ثم ينسخ شخص ما هذا الإعداد إلى بيئة التدريج، وتبدأ الاختبارات في الفشل. يلقي الفريق باللوم على الاختبارات. يقومون بتصحيح إطار الاختبار. يفحصون الكود. بعد أيام، يلاحظ شخص ما الرابط.
هذا الاختفاء يجعل أخطاء الإعدادات أكثر غدرًا من أخطاء الكود. تظهر أخطاء الكود أثناء التطوير، أثناء مراجعة الكود، أثناء الاختبار. تختبئ أخطاء الإعدادات في العراء، في انتظار الظروف المناسبة للهجوم.
تعامل مع الإعدادات مثل الكود
الحل ليس معقدًا، لكنه يتطلب تحولًا في العقلية. يجب التعامل مع الإعدادات بنفس الانضباط مثل الكود. يجب أن يمر كل تغيير في الإعدادات بنفس العملية:
- مراجعة الكود من قبل شخص آخر
- التحقق من الصيغة مقابل مخطط
- فحوصات سلامة القيمة
- الاختبار في بيئة تدريج قبل الإنتاج
هذا ليس عن البيروقراطية. إنه عن الاعتراف بأن الإعدادات ليست مواطنًا من الدرجة الثانية في عملية التسليم. الإعدادات هي قطعة تسليم يمكن أن تعطل نظامًا بأكمله بخطأ حرف واحد.
قائمة تحقق عملية لتغييرات الإعدادات
قبل نشر أي تغيير في الإعدادات، راجع قائمة التحقق السريعة هذه:
- هل راجع شخص آخر التغيير؟
- هل تم التحقق من الصيغة مقابل مخطط؟
- هل جميع الروابط والمنافذ والنقاط النهائية قابلة للوصول من البيئة المستهدفة؟
- هل قيم المهلة معقولة للحمل المتوقع؟
- هل تم تدوير بيانات الاعتماد مؤخرًا وتحديثها في جميع البيئات؟
- هل تم اختبار التغيير في بيئة غير إنتاجية؟
- هل هناك خطة للتراجع إذا تسبب الإعداد في مشاكل؟
تستغرق قائمة التحقق هذه دقيقتين. يمكن أن توفر ساعات من التصحيح وتمنع انقطاعات الإنتاج.
الخلاصة
أخطاء الإعدادات أسرع وأصعب في التتبع وأكثر اختفاءً من أخطاء الكود. حرف واحد ناقص يمكن أن يعطل تطبيقًا بأكمله. قيمة مهلة خاطئة يمكن أن تجعل نظامًا سليمًا يبدو معطلاً. الإعدادات ليست تفصيلًا يتم التعامل معه بشكل عابر. إنها قطعة تسليم حرجة تستحق نفس الدقة مثل الكود. تعامل معها بهذه الطريقة، أو استعد لجلسات التصحيح التي تليها.