كل برنامج أتمتة في المؤسسات يصطدم بالجدار ذاته. توجيه تذاكر ServiceNow، ومعالجة انحراف Terraform، وتدوير الشهادات، وتوفير مجموعات Active Directory، ونشر تحديثات SCCM، وتنسيق خطوط CI/CD. أول عشرة أو عشرين سير عمل يبررون الاستثمار بسهولة، ومعادلة العائد على الاستثمار تصمد تمامًا حتى يتجاوز عدد سير العمل المئات، فينتقل جزء كبير من أسبوع فريق تقنية المعلومات من بناء أتمتة جديدة إلى منع الأتمتة الحالية من الانهيار.

تُعيد بوابة دفع تصميم مسار المصادقة الخاص بها فيتوقف سير عمل تقديم المطالبات عن المصادقة. تُصدر Salesforce تحديثًا للبيانات الوصفية فيبدأ تعيين حقل في خط أنابيب تحويل العميل المحتمل إلى فرصة بكتابة قيم فارغة. تُلغي AWS إصدارًا من API فتبدأ خطة Terraform التي كانت تعمل بنجاح لمدة عام بإرسال أخطاء 400 في كل عملية تطبيق. يفتح أحدهم تذكرة، ويكتشف شخص آخر ما الذي تغيّر، ثم يُصلحه ويختبره وينشر الإصلاح، وفي هذه الأثناء تكون العملية التي كان سير العمل يؤتمتها إما قد نُفذت يدويًا أو لم تُنفذ على الإطلاق.

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

بُني محرك سير العمل في Triggerfish لتغيير هذا الواقع. سير العمل ذاتي الإصلاح متاح اليوم، ويمثل أهم قدرة في المنصة حتى الآن.

ما الذي يعنيه الإصلاح الذاتي فعلًا

يُستخدم هذا المصطلح بشكل فضفاض، لذا دعني أكون واضحًا حول ماهيته.

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

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

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

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

لماذا يهم السياق الذي تبنيه في سير العمل

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

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

إليك كيف يبدو ذلك عمليًا. لنفترض أنك تؤتمت توفير صلاحيات الوصول للموظفين. موظف جديد يبدأ يوم الاثنين وسير العمل يحتاج إلى إنشاء حسابات في Active Directory، وتوفير عضوية GitHub الخاصة بالمؤسسة، وتعيين مجموعات Okta، وفتح تذكرة Jira تؤكد الإنجاز. إحدى الخطوات تجلب سجل الموظف من نظام الموارد البشرية. حقل الهدف فيها لا يقول فقط "جلب سجل الموظف." بل يقرأ: "هذه الخطوة هي مصدر الحقيقة لكل قرار توفير لاحق. الدور والقسم وتاريخ البدء من هذا السجل تحدد مجموعات Active Directory التي ستُعيّن، وفرق GitHub التي ستُوفر، وسياسات Okta التي ستُطبق. إذا أعادت هذه الخطوة بيانات قديمة أو ناقصة، فإن كل خطوة لاحقة ستوفر صلاحيات وصول خاطئة."

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

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

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

المراقبة الحية تعني رصد المشاكل قبل أن تتحول إلى أعطال

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

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

يبقى سير عملك ملكك

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

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

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

إدارة كل هذا عبر كل قناة تستخدمها بالفعل

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

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

نفس الحالة المُنظمة تغذي واجهة Tidepool الحية عندما تريد الصورة الكاملة. نفس البيانات، سطح مختلف.

ما الذي يغيره هذا فعلًا لفرق تقنية المعلومات

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

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

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

متاح اليوم

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

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

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