हर एंटरप्राइज़ ऑटोमेशन प्रोग्राम एक ही दीवार से टकराता है। ServiceNow टिकट राउटिंग, Terraform ड्रिफ़्ट रेमेडिएशन, सर्टिफ़िकेट रोटेशन, AD ग्रुप प्रोविज़निंग, SCCM पैच डिप्लॉयमेंट, CI/CD पाइपलाइन ऑर्केस्ट्रेशन। पहले दस-बीस वर्कफ़्लो आसानी से निवेश को सही ठहराते हैं, और ROI का गणित तब तक सही रहता है जब तक वर्कफ़्लो की संख्या सैकड़ों में नहीं पहुँच जाती और IT टीम के हफ़्ते का एक बड़ा हिस्सा नया ऑटोमेशन बनाने से हटकर मौजूदा ऑटोमेशन को चालू रखने में खर्च होने लगता है।

एक पेयर पोर्टल अपना ऑथ फ़्लो रीडिज़ाइन करता है और क्लेम्स सबमिशन वर्कफ़्लो ऑथेंटिकेट करना बंद कर देता है। Salesforce एक मेटाडेटा अपडेट पुश करता है और लीड-टू-ऑपर्चुनिटी पाइपलाइन में एक फ़ील्ड मैपिंग null लिखने लगती है। AWS एक API वर्शन डेप्रिकेट करता है और एक साल से सही चल रहा Terraform प्लान हर अप्लाई पर 400 एरर फेंकने लगता है। कोई टिकट खोलता है, कोई और पता लगाता है कि क्या बदला, पैच करता है, टेस्ट करता है, फ़िक्स डिप्लॉय करता है, और इस बीच जो प्रोसेस ऑटोमेट हो रही थी वह या तो मैन्युअली चली या चली ही नहीं।

यह मेंटेनेंस ट्रैप है, और यह इम्प्लीमेंटेशन की विफलता नहीं बल्कि संरचनात्मक समस्या है। पारंपरिक ऑटोमेशन सटीक पाथ फ़ॉलो करता है, सटीक पैटर्न मैच करता है, और जैसे ही वास्तविकता उस समय से अलग होती है जब वर्कफ़्लो लिखा गया था, तुरंत टूट जाता है। रिसर्च एक जैसी है: संगठन अपने कुल ऑटोमेशन प्रोग्राम खर्च का 70 से 75 प्रतिशत नए वर्कफ़्लो बनाने पर नहीं बल्कि मौजूदा वर्कफ़्लो को मेंटेन करने पर खर्च करते हैं। बड़े डिप्लॉयमेंट में, 45 प्रतिशत वर्कफ़्लो हर हफ़्ते टूटते हैं।

Triggerfish का वर्कफ़्लो इंजन इसे बदलने के लिए बनाया गया था। सेल्फ-हीलिंग वर्कफ़्लो आज शिप हो रहे हैं, और ये प्लेटफ़ॉर्म की अब तक की सबसे महत्वपूर्ण क्षमता हैं।

सेल्फ-हीलिंग का वास्तव में क्या मतलब है

यह शब्द ढीले तरीके से इस्तेमाल होता है, तो मैं सीधे बताता हूँ कि यह क्या है।

जब आप किसी Triggerfish वर्कफ़्लो पर सेल्फ-हीलिंग इनेबल करते हैं, तो उस वर्कफ़्लो के चलना शुरू होते ही एक लीड एजेंट स्पॉन होता है। यह कुछ टूटने पर लॉन्च नहीं होता; यह पहले स्टेप से ही वॉच कर रहा होता है, इंजन से एक लाइव इवेंट स्ट्रीम प्राप्त करता है जैसे-जैसे वर्कफ़्लो आगे बढ़ता है और हर स्टेप को रियल टाइम में ऑब्ज़र्व करता है।

लीड को एक भी स्टेप चलने से पहले पूरी वर्कफ़्लो डेफ़िनिशन पता होती है, जिसमें हर स्टेप के पीछे का इंटेंट, हर स्टेप अपने से पहले के स्टेप्स से क्या उम्मीद करता है, और अपने बाद के स्टेप्स के लिए क्या प्रोड्यूस करता है — यह सब शामिल है। इसे पिछले रन का इतिहास भी पता होता है: क्या सफल हुआ, क्या विफल हुआ, क्या पैच प्रस्तावित हुए और किसी इंसान ने उन्हें अप्रूव किया या रिजेक्ट किया। जब यह कुछ ऐसा पहचानता है जिस पर एक्शन लेना ज़रूरी है, तो वह सारा कॉन्टेक्स्ट पहले से मेमोरी में होता है क्योंकि यह पूरे समय वॉच कर रहा था, बजाय इसके कि बाद में रीकंस्ट्रक्ट करे।

