एक मासिक रनबुक एक पुनरुत्पादक बैकलिंक रिपोर्ट के लिए

मासिक क्यों और दैनिक क्यों नहीं

हमारा ग्राफ़ लगभग महीने में एक बार रिफ्रेश होता है। एक दैनिक जॉब वही नंबर लौटाता है।

इसे बार-बार चलाने से रिपोर्ट अधिक वर्तमान नहीं बनती, यह इसे समझाने की लागत केवल बढ़ाती है। एक पाठक जो 30 समान बिंदु देखता है, वह मानेगा कि पाइपलाइन खराब है।

महीने में एक दिन जानबूझकर चुनें, आदर्श रूप से पिछले रिफ्रेश के स्थिर होने के एक सप्ताह बाद। फ़ाइल के नाम में तारीख लिखें, ताकि शेड्यूल स्वयं दस्तावेजित हो।

पहले कैलेंडर चुनें और रिपोर्ट को उसका अनुसरण करने दें। एक रिपोर्ट जो हर बार जब कोई नोटबुक खोलता है फिर से बनती है, उसकी कोई स्पष्ट तारीख नहीं होती, और समीक्षा में यह बचाना मुश्किल है।

नंबरों के अलावा क्या स्टोर करें

रिपोर्ट का आधा हिस्सा मेटाडेटा है, इसलिए इसे नंबरों के साथ स्टोर करें।

खींचने की तारीख, एक्शन नाम, पैरामीटर (per, sort, order) और प्रतिक्रिया के क्रेडिट फ़ील्ड को हर स्नैपशॉप के बगल में एक छोटी साइडकार फ़ाइल में लिखें। छह महीने बाद, जब कोई सहकर्मी पूछता है कि अक्टूबर सितंबर से अलग क्यों दिखता है, वह फ़ाइल दस सेकंड में जवाब देती है, न कि एक दोपहर में।

स्क्रिप्ट के git commit और renv से पैकेज वर्जन जोड़ें। एक रिपोर्ट जो यह नहीं बता सकती कि किस कोड और किस इंडेक्स स्टेट ने चार्ट बनाया, वह एक स्क्रीनशॉट है, विश्लेषण नहीं, चाहे tibble कितनी भी साफ़ क्यों न दिखे।

एक न्यूनतम targets लेआउट

जब योजना छोटी रहती है तो तीन targets काफी हैं।

एक टार्गेट API से खींचता है और तारीख वाली फ़ाइल लिखता है, एक फ़ाइल पढ़ता है और tibble बनाता है, एक Quarto दस्तावेज़ रेंडर करता है। चूंकि केवल पहला टार्गेट नेटवर्क को छूता है, आप बाकी को जितनी बार चाहें ऑफ़लाइन रन कर सकते हैं और चार्ट गलती से नहीं बदलेगा।

renv के साथ पैकेज वर्जन को पिन करें, रिपोर्ट के फुटर में सत्र जानकारी रिकॉर्ड करें, और बल्क स्कोरिंग पेज से थ्रेशोल्ड टेबल को कोड के बगल रिपॉजिटरी में रखें। पैसे के पक्ष के लिए, बजट पेज आपको बताता है कि एक महीने में कितना खर्च होना चाहिए।

जब कुछ फेल हो जाए, तो पहले कोड पढ़ें। HTTP 401 का मतलब है कि कुंजी गलत या गायब है। HTTP 402 का मतलब है कि क्रेडिट खत्म हो गए। बाकी सब कुछ पूरा लॉग करने योग्य है। teardown उन चरणों को कवर करता है, और join उदाहरण शेड्यूल करने के लिए एक अच्छी पहली जॉब है।

यह जानना कि एक रन गलत हो गया है, एक सहकर्मी से पहले

एक पुनरुत्पादक बैकलिंक रिपोर्ट जो चुपचाप फेल होती है, उससे ज्यादा भ्रमित करती है जो कभी नहीं चली। असल सवाल यह नहीं है कि क्या जॉब फेल हो सकती है, बल्कि यह है कि किसी को इसके बारे में कितनी जल्दी पता चलता है।

जॉब को जोर से फेल करें

