DataOps डेटा वितरण और निगरानी व्यवस्थित करता है। सफल रन सही सामग्री या पूरी ट्रेसिंग सिद्ध नहीं करता।
पुनः प्रयास नियंत्रित करें
दोबारा चलाने का अपेक्षित परिणाम तय करें और दोहराव या आंशिक परिणाम रोकें। पुनरुत्पादन के लिए इनपुट, अवधि, नियम और संस्करण रखें; बदले इनपुट अलग परिणाम दे सकते हैं। नियंत्रित बहाली का रास्ता भी तय करें।
संस्करण और वंश अलग रखें
संस्करण अवस्थाएँ और बदलाव बताते हैं; वंश स्रोत, रूपांतरण और परिणाम जोड़ता है। उपयोग के अनुसार पूर्णता, विशिष्टता, संगति, समयबद्धता, वैधता और सटीकता जाँचें। सही प्रारूप में गलत मान हो सकता है और सटीक डेटा बहुत पुराना।
| बिंदु | दर्ज की जाने वाली जाँच |
|---|---|
| निष्पादन | तकनीकी स्थिति और अपेक्षित परिणाम |
| गुणवत्ता | उपयोग के अनुसार सामग्री जाँच |
| उत्पत्ति | स्रोत, रूपांतरण और परिणाम जुड़े |
स्रोत और सत्यापन
समय क्षेत्र और देर से आए घटनाक्रम
रिपोर्ट अवधि घटना समय और समापन नियमों पर निर्भर है।
- घटना का समय, प्राप्ति का समय और व्यवसाय का समय-क्षेत्र अलग दर्ज करें। काल्पनिक उदाहरण में 23:30 UTC, स्थिर UTC+02:00 अंतर पर अगले दिन 01:30 है। PostgreSQL का समय-क्षेत्र वाला टाइमस्टैम्प मूल क्षेत्र का नाम सुरक्षित नहीं रखता।
- शुरुआत शामिल करें और अंत बाहर रखें। UTC में बदलने से पहले व्यवसाय के क्षेत्र में सीमाएँ निकालें। मौसमी घड़ी परिवर्तन, महीने का बदलाव और बिना समय की तारीख जाँचें; स्थानीय दिन हमेशा 24 घंटे नहीं होता।
- स्वीकार्य विलंब और रिपोर्ट बंद करने का समय तय करें। वही पहचानकर्ता दोहराकर नई घटना को डुप्लिकेट से अलग करें। प्रकाशित संस्करण रखें और सुधार का प्रभाव दर्ज करें; वॉटरमार्क आगमन का अनुमान है, पूर्णता की गारंटी नहीं।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}अपेक्षित निर्णय
बताए समय क्षेत्र में घटना 9 अक्टूबर की है। UTC का क्षण भी सुरक्षित रखें।
सत्यापन प्रक्रिया
- रिपोर्ट समय क्षेत्र और संदर्भ क्षण तय करें।
- आधी रात के पास घटना दोहराएँ।
- UTC, स्थानीय तारीख़ और समाप्ति नियम रखें। घड़ी बदलते समय की अस्पष्ट स्थानीय घड़ी का उदाहरण जोड़ें; किसी क्षण का अनुमान लगाने के बजाय ऑफ़सेट और समय क्षेत्र सुरक्षित रखें।
क्या प्राप्ति की तारीख को घटना की तारीख मान सकते हैं?
केवल जब रिपोर्ट की परिभाषा ऐसा कहती हो। दोनों समय रखें और देर से आई घटनाओं का व्यवहार समझाएँ।
प्राथमिक स्रोत: PostgreSQL — Date/time types. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
संग्रह बाधा: लॉग और गायब घटनाएँ मिलाएँ
बनी, मिली और उपयोगी घटनाएँ अलग करें; मौन को घटना न होने का प्रमाण न मानें।
- एप्लिकेशन, कलेक्टर और भंडारण के जिम्मेदार लिखें। स्थिर पहचानकर्ताओं वाली सीमित काल्पनिक घटना-श्रृंखला तैयार करें, बिना रहस्य या ग्राहक डेटा। घटना और निरीक्षण का समय रखें; संग्रह में देरी स्वतः हानि नहीं है।
- परीक्षण में गंतव्य रोकें और फिर बहाल करें। कतार, प्रयास, अस्वीकृति और पुनः शुरू होना देखें। स्थायी कतार कुछ हानि सीमित कर सकती है, पर क्षमता सीमित और भंडारण पर निर्भर है; पूरी कतार का व्यवहार तय करें। जाँचें कि संग्रह सेवा चुपचाप न रोकता हो।
- एक ही निरीक्षण कटऑफ पर संदर्भ और वास्तव में पढ़ी जाने वाली घटनाएँ मिलाएँ। दोहराव, देरी और गायब घटनाएँ अलग गिनें; नेटवर्क पुष्टि अंतिम उपयोग साबित नहीं करती। विश्वसनीय संदर्भ न हो तो कवरेज अज्ञात है, शून्य हानि या शून्य घटना नहीं।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"expected_ids": [
"E1",
"E2",
"E3"
],
"received_ids": [
"E1",
"E1",
"E3"
],
"received_rows": 3,
"unique_received": 2,
"missing_ids": [
"E2"
],
"observation_cutoff": "same_for_both_sets"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: E1, E2 और E3 अपेक्षित हैं, लेकिन E1, E1 और E3 मिलते हैं। तीन पंक्तियाँ पूर्णता साबित नहीं करतीं: E1 दोहराता है और कटऑफ पर E2 गायब है।
प्राथमिक स्रोत: OpenTelemetry — Collector resiliency. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.
ZIP और TAR: निर्देशिका और संसाधन सीमा में निकालें
निकाली फ़ाइलों को प्रकाशित करने से पहले पथ, लिंक और वास्तविक विस्तार जाँचें।
- न्यूनतम अनुमति वाली नई गैर-सार्वजनिक निर्देशिका में निकालें। पूर्ण पथ, ऊपर जाने वाले पथ, अनावश्यक लिंक और विशेष फ़ाइलें अस्वीकार करें। वास्तविक समाधान किए लक्ष्य और नाम टकराव को लक्ष्य सिस्टम, अक्षर केस सहित, जाँचें। टेक्स्ट उपसर्ग अकेले सीमा साबित नहीं करता।
- लिखे बाइट, प्रविष्टि संख्या, गहराई, समय और प्रक्रिया संसाधन पर प्रति फ़ाइल और कुल सीमा रखें। केवल संपीड़ित या घोषित आकार न मानें। अनावश्यक नेस्टेड अभिलेख अस्वीकार करें; जरूरी हों तो सभी स्तर कुल बजट साझा करें। लाइब्रेरी और फ़िल्टर अद्यतन रखें।
- ../, पूर्ण पथ, लिंक, दोहराव और बजट अधिकता जाँचें। रुकावट में बैच प्रकाशित न हो और पुरानी फ़ाइल न बदले। प्रकार और सामग्री जाँचकर प्रकाशित करें; अलग निर्देशिका साफ करते समय लक्ष्य सत्यापित करें।
दोहराने योग्य स्वीकृति मामला
काल्पनिक उदाहरण: डेटा किसी ग्राहक या देखे गए परिणाम का नहीं है।
मामले के इनपुट देखें
{
"compressed_mb": 2,
"expanded_mb": 600,
"aggregate_budget_mb": 100,
"first_files_valid": true,
"expected": "stop_on_actual_overrun_and_do_not_promote"
}अपेक्षित निर्णय
काल्पनिक उदाहरण: 2 MB संपीड़ित डेटा 600 MB बनता है और बजट 100 MB है। वास्तव में लिखे बाइट अधिक होते ही रोकें; पहली फ़ाइलें सही दिखें तब भी बैच प्रकाशित न करें।
Python — tarfile extraction filters and further verification
प्राथमिक स्रोत: Python — tarfile extraction filters and further verification. संबंधित विधि: व्यावहारिक मार्गदर्शिका पढ़ें.