Vakuózní kontrola — tichý fail za 2>/dev/null vypadá jako „vše v pořádku"

import { Aside } from ‘@astrojs/starlight/components’;

Checky a samplery psát fail-loud: pre-flight ověření přístupu, non-zero exit při chybě i prázdném výstupu, self-check počtu vzorků, timestamp per vzorek. Nikdy `2>/dev/null` na příkazu, jehož výstup je důkazem — a nikdy neinterpretovat prázdno jako nulu.

Symptom

Deploy watch několik oken po sobě hlásil „fronty spojení 0, vše čisté”. Post-mortem ukázal, že kontrolní příkaz celou dobu selhával na autentizaci (SCRAM heslo) — 2>/dev/null chybu spolkl, prázdný výstup se četl jako „nic ve frontě”. Souběžně inline nohup bash -c "…" sampler kvůli vrstvení uvozovek nikdy nezapsal vzorek a závěrečná agregace awk END{print max} nad prázdným logem vypsala uklidňující max: 0.

Root cause

Tři vrstvy téže chyby:

1. 2>/dev/null na příkazu, jehož výstup byl důkazem — auth selhání se stalo neviditelným;
2. interpretace prázdného výstupu jako „0 nálezů” (vakuózní pravda);
3. agregace (awk/grep -c) nad prázdným vstupem vrací 0, což je od skutečné nuly nerozlišitelné.

Fix

Sampler/check přepsán do souboru (žádné vrstvení uvozovek v nohup) s fail-loud kontraktem: pre-flight autentizace a neprázdnosti (vlastní exit kódy), per-vzorek fail s okamžitým non-zero, timestamp v každém řádku, závěrečný self-check „počet vzorků == plán, jinak non-zero”. Před nasazením povinná read-only zkouška: úspěšná cesta (reálné vzorky, správný počet) i chybová cesta (podvržený prázdný credentials soubor → non-zero).

Poučení

Kontrola, která neumí selhat, nekontroluje nic. Ke každému watch kritériu si polož otázku: jak poznám rozdíl mezi „nula problémů” a „check neběžel”? Pokud odpověď neexistuje, důkaz je vakuózní.