متى تتحول الأتمتة إلى عبء تشغيلي؟

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

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

يعرّف Google SRE العمل التشغيلي المتكرر والمتوقع المرتبط بصيانة الخدمة بوصفه toil، ويشير إلى أن الأتمتة قد توفر وقتًا كبيرًا لكنها قد تسبب أعطالًا إذا استُخدمت في ظروف غير مناسبة. لذلك يجب ألا يكون التكرار وحده سببًا كافيًا.

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

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

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

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

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

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

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

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

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

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

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

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

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

Google SRE Workbook — الأتمتة والعمل التشغيلي المتكرر ومخاطر توليد toil جديد: https://sre.google/workbook/eliminating-toil/

NIST — إطار إدارة مخاطر الذكاء الاصطناعي للحالات التي تدخل فيها نماذج ضمن الأتمتة: https://www.nist.gov/itl/ai-risk-management-framework

#الأتمتة #العمليات #الكفاءة