---
title: Degradovaný režim: Čo robiť, keď zdroj pravdy nefunguje
type: playbook
level: L2
status: live
revision: 1
updated: 2026-08-14
systemVersion: 4.2
authoring: machine-translated
tags: [reliability, data, playbook]
rating: 7.40
ratingAxes: useful 8 · evidence 6 · pull 7 · original 8 · form 9
ratingKind: derived
source: degraded mode rule, in production
---

# Degradovaný režim: Čo robiť, keď zdroj pravdy nefunguje

_Written 2026-08-14 · last verified 2026-08-14 · system v4.2 · live_

**TL;DR** — Keď je autoritatívny zdroj nedostupný, chybou nie je zastaviť sa — chybou je odpovedať z cache bez toho, aby to bolo priznané. Degradovaný režim robí náhradné riešenie explicitným: číta z cache, každé číslo označí jeho vekom, zápisy radí do fronty namiesto ich priameho vykonania a po obnovení zosúlaďuje stav.

## Predpoklady

Agent, ktorý je závislý od externého referenčného systému — CRM, databázy, nástroja na správu úloh. Lokálna cache alebo zrkadlo dôležitých častí týchto dát.

Ak cache neexistuje, degradovaný režim má len jednu vetvu: oznámiť, že zdroj je nedostupný, a zastaviť sa. To je platné riešenie a pre tento prípad je tento návod krátky.

## Postup

**1. Rozlišujte nedostupnosť od prázdnoty.** Vo väčšine API vyzerajú obe rovnako — chyba aj prázdny výsledok neprinesú nič použiteľné. Overujte to explicitne, pretože *žiadne záznamy* a *žiadna odpoveď* vedú k opačným akciám.

**2. Oznámte režim ešte pred obsahom.** Prvý riadok akejkoľvek degradovanej odpovede to musí uviesť:

> `⚠ source unavailable — answering from cache, last synced 2026-08-13 09:12 (29 h)`

Nie ako poznámku pod čiarou. Čitateľ si na základe tohto riadku určuje, nakoľko môže dôverovať všetkému, čo nasleduje — preto musí byť hore.

**3. Označujte hodnoty podľa veku, s prahmi, ktoré sa stupňujú.** Číslo staré 2 hodiny a číslo staré 3 týždne predstavujú odlišný druh tvrdenia. Pracovné prahy: nad **14 dní** označte upozornením, nad **30 dní** označte ako `[STALE]` a vôbec ho nepoužívajte ako základ pre nezvratné rozhodnutie.

**4. Zápisy radťe do fronty; nikdy ich neaplikujte naslepo.** Zmeny vykonané počas výpadku sa zaznamenávajú lokálne a označia sa ako čakajúce, nezapisujú sa do cache, akoby boli potvrdené. Cache, ktorá prijíma zápisy, prestáva byť cache a stáva sa druhým referenčným systémom — chybou, ktorá produkuje dve sebavedomé odpovede.

**5. Po obnovení explicitne zosúlaďte stav.** Keď sa zdroj vráti do prevádzky, prehrajte zaradené zmeny a potom **porovnajte**, namiesto toho, aby ste niečo predpokladali. Čokoľvek, čo sa počas výpadku zmenilo na oboch stranách, je konflikt — a konflikty sa musia zviditeľniť, nie potichu vyriešiť podľa časovej pečiatky.

**6. Vopred rozhodnite, na ktoré otázky sa nedá odpovedať vôbec.** Niektoré veci nesmú za žiadnych okolností pochádzať z cache — čokoľvek, čo napája nezvratnú akciu, čokoľvek, kde je zmysel otázky práve v aktuálnosti hodnoty. Zostavte ich zoznam a nechajte agenta radšej odmietnuť, než aby podal zastarané dáta s označením:

> `cannot answer from cache: current stock before a purchase commitment, payment status, anything with a legal deadline`

Odmietnutie je horší zážitok, ale lepší výsledok. Alternatívou je správne označené číslo, na ktoré sa aj tak konalo — pretože označenie je len žiadosť o opatrnosť a opatrnosť je presne to, čo pod časovým tlakom mizne.

## Overenie

Simulujte to. Zablokujte zdroj a spustite 3 bežné požiadavky. Odpovede by mali byť použiteľné, viditeľne označené, a žiadna z nich by nemala nič zapísať.

Následne otestujte proces obnovy s vyvolaným konfliktom: zmeňte ten istý záznam na oboch stranách, obnovte zdroj a overte, že sa konflikt zviditeľní, namiesto toho, aby jedna strana potichu zvíťazila.

## Riešenie problémov

**Degradované odpovede vyzerajú ako bežné odpovede.** Riadok s označením režimu chýba alebo je príliš nenápadný. Toto je celá podstata zlyhania — neoznačená odpoveď z cache je horšia než žiadna odpoveď, pretože čerpá dôveru, ktorú si nezaslúžila.

**Cache sa od zdroja výrazne odkláňa.** Frekvencia synchronizácie je príliš nízka vzhľadom na premenlivosť dát, alebo synchronizácia zlyháva potichu. Overte, že zlyhanú synchronizáciu je možné odlíšiť od obdobia pokoja.

**Zaradené zápisy sa hromadia a aplikujú hromadne bez kontroly.** Obmedzte frontu limitom. Po prekročení prahu je správnym správaním prestať prijímať zmeny a otvorene to oznámiť, namiesto toho, aby sa hromadil problém so zosúladením, ktorý si nikto neprečíta.
