Provoz systému — logování, monitoring a alerting, distribuovaný tracing, zálohování, plán obnovy a připravenost na zátěž. Určuje, jak rychle tým odhalí a vyřeší produkční problém.

📊 Skóre

Stav	Počet
🟢 OK	4
🟠 Částečně	1
🔴 Špatně	2

Celkově: observabilita a provoz mají solidní základ — distribuovaný tracing, monitoring dostupnosti, alerting nákladů i automatické zálohy databáze fungují. Zbývají dvě mezery: jednotné strukturované logování a chybějící recovery plán + zátěžové testy.

🔍 Co jsme hodnotili

#	Položka	Stav
33	Distribuovaný tracing	🟢
31	Monitoring a alerting (dostupnost/infra)	🟢
32	Alerting nákladů infrastruktury	🟢
34	Automatické zálohování	🟢
30	Strukturované logy	🟠
35	Definovaný a zdokumentovaný recovery plán	🔴
36	Očekávaná zátěž + zátěžové testy	🔴

📌 Klíčové nálezy

🟢 Distribuovaný tracing napříč službami

Existuje sdílený balík @tfpl/opentelemetry implementovaný ve všech 9 backendových službách (propagátory W3C/Baggage/Jaeger/B3, instrumentace HTTP/NestJS/MySQL). Jaeger je nasazen jako součást infrastruktury. Požadavek lze sledovat napříč mikroslužbami — to je u microservices klíčové a často chybějící.

🟢 Monitoring dostupnosti a infrastruktury

14 GCP uptime checků ze tří regionů s alert policy do Slacku (#tf-platform-status), infra metriky přes GCP + Prometheus/Lens, replikace metrik do BigQuery přes K8s CronJob. Dostupnost a infrastruktura jsou pokryté dobře; slabší je aplikační APM (metriky na úrovni aplikace).

🟢 Alerting nákladů infrastruktury

Náklady jsou hlídané přes GCP budget alerts s notifikací na e-mail. Nastavení je v GCP konzoli (mimo repozitář), proto ho audit ze zdrojového kódu nezachytil — potvrzeno týmem. Překročení rozpočtu tedy tým zachytí.

🟢 Automatické zálohování databáze

Hlavní databáze má v GCP nastavené denní automatické zálohy. Kromě toho existuje verzovaná záloha dat jedné podpůrné služby (sidecar skript zálohuje 2× denně). Zálohování je tedy pokryté.

🟠 Nejednotné logování

OpenTelemetry pokrývá traces, ale logování není jednotně strukturované do JSON — winston má jen jedna služba, ostatní spoléhají na NestJS Logger → stdout → GCP Cloud Logging. Interní evidence dluhu navíc hlásí console.log/error obcházející Logger v produkci.

🔴 Chybí recovery plán a zátěžové testy

• Recovery plán: přestože zálohy existují, není zdokumentovaný postup obnovy (DR plán — kdo, co, v jakém pořadí, jak dlouho). Zálohy bez ověřeného recovery postupu dávají jen částečnou jistotu.
• Zátěž: žádný nástroj pro zátěžové testy (k6, artillery, jmeter) a žádná definice očekávané zátěže / SLO.

✅ Doporučení

Priorita	Doporučení
Vysoká	Sepsat a otestovat recovery (DR) plán — využít existující denní zálohy DB.
Vysoká	Sjednotit strukturované JSON logování napříč službami a odstranit console.log z produkce.
Střední	Definovat očekávanou zátěž / SLO a zavést zátěžové testy klíčových toků.