जिन रन पर आप भरोसा कर सकते हैं

कोई ऑटोमेशन पर ध्यान तब तक नहीं देता जब तक वह कुछ दो बार न भेज दे

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

प्रकाशित करने से पहले सिमुलेट करें

किसी बंद वर्कफ़्लो से एक वास्तविक रिकॉर्ड पास करें, और ठीक यही पढ़ें कि क्या होता: कौन-सा पथ चुना गया, हर स्टेप पर हर मान, हर संदेश की भाषा, और वह अनुरोध जो प्रत्येक बाहरी सिस्टम को जाता।

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

सिमुलेशन ही उस प्रश्न का उत्तर है जो लोगों को ऑटोमेशन चालू करने से रोकता है: यह वास्तव में क्या करेगा?

सिमुलेशन · ऑर्डर 88 214कुछ भेजा नहीं गया

1पता सत्यापित करेंमेल खाया। 6 फ़ील्ड लिखे होते।
?शर्त1 000 zł से अधिक का ऑर्डर? नहीं — 289,00 zł। छोटा पथ अपनाया गया।
3इनवॉइसइनवॉइसिंग सिस्टम को POST किया होता। पेलोड पूरा दिखाया गया है।
!यहाँ पकड़ा गयाVAT दर गलत फ़ील्ड से मैप हुई। लेखक के इनबॉक्स के बजाय सिमुलेशन में मिली।

भेजा गया: कुछ नहींशुल्क लिया गया: कुछ नहीं

हर रन उसी संस्करण पर चलता है जिस पर वह प्रवेश करता है

किसी वर्कफ़्लो में बदलाव प्रकाशित करने से उसके भीतर पहले से चल रहे रन प्रभावित नहीं होते। प्रत्येक रन उसी संस्करण से बंधा रहता है जिस पर वह शुरू हुआ था और उसी संस्करण को पूरा करता है, चाहे उसमें कितना भी समय लगे और आप बीच में कितना भी बदलाव करें।

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

नए रन को नया संस्करण प्रकाशित करते ही मिल जाता है। कोई रन किस संस्करण पर है, यह रन पर ही लिखा रहता है, इसलिए मार्च के व्यवहार का प्रश्न सितंबर में भी उत्तर रखता है।

चालू अवस्था में संपादनv4 → v5

1पहले2 918 रन चल रहे हैं, सभी v4 पर। कुछ दो-दिन की प्रतीक्षा में हैं।
2v5 प्रकाशित करें11:40दो चरणों का क्रम बदला, एक संदेश फिर से लिखा।
3बाद मेंवे 2 918 रन v4 पूरा करेंगे। 11:40 से शुरू होने वाला सब कुछ v5 चलाएगा।
§किसी को नहींएक ही वर्कफ़्लो का आधा और दूसरे का आधा मिला।

प्रत्येक रन पर संस्करण दर्जपुराने संस्करण सुरक्षित रखे गए

पुनःप्रयास जो दोबारा भेज नहीं सकते

एक चरण अपने इनपुट का शुद्ध फ़ंक्शन है, और उसके प्रभाव रन की अगले चरण की ओर प्रगति के साथ एक साथ कमिट होते हैं। ऐसा कोई अंतराल नहीं जिसमें संदेश जा चुका हो पर रन को इसकी जानकारी न हो।

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

आइडेंपोटेंसी की समर्थन करने वाले सिस्टमों को की जाने वाली आउटबाउंड कॉल में एक की जाती है, जो रन और चरण से बनाई जाती है, ताकि सामने वाला पक्ष भी दोहराव को पहचान सके।

भेजने के बीच वर्कर मरारिकवर हुआ

1चरण 5 शुरू होता है09:14:06शिपिंग सूचना भेजें।
✕वर्कर मर जाता है09:14:07डिप्लॉय। कुछ भी कमिट नहीं हुआ था।
2उठाया गया09:14:31दूसरा वर्कर रन को अब भी चरण 5 पर पाता है।
✓एक बार भेजा गया09:14:32ग्राहक को एक ई-मेल मिला, दो नहीं।

प्रभाव प्रगति के साथ कमिट होते हैंप्रति रन और चरण आइडेंपोटेंसी की

ऐसा लॉग जो इंसान के पढ़ने के लिए लिखा गया हो

हर रन, हर चरण, लिया गया शाखा-पथ और उसे तय करने वाला मान। प्रति चरण समय। प्रत्येक बाहरी कॉल का अनुरोध और प्रतिक्रिया, क्रेडेंशियल हटाकर। रन जिस संस्करण पर था। रन कहाँ प्रतीक्षा कर रहा है और कब तक।

जब कोई पूछे कि चौदह तारीख़ को दिए गए ऑर्डर का क्या हुआ, तो उत्तर मौजूद है, और उसे ढूँढने में एक मिनट लगता है, तीन सिस्टमों के लॉग मिलाने की एक दोपहर नहीं।

विफल होने वाले रन एक जगह इकट्ठा होते हैं और कारण के अनुसार समूहित होते हैं, ताकि “रातभर में इकतालीस विफलताएँ” का अर्थ निकले “एक आपूर्तिकर्ता ने नौ मिनट तक 503 लौटाया”, न कि इकतालीस अलग-अलग जाँच-पड़ताल।

रातभर, समूहित41 विफलताएँ

1एक कारणआपूर्तिकर्ता API ने 02:41 से 02:50 के बीच 503 लौटाया।
2क्या हुआसभी 41 फिर से आज़माए गए; 39 दूसरे प्रयास में सफल हुए।
3शेष बचेदो रुक गए हैं और किसी व्यक्ति की प्रतीक्षा कर रहे हैं। दोनों उस पंक्ति के साथ सूचीबद्ध हैं जो विफल हुई।
§इकतालीस नहींजाँच-पड़तालें। एक, और दो रिकॉर्ड के बारे में एक निर्णय।

क्रेडेंशियल छिपाए गएसंस्करण दर्ज

जो हम दावा नहीं करते

हम मार्केटिंग पृष्ठ पर अपटाइम का आँकड़ा प्रकाशित नहीं करते, क्योंकि मापन की अवधि और “चालू” की परिभाषा के बिना कोई संख्या केवल सजावट है। यदि आपको इसकी अनुबंध के तहत आवश्यकता है, तो पूछें और हम बात करेंगे कि हम वास्तव में किस बात का वचन दे सकते हैं।

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

प्रतीक्षा पर: दो दिन से प्रतीक्षारत रन एक कतार में बैठा कोई जॉब नहीं, बल्कि रन पर एक wake_at है। इसीलिए एक वर्कफ़्लो तीन सप्ताह की प्रतीक्षा में एक लाख रन रख सकता है बिना किसी लागत के, और इसीलिए इस समय प्रतीक्षारत रनों की संख्या पर आपको सोचने की आवश्यकता नहीं है।