DataOps järjestää tietojen toimituksen ja seurannan. Onnistunut suoritus ei todista sisällön oikeellisuutta tai täydellistä jäljitettävyyttä.
Hallitse uusinnat
Määrittele uusinnan tavoite ja estä kaksoiskappaleet tai osatulokset. Säilytä syötteet, aika, säännöt ja versiot toistoa varten; muuttuneet syötteet voivat tuottaa eri tuloksen. Määrittele hallittu palautuminen.
Erota versiot ja tietolinja
Versionhallinta kuvaa tiloja ja muutoksia; tietolinja yhdistää lähteet, muunnokset ja tulokset. Arvioi täydellisyys, yksikäsitteisyys, johdonmukaisuus, ajantasaisuus, kelvollisuus ja oikeellisuus käyttötarkoituksen mukaan. Kelvollinen muoto voi sisältää virheen, ja oikea tieto olla liian vanhaa.
| Kohta | Dokumentoitava tarkistus |
|---|---|
| Suoritus | Tekninen tila ja tavoiteltu tulos |
| Laatu | Käyttötarkoitukseen sopivat tarkistukset |
| Alkuperä | Lähteet, muunnokset ja tulos yhdistetty |
Lähteet ja tarkistus
Aikavyöhykkeet ja myöhäiset tapahtumat
Raportin ajanjakso riippuu tapahtuma-ajasta ja sulkemissäännöstä.
- Kirjaa tapahtuma-aika, vastaanottoaika ja liiketoiminnan aikavyöhyke erikseen. Kuvitteellisessa esimerkissä 23:30 UTC on seuraavan päivän 01:30 kiinteällä UTC+02:00-siirtymällä. PostgreSQLin aikavyöhykkeen sisältävä aikaleima ei säilytä alkuperäistä vyöhykkeen nimeä.
- Käytä mukaan kuuluvaa alkua ja pois jätettävää loppua. Muodosta rajat liiketoiminnan vyöhykkeessä ennen UTC-muunnosta. Testaa kesäaikaan siirtyminen, kuukauden vaihde ja päivämäärä ilman kellonaikaa; paikallista päivää ei voi aina korvata 24 tunnilla.
- Määritä hyväksyttävä viive ja raportin sulkemisaika. Toista sama tunniste erottaaksesi uuden tapahtuman kaksoiskappaleesta. Säilytä julkaistu versio ja kirjaa korjauksen vaikutus; vesileima on arvio saapumisesta eikä lupaus kaikkien tietojen saapumisesta.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"event_time": "2026-10-08T23:30:00Z",
"report_zone": "UTC+02:00",
"local_time": "2026-10-09T01:30:00+02:00"
}Odotettu päätös
Tapahtuma kuuluu annetussa vyöhykkeessä 9. lokakuuta. Säilytä myös UTC-hetki.
Tarkistusmenettely
- Määritä raportin vyöhyke ja viitehetki.
- Toista tapahtuma lähellä keskiyötä.
- Säilytä UTC, paikallispäivä ja katkaisusääntö. Sisällytä kellonsiirron monitulkintainen paikallisaika; säilytä UTC-siirtymä ja aikavyöhyke sen sijaan, että päättelisit hetken.
Voiko vastaanottopäivää käyttää tapahtumapäivänä?
Vain jos raportin määritelmä sitä edellyttää. Säilytä molemmat ajat ja selitä myöhäisten tapahtumien käsittely.
Ensisijainen lähde: PostgreSQL — Date/time types. Aiheeseen liittyvä menetelmä: lue käytännön opas.
Keruun katkos: lokien ja puuttuvien tapahtumien täsmäytys
Erota tuotetut, vastaanotetut ja käytettävät tapahtumat; hiljaisuus ei osoita häiriöiden puuttumista.
- Kartoita sovellus, kerääjä ja tallennus vastuineen. Valmistele rajallinen kuvitteellinen tapahtumajono vakailla tunnisteilla ilman salaisuuksia tai asiakastietoja. Säilytä tapahtuma- ja havaintoaika: keruun viive ei automaattisesti tarkoita menetystä.
- Katkaise testissä kohde ja palauta se. Tarkkaile jonon täyttymistä, yrityksiä, hylkäyksiä ja käynnistystä. Pysyvä jono voi vähentää menetyksiä, mutta on rajallinen ja riippuu tallennuksesta; määritä täyden jonon toiminta. Tarkista ettei keruu hiljaisesti estä palvelua.
- Täsmäytä vertailujoukko luettaviin tapahtumiin samalla havaintokatkaisulla. Laske toistot, viiveet ja puutteet erikseen; verkkokuittaus ei todista lopullista käytettävyyttä. Ilman luotettavaa vertailua kattavuus on tuntematon, ei nolla menetystä tai häiriötä.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"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"
}Odotettu päätös
Kuvitteellinen esimerkki: E1, E2 ja E3 odotetaan, mutta E1, E1 ja E3 saapuvat. Kolme riviä ei todista täydellisyyttä: E1 toistuu ja E2 puuttuu havaintokatkaisulla.
Ensisijainen lähde: OpenTelemetry — Collector resiliency. Aiheeseen liittyvä menetelmä: lue käytännön opas.
ZIP ja TAR: pura tiedostot polku- ja resurssirajojen sisällä
Tarkista polut, linkit ja puretut tiedot ennen tiedostojen julkaisua.
- Pura uuteen ei-julkiseen hakemistoon vähimmäisoikeuksin. Hylkää absoluuttiset polut, hakemistosta nousut, tarpeettomat linkit ja erikoistiedostot. Tarkista ratkaistut kohteet ja ristiriidat kohdejärjestelmän sääntöjen mukaan, myös kirjainkoko. Tekstietuliite ei yksin todista rajausta.
- Aseta tiedosto- ja kokonaisrajat kirjoitetuille tavuille, merkinnöille, syvyydelle, ajalle ja prosessin resursseille. Pakattu tai ilmoitettu koko ei riitä. Hylkää tarpeettomat sisäkkäiset arkistot; muuten käytä yhteistä kokonaisbudjettia. Päivitä kirjasto ja suodattimet.
- Testaa ../, absoluuttinen polku, linkki, kaksoiskappale ja budjettiylitys. Keskeytys jättää erän julkaisematta eikä korvaa vanhoja tiedostoja. Tarkista tyypit ja sisältö ennen julkaisua; varmista kohde siivouksen yhteydessä.
Toistettava hyväksyntätapaus
Kuvitteellinen esimerkki: tiedot eivät kuvaa asiakasta tai havaittua tulosta.
Näytä tapauksen tiedot
{
"compressed_mb": 2,
"expanded_mb": 600,
"aggregate_budget_mb": 100,
"first_files_valid": true,
"expected": "stop_on_actual_overrun_and_do_not_promote"
}Odotettu päätös
Kuvitteellinen esimerkki: 2 MB pakattuna tuottaa 600 MB, kun budjetti on 100 MB. Pysäytä kirjoitettujen tavujen ylittäessä rajan, älä julkaise erää vaikka alkutiedostot näyttävät kelvollisilta.
Python — tarfile extraction filters and further verification
Ensisijainen lähde: Python — tarfile extraction filters and further verification. Aiheeseen liittyvä menetelmä: lue käytännön opas.