Agenttiyrityksen luotettavuus

Autonomiset agentit esittävät ei-deterministisiä suorituskuvioita, jotka eroavat täysin perinteisestä Salesforcen automatisoinnista. Vaikka Salesforce-kulku ja Apex noudattavat ennustettavia polkuja, jotka tuottavat toistuvia tuloksia hallituissa olosuhteissa, agentit ajattelevat ongelmia dynaamisesti. Esimerkiksi sama kysymys kahdesti voi kestää eri suorituspolkuja, kuluttaa eri resursseja ja tuottaa eri tuloksia. Tämä ei-deterministisyys luo luotettavuushaasteita, joita perinteiset testaus- ja valvontatavat eivät ratkaise.

Agenttien luotettavuuden virhetilat eroavat selkeästi Salesforce-kulun tai Apex. Large Language Model (LLM) -viitepalvelut edustavat ulkoisia sidonnaisuuksia, joiden saatavuusominaisuudet ovat erillään Salesforce Platformista. Agentit luovat vastauksia, jotka joskus rikkovat odotettua rakennetta kehotteiden ohjeista huolimatta. Agentin kontekstin valmistelu kuluttaa hallintarajoituksia ennustetusti. Rajoittamattoman datan noutaminen vaikuttaa agenteihin vakavammin, koska agentit voivat pyytää avointa kontekstia, kun taas deterministisillä kyselyillä on suora vaikutusalueen hallinta.

Luotettava agenttiarkkitehtuuri vaatii monitasoisen varaketjun, joka heikkenee hienovaraisesti — hienostuneista agenteista yksinkertaisempiin agenteihin, joissa on rajoitettu konteksti, deterministisiin sääntöjärjestelmiin ja lopuksi ihmisten käsittelyyn Omni-Channelin kautta. Sovellusalustan tapahtumat -ominaisuus tarjoaa kestäviä uudelleenyritysjonoja tarkastuspisteiden kuvioilla, jolloin epäonnistuneet työnkulut voidaan jatkaa viimeisestä onnistuneesta vaiheesta. Viestiketjut seuraavat LLM-palvelun tilaa sovellusalustan välimuistissa reaaliaikaisesti, ja ne tukevat kynnysarvoja ja kokoonpanoa koskevat mukautetut metadatatyypit, jotka reititetään varakuvioihin peräkkäisten virheiden jälkeen. Valvonta vaatii, että seurataan keskusteluiden onnistumissuhteita, epäonnistumisten välistä keskiarvoista aikaa (MTBF), keskiarvoista palautusaikaa (MTTR) ja perustamisen tarkkuutta. Agentforce Observability tarjoaa istuntojen jälkiä, kunnon ja viiveen tilastoja sekä eskalointi- ja ennaltaehkäisymääriä, mutta sinun täytyy silti laatia itse luotettavuustilastoja, kuten MTBF, MTTR ja maadoituksen tarkkuus.

Tämä asiakirja kattaa muutokset, kun agentit ovat kuvassa. Kaikkiin Salesforce-ratkaisuihin (palvelutaso-objektin (SLO) suunnitteluun, vianmääritykseen, skaalautumiseen ja valvontaan) liittyviä perustavanlaatuisia luotettavuuskuvioita on kohdassa Luotettavuus-sarakkeessa.

Agentforce epäonnistuvat eri tavoin kuin Salesforce-kulku tai Apex Näiden virhetilojen ymmärtäminen määrittää luotettavuuden arkkitehtuuria.

LLM-palvelun vapaat ajat: LLM-päätepisteet kohtaavat satunnaisia viiveen nousua tai saatavuusongelmia. Agentforce näytetään valvottavana tuotteena trust.salesforce.com:issa Analyticsin ja muiden Salesforce-palveluiden rinnalla. Tarkkoja LLM-viive- ja pyyntökohtaisia suorituskykytilastoja ei kuitenkaan näytetä. Toteuta katkaisijoita käyttämällä sovellusalustan välimuistia reaaliaikaiselle alhaisen viiveen tilalle, joka on varustettu kynnysarvojen ja kokoonpanon mukautetuilla metadatatyypeillä, seurataksesi LLM-palvelun kuntoa. Sovellusalustan välimuisti on paras vaihtoehto – merkinnät voidaan poistaa ennen niiden voimassaoloaikaa (TTL) — joten pysy avoinna/poistettu-tilassa pysyvässä tallennustilassa, kuten mukautetussa objektissa, eikä vain välimuistissa. Säädä matkan ehtoa päätepisteeseen: peräkkäisten virheiden määrä (esimerkiksi viisi) tai kynnysarvon ylittäminen peräkkäisessä ikkunassa. Kun viestiketju siirtyy, avaa se ja reititä se varakuvioihin, kuten yksinkertaisempiin kehotteisiin, välimuistiin tallennettuihin vastauksiin tai henkilön lähetykseen, kunnes onnistunut testipyyntö osoittaa palautusta.
Vastauksen vahvistusvirheet: Agentit luovat joskus vastauksia, jotka rikkovat odotettua rakennetta kehotteiden ohjeista huolimatta. Agentti palauttaa joskus väärin muotoiltua JSON-tiedostoa, ohittaa pakolliset kentät tai sisältää odottamattomia datatyyppejä. Sovellusalustan välimuisti voi tallentaa vahvistettuja vastausskeemoja, mikä mahdollistaa nopean vahvistuksen. Kun vahvistus epäonnistuu, yritä uudelleen tarkennetuilla kehotteilla, mukaan lukien vahvistusvirhe ja esimerkki oikeasta rakenteesta. Määritä uudelleenyritysten enimmäismäärä (3–5) välttyäksesi loputtomilta uudelleenyrityksiltä.
Hallucinaation havaitseminen: Kun datan perustaminen ei ole täydellistä, agentit tuottavat todennäköisiä, mutta virheellisiä tietoja. Toisin kuin deterministiset kyselyt, jotka palauttavat ”ei löydy”, agentit täyttävät aukot johtopäätöksellä. Einstein Trust Layer Audit Trail kirjaa lokiin jokaisen kehotteen, peitetyn kehotteen, vastauksen, toksisuuksien havaitsemisen tuloksen ja käyttäjien palautteen hallintatarkastusta varten. Se ei kuitenkaan sieppaa vaiheittaisia perusteluja. Käytä Agentforcen istuntojen jäljittämistä, joka tallentaa perustelujärjestelmän suoritukset, jotta voit siepata ne vaiheittain. Vaadi agentteja lisäämään Data 360 (aiemmalta Data Cloudilta) -hakutuloksen augmented generation (RAG) -hakutulosten lähteitä. Ristiviittauksen agentit tekevät korvausvaatimuksia haetuista lähteistä, jotta ne voivat havaita faktan poikkeamia ennen toiminnon suorittamista. Suoritettu tarkastus lisää vähän viiveä, koska se suoritetaan lähteille, jotka ovat jo asiayhteydessä. Tarkastus, joka vaatii erillisen matkan, kuten toisen mallin puhelun tai ulkoisen palvelun, maksaa enemmän. Varaa nämä tarkastukset vahvasti vaikuttaville kirjoituksille, mukaan lukien talous- tai tilausten päivitykset, ja suorita ne ei-synkronoidusti reaaliaikaisen keskustelun aikana.
Hallintorajoitukset: Agenttien kontekstiin valmistautuminen kuluttaa Salesforce-objektien kyselyiden kielen (SOQL) kyselyitä, CPU-aikoja ja pehmeää muistia odottamattomalla tavalla keskustelun kulun perusteella. Proactive Monitoring on allekirjoitusten onnistumisen (aiemmin allekirjoitusten tuen) oikeutuspalvelu Salesforcen onnistumissuunnitelmassa, jossa Salesforce valvoo asiakastilejä ennakoivasti. Proactive Monitoring ei ole itsepalvelukokoonpanoon perustuva hälytys, joka on kaikkien asiakkaiden käytettävissä. Jos käytät itsepalvelupäälliköiden rajoitusten valvontaa, käytä skaalauskeskusta tunnistaaksesi resurssiintensiviset agenttitoiminnot, jotka lähestyvät rajoituksia. Toteuta sivutusta agenttitoiminnoissa, jotka noutavat suuria tietueiden kokoelmia. Käytä sovellusalustan välimuistia usein käytetyille viitetiedoille.
Datan vääristyminen agentin asiayhteydessä: Agentit, jotka hakevat tietoja yli 10 000 mahdollisuutta sisältävistä tileistä tai tapauksista, joilla on verrattain suuri toimintohistoria, kohtaavat samat datavirheiden haasteet kuin Apex. Toisin kuin deterministiset kyselyt, joissa voit hallita vaikutusaluetta, agenttien perustelut voivat pyytää "kaikkia historiatietoja" ennustettavasti. Voit välttyä tältä suunnittelemalla agenttitoimintoja, joilla on järkeviä kovia rajoituksia (esimerkiksi enimmäismäärä 200 alitason per ylätaso) ja toteuttamalla näytestystrategioita, kun rajoitukset ylitetään. Määrä rajoittaa, kuinka paljon dataa agentti syöttää asiayhteyteen. Yhdistä se valikoiviin indeksoituihin suodattimiin, jotta itse kysely pysyy edullisena, koska vääristyneen ylätason indeksoimaton suodatin tai aggregaatti skannaa koko alitason joukon ennen kynnysarvon käyttöönottoa.

Suunnittele monitasoisia varaketjuja salliaksesi agenttien jatkaa toimintaansa pienellä kapasiteetilla eikä epäonnistua kokonaan.

Ensisijainen agentti ja täysi konteksti: Kehittyneet agentit, joilla on täydellinen Data 360 -pohja, kattava keskusteluhistoria ja monimutkaiset perustelut. Parhaan laadun, mutta resurssien määrän ja suurimman virheiden riskin.
Toissijainen agentti, jossa on rajoitettu konteksti: Yksinkertaisempi agentti käyttämällä tiivistettyä kontekstia (esimerkiksi edelliset 30 päivää vs. koko historia, 5 parasta vektorihaun tulosta vs. 20 parasta). Pienempi konteksti tarkoittaa vähemmän tokeneita, nopeampaa päätelmää ja vähemmän epäonnistumisen todennäköisyyttä, mutta vain, jos pienempi konteksti kattaa tehtävän tarvitseman datan.
Deterministinen sääntöjärjestelmä: Perinteinen Salesforce-kulku tai Apex, joka käsittelee yleisiä skenaarioita, kun agenttien päättely epäonnistuu. Säännöt eivät sovellu uusiin tilanteisiin, mutta ne käsittelevät tunnettuja kuvioita luotettavasti. Tilauksen vahvistusagentti siirtyy takaisin vakiomuotoisiin vahvistussääntöihin, kun taas liidien pisteytysagentti siirtyy takaisin sääntöihin perustuvaan pisteytyksen laskemiseen.
Henkilön lähetys Omni-Channelin kautta: Reititä ihmisjonoon, kun automatisoidut vaihtoehdot ovat loppuneet. Määritä taitoihin perustuva reititys varmistaaksesi, että eskaloinnit saavuttavat asiaankuuluvan ammattitaidon. Välitä keskustelun koko konteksti — mukaan lukien yritetyt strategiat, agentille laskemasi luottamustason pisteet ja epäonnistumisen syyt — salliaksesi tehokkaan ihmisen toiminnan.

Toteuta varalogiikkaa Salesforce-kulun tai Apexin orkestrointiin, jonka käynnistävät sovellusalustan tapahtumat. Jokainen taso kirjaa onnistuneen strategian lokiin, mikä tarjoaa näkyvyyttä epäonnistumiskuvioihin ja varatoimintoihin.

Kaikki tämän osion Sovellusalustan tapahtuma -kuviot ovat raskaan sovellusalustan tapahtumatyyppejä, jotka tarjoavat 72 tunnin toistamisen säilytysajan. Sovellusalustan vakiomuotoiset tapahtumat säilytetään vain 24 tunnin ajan. Käytä raskaita tapahtumatyyppejä kaikille agenttien kestävyyteen, uudelleenyritysjonoon ja tarkastuspisteeseen perustuville kuvioille, joissa toistamisen kestävyys on luotettavuusvaatimus. Sovellusalustan tapahtumat -ominaisuus tarjoaa kestävää viestintää, joka sallii agenttien työnkulkujen selviytyä virheistä ja palauttaa ne automaattisesti.

Tarkastuspisteen agentin edistyminen: Monivaiheiset agenttien työnkulut julkaistavat tarkastuspisteiden tapahtumat onnistuneen vaiheen jälkeen. Sopimusten käsittelijä suorittaa asiakirjan noudon, julkaisee ContractParsed-tapahtuman kerätyillä tiedoilla ja jatkaa sitten lausekeanalyysiä. Jos lausekeanalyysi epäonnistuu, toista ContractParsed-tapahtuma jatkaaksesi noudetusta datasta jäsentämättä dataa uudelleen. Tämä toimii, kun tarkastuspisteen hyötykuorma sisältää kyseisen datan ja tilaaja on idempotent, koska toisto toimittaa tapahtumat uudelleen työnkulun keskivaiheen sijaan. Tallenna tapahtuman tietosisällön tarkastuspisteen tila, mukaan lukien korrelaatiotunnus, suoritetut vaiheet ja jatkamiseen tarvittu tila.
Kokeilujono eksponenttisella rästityksellä: Epäonnistuneet agenttipyynnöt julkaistaan AgentRetryRequested-tapahtumaan, jossa yrityksen määrä uudelleen tietosisällössä. Tapahtuman tilaaja käsittelee uudelleenyritykset, joilla on eksponenttisia rästityöt (esimerkiksi 30 sekuntia, 2 minuuttia, 8 minuuttia, 30 minuuttia). Kun uudelleenkäynnit on suoritettu enintään (tavallisesti 5 kertaa), reititä dead-letter-jonoon ja hälytysoperaatioihin. Suuren volyymin sovellusalustan tapahtumat säilyttävät 72 tunnin toistohyökkäyksen. Käytä tehokäyttöisiä tapahtumatyyppejä agenttien uudelleenyritysjonoille, jotta tilaajat voivat jatkaa organisaation huoltotyön tai käyttöönoton käyttökatkoksen jälkeen. Sovellusalustan vakiomuotoiset tapahtumat säilytetään vain 24 tuntia.
Tapahtumiin perustuva orkestrointi: Suunnittele agenttien työnkulut löysästi yhdistettyinä tapahtumaketjuina. Liidien luonti julkaisee LeadCreated-arvon. Liidien pisteytysagentti tilaa, pisteyttää ja julkaisee LeadScored-arvon. Liidien reititysagentti tilaa LeadScored-objektin ja kohdistaa sen asiaankuuluvaan jonoon. Jokainen agentti voi epäonnistua ja yrittää uudelleen itsenäisesti. Yksittäinen agentin virhe ei estä koko työnkulkua — alaiset agentit käsittelevät sen, kun sidonnaisuudet palautuvat.
Korrelaation tunnuksen seuranta: Lisää korrelaatiotunnus mukautettuna kenttänä kaikkiin asiaan liittyvien tapahtumien tietosisältöihin. Toista tapahtumia käyttämällä Pub/Sub API:a by replayId, joka on läpinäkymätön, ei-yhteensopiva tunnistin, rakentaaksesi työnkulkuhistorian uudelleen 72 tunnin säilytysajan sisällä. Ota korrelaatioiden tunnuksiin perustuva virheenkorjaus käyttöön toteuttamalla tilaajapuolen kuvio, joka kirjaa saapuvat tapahtumat replayId- ja korrelaatiotunnuksillaan mukautettuun objektiin, mikä mahdollistaa tapahtumien ristikkäisen jäljitettävyyden. Tämä lokikuvio on mukautettu toteutuksesi, jonka luot itse, et natiivisovellusalustan kyselykykyä.

Siirrä synkronointirajoituksia ylittävät agenttitoiminnot ei-synkronoituun kontekstiin, mikä sallii korkeammat hallintarajoitukset ja pidemmät aikakatkaisut.

Apex-eräasetukset joukkotoiminnoille: Yli 1 000 tietuetta analysoiva agentti hyötyy Apex erästä, joka tarjoaa 200 SOQL-kyselyä, 150 DML-lausuntoa (enintään 10 000 DML-riviä) ja 60 000 millisekuntia (60 sekuntia) CPU-aikaa per suoritusmenetelmä. Liidien pisteytysagentti, joka käsittelee liidien öisiä tuontia. Tapausten sentimenttianalyysi historiallisista tapauksista. Mahdollisuuksien ennustaminen, joka analysoi kokonaisia myyntiputkia.
Jonoon asetettavat ketjut monivaiheisille työnkuluille: Monimutkaiset agenttien työnkulut, jotka vaativat useita ulkoisia API-kutsuja, suuria datajoukkoanalyysejä tai pidempiä käsittelyaikoja, käyttävät Apex. Jokainen jonoon lisättävä työ saa 60 CPU-aikaa ja 12 Mt tähteä. Ketjutetaan seuraavaan jonoon työnkuluille, jotka ylittävät yhden työn rajoitukset. Seuraa mukautettujen objektien edistymistä, jotta epäonnistunut työ voidaan jatkaa edellisestä suoritetusta vaiheesta.
@future yksinkertaisille asynkronoiduille viesteille: Helppokäyttöiset agenttitoiminnot, kuten ilmoitusten lähettäminen, ulkoisiin järjestelmiin kirjautuminen tai muut kuin kiireelliset päivitykset, käyttävät @future-metodeja. Fire-and-forget-kuvio soveltuu silloin, kun työnkulku ei tarvitse palautetta ja voi sietää virheitä.

Valvo asynkronisen käsittelyn kapasiteettia Apex (Määritykset → Apex) ja Apex Flex -jonosta. Enintään 5 samanaikaista erätyötä rajoittaa agenttien samanaikaista käsittelyä. Apex Flex -jonossa on ylimääräisiä töitä, jotka sisältävät enintään 100 työtä Pidossa-tilassa. Kaikilla asynkronisilla Apex-tyypeillä, erä, tuleva, jono ja ajoitettu Apex, on sama organisaationlaajuinen päivittäinen rajoitus (DailyAsyncApexExecutions) ei-synkronoiduille Apex-suorituksille: suurempi kuin 250 000 tai 200 kertaa käyttäjälisenssien määrä. Kun suoritat agenteille usein kyselyitä tai yrität tilaajien jonoja uudelleen, jonot voivat tyhjentää kiintiön nopeasti. Välty tältä, jos haluat asettaa nämä jonot erä- tai rajoituskertoihin pysyäksesi rajoituksen sisällä — mikä koskee organisaationlaajuisesti kaikkia asynkronoituja Apex, äläkä erillisenä rajoituksena vain Jonotettava-kenttään. Ilmoita, kun kulutus lähestyy näitä rajoituksia, jotta tiimit voivat hallita kapasiteettia ennakoivasti.

Vahvista agenttien kestävyyttä ennen tuotantoympäristöä testaamalla strategioita, jotka käsittelevät ei-deterministisiä toimintatapoja.

Lataustestaus Full Copy -sandboxissa: Testaa agenttien suorituskykyä tuotanto-asteikon latauksessa käyttämällä täyttä dataa. Simuloi samanaikaisia keskusteluita, jotka vastaavat suurinta kysyntää. Mittaa p95- ja p99-kestoja tunnistaakseen suorituskyvyn heikentymisen stressin alaisena. Vahvista, että hallintarajoitusten kulutus pysyy kynnysarvojen alapuolella ruuhka-aikojen aikana. Lataustestaus Partial Copy -sandboxissa, jossa on vähemmän dataa, tarjoaa harhaanjohtavaa luottamusta, koska datan määrä vaikuttaa suoraan agenttien suorituskykyyn. Pyydä Salesforcelta hyväksyntä ennen näiden testien suorittamista (vähintään viikko ennen suorituskykytestipyyntöjä). Hyväksymättömiä testejä voidaan rajoittaa tai estää.
Virhe-injektio: Käytä tarkoituksella virheitä vahvistaaksesi palautusmekanismeja. Simuloi LLM:n johtopäätöksen virheitä palvelualueella, jota katkaisija valvoo, varmistaaksesi, että katkaisija aktivoituu. Syötä SOQL-poikkeuksia testataksesi virheiden käsittelyä. Korjaa agenttien vastaukset testaamaan vahvistuslogiikkaa. Lisää datavirhe (tilit, joilla on yli 10 000 alitason tiliä) testataksesi sivutuslogiikkaa. Määritä aggressiivisia aikakatkaisuja testataksesi aikakatkaisustrategioiden käsittelyä ja yrittääksesi niitä uudelleen.
Kaositekniikka: Poista sovellusalustan tapahtumien tilaajat satunnaisesti käytöstä testataksesi toistamisen palautusta. Lopeta asynkronointityöt suorituksen aikana testataksesi tarkastuspisteen uudelleenkäynnistystä. Tuo muuttujien viive ulkoisiin järjestelmiin testataksesi progressiivisia aikakatkaisustrategioita. Chaos-kokeilut vahvistavat kestävyyttä realistisissa virheiden yhdistelmissä. Ajoita säännöllisiä kaaoksen päiviä vaiheistetuissa ympäristöissä, jotta voit pysyä kestävänä agenttien kehittyessä.
Pitkäaikaiset vakaustestit: Suorita agenttien työkuormia jatkuvasti yli 72 tunnin ajan ja valvo ajasta riippuvia virheitä. Virheiden kerääntyminen ja suorituskyvyn asteittainen heikentyminen vain jatkuvan toiminnan aikana. Seuraa CPU-aikojen trendejä tunnistaaksesi asteittaisen heikkenemisen suorituksen aikana.

Määritä palvelutasojen indikaattorit (SLI), jotka sallivat tavoitteiden luotettavuuden mittaamisen. Luo SLO-kertakirjautumiset ennen agenttien rakentamista, äläkä tuotanto-virheiden jälkeen.

Keskustelun onnistumissuhde: Prosenttiosuus agenttien keskusteluista, jotka on suoritettu ilman virheitä tai aikakatkaisuja. Laske lahjakas lahjoitus ihmiselle menestykseksi, äläkä epäonnistumiseksi — eskalointi on suunnitelman viimeinen varataso. Laske epäonnistuneet tai tahattomat eskaloinnit tilastoon — se on hyödyllinen luotettavuussignaali, mutta ei täydellinen välityspalvelu käyttäjäkokemukselle, koska kohtelias rekisteröinti voi peittää ratkaisemattoman ongelman. Seuraa erikseen agenttityypin ja käyttötarkoituksen mukaan, koska liidien pisteytyksen onnistumisen ehdot eroavat sopimuksen tarkastuksesta. Hälytys, kun onnistumissuhde laskee SLO:n alle (tavallisesti 95–99 %).
Virheiden välinen keskiaika (MTBF): Agenttien virheiden välinen keskiarvoinen toiminta-aika. Korkeampi MTBF tarkoittaa vähemmän virheitä ja parempaa luotettavuutta. Laske agenttien toiminta-ajat yhteensä jaettuna virheiden määrällä. Seuraa agenttityyppiä tunnistaaksesi luotettavimmat agentit, jotka vaativat optimointiin sijoituksia.
Keskiarvoinen palautusaika (MTTR): Keskimääräinen aika virheiden havainnosta palvelun palautukseen. Automatisoitu palautus sovellusalustan tapahtumien toistamisen ja katkaisijoiden kautta palauttaa palvelun paljon nopeammin ja vähemmällä manuaalisella virheellä kuin käytännön interventio. Alhainen MTTR vähentää liiketoiminnan vaikutusta per vahinkotapahtuma.
Maadoituksen tarkkuus: Prosenttiosuus agenttien vastauksista, jotka ovat tosiasiallisesti oikeita lähdedatan vahvistuksen perusteella. Esimerkkejä agenttien satunnaisista vastauksista vahvistaaksesi Data 360 -lähteitä koskevia korvausvaatimuksia. Maantieteellinen tarkkuus alle 95 % osoittaa hallusinaatio-ongelmia, jotka vaativat kehotteen hienosäätämistä tai asiayhteyden parempaa hakua.
Sovellusalustan tapahtumien toistamisen aukot: Puuttuvien tai toimittamattomien tapahtumien määrä, esimerkiksi tilaaja offline-tilassa säilytysajan ulkopuolella. Nolla aukkoja on positiivinen signaali tapahtumiin perustuvasta terveellisestä arkkitehtuurista. Niiden aukot osoittavat tilaajien ongelmia, tapahtumien julkaisuvirheitä tai kapasiteettirajoituksia. Seuraa näitä aukkoja yllä kuvatulla tilaajapuolen lokien kuviolla ja tallenna kunkin tapahtuman replayId ja korrelaatiotunnus mukautettuun objektiin.

Luotettavat agentit saadaan suunnittelusta epäonnistumisen varalta etukäteen — määrittämällä SLI:t/SLO-kertakirjautumiset, hallinnoijien rajoitusten huomioimisen asiayhteydestä ja monitasoisten varaketjujen käsittelystä ennen niiden rakentamista, eikä niiden kiinnittämistä jälkeenpäin. Kerrosten katkaisijat ja sovellusalustan tapahtumiin perustuva uudelleenyritys- ja tarkastuspistelogiikka, jotta työnkulut palautuvat automaattisesti, ja henkilökohtainen siirto on viimeinen vaihtoehto. Vahvista tämä rakenne järjestelmällisellä latauksella, vianetsinnällä ja kaaoksen testauksella ja valvo sitten samoja SLI-kertakirjautumiskertoja tuotantoympäristössä varmistaaksesi, että ne säilyvät ajan myötä.

Pääsarakkeen Luotettavuus-pilarin luotettavuutta koskevat ohjeet koskevat agentteja, joilla on alustakohtaisia huomioitavia asioita. Onnistuneet agenttiarkkitehtuurit tasapainottavat itsenäistä kapasiteettia asianmukaisen valvonnan kanssa, mikä mahdollistaa itsekuntoutumisen väliaikaisista virheistä ja eskaloinnin, kun luottamustaso heikkenee tai rintatapauksia ilmenee.

Jaa palautetta hyvin rakennetusta kehysjärjestelmästä.