जब कुछ गलत होता है, तो लीड उसकी ट्राइएज करता है। एक फ़्लेकी नेटवर्क कॉल को बैकऑफ़ के साथ रिट्राई मिलती है। एक बदला हुआ API एंडपॉइंट जिसके लिए वर्कअराउंड संभव है, उसे इस रन के लिए वर्कअराउंड किया जाता है। वर्कफ़्लो डेफ़िनिशन में कोई स्ट्रक्चरल समस्या होने पर रन पूरा करने के लिए एक प्रस्तावित फ़िक्स लागू किया जाता है, और वह बदलाव स्थायी होने से पहले आपकी अप्रूवल के लिए सबमिट किया जाता है। एक टूटे हुए प्लगइन इंटीग्रेशन के लिए एक नया या अपडेटेड प्लगइन लिखकर रिव्यू के लिए सबमिट किया जाता है। अगर लीड अपने सारे प्रयास खर्च कर देता है और समस्या हल नहीं कर पाता, तो यह आपको एक स्ट्रक्चर्ड डायग्नोसिस के साथ एस्केलेट करता है जिसमें बताया जाता है कि उसने क्या ट्राई किया और उसके अनुसार रूट कॉज़ क्या है।

वर्कफ़्लो जब भी सुरक्षित रूप से चल सकता है, चलता रहता है। अगर कोई स्टेप ब्लॉक होता है, तो सिर्फ़ वे डाउनस्ट्रीम स्टेप्स रुकते हैं जो उस पर निर्भर हैं जबकि पैरेलल ब्रांचेज़ जारी रहती हैं। लीड को डिपेंडेंसी ग्राफ़ पता होता है और यह सिर्फ़ वही पॉज़ करता है जो वास्तव में ब्लॉक है।

आप वर्कफ़्लो में जो कॉन्टेक्स्ट डालते हैं वह क्यों मायने रखता है

जो चीज़ सेल्फ-हीलिंग को प्रैक्टिस में काम करती है वह यह है कि Triggerfish वर्कफ़्लो को लिखते समय से ही रिच स्टेप-लेवल मेटाडेटा की ज़रूरत होती है। यह वैकल्पिक नहीं है और यह अपने आप में डॉक्यूमेंटेशन के लिए नहीं है; यह वह है जिससे लीड एजेंट रीज़न करता है।

वर्कफ़्लो में हर स्टेप में टास्क डेफ़िनिशन के अलावा चार अनिवार्य फ़ील्ड होते हैं: एक डिस्क्रिप्शन जो बताता है कि स्टेप मैकेनिकली क्या करता है, एक इंटेंट स्टेटमेंट जो बताता है कि यह स्टेप क्यों है और यह किस बिज़नेस उद्देश्य की पूर्ति करता है, एक expects फ़ील्ड जो बताता है कि इसे कौन सा डेटा प्राप्त होने की उम्मीद है और पिछले स्टेप्स को किस स्थिति में होना चाहिए, और एक produces फ़ील्ड जो बताता है कि यह डाउनस्ट्रीम स्टेप्स के उपयोग के लिए कॉन्टेक्स्ट में क्या लिखता है।