एक शेड्यूल किया गया जॉब एक गैर-शून्य स्टेटस के साथ बाहर निकलता है जब एक कॉल HTTP 401 या 402 लौटाती है, और शेड्यूलर रन को फेल के रूप में चिह्नित करता है। यह आपका सबसे सस्ता अलर्ट है, और इसके लिए किसी अतिरिक्त सेवा की आवश्यकता नहीं है।

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

प्रत्येक विफलता के लिए एक संदेश भेजें

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

संदेश में विफल टार्गेट, स्टेटस कोड और समय का नाम होना चाहिए। बाकी सब कुछ लॉग में है।

जांचें कि आउटपुट संयुक्त है

एक रन सफल हो सकता है और फिर भी गलत हो सकता है। पिछले महीने की तुलना में पंक्ति गिनती से तुलना करें, और एक थ्रेशोल्ड से आगे की गिरावट को फ्लैग करें जिसे आपने पहले से चुना था।

जांच उतनी ही सरल हो सकती है जितनी एक अपेक्षित रेंज। लक्ष्य एक आधा-खाली स्नैपशॉप को नोटिस करना है, एक चार्ट क्लाइंट तक पहुंचने से पहले।

रिपोर्ट के लिए एक मालिक नाम दें

रिपोर्ट के लिए एक मालिक नाम दें। एक अलर्ट जिसका कोई मालिक नहीं है, उसे हर कोई पढ़ता है और कोई भी कार्रवाई नहीं करता।

मालिक को जॉब ठीक करने की आवश्यकता नहीं है। मालिक को यह तय करना है कि क्या एक देर से रिपोर्ट स्वीकार्य है, और रिपोर्ट में ही कहना है।

रनबुक हेडर में मालिक का नाम लिखें, और जब मालिक बदल जाए तो इसे अपडेट करें। एक पूर्व मालिक वाली रनबुक एक शांत खतरा है।

दिन चुनना और पहली जॉब को हाथ से चलाना

टाइमिंग और पहली रन तय करते हैं कि क्या शेड्यूल बना रहेगा। दोनों पहले महीने में गलत करना आसान है, और दोनों सही करना सस्ता है।

दो निर्णय, एक बार लिखे गए, बाद में सबसे ज्यादा बहस बचाते हैं। पहला दिन है। दूसरा वह जगह है जहां टाइमर चलता है। दोनों रनबुक में होने चाहिए, किसी के दिमाग में नहीं।

एक दिन चुनें और उसे लिखें

महीने में एक निश्चित दिन, जैसे कि रिफ्रेश स्थिर होने के बाद पहले कार्य दिवस, एक अगले महीने की अनुमान से आसान है।

दिन को शेड्यूल फ़ाइल में ही डालें, ताकि टाइमिंग कोड का हिस्सा हो और किसी के कैलेंडर में कोई मेमोरी न हो।

पहली जॉब को हाथ से चलाएं

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

पहली रन सीक्रेट स्टोर का भी परीक्षण करती है। एक कुंजी जो आपकी मशीन पर काम करती है लेकिन CI में गायब है, पहली शेड्यूल विफलता का एक सामान्य कारण है।

साइडकार को ईमानदार रखें

साइडकार फ़ाइल रिकॉर्ड करती है कि रन ने क्या किया। यदि कोई व्यक्ति इसे हाथ से लिखता है, तो यह रन से भटक जाता है। स्क्रिप्ट को इसे लिखने दें, और लोगों को केवल इसे पढ़ने दें।

एक साइडकार जिसे स्क्रिप्ट ने कभी छुआ नहीं, एक नोट है, रिकॉर्ड नहीं, और रिपोर्ट को रिकॉर्ड का उल्लेख करना चाहिए।

एक महीने में साइडकार को फ़ाइल से तुलना करें। यदि दो में नंबर असहमत हैं, तो रन एक ऐसे तरीके से फेल हो गया जिसे स्क्रिप्ट ने नोटिस नहीं किया।

टाइमर कहाँ रहता है

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

जो भी आप चुनते हैं, टाइमर को रिपॉजिटरी में स्क्रिप्ट के बगल में लिखें, ताकि अगला व्यक्ति जान सके कि जॉब कहाँ रहती है।