عندما تعيق سياسات البنية التحتية سير العمل: التعامل مع الاستثناءات دون كسر الأمان

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

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

ماذا ستفعل؟

المشكلة مع السياسات الجامدة

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

الهدف ليس إلغاء السياسات. بل جعلها مرنة بما يكفي حتى لا يشعر الناس بأنهم مجبرون على تجاوزها. تحتاج إلى آلية واضحة للاستثناءات تحافظ على مساءلة الجميع.

ثلاثة أشياء يحتاجها كل استثناء

نظام الاستثناءات المصمم جيدًا يحتوي على ثلاثة مكونات غير قابلة للتفاوض: التسجيل والموافقة وتاريخ انتهاء الصلاحية.

التسجيل

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

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

الموافقة

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

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

تاريخ انتهاء الصلاحية

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

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

تصميم تدفق الاستثناء

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

عمليًا، يبدو التدفق كالتالي:

يوضح الرسم البياني التالي عملية طلب الاستثناء:

flowchart TD A[يكتشف خط الأنابيب انتهاكًا للسياسة] --> B{اختيار إجراء} B -->|إلغاء| C[تم حظر التغيير] B -->|طلب استثناء| D[تقديم طلب استثناء] D --> E[تسجيل تفاصيل الطلب] E --> F[إخطار الموافق] F --> G{تمت الموافقة؟} G -->|لا| H[تم حظر التغيير] G -->|نعم| I[يستمر خط الأنابيب مع حالة استثناء] I --> J[تعيين تاريخ انتهاء الصلاحية] J --> K[إرسال تذكيرات قبل انتهاء الصلاحية] K --> L{انتهت الصلاحية؟} L -->|لا| M[المورد في حالة استثناء] L -->|نعم| N[إعادة تشغيل فحص السياسة] N --> O{متوافق؟} O -->|نعم| P[تم إغلاق الاستثناء] O -->|لا| Q[فرض السياسة / إصلاح المورد]
  1. يقوم خط الأنابيب بتشغيل فحوصات السياسة أثناء التخطيط أو التطبيق.
  2. يتم اكتشاف انتهاك. يقدم خط الأنابيب خيارين: إلغاء التغيير، أو تقديم طلب استثناء.
  3. إذا قدم الفريق استثناءً، ينشئ خط الأنابيب تذكرة أو إشعارًا للموافق المخول.
  4. بمجرد الموافقة، يستمر خط الأنابيب، ولكن يضع علامة على المورد على أنه في حالة استثناء.
  5. يرسل النظام تذكيرات قبل انتهاء صلاحية الاستثناء. بعد انتهاء الصلاحية، يعيد تلقائيًا تشغيل فحص السياسة.

ما لا يجب فعله

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

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

قائمة مراجعة عملية للتعامل مع الاستثناءات

  • يتم تسجيل كل استثناء مع الطالب والسياسة المخالفة والموارد المتأثرة والسبب والموافق
  • تتطلب الاستثناءات موافقة من شخص يفهم مخاطر السياسة
  • جميع الاستثناءات لها تواريخ انتهاء صلاحية صريحة (يوصى بـ 7-30 يومًا)
  • يمنع خط الأنابيب النشر حتى تتم الموافقة على الاستثناء
  • يتم إرسال تذكيرات تلقائية قبل انتهاء صلاحية الاستثناء
  • تؤدي الاستثناءات منتهية الصلاحية إلى إعادة فحص تلقائي للسياسة
  • تتم مراجعة تكرار الاستثناءات ربع سنويًا لتحديد تحسينات السياسة

الخلاصة

السياسات بدون آليات استثناء تخلق أنظمة ظل. سيعمل الفرق حولها، وستفقد الرؤية حول ما يعمل بالفعل في بنيتك التحتية. تدفق الاستثناء المصمم جيدًا لا يضعف سياساتك. بل يقويها بجعلها واقعية بما يكفي حتى يتبعها الناس بالفعل. المفتاح هو التسجيل والموافقة وتاريخ انتهاء الصلاحية. بدون الثلاثة، ليس لديك عملية استثناء. لديك سياسة مكسورة بالفعل.