castomFLOW
castomFLOW उघडा

विश्वास ठेवता येणारे रन

कोणीही ऑटोमेशनकडे लक्ष देत नाही जोपर्यंत तो एखादे काहीतरी दोनदा पाठवत नाही

मग सर्वजण लक्षात घेतात. या पानावरील चार यंत्रणा अस्तित्वात आहेत कारण या प्रकारच्या सॉफ्टवेअरची अपयशे नेहमी तीच चार असतात, आणि ती काळजीने नव्हे तर डिझाइनने टाळता येतात.

प्रकाशित करण्यापूर्वी सिम्युलेशन करा

बंद असलेल्या वर्कफ्लोमधून खरा रेकॉर्ड पाठवा, आणि नेमके काय घडले असते ते परत वाचा: घेतलेला मार्ग, प्रत्येक स्टेपवरील प्रत्येक मूल्य, प्रत्येक संदेशाचे शब्द, आणि प्रत्येक बाह्य प्रणालीला गेला असता विनंती.

काहीही बाहेर जात नाही. ईमेल पाठवला जात नाही, बिल तयार होत नाही, शुल्क आकारले जात नाही, ओळ लिहिली जात नाही. बाह्य कॉल इंटेन्शन म्हणून नोंदवले जातात, पाठवले गेले असता पेलोडसह, ज्यामुळे ते एखाद्याची समस्या होण्यापूर्वी मॅपिंग बरोबर आहे का हे आपण पाहू शकता.

सिम्युलेशन हा त्या प्रश्नाचे उत्तर आहे जो लोकांना ऑटोमेशन चालू करण्यापासून थांबवतो: हे प्रत्यक्षात काय करेल?

सिम्युलेशन · ऑर्डर 88 214काहीही पाठवले नाही
  • 1पत्ता तपासाजुळले. ६ फील्ड लिहिले असते.
  • ?अट१ ००० zł पेक्षा जास्त ऑर्डर? नाही — २८९,०० zł. लहान मार्ग घेतला.
  • 3बीजकइन्व्हॉइसिंग प्रणालीला POST केले असते. पेलोड पूर्ण दाखवले आहे.
  • !येथे पकडलेVAT दर चुकीच्या फील्डमधून मॅप झाला. लेखापालाच्या इनबॉक्समध्ये न जाता सिम्युलेशनमध्ये आढळला.

पाठवले: काहीही नाहीआकारले: काहीही नाही

प्रत्येक रन ज्या आवृत्तीवर प्रवेश करते तीच आवृत्ती पाळते

वर्कफ्लोमध्ये बदल प्रकाशित केल्याने त्यात आधीच असलेल्या रन्सवर परिणाम होत नाही. प्रत्येक रन ज्या आवृत्तीवर सुरू झाले तीच आवृत्तीवर बद्ध असते आणि ती आवृत्ती पूर्ण करते — त्याला कितीही वेळ लागो, आणि त्या दरम्यान आपण कितीही बदल करा.

त्यामुळे दहा हजार लोक अर्ध्या वाटेवर असताना आपण वर्कफ्लोची रचना बदलू शकता, आणि प्रत्येकजण जो प्रवाह त्यांना दिला होता तोच पूर्ण करतो. पर्याय — प्रवेशावेळी संपूर्ण पुढील मार्ग तयार करणारी रचना — बहुतांश टूल्समध्ये चालू ऑटोमेशन संपादित करणे धोकादायक वाटण्याचे कारण आहे. येथे ते सामान्य गोष्ट आहे.

आपण प्रकाशित केल्याच्या क्षणापासून नवीन रन्स नवीन आवृत्ती घेतात. रन कोणत्या आवृत्तीवर आहे हे त्या रनवरच लिहिलेले असते, त्यामुळे मार्चमधील वर्तनाबद्दलच्या प्रश्नाचे उत्तर सप्टेंबरमध्येही उपलब्ध असते.

चालू असताना संपादनv4 → v5
  • 1पूर्वी२ ९१८ रन्स चालू आहेत, सर्व v4 वर. काही दोन दिवसांच्या प्रतीक्षेत.
  • 2v5 प्रकाशित करादोन टप्पे पुनर्क्रमित केले, एक संदेश पुनर्लिखित केला.
  • 3नंतरते २ ९१८ रन्स v4 पूर्ण करतील. ११:४० पासून सुरू होणारे सर्व रन्स v5 चालवतील.
  • §कोणीहीएका वर्कफ्लोचा अर्धा आणि दुसऱ्याचा अर्धा भाग मिळाला नाही.

प्रत्येक रनवर आवृत्ती नोंदवली जातेजुन्या आवृत्ती टिकवल्या जातात

दुहेरी पाठवणे अशक्य होईल असे रिट्राय

टप्पा हा त्याच्या इनपुट्सचे शुद्ध फंक्शन असतो, आणि त्याचे परिणाम रनच्या पुढील टप्प्याकडे जाण्याबरोबर एकत्र कमिट होतात. संदेश बाहेर गेला पण रनला ते माहीत नाही अशी कोणतीही क्षणभंगुर अवस्था नसते.

हेच संपूर्ण तंत्र आहे, आणि ते वचन नव्हे तर संरचनात्मक गुणधर्म आहे. टप्प्याच्या मध्येच खंडित झालेला वर्कर — डिप्लॉय, क्रॅश, नाहीसा झालेली मशीन — रनला तिथेच जसे होते तसे सोडतो. दुसरा वर्कर ते घेतो आणि टप्पा पुन्हा चालवतो. परिणाम आणि प्रगती एकत्र कमिट होत असल्याने, एकतर दोन्ही घडले किंवा काहीही घडले नाही.

आयडेम्पोटेन्सी की असलेल्या प्रणालींना केल्या जाणाऱ्या बाह्य कॉल्समध्ये ती असते, जी रन आणि टप्प्यावरून तयार होते, त्यामुळे समोरील बाजूही पुनरावृत्ती ओळखू शकते.

पाठवताना वर्कर खंडित झालापुनर्प्राप्त झाले
  • 1टप्पा ५ सुरू होतोशिपिंग सूचना पाठवा.
  • ✕वर्कर खंडित होतोडिप्लॉय. काहीही कमिट झाले नव्हते.
  • 2पुन्हा घेतलेदुसरा वर्कर रन अजूनही टप्पा ५ वर असल्याचे शोधतो.
  • ✓एकदाच पाठवलेग्राहकाला दोन नव्हे तर एकच ईमेल मिळाला.

परिणाम प्रगतीबरोबर कमिट होतातप्रत्येक रन आणि टप्प्यासाठी आयडेम्पोटेन्सी की

माणसाने वाचण्यासाठी लिहिलेला लॉग

प्रत्येक रन, प्रत्येक टप्पा, घेतलेली शाखा आणि ती ठरवणारे मूल्य. प्रत्येक टप्प्याची वेळ. प्रत्येक बाह्य कॉलची विनंती आणि प्रतिसाद, क्रेडेन्शियल्स लपवून. रन ज्या आवृत्तीवर होते ती. रन कुठे प्रतीक्षेत आहे आणि कधीपर्यंत.

चौदा तारखेला केलेल्या ऑर्डरचे काय झाले अशी कोणी विचारल्यास उत्तर असते, आणि ते शोधण्यास तीन प्रणालींचे लॉग जुळवण्याचा संध्याकाळ नव्हे तर एक मिनिट लागतो.

अयशस्वी होणाऱ्या रन एकाच ठिकाणी कारणासह गटबद्ध होतात, त्यामुळे "रात्रभरात एकतीस अपयले" हे "एका पुरवठादाराने 503 नऊ मिनिटांसाठी परत केले" असे सुटते, एकतीस वेगळ्या तपासण्यांचे नाही.

रात्रभर, गटबद्ध41 अपयले
  • 1एकच कारणपुरवठादाराच्या API ने 02:41 ते 02:50 दरम्यान 503 परत केले.
  • 2काय घडलेसर्व 41 पुन्हा प्रयत्न केले; 39 दुसऱ्या प्रयत्नात यशस्वी झाले.
  • 3शिल्लकदोन थांबलेले आहेत आणि व्यक्तीची वाट पाहत आहेत. दोन्ही अयशस्वी झालेल्या ओळीसह सूचीबद्ध आहेत.
  • §एकतीस नाहीतपासण्या. एक, आणि दोन रेकॉर्डबद्दल निर्णय.

क्रेडेन्शियल छुपे केलेआवृत्ती नोंदवली

आम्ही काय दावा करत नाही

आम्ही मार्केटिंग पृष्ठावर अपटाइम आकडा प्रकाशित करत नाही, कारण मोजमाप कालावधी आणि "चालू" च्या व्याख्येशिवाय एक आकडा म्हणजे केवळ सुशोभीकरण. आपल्याला तो करारनाम्यानुसार हवा असल्यास, विचारा आणि आम्ही प्रत्यक्षात काय वचन देऊ शकतो याबद्दल बोलू.

आम्ही दुसऱ्या कोणाचे API विश्वासार्ह बनवू शकत नाही. पुरवठादार खाली असल्यास, त्यावर अवलंबून असलेला वर्कफ्लो थांबतो, पुन्हा प्रयत्न करतो आणि शेवटी स्पष्ट कारणासह थांबतो. आम्ही वचन देऊ शकतो ते म्हणजे अपयश दृश्यमान असते, ते काहीही दूषित करत नाही, आणि पुन्हा सुरू करताना संदेश दुसऱ्यांदा पाठवला जात नाही.

प्रतीक्षेबद्दल: दोन दिवस थांबलेली रन म्हणजे रनवरील wake_at आहे, रांगेत बसलेले काम नाही. त्यामुळेच तीन-आठवड्याच्या प्रतीक्षेत एक वर्कफ्लो शंभर हजार रन धरू शकतो आणि त्याची किंमत काही लागत नाही, आणि सध्या प्रतीक्षेत असलेल्या रनची संख्या आपल्याला विचार करावी लागत नाही.

आपण कधीच विचार न करणारे रन म्हणजे यशस्वी झालेले रन.