प्रैक्टिस में यह कैसा दिखता है। मान लीजिए आप एम्प्लॉयी एक्सेस प्रोविज़निंग ऑटोमेट कर रहे हैं। एक नई हायर सोमवार से शुरू हो रही है और वर्कफ़्लो को Active Directory में अकाउंट बनाने, उनकी GitHub ऑर्ग मेंबरशिप प्रोविज़न करने, उनके Okta ग्रुप असाइन करने, और कम्प्लीशन कन्फ़र्म करने के लिए एक Jira टिकट खोलने की ज़रूरत है। एक स्टेप आपके HR सिस्टम से एम्प्लॉयी रिकॉर्ड फ़ेच करता है। उसका इंटेंट फ़ील्ड सिर्फ़ "एम्प्लॉयी रिकॉर्ड लाओ" नहीं कहता। यह कहता है: "यह स्टेप हर डाउनस्ट्रीम प्रोविज़निंग निर्णय के लिए सत्य का स्रोत है। इस रिकॉर्ड से रोल, डिपार्टमेंट और स्टार्ट डेट यह तय करते हैं कि कौन से AD ग्रुप असाइन होंगे, कौन सी GitHub टीमें प्रोविज़न होंगी, और कौन सी Okta पॉलिसीज़ लागू होंगी। अगर यह स्टेप पुराना या अधूरा डेटा रिटर्न करता है, तो हर डाउनस्ट्रीम स्टेप गलत एक्सेस प्रोविज़न करेगा।"

लीड उस इंटेंट स्टेटमेंट को तब पढ़ता है जब स्टेप फ़ेल होता है और समझता है कि दाँव पर क्या है। उसे पता होता है कि एक पार्शियल रिकॉर्ड का मतलब है कि एक्सेस प्रोविज़निंग स्टेप्स गलत इनपुट के साथ चलेंगे, जिससे दो दिन में शुरू होने वाले एक वास्तविक व्यक्ति को गलत परमिशन मिल सकती हैं। यह कॉन्टेक्स्ट इसे आकार देता है कि वह कैसे रिकवर करने की कोशिश करता है, डाउनस्ट्रीम स्टेप्स को पॉज़ करता है या नहीं, और एस्केलेट करने पर आपको क्या बताता है।

उसी वर्कफ़्लो में एक और स्टेप HR फ़ेच स्टेप का produces फ़ील्ड चेक करता है और जानता है कि उसे .employee.role और .employee.department नॉन-एम्प्टी स्ट्रिंग्स के रूप में मिलने चाहिए। अगर आपका HR सिस्टम अपना API अपडेट करता है और उन फ़ील्ड्स को .employee.profile.role के अंदर नेस्टेड रिटर्न करने लगता है, तो लीड स्कीमा ड्रिफ़्ट का पता लगाता है, इस रन के लिए एक रनटाइम मैपिंग लागू करता है ताकि नई हायर सही ढंग से प्रोविज़न हो, और स्टेप डेफ़िनिशन अपडेट करने के लिए एक स्ट्रक्चरल फ़िक्स प्रस्तावित करता है। आपने इस विशिष्ट केस के लिए कोई स्कीमा माइग्रेशन रूल या एक्सेप्शन हैंडलिंग नहीं लिखी। लीड ने उस कॉन्टेक्स्ट से रीज़न किया जो पहले से वहाँ था।

इसीलिए वर्कफ़्लो ऑथरिंग क्वालिटी मायने रखती है। मेटाडेटा सिर्फ़ औपचारिकता नहीं है; यह वह ईंधन है जिस पर सेल्फ-हीलिंग सिस्टम चलता है। उथले स्टेप डिस्क्रिप्शन वाला वर्कफ़्लो एक ऐसा वर्कफ़्लो है जिसके बारे में लीड तब रीज़न नहीं कर पाता जब इसकी सबसे ज़्यादा ज़रूरत होती है।

लाइव वॉच करने का मतलब है समस्याओं को विफलता बनने से पहले पकड़ना

चूँकि लीड रियल टाइम में वॉच कर रहा होता है, यह सॉफ़्ट सिग्नल्स पर तब एक्ट कर सकता है जब चीज़ें वास्तव में टूटी भी नहीं होतीं। एक स्टेप जो ऐतिहासिक रूप से दो सेकंड में पूरा होता था अब चालीस सेकंड ले रहा है। एक स्टेप जो हर पिछले रन में डेटा रिटर्न करता था अब एम्प्टी रिज़ल्ट रिटर्न कर रहा है। एक कंडीशनल ब्रांच ली जा रही है जो पूरे रन हिस्ट्री में कभी नहीं ली गई। इनमें से कोई भी हार्ड एरर नहीं है और वर्कफ़्लो चलता रहता है, लेकिन ये सिग्नल हैं कि एनवायरनमेंट में कुछ बदल गया है। इन्हें तब पकड़ना बेहतर है जब अगला स्टेप ख़राब डेटा कंज़्यूम करने की कोशिश करे उससे पहले।

इन चेक्स की सेंसिटिविटी हर वर्कफ़्लो के लिए कॉन्फ़िगर की जा सकती है। एक नाइटली रिपोर्ट जनरेशन में ढीले थ्रेशोल्ड हो सकते हैं जबकि एक एक्सेस प्रोविज़निंग पाइपलाइन बारीकी से वॉच करती है। आप सेट करते हैं कि कितने विचलन पर लीड का ध्यान जाना चाहिए।

यह अभी भी आपका वर्कफ़्लो है

लीड एजेंट और उसकी टीम आपकी अप्रूवल के बिना आपकी कैनोनिकल वर्कफ़्लो डेफ़िनिशन नहीं बदल सकते। जब लीड एक स्ट्रक्चरल फ़िक्स प्रस्तावित करता है, तो वह मौजूदा रन पूरा करने के लिए फ़िक्स लागू करता है और बदलाव को एक प्रस्ताव के रूप में सबमिट करता है। आप इसे अपनी क्यू में देखते हैं, रीज़निंग देखते हैं, अप्रूव या रिजेक्ट करते हैं। अगर आप रिजेक्ट करते हैं, तो वह रिजेक्शन रिकॉर्ड होती है और उस वर्कफ़्लो पर काम करने वाला हर भविष्य का लीड जानता है कि वही चीज़ दोबारा प्रस्तावित नहीं करनी है।

एक चीज़ है जो लीड कॉन्फ़िगरेशन की परवाह किए बिना कभी नहीं बदल सकता: अपना ख़ुद का मैंडेट। वर्कफ़्लो डेफ़िनिशन में सेल्फ-हीलिंग पॉलिसी — पॉज़ करना है या नहीं, कितनी देर रिट्राई करना है, अप्रूवल ज़रूरी है या नहीं — यह ओनर-ऑथर्ड पॉलिसी है। लीड टास्क डेफ़िनिशन पैच कर सकता है, API कॉल अपडेट कर सकता है, पैरामीटर एडजस्ट कर सकता है, और नए प्लगइन लिख सकता है। यह अपने ख़ुद के व्यवहार को नियंत्रित करने वाले नियम नहीं बदल सकता। यह सीमा हार्ड-कोडेड है। एक एजेंट जो अपने ख़ुद के प्रस्तावों पर लागू अप्रूवल आवश्यकता को अक्षम कर सके, पूरे ट्रस्ट मॉडल को अर्थहीन बना देगा।

प्लगइन परिवर्तन उसी अप्रूवल पाथ से गुज़रते हैं जो Triggerfish में किसी भी एजेंट द्वारा लिखे गए प्लगइन के लिए है। यह तथ्य कि प्लगइन किसी टूटे हुए वर्कफ़्लो को ठीक करने के लिए लिखा गया था, इसे कोई विशेष भरोसा नहीं देता। यह उसी रिव्यू से गुज़रता है जैसे आपने किसी एजेंट से स्क्रैच से कोई नया इंटीग्रेशन बनाने को कहा हो।

इसे हर उस चैनल पर मैनेज करना जो आप पहले से इस्तेमाल कर रहे हैं

आपको यह जानने के लिए कि आपके वर्कफ़्लो क्या कर रहे हैं, किसी अलग डैशबोर्ड में लॉगिन नहीं करना चाहिए। सेल्फ-हीलिंग नोटिफ़िकेशन वहीं आती हैं जहाँ आपने Triggerfish को पहुँचने के लिए कॉन्फ़िगर किया है: Slack पर इंटरवेंशन समरी, Telegram पर अप्रूवल रिक्वेस्ट, ईमेल से एस्केलेशन रिपोर्ट। सिस्टम अर्जेंसी के हिसाब से सही चैनल पर आप तक पहुँचता है बिना आपके किसी मॉनिटरिंग कंसोल को रिफ़्रेश किए।

वर्कफ़्लो स्टेटस मॉडल इसी के लिए बनाया गया है। स्टेटस कोई फ़्लैट स्ट्रिंग नहीं बल्कि एक स्ट्रक्चर्ड ऑब्जेक्ट है जो वह सब कुछ कैरी करता है जो एक नोटिफ़िकेशन को अर्थपूर्ण बनाने के लिए ज़रूरी है: मौजूदा स्थिति, हेल्थ सिग्नल, कोई पैच आपकी अप्रूवल क्यू में है या नहीं, पिछले रन का परिणाम, और लीड अभी क्या कर रहा है। आपका Slack मेसेज एक ही नोटिफ़िकेशन में कह सकता है "एक्सेस प्रोविज़निंग वर्कफ़्लो पॉज़्ड है, लीड प्लगइन फ़िक्स लिख रहा है, अप्रूवल ज़रूरी होगी" — बिना कॉन्टेक्स्ट खोजे।

जब आप पूरी तस्वीर चाहते हैं तो वही स्ट्रक्चर्ड स्टेटस लाइव Tidepool इंटरफ़ेस को फ़ीड करता है। वही डेटा, अलग सरफ़ेस।

IT टीमों के लिए यह वास्तव में क्या बदलता है

आपके संगठन में जो लोग अपना हफ़्ता टूटे वर्कफ़्लो ठीक करने में बिताते हैं, वे कम-कुशल काम नहीं कर रहे। वे डिस्ट्रिब्यूटेड सिस्टम्स डीबग कर रहे हैं, API चेंजलॉग पढ़ रहे हैं, और रिवर्स-इंजीनियरिंग कर रहे हैं कि कल तक सही चल रहा वर्कफ़्लो आज क्यों फ़ेल हो रहा है। यह मूल्यवान निर्णय-क्षमता है, और अभी यह लगभग पूरी तरह मौजूदा ऑटोमेशन को ज़िंदा रखने में खप रही है बजाय नया ऑटोमेशन बनाने या कठिन समस्याएँ हल करने के।

सेल्फ-हीलिंग वर्कफ़्लो उस निर्णय-क्षमता को ख़त्म नहीं करते, बल्कि यह बदलते हैं कि वह कब लागू होती है। आधी रात को किसी टूटे वर्कफ़्लो पर फ़ायरफ़ाइटिंग करने की बजाय, आप सुबह एक प्रस्तावित फ़िक्स रिव्यू कर रहे हैं और तय कर रहे हैं कि लीड का डायग्नोसिस सही है या नहीं। आप एक प्रस्तावित बदलाव के अप्रूवर हैं, न कि दबाव में पैच लिखने वाले।

यही वह लेबर मॉडल है जिसके इर्द-गिर्द Triggerfish बना है: इंसान एजेंट के काम को रिव्यू और अप्रूव करें बजाय उस काम को ख़ुद करने के जो एजेंट संभाल सकते हैं। ऑटोमेशन कवरेज बढ़ता है जबकि मेंटेनेंस बोझ घटता है, और जो टीम अपने 75 प्रतिशत समय अपकीप पर खर्च कर रही थी वह उस समय का बड़ा हिस्सा उन चीज़ों की ओर रीडायरेक्ट कर सकती है जिनमें वास्तव में मानवीय निर्णय की ज़रूरत है।

आज शिप हो रहा है

सेल्फ-हीलिंग वर्कफ़्लो आज Triggerfish वर्कफ़्लो इंजन में एक वैकल्पिक फ़ीचर के रूप में शिप हो रहे हैं। यह प्रति वर्कफ़्लो ऑप्ट-इन है, वर्कफ़्लो मेटाडेटा ब्लॉक में कॉन्फ़िगर किया जाता है। अगर आप इसे इनेबल नहीं करते, तो आपके वर्कफ़्लो के चलने के तरीके में कुछ नहीं बदलता।

यह इसलिए मायने रखता है कि यह सीधे उस चीज़ को संबोधित करता है जिसने एंटरप्राइज़ ऑटोमेशन को ज़रूरत से ज़्यादा महँगा और कठिन बना दिया है, न कि इसलिए कि यह एक कठिन तकनीकी समस्या है (हालाँकि यह है)। वर्कफ़्लो मेंटेनेंस टीम वह पहली नौकरी होनी चाहिए जो AI ऑटोमेशन ले। यह इस तकनीक का सही उपयोग है, और Triggerfish ने यही बनाया है।

अगर आप जानना चाहते हैं कि यह कैसे काम करता है, तो पूरा स्पेक रिपॉज़िटरी में है। अगर आप इसे आज़माना चाहते हैं, तो workflow-builder स्किल आपको आपका पहला सेल्फ-हीलिंग वर्कफ़्लो लिखने में गाइड करेगी।