Cena bez původu a času není úplná informace
Aplikace může zobrazit číslo s několika desetinnými místy, ale uživatel z něj nepozná, zda je aktuální, zpožděné nebo opravené. Každý datový proud má poskytovatele, instrument, typ hodnoty, čas události a čas přijetí. Tyto časy se mohou výrazně lišit. U produktu s obchodním rozhodnutím musí být jasné, která hodnota se používá pro zobrazení a která pro skutečný pokyn. Když je feed nedostupný, stará cena nesmí vypadat jako čerstvá. Přesnost formátu není totéž co kvalita obsahu. U každého zdroje nejdřív popište jeho význam a smluvní podmínky.
Zaznamenejte také, zda jde o nabídku, poptávku, poslední obchod, indikativní hodnotu nebo agregaci. Dvě čísla pro stejný instrument se nemusí rovnat, protože představují jinou událost. Uživatelé i vývojáři potřebují shodnou terminologii. Zdroje mohou mít odlišné obchodní hodiny, měny, časová pásma a pravidla pro opravy. Před propojením více feedů vytvořte datovou smlouvu: identifikátor instrumentu, typ zprávy, čas, měna, velikost, kvalita a přípustná prodleva. Pokud chybí obchodní význam pole, technické sjednocení názvů může vytvořit zavádějící data.
Proud potřebuje pořadí a schopnost obnovy
Při živém přenosu mohou zprávy vypadnout, dorazit opakovaně nebo ve špatném pořadí. FIX Trading Community popisuje snapshoty a inkrementální aktualizace pro tržní data, včetně pravidel pro udržování knihy objednávek. Konkrétní feed se však řídí vlastní specifikací poskytovatele. Ověřte, zda zpráva nese pořadové číslo, jak se zjistí mezera a zda lze vyžádat nový snapshot. Bez toho může aplikace dál kreslit zdánlivě plynulý graf nebo knihu, přestože jí chybí důležitý krok. Obnova po přerušení je součást správnosti, ne jen otázka síťového připojení.
Při spojení snapshotu a následných změn stanovte přesný okamžik, od kterého se aktualizace aplikují. Pokud se během načítání snapshotu ztratí jedna událost, konečný stav bude chybný. Testujte přerušení uprostřed vysoké zátěže a opětovné připojení. Uživatel má vidět, když je stav neúplný. Některé obrazovky mohou zobrazit poslední známou hodnotu se zřetelným varováním; jiné musí zastavit akci, která závisí na úplných datech. Toto pravidlo určuje produktový vlastník podle rizika, nikoli pouze autor komponenty zobrazující graf.
Časové značky rozlišují tři různé zpoždění
Doba mezi událostí na trhu a odesláním poskytovatelem, mezi odesláním a přijetím aplikací a mezi přijetím a vykreslením se sčítá. Jedno obecné číslo „latence“ zakryje, kde vzniká problém. Ukládejte čas události, čas ingestu a případně čas zobrazení se srozumitelnou konvencí. Synchronizace hodin má své limity; při porovnání více systémů sledujte i rozdíl mezi jejich časem. Pokud feed poskytuje pouze čas přijetí, neslibujte přesnost času původního obchodu. U historických dat rozlišujte datum obchodní seance a skutečnou časovou značku, zejména přes půlnoc a při změnách časového pásma.
Pro uživatele může být důležitější stáří poslední ověřené hodnoty než průměrná síťová latence. Zobrazte jej tam, kde se podle dat rozhoduje. Při dosažení limitu se musí změnit stav obrazovky nebo dostupnost akce podle schváleného pravidla. Při rychlém feedu může být problém v pořadí, nikoli ve zpoždění. Metriky proto rozdělte podle instrumentu, zdroje a typu zprávy. Zjistěte, zda špička zdržuje všechny hodnoty nebo pouze určitou skupinu. Tak se řešení zaměří na příčinu místo nákupu většího serveru naslepo.
Duplicity, mezery a odlehlé hodnoty vyžadují odlišnou reakci
Duplicitní událost nemusí změnit poslední cenu, ale může zdvojit objem nebo počet obchodů. Chybějící interval může narušit graf a zůstat dlouho neviditelný, pokud se později přenos obnoví. Náhlý skok může být skutečný trh i chyba vstupu. Neopravujte automaticky všechno stejným pravidlem. Definujte kontrolu pro každou kategorii: identifikátor zprávy, sekvenci, dostupnost instrumentu, rozumné rozsahy a porovnání s alternativním zdrojem, pokud je oprávněně dostupný. Odchylka má mít status a vlastníka, aby systém neignoroval kvalitativní problém jen proto, že nevypnul celý feed.
Při opravě historických dat zachovejte informaci o původní hodnotě a době opravy, pokud je důležitá pro vysvětlení uživatelského rozhodnutí. Graf může později ukazovat správnou historii, ale uživatel v době akce viděl jinou hodnotu. Tyto pohledy není správné zaměňovat. Pro přepnutí na náhradní zdroj stanovte, jak se zachází s rozdílnou metodikou a licencí. Cena od dvou poskytovatelů nemusí být přímo zaměnitelná. Rozhodnutí o zdroji má být verzované a auditovatelné, zvlášť pokud se používá při výpočtech nebo upozorněních.
Latence a úplnost se musí vyvažovat podle úlohy
Živá obrazovka může upřednostnit rychlé zobrazení s označením nejistoty. Účetní nebo analytický výstup může raději čekat na úplnější data. Nemusíte pro oba případy stavět totožnou cestu. Rozdělte proud na živé zobrazení, potvrzený historický záznam a případně kontrolovanou dávku pro reporting. U každé vrstvy určete, jak se pozná dokončení a zda jsou pozdější opravy přijímány. Pokud se čísla liší, rozhraní má vysvětlit proč. Přesnost a čerstvost nejsou jedna osa kvality; dobrou architekturu určuje kontext použití.
Při vysokém objemu používejte limity front a plán pro dohnání zpoždění. Když aplikace nezvládá proud, nesmí bez upozornění ztrácet zprávy a současně tvrdit, že je aktuální. U méně důležitých vizualizací může být schválené vzorkování; u knihy či výpočtu obchodního stavu nikoli bez zvláštního rozhodnutí. Měřte percentily zpoždění a stáří nejstarší nezpracované události. Po obnovení provozu určete, zda se nejdřív doplní historie, nebo se vytvoří nový snapshot a staré mezery se označí. Tento výběr patří do provozního návodu.
Monitoring musí mluvit o kvalitě, nejen o dostupnosti
Zelené spojení s poskytovatelem neznamená správná data. Sledujte stáří poslední zprávy, mezery v sekvenci, chybové dekódování, počet oprav, rozdíl proti očekávanému objemu a odchylky u instrumentů. OpenTelemetry popisuje metriky jako agregované signály o chování systému; použijte je k měření skutečných kvalitativních podmínek. U každého alarmu stanovte hranici, časové okno a člověka, který rozhodne. Jiná pravidla mohou platit v obchodních hodinách a mimo ně. Nechcete budit pohotovost kvůli tichu, které je pro daný trh normální.
Provozní přehled by měl ukázat zdroj problému, rozsah a dopad na uživatelské funkce. Při výpadku lze některé části platformy ponechat aktivní a jiné pozastavit. Zaznamenejte, kdy byla kvalita snížena, co viděli uživatelé a kdy se stav obnovil. Po incidentu porovnejte monitor s realitou: zjistil chybu dřív než klienti? Vedl k bezpečné akci? Pokud ne, přidejte konkrétní test nebo metriku. Obecný alarm „feed down“ neřeší situaci, kdy feed běží, ale pro jeden důležitý instrument posílá chybný nebo starý údaj.
Testujte proudy, ne jen statické odpovědi API
Sestavte ukázkové sekvence se správným průběhem, duplicitou, mezerou, opožděným snapshotem, opravou hodnoty a změnou pořadí. U každé definujte očekávaný stav interní evidence, obrazovky a alarmu. Testujte i ztrátu spojení během špičky a opětovné připojení. U formátů s více typy zpráv prověřte chování při neznámém poli nebo verzi. Data pro testy musí respektovat smluvní omezení zdroje. Pokud produkční feed nelze legálně ukládat pro opakované testy, vytvořte schválené syntetické příklady se stejnými chybovými vlastnostmi.
Nechte člověka mimo implementační tým podle provozního přehledu poznat, že zobrazená hodnota už není vhodná k rozhodnutí. Pokud to nedokáže, chybí srozumitelná signalizace. Před spuštěním ověřte pravidla pro fallback a to, co se stane, když jsou oba zdroje nedostupné. Po vydání sledujte reálné odchylky a doplňujte regresní sadu. EXCOIN může navrhnout datovou cestu, ale bez konkrétního zdroje, licence a produktu nelze slíbit latenci ani správnost cen. Silný výsledek je systém, který umí ukázat původ a stáří hodnoty, rozpoznat neúplný proud a bezpečně přiznat nejistotu.
Předání odpovědnosti mezi dodavatelem dat a provozem
Součástí předání má být jasná matice odpovědnosti: kdo kontroluje smluvní rozsah dat, kdo sleduje technický stav příjmu, kdo rozhoduje o označení hodnot za neplatné a kdo komunikuje incident uživatelům. Kontaktní údaje a postup eskalace musí být použitelné i mimo pracovní dobu, pokud tak funguje produkt. Pro každý typ zdroje evidujte verzi rozhraní, pravidla aktualizace, výjimky v kalendáři trhu a dohodnutý postup při plánované odstávce. Bez těchto údajů může provoz správně rozpoznat anomálii, ale nebude vědět, zda jde o chybu na jeho straně, změnu dodavatele nebo očekávané chování trhu.
Pravidelně společně přezkoumávejte vzorky incidentů a falešných alarmů. Zjištění promítněte do kontraktu, testů i uživatelského vysvětlení stavu. Takový cyklus je praktičtější než jednorázové potvrzení, že feed při předání fungoval.