Temu Duga Kejuruteraan Data: Bagaimanakah Anda Mereka Bentuk SLO Kualiti Data untuk Paip Genting?

Gesaan dan Konteks Berkenaan

Satu set data fact_order_settlements harian memproses kira-kira 10 juta peristiwa pesanan daripada 12 sistem sumber. Bahagian kewangan memulakan penutupannya pada 07:00 UTC. Pengatur masa (orchestrator) pada masa ini hanya melaporkan sama ada tugas telah selesai, jadi larian yang bertanda hijau masih boleh menerbitkan partisi yang lewat, tertinggal satu sumber, menduplikasi versi pesanan, atau tidak sepadan dengan jumlah sumber.

Reka bentuk SLO kualiti data dan kawalan yang menguatkuasakannya. Sistem sumber menyediakan manifes kawalan yang mengandungi kiraan rekod dan jumlah kasar mengikut sumber, mata wang, dan tarikh perniagaan. Peristiwa mentah kekal boleh dimainkan semula (replayable) selama 30 hari, pembetulan mungkin tiba selama 24 jam, dan dua pengguna mempunyai keperluan berbeza: kewangan memerlukan data yang diperakui, manakala penganalisis boleh menggunakan paparan awal yang ditandakan dengan jelas.

Kupas SLI, objektif, penempatan peraturan, pintu pelepasan, pemilikan, penghalaan amaran, tindakan belanjawan ralat, pemulihan insiden, dan pengesahan pelancaran. 10 juta peristiwa, 12 sumber, tarikh akhir, pengekalan, dan sasaran yang dicadangkan ialah andaian temu duga. Sasaran pengeluaran memerlukan persetujuan pengguna dan ukuran sejarah. Ini ialah soalan data kerana terasnya ialah kontrak kualiti yang boleh dikendalikan untuk produk data. Kerja bermula sebelum sesuatu insiden dan berterusan melalui perakuan dan semakan dasar.

Perkara yang Dinilai oleh Penemu Duga

Pertama, bolehkah calon menterjemahkan "data berkualiti tinggi" kepada hasil pengguna yang boleh diperhatikan? Keterkinian (freshness), kelengkapan, kesahan, ketekalan, ketepatan, dan keunikan menggambarkan mod kegagalan yang berbeza. Satu skor kualiti gabungan boleh menyembunyikan duplikasi sifar toleransi di sebalik beberapa semakan yang lulus.

Kedua, bolehkah calon memilih penyebut yang boleh dipercayai? Membandingkan kiraan baris hari ini dengan semalam menangkap anomali besar tetapi tidak dapat membuktikan kelengkapan. Manifes sumber, julat ofset log perubahan, atau lejar yang dikawal secara bebas membekalkan bukti yang lebih kukuh tentang apa yang sepatutnya tiba.

Ketiga, bolehkah calon memisahkan spesifikasi SLI daripada pelaksanaannya? "Kewangan menerima data yang diperakui sebelum penutupan" menyatakan hasilnya. Mengukur masa selesai penjadual ialah pelaksanaan yang terlepas kegagalan penerbitan, katalog, kebenaran, dan bacaan hiliran. Jawapan yang kukuh mengukur berhampiran sempadan pengguna dan mendokumentasikan titik buta.

Keempat, adakah setiap kegagalan mencetuskan tindakan yang telah ditetapkan terlebih dahulu? Invarian tegar memerlukan sekatan penerbitan atau kuarantin. Amaran memerlukan pemilik dan laluan semakan. Suatu amaran kecemasan (page) sepatutnya mewakili impak pengguna yang mendesak. "Beri amaran pada setiap peraturan yang gagal" memindahkan kerja reka bentuk kepada jurutera bertugas (on-call) dan mencipta hingar.

Akhir sekali, bolehkah calon menjadikan pemilikan boleh dilaksanakan? Pengeluar, jurutera platform, pemilik set data, dan bahagian kewangan mungkin berkongsi tanggungjawab, tetapi setiap peraturan, insiden, dan kelulusan masih memerlukan seorang pemilik yang bertanggungjawab secara langsung dan laluan eskalasi.

Soalan Penjelasan Sebelum Menjawab

Apakah maksud "sedia" kepada pihak kewangan? Jika penutupan memerlukan data yang diperakui pada 07:00, ukur masa apabila pihak kewangan boleh membuat kueri versi yang diperakui, bukan apabila transformasi terakhir selesai. Jika pratonton berguna, terbitkannya di bawah status dan kontrak yang berasingan.
Apakah bukti bebas yang mentakrifkan kelengkapan dan ketepatan? Manifes sumber menyokong penyelarasan kiraan dan jumlah. Tanpanya, gunakan ofset, syot kilat (snapshot) sumber, atau jumlah lejar dan labelkan semakan volum statistik sebagai pengesanan anomali dan bukannya bukti.
Apakah kunci perniagaan dan model kemas kini? Keunikan mungkin terpakai pada (source_id, order_id, version), manakala keadaan perniagaan terkini mungkin memerlukan satu versi pemenang bagi setiap pesanan. Pembetulan yang lewat mengubah kedua-dua semakan dan kitaran hayat perakuan.
Kegagalan manakah yang boleh diturunkan tarafnya (degrade) dan manakah yang mesti menyekat? Kunci yang hilang, versi pendua, atau ketidakpadanan lejar boleh merosakkan penutupan dan harus menyekat perakuan. Atribut pemasaran pilihan boleh dikuarantin manakala medan kewangan yang diperakui diteruskan.
Berapa banyakkah peristiwa kualiti wujud dalam tetingkap SLO? Paip harian mempunyai terlalu sedikit pemerhatian untuk objektif bulanan 99.9% yang bermakna. Sasaran 60 hari perniagaan bergolek seperti 59 perakuan tepat pada masanya mempunyai granulariti yang boleh difahami.
Siapakah yang boleh mengetepikan (waive) pintu yang gagal? Pengecualian memerlukan pelulus, pengguna yang terjejas, masa tamat tempoh, sebab, dan rekod audit. Jurutera bertugas tidak seharusnya mentakrifkan semula kontrak kewangan secara senyap semasa insiden.
Apakah pemulihan yang boleh dilakukan? Main semula data mentah selama 30 hari menyokong pembinaan semula secara deterministik. Jika sejarah sumber boleh berubah atau tidak lengkap, keperluan pemulihan dan bukti mesti berubah.

Kerangka Jawapan 30-Saat

"Saya akan bermula daripada keputusan kewangan, kemudian mentakrifkan SLI berasingan untuk keterkinian yang diperakui, penyelarasan manifes, kelengkapan kunci perniagaan, kesahan, dan keunikan. Saya akan mengukur jadual yang diperakui pada sempadan penggunanya dan memastikan invarian kewangan sifar toleransi dipisahkan daripada ketepatan masa yang dibelanjakan.

Semakan skema dijalankan sebelum penggunaan, semakan baris dijalankan semasa pengingesan, semakan perniagaan dijalankan selepas transformasi, dan penyelarasan hujung ke hujung mengawal pintu perakuan. Pihak kewangan membaca hanya paparan diperakui yang diberi versi; penganalisis boleh memilih paparan awal yang berlabel. Setiap peraturan mempunyai tindakan, pemilik, dan buku panduan (runbook). Saya akan menguji kontrak secara kenari (canary) pada satu sumber, membandingkan pengesanan dengan insiden yang diketahui, melaras penggera palsu, melatih main semula, dan membiarkan dasar belanjawan ralat yang dipersetujui mengubah keutamaan kejuruteraan apabila objektif keterkinian telah habis."

Perbincangan Mendalam Langkah demi Langkah

Langkah 1: Takrifkan Produk Data dan Hasil Pengguna

Tulis satu kontrak untuk set data penyelesaian yang diperakui, bukan katalog bagi setiap semakan yang mungkin. Namakan versi set data, tarikh perniagaan, pengguna, pemilik, tarikh akhir perakuan, dasar pembetulan, dan bukti yang disimpan untuk audit. Dua mod pengguna mestilah jelas:

preliminary: tersedia awal, mungkin mengandungi sumber lewat yang diisytiharkan, tidak pernah digunakan untuk penutupan kewangan;
certified: tidak boleh diubah untuk versi yang dinyatakan, semua pintu tegar lulus, dengan manifes dan ID keputusan kualiti;
superseded: digantikan oleh versi pembetulan sementara bukti terdahulu kekal boleh ditemui.

Model keadaan ini menghalang status orkestrasi hijau daripada menjadi jaminan perniagaan yang tidak disengajakan. Pihak kewangan hanya membuat kueri certified; pengguna penerokaan boleh menukar keterkinian untuk kepastian tanpa melemahkan kontrak kewangan.

Langkah 2: Tulis Setiap SLI sebagai Peristiwa Baik berbanding Peristiwa Layak

Gunakan hasil yang kelihatan kepada pengguna dan unit yang ditakrifkan. Untuk senario ini, SLI keterkinian permulaan ialah:

text

freshness_sli =
  business-day partitions certified and queryable by 06:30 UTC
  / eligible business-day partitions

starting_slo = at least 59 good partitions in a rolling 60-business-day window

Ambang ini meninggalkan 30 minit sebelum penutupan kewangan dan satu perakuan lewat dalam tetingkap contoh. Kedua-dua nilai ialah andaian untuk dirundingkan dengan pihak kewangan dan disahkan terhadap sejarah. Ukur daripada kueri pengguna atau keadaan katalog yang mengesahkan versi boleh dibaca; cap masa penyiapan penjadual hanyalah isyarat diagnostik.

Berikan dimensi lain kriteria kejayaan mereka sendiri:

Kelengkapan: setiap manifes sumber yang dijangka ada; kiraan rekod dan liputan kunci kritikal diselaraskan.
Keunikan: sifar tupel (source_id, order_id, version) pendua dalam partisi yang diperakui.
Kesahan: kunci yang diperlukan wujud dan medan yang dikawal kontrak menggunakan jenis, domain, dan julat yang dibenarkan.
Ketekalan: kiraan dan jumlah diselaraskan mengikut sumber, mata wang, dan tarikh perniagaan sebelum pengagregatan.
Ketepatan masa pembetulan: pembetulan yang diterima menjadi versi baharu yang diperakui dalam tetingkap yang dipersetujui.

Ketepatan lebih sukar untuk disimpulkan daripada bentuk dalaman. Jumlah yang sah dan unik masih boleh menjadi salah. Jumlah yang dikawal sumber, penyelarasan lejar, semakan perniagaan bersampel, dan semakan hasil hiliran menyediakan bukti yang lebih kukuh daripada peraturan format.

Langkah 3: Pilih Invarian Tegar, SLO, dan Diagnostik Secara Sengaja

Tiga kelas memastikan tindakan boleh difahami:

Invarian tegar: sebarang pelanggaran menyekat perakuan, seperti kunci perniagaan yang hilang, versi pendua, atau jumlah kewangan yang tidak diselaraskan.
Objektif yang dibelanjakan: kegagalan sekali-sekala diterima dalam dasar bertulis, seperti tarikh akhir perakuan atau pemulihan pembetulan.
Diagnostik: isyarat yang membantu penyiasatan tetapi tidak mentakrifkan kejayaan pengguna, seperti perubahan volum 20% hari ke hari.

Jangan tukarkan keperluan ketepatan tegar kepada "baris buruk yang dibenarkan" semata-mata untuk memuatkan formula belanjawan ralat. Satu pesanan bernilai tinggi yang berulang boleh membawa kesan lebih besar daripada ribuan nilai nol pilihan yang tidak berbahaya. Pastikan setiap objektif dan akibatnya berasingan; skor papan pemuka keseluruhan mungkin meringkaskan trend tetapi tidak boleh mengatasi peraturan yang menyekat.

Langkah 4: Letakkan Semakan pada Sempadan Berguna Terawal

Jalankan keserasian skema dan contoh kontrak dalam CI pengeluar dan transformasi. Semasa pengingesan, sahkan kebolehuraian, medan sampul yang diperlukan, identiti sumber, kesinambungan ofset, dan keidempotenan; kuarantin rekod buruk yang boleh dikenal pasti dengan kod sebab. Selepas transformasi, uji kunci perniagaan, hubungan rujukan, pemilihan versi, peraturan mata wang, dan hirisan peringkat sumber. Semasa penerbitan, lakukan penyelarasan manifes dan lejar serta sahkan bahawa versi tepat yang diperakui boleh dikueri.

Peraturan yang sama tidak perlu dijalankan di mana-mana. Ujian unit bukan nol dengan lima lekapan mengesahkan laluan kod tetapi menyatakan sedikit perkara tentang sumber pengeluaran. Agregat pengeluaran boleh mengesan kegagalan tetapi mungkin tiba terlalu lewat untuk melindungi pengguna perantaraan. Letakkan semakan pencegahan kos rendah sebelum perubahan, semakan operasi di tempat data masuk, dan semakan hujung ke hujung di tempat janji itu digunakan.

Berikut ialah pseudo-YAML neutral alat yang bersifat ilustrasi dan bukannya skema khusus produk:

yaml

dataset: finance.fact_order_settlements
owner: finance-data
consumer: daily-close
certification_deadline_utc: "06:30"
rules:
  - name: required_business_key
    dimension: completeness
    scope: row
    pass_ratio: 1.0
    action: block_and_quarantine
  - name: unique_order_version
    dimension: uniqueness
    scope: [source_id, order_id, version]
    pass_ratio: 1.0
    action: block_certification
  - name: source_manifest_reconciliation
    dimension: consistency
    scope: [source_id, currency, business_date]
    pass_ratio: 1.0
    action: block_certification_and_page_owner

Langkah 5: Gunakan Penyelarasan Bebas dan Hiris Hasilnya

Cantumkan (join) agregat yang diterima kepada semua baris manifes yang dijangkakan, termasuk sumber yang tidak menghantar apa-apa. Sambungan kiri (left join) daripada data yang diterima sahaja menjadikan sumber yang tiada tidak dapat dilihat. Bandingkan kiraan dan jumlah dalam mata wang asalnya sebelum sebarang penukaran yang menghilangkan data (lossy). Rekodkan ID manifes, tanda aras (watermark) sumber, versi transformasi, syot kilat jadual, dan keputusan peraturan bersama-sama.

Hiris kegagalan mengikut sumber, rantau, mata wang, jenis peristiwa, dan peringkat paip. Kadar kelulusan global 99.99% boleh menyembunyikan gangguan menyeluruh bagi sumber bervolum rendah. Sebaliknya, satu sumber lewat yang diketahui tidak sepatutnya menghasilkan amaran bertugas yang serupa daripada pengingesan, transformasi, dan penerbitan. Halakan sempadan rosak pertama yang boleh diambil tindakan dan sekat amaran terbitan sambil mengekalkan diagnostik.

Jalur sejarah berguna untuk pengesanan anomali volum, tetapi kemusiman, promosi, dan sumber yang baru dilancarkan boleh mengubahnya secara sah. Anggap anomali sebagai bukti untuk disiasat sehingga jumlah kawalan bebas mengesahkan kehilangan.

Langkah 6: Jadikan Pintu, Pengecualian, dan Pemilikan Boleh Dilaksanakan

Setiap peraturan harus mengisytiharkan keterukan, tindakan, pemilik langsung, pemilik sandaran, sasaran eskalasi, buku panduan, dan masa pengakuan maksimum. Pembahagian praktikal ialah:

kegagalan skema atau manifes sumber: pengeluar memiliki pembetulan; pemilik pengingesan membendung impak;
kegagalan pengangkutan, penyahduplikasian, atau orkestrasi: platform data memiliki pemulihan;
kegagalan transformasi semantik atau penyelarasan: pemilik set data memiliki diagnosis dan pembinaan semula;
pertikaian definisi perniagaan: pengurus data (data steward) kewangan memutuskan kontrak, dengan semakan perubahan yang boleh diaudit.

Penepian mencipta versi baharu yang diturunkan taraf secara eksplisit atau mengekalkan set data sebagai awal. Ia merekodkan siapa yang meluluskannya, mengapa perniagaan menerima risiko tersebut, pengguna mana yang terjejas, dan bila pengecualian itu tamat tempoh. Jangan sekali-kali menulis ganti keputusan yang gagal atau mengarahkan alias yang diperakui secara senyap ke partisi yang tidak disahkan.

Langkah 7: Takrifkan Dasar Belanjawan Ralat yang Mengubah Keputusan

Untuk contoh SLO keterkinian, satu partisi lewat ialah belanjawan bagi 60 hari perniagaan bergolek. Jejak penggunaan dan kadar pembakaran (burn rate). Satu hari lewat menghabiskan keseluruhan belanjawan; partisi kewangan yang diperakui yang tidak betul mencetuskan dasar insiden tanpa mengira baki belanjawan keterkinian.

Persetujui tindakan sebelum kegagalan berlaku. Apabila ramalan kadar pembakaran menunjukkan bahawa satu-satunya kegagalan yang dibenarkan berisiko berlaku, semak punca utama dan sahkan kapasiti pemulihan. Apabila habis, jedakan perubahan paip yang berisiko, utamakan kerja kebolehpercayaan, dan perlukan kriteria keluar yang diluluskan oleh pemilik. Dasar ini menjadikan SLO alat membuat keputusan. Papan pemuka tanpa akibat hanyalah pelaporan.

Semak semula SLI apabila pengesanan tidak berkorelasi dengan insiden pengguna atau amaran mempunyai kepersisan yang rendah. Alihkan ukuran lebih dekat kepada kewangan, tambah hirisan yang hilang, atau longgarkan diagnostik yang bising. Jangan melonggarkan invarian tegar untuk mendiamkan hingar operasi; betulkan pelaksanaan atau penghalaan.

Langkah 8: Lakukan Kenari, Latih Pemulihan, dan Buktikan Liputan

Nilai peraturan secara bayangan (shadow-evaluate) tanpa menyekat pada satu sumber dan tetingkap sejarah 14 hingga 30 hari yang representatif. Masukkan kegagalan terkawal: tinggalkan sumber, duplikasi versi pesanan, pecahkan skema, lewatkan penerbitan, dan ubah jumlah sambil mengekalkan kiraan baris. Sahkan peraturan, pemilik, dan buku panduan yang dijangka diaktifkan sekali.

Kemudian sekat satu sumber berisiko rendah, kembangkan mengikut kekritisan sumber, dan akhirnya lindungi perakuan. Kriteria penerimaan merangkumi liputan pengesanan untuk kegagalan yang dimasukkan, tiada partisi diperakui yang salah, kadar amaran palsu yang terhad, bukti yang boleh dibaca oleh pengguna, main semula deterministik daripada peristiwa mentah, dan pemulihan sebelum tarikh akhir kewangan. Ukur kos peraturan dan imbas hanya partisi yang diubah jika ketepatan membenarkan; sistem kualiti yang secara rutin terlepas tarikh akhirnya sendiri menjejaskan paip tersebut.

Selepas pelancaran, semak insiden yang ditemui pengguna secara manual dan amaran yang tidak menghasilkan sebarang impak. Kedua-dua set tersebut mendedahkan liputan yang hilang dan kepersisan yang rendah. Versikan perubahan kontrak dengan model data, perlukan semakan pengeluar dan pengguna, dan kekalkan set peraturan tepat yang digunakan untuk setiap perakuan.

Contoh Jawapan Berkualiti Tinggi

"Saya akan mentakrifkan perkhidmatan dari sudut pandangan pihak kewangan: partisi penyelesaian tertentu diperakui, boleh dikueri, diselaraskan, dan tersedia sebelum penutupan. DAG yang selesai ialah diagnostik, jadi saya akan menyiasat versi yang diterbitkan dan mengekalkan manifes, syot kilat, versi kod, dan keputusan kualitinya.

Untuk keterkinian, saya mungkin mencadangkan 59 partisi yang diperakui menjelang 06:30 dalam tetingkap 60 hari perniagaan bergolek, kemudian menentukurkannya dengan pihak kewangan dan prestasi sejarah. Ketepatan mempunyai pintu tegar yang berasingan. Setiap manifes sumber mesti tiba; kiraan dan jumlah mata wang asal mesti diselaraskan mengikut sumber dan tarikh perniagaan; kunci perniagaan yang diperlukan mestilah lengkap; dan (source_id, order_id, version) mestilah unik. Saya tidak akan sekali-kali mempuratakan perkara ini menjadi skor yang membolehkan satu kegagalan yang menyekat lulus.

Semakan dijalankan pada beberapa sempadan. CI menangkap kes skema dan transformasi yang tidak serasi. Pengingesan menyemak sampul, ofset, dan keidempotenan serta mengkuarantin kegagalan yang boleh dikenal pasti. Transformasi menyemak peraturan semantik dan rujukan. Penerbitan melakukan penyelarasan bebas dan mengesahkan versi tepat boleh dibaca. Pihak kewangan menerima hanya alias yang diperakui; penganalisis boleh menggunakan paparan awal yang membawa status sumber dan kualiti.

Setiap peraturan yang gagal dipetakan kepada tindakan dan seorang pemilik. Pengeluar mengendalikan kontrak sumber yang rosak, pasukan platform mengendalikan pengangkutan, dan pemilik set data mengendalikan transformasi dan perakuan. Penepian adalah terhad masa, kelihatan kepada pengguna, dan diluluskan oleh pengurus data kewangan. Partisi yang diperakui yang tidak betul ialah satu insiden walaupun belanjawan keterkinian masih ada.

Saya akan membayangi peraturan pada partisi sejarah, menyuntik kegagalan sumber yang hilang, kunci pendua, skema, kelewatan, dan kiraan-sama-jumlah-salah, kemudian menyekat satu sumber. Saya akan mengembangkannya hanya apabila pengesanan, penghalaan, main semula, kadar amaran palsu, dan masa jalan peraturan memenuhi kriteria penerimaan. Jika satu hari lewat yang dibenarkan telah habis, dasar yang dipersetujui memindahkan kapasiti daripada kerja ciri kepada kebolehpercayaan sehingga kriteria keluar dipenuhi."

Kesilapan Biasa

Hanya memantau kejayaan tugas → Tugas yang selesai boleh menerbitkan data yang tidak lengkap atau tidak boleh dibaca → Ukur objek yang diperakui pada sempadan pengguna.
Menggunakan kiraan baris semalam sebagai bukti kelengkapan → Perubahan permintaan yang sah dan kehilangan sumber secara senyap kelihatan serupa → Selaraskan terhadap manifes, ofset, syot kilat, atau jumlah terkawal yang lain.
Menggabungkan semua semakan ke dalam satu skor → Banyak peraturan pilihan yang lulus boleh menutup satu invarian kewangan → Berikan setiap dimensi kritikal ambang dan tindakannya sendiri.
Menetapkan 99.9% pada satu peristiwa harian sebulan → Penyebut tidak dapat menyatakan kepersisan tersebut → Pilih tetingkap dan unit dengan granulariti yang bermakna.
Memberi setiap baris buruk belanjawan ralat → Kiraan baris mengabaikan nilai perniagaan dan integriti tegar → Kekalkan invarian sifar toleransi di luar ketepatan masa yang dibelanjakan.
Menghantar amaran pada setiap peraturan yang gagal → Satu kerosakan sumber mencipta lata amaran yang tidak boleh diambil tindakan → Hantar amaran pada sempadan milik pertama dan sekat terbitan hiliran.
Membiarkan jurutera bertugas mengetepikan pintu secara senyap → Pengguna tidak dapat menilai risiko dan bukti audit hilang → Gunakan pengecualian yang diluluskan, mempunyai tarikh luput, dan kelihatan kepada pengguna.
Hanya menguji laluan bahagia (happy path) → Pasukan mendapati bahawa pemulihan adalah tidak deterministik semasa penutupan → Suntik kegagalan yang representatif dan latih main semula sebelum penguatkuasaan.
Menambah imbasan jadual penuh yang mahal pada setiap larian → Semakan kualiti menghabiskan margin keterkinian yang dilindunginya → Gunakan semakan tokokan (incremental) ditambah penyelarasan penuh berkala jika selamat.

Soalan Susulan dan Maklum Balas

Susulan 1: Bagaimana jika sumber tidak dapat menyediakan manifes?

Nilaikan pengganti mengikut kebebasan. Syot kilat sumber, julat jujukan log pangkalan data, ofset broker, inventori fail dengan checksum, dan lejar yang dihasilkan secara berasingan adalah lebih kukuh daripada kiraan baris jadual sasaran itu sendiri. Gunakan jalur sejarah untuk mengesan anomali, dedahkan bahawa ia tidak dapat membuktikan kelengkapan, dan jadikan penghantaran manifes atau jumlah kawalan sebahagian daripada kontrak pengeluar untuk sumber kritikal.

Susulan 2: Bagaimana jika pihak kewangan menuntut sifar partisi lewat selama-lamanya?

Sasaran 100% tersirat tidak meninggalkan mekanisme untuk mengutamakan kerja kebolehpercayaan dan mungkin tidak dapat dipertahankan secara operasi. Kuantifikasikan redundansi, masa main semula, kebergantungan sumber, dan kos yang diperlukan untuk mendekati permintaan tersebut. Kekalkan ketepatan kewangan sebagai pintu tegar, cadangkan sasaran keterkinian yang boleh diukur ditambah sasaran aspirasi yang lebih ketat, dan dapatkan persetujuan eksplisit perniagaan, kejuruteraan, dan operasi mengenai dasar tindak balas.

Susulan 3: Bagaimanakah anda mengendalikan pembetulan selepas partisi diperakui?

Cipta versi perakuan baharu yang tidak boleh diubah, pautkannya kepada versi terdahulu dan manifes pembetulan, jalankan semula semua peraturan penyelarasan yang terjejas, dan alihkan alias yang diperakui secara atomik hanya selepas kelulusan. Kekalkan bukti lama untuk audit. Ukur masa pemulihan pembetulan secara berasingan kerana SLI keterkinian asal tidak dapat menerangkan seberapa cepat ralat yang diketahui dibaiki.

Susulan 4: Bagaimanakah anda mengelakkan kelesuan amaran (alert fatigue) merentas ratusan set data?

Susun set data mengikut tahap impak pengguna, perlukan pemilik langsung sebelum menghantar amaran, dan hantar amaran hanya pada ancaman SLO atau kegagalan pintu tegar yang boleh diambil tindakan. Kumpulkan kegagalan peraturan yang berkaitan di bawah kebergantungan rosak terawal, halakan amaran ke baris gilir semakan, dan bandingkan amaran dengan insiden pengguna sebenar secara berkala. Hentikan atau reka bentuk semula peraturan yang mempunyai kepersisan rendah secara berterusan.

Susulan 5: Apakah yang berubah untuk paip penstriman (streaming)?

Gantikan satu peluang perakuan harian dengan tetingkap masa peristiwa atau minit pengguna. Takrifkan keterkinian daripada masa peristiwa kepada keadaan yang boleh dikueri, kelengkapan daripada tanda aras tertutup atau ofset sumber, dan tingkah laku pembetulan untuk peristiwa lewat. Gunakan amaran kadar pembakaran ke atas tetingkap pendek dan panjang, sambil mengekalkan invarian tegar bagi setiap rekod atau setiap kunci yang mesti mengkuarantin data dengan serta-merta.

Susulan 6: Bagaimanakah anda menilai alat kualiti data?

Mulakan dengan kesesuaian kontrak dan bukannya bilangan ciri. Sahkan peraturan baris dan agregat, keunikan kunci komposit, pelaksanaan tokokan, bukti rekod yang gagal, keputusan yang diberi versi, pintu orkestrasi, metadata pemilikan, API, penghalaan amaran, dan kos pada skala pengeluaran. Jalankan suite kegagalan yang disuntik melalui setiap calon; papan pemuka yang kemas tidak dapat mengimbangi ketiadaan penyelarasan hujung ke hujung atau pintu pelepasan yang tidak boleh dikuatkuasakan.