Ezen az oldalon
Vegyünk egy képzeletbeli, százlépéses böngészőfeladatot. Tegyük fel, hogy minden lépés 99%-ban sikerül, a többitől függetlenül. Annak esélye, hogy mindegyik működik, 0.99^100, vagyis körülbelül 36,6%.
A kilencvenkilenc százalék kiválónak hangzik. A harminchat nem.
A tranzakciós böngészőmunkáról szóló forrásbeszélgetés ezzel a számítással egy szűk állítást szemléltet: az ügyfél akkor kap értéket, ha a feladat befejeződik, miközben a költség és a hibakockázat minden lépésnél nő. Ez feltételezésen alapuló számtan, nem valamely böngészőügynök vagy Tajo-szinkronizálás közzétett sikeraránya. A valós hibák függhetnek egymástól. Egy lejárt bejelentkezés több későbbi műveletet is megszakíthat.
Ezért nem az a hasznos kérdés, hogy „Mennyire volt pontos a modell utolsó kattintása?”, hanem az, hogy „Létrejött a felhasználó által kért állapot?”
A tranzakció a fontos egység
Képzelj el egy ügynököt, amely megnyit egy biztosítási portált, megkeres egy dokumentumot, letölti, majd ellenőrzi, hogy a megfelelő fiókhoz tartozik-e. Kilencvenkilenc képernyőn helyesen navigálhat, mégis rossz fájlt tölthet le a századikon. A sikeres kattintásokat mutató napló nem teszi helyessé az eredményt.
Ugyanez igaz egy integrációra. Az ügynök megtalálhat egy API-t, javasolhat mezőleképezést és menthet piszkozatot. Ebből még nem következik, hogy a célrendszerben lévő kapcsolathoz a kívánt hozzájárulási állapot tartozik. A munka csak akkor kész, ha a jóváhagyott művelet lefutott, és a fontos utófeltételt ellenőrizték.
Ez a tevékenység és a befejezés közötti különbség. A tevékenység könnyen számolható. A befejezést meg kell határozni.
Fájlletöltésnél ez lehet olyan eredmény, amelynek fiókszáma egyezik a kéréssel. Kapcsolat szinkronizálásánál lehet olyan célrekord, amelyben helyes az azonosító, a mezők és az engedélyezett üzenetküldési állapot. Az ellenőrzésnek azt kell vizsgálnia, amiért a felhasználó a feladatot kérte. Az előző hívás zöld válasza azt bizonyítja, hogy a hívás visszatért. Nem feltétlenül azt, hogy a célállapot a kívánt módon változott.
A Tajo üzleti eszközök összekapcsolásáról szóló útmutatója a munkafolyamattal és az egyes adatobjektumok mértékadó forrásával kezd. Ezek a döntések adnak jelentést a végső ellenőrzésnek. Ha két rendszer is magát tekinti egy mező tulajdonosának, még a hibátlanul végrehajtott írás is rossz tartós állapotot eredményezhet.
Mennyibe kerül egy újabb döntés?
Ugyanazzal a feltételezett 99%-os aránnyal tíz független döntés körülbelül 90,4%-os teljes sikert ad. Ötven 60,5%-ot. Száz 36,6%-ot.
A teljes lánc sikerének esélye (%)
Független lépések száma
- Feltételezett 99%-os lépéssiker
A számított értékek
| Lépések | A teljes lánc sikere (%) |
|---|---|
| 0 | 100,0 |
| 10 | 90,4 |
| 25 | 77,8 |
| 50 | 60,5 |
| 75 | 47,1 |
| 100 | 36,6 |
A görbe meredek, mert a szorzást nem érdekli a jó átlag. Minden újabb döntésnek meg kell indokolnia a helyét.
Ez nem jelenti azt, hogy minden API-hívást egy óriási műveletté kell összevonni. Egyes hívások determinisztikusak: oldal lekérése ismert kurzorral, azonosító összehasonlítása vagy mező írása jóváhagyott leképezés szerint. A modellnek nem kell ezeket minden rekordnál újra eldöntenie. Más hívások valódi kétértelműséget hordoznak: új szolgáltatói mező, megváltozott hibaüzenet vagy tisztázatlan tulajdonosú kérés. Ezeknél szükség lehet megítélésre.
A gyakorlatban a megítélés megtervezhet vagy javíthat egy szabályt, az egyszerű kód pedig alkalmazhatja a stabil szabályt. A fordított ETL jó példa az ismétlődő adatmozgatásra: a rutinszerű soronkénti műveleteket a folyamatnak, nem egy beszélgetésnek kell végrehajtania. Az ügynök továbbra is segíthet eldönteni, mit tegyen a folyamat.
Ez határvonal, nem jelszó. Ha a szolgáltató megváltoztatja egy mező jelentését, a determinisztikus szabály hibátlanul ismételhet egy rossz műveletet. A rendszernek észlelnie kell, ha a feltételezései megváltoztak, és vissza kell küldenie az esetet ellenőrzésre.
Miért nem elég egyetlen nagy eszköz?
Jogos ellenvetés: „Ha a hosszú láncok elbuknak, tegyük az egész feladatot egyetlen eszközhívás mögé.” Ez segít, ha az eszköz jól meghatározott tranzakció, ellenőrizhető eredménnyel. Akkor nem segít, ha csak elrejti a hosszú és bizonytalan folyamatot.
Tegyük fel, hogy a syncCustomer() az állapotfrissítés elküldése után success: true választ ad. Ha a célrendszer később dolgozza fel a frissítéseket, a hívás ekkor még nem bizonyíthatja a kapcsolathoz tartozó végső állapotot. Az eszköz kevesebb látható lépést adott. A bizonytalanságot nem csökkentette.
Jobb felület mutatja a fontos állapotokat: befogadva, alkalmazva, ellenőrizve vagy meghiúsult. E szavak mögött bizonyítéknak kell állnia. Kis következményű előnézetnél elég lehet az elfogadott írás. Kampánycélközönségnél vagy hozzájárulási változásnál célrendszerbeli ellenőrzés kell, mielőtt bárki késznek nevezi.
Ebben a javasolt Tajo-nézetben az elfogadott kérés és az alkalmazott módosítás külön szerepel az igazolt célállapottól. Az utolsó ellenőrzés még függőben van. A következő lépés célja világos: megnézni, mit tárolt a célrendszer. Egy újabb sikeres eszközhívás nem válaszolna az eredeti kérdésre.
Az elvégzett íráshoz még bizonyíték kell
Befejeződött a vásárlók szinkronizálása?
Az írás megtörtént. Az ellenőrzés függőben van.
A célrendszer állapotát még nem ellenőriztük.
Szinkronizálási tevékenység
- Kérés elfogadva
- Módosítás alkalmazva
- A célrendszer ellenőrzése függőben
Példafuttatás · 14:32 UTC
Amit tudunk
- Szolgáltatói válasz
- Elfogadva
- Írás eredménye
- Alkalmazva
- Visszaolvasás a célrendszerből
- Függőben
A sikeres hívás nem bizonyítja a végső állapotot.
A javasolt elrendezés a Tajo tevékenységfolyamán alapul. Az ábra ellenőrzési állapotot ad hozzá; nem állítja, hogy a célrendszerből való visszaolvasás már megvalósult.
Ez a mérésen is változtat. Rögzítsd a próbálkozások számát, ha segít feltárni a költséget. Rögzítsd a köztes hibákat, ha egy hibás lépésre mutatnak. A folyamatot azonban az ellenőrzött, befejezett tranzakciók alapján ítéld meg, és a szám mellé írd oda az ellenőrzés módját. A „hívások 99%-a sikeres volt” jelentés nem válaszolja meg, hogy a vásárlók el tudták-e végezni a dolgukat.
Az MCP-szerverekről szóló magyarázat megmutatja, hogyan hívhat meg egy asszisztens másik rendszert eszközökkel. Az eszközhöz való hozzáférés csak a kezdő lépés. A megállapodás lényege a hátrahagyott állapot.
Száz jó kattintás után is maradhat üres a kéz. Az eredményt számold.
Gyakran Ismételt Kérdések
Miért bukik el egy hosszú folyamat, ha a lépései többnyire helyesek?
Ha minden lépés egymástól függetlenül p valószínűséggel sikeres, az n lépéses lánc sikerének esélye p az n-ediken. Feltételezett 99%-os lépéssiker mellett száz lépés körülbelül 36,6%-ban fejeződik be. A valós hibák összefügghetnek, ezért ez példa, nem mért ügynöki arány.
A kevesebb eszközhívás garantálja a megbízhatóságot?
Nem. A kevesebb hívás csak akkor segít, ha az összevont műveletnél megmaradnak a megfelelő ellenőrzési és helyreállítási pontok. Egyetlen átláthatatlan hívás éppúgy elrejthet egy sikertelen írást.
Mit mérjen egy csapat az ügynöki munkafolyamatnál?
A felhasználó tranzakciójának ellenőrzött befejezését mérje, ne csak a sikeres modellhívásokat. Határozza meg a kész munkát bizonyító eredményt vagy célállapotot, majd számolja meg, hányszor jön létre a teljes folyamat után.