Jaa

Tilapäisten vikojen käsittelemistä koskevat suositukset

  • Artikkeli

Koskee tätä Power Platform hyvin suunnitellun luotettavuuden tarkistuslistan suositusta:

RE:05 Vahvista työmäärän vikasietoisuutta ottamalla käyttöön virheiden ja tilapäisten vikojen käsitteleminen. Muodosta ratkaisuun ominaisuuksia, jotka käsittelevät osien virheitä ja tilapäisiä virheitä.

Tässä oppaassa kerrotaan pilvisovellusten tilapäisten vikojen käsittelemistä koskevista suosituksista. Kaikkien etäpalveluiden ja resurssien kanssa kommunikoivien sovellusten on huomattava tilapäiset virheet heti. Tämä koskee erityisesti pilvipalvelussa suoritettavia sovelluksia, joissa tämän tyyppiset virheet ovat todennäköisesti yleisiä ympäristön ominaisuuksista ja Internet-yhteydestä johtuen. Tilapäisiä virheitä ovat esimerkiksi osien ja palveluiden verkkoyhteyden hetkellinen menetys, palvelun tilapäinen käyttämättömyys ja aikakatkaisut, jotka tapahtuvat, kun palvelu on ruuhkautunut. Nämä virheet korjaantuvat usein itse, joten jos toiminto toistetaan sopivan viiveen jälkeen, se todennäköisesti onnistuu.

Tärkeimmät suunnittelustrategiat

Tilapäisiä virheitä voi tapahtua missä tahansa ympäristössä tai käyttöjärjestelmässä ja millaisessa sovelluksessa tahansa.

Haasteet

Tilapäiset virheet voivat vaikuttaa merkittävästi sovelluksen havaittavaan käytettävyyteen, vaikka se olisi testattu perusteellisesti kaikissa ennakoitavissa olevissa tilanteissa. Varmista, että Power Platformin työmäärä toimii luotettavasti varmistamalla, että se voi vastata seuraaviin haasteisiin:

  • Sovelluksen on pystyttävä tunnistamaan virheet niiden ilmetessä ja määrittämään, ovatko virheet todennäköisesti tilapäisiä, pitkäkestoisia vai päätevirheitä. Eri resurssit saattavat palauttaa erilaisia vastauksia virheen ilmetessä. Vastaukset voivat vaihdella myös toiminnon kontekstin perusteella. Esimerkiksi vastaus virheeseen, jossa sovellus hakee tietoja mukautetusta yhdistimestä, voi olla erilainen kuin vastaus silloin, kun sovellusta suoritetaan pilvityönkulussa ja se odottaa vastausta.

  • Sovelluksen on pystyttävä yrittämään toiminnon suorittamista uudelleen, jos se määrittää, että virhe on todennäköisesti tilapäinen.

  • Sovelluksen on käytettävä uudelleenyrityksissä soveltuvaa strategiaa. Strategia määrittää, miten monta kertaa sovellus voi yrittää toimintoa uudelleen, kunkin yrityksen välisen viiveen ja toiminnot, jotka suoritetaan epäonnistuneen yrityksen jälkeen. Yritysten ja niiden välillä olevien viiveiden sopiva määrä on usein vaikea määrittää. Strategia vaihtelee resurssin tyypin sekä resurssin ja sovelluksen nykyisten toimintoehtojen mukaan.

Yleiset ohjeet

Seuraavien ohjeiden avulla voit suunnitella sovelluksille sopivat tilapäisten virheiden käsittelymenettelyt.

Määritetään, onko olemassa valmis uudelleenyritysmenetelmä

Jotkin palvelut, joihin muodostat yhteyden, saattavat jo sisältää tilapäisen vian käsittelymekanismin. Käytettävä uudelleenyrityskäytäntö on yleensä räätälöity kohdepalvelun ominaisuuksien ja vaatimusten mukaan. Vaihtoehtoisesti palveluiden REST-rajapinnat voivat palauttaa tietoja, joiden avulla voit selvittää, onko uudelleenyritys tarkoituksenmukainen ja miten kauan on odotettava ennen seuraavaa uudelleenyritystä.

Käytä valmista uudelleenyritysmenetelmää, kun sellainen on käytettävissä. Joskus määritetyt, hyvin tunnetut vaatimukset tekevät erilaisesta uudelleenyritystoiminnasta parhaan vaihtoehdon.

Määritetään, soveltuuko toiminto uudelleenyritykseen

Suorita uudelleenyritystoiminnot vain, jos viat ovat tilapäisiä (yleensä virheen luonne osoittaa tämän) ja kun toiminnon uudelleenyrityksen yhteydessä onnistumiselle on ainakin pieni todennäköisyys. Toimintoja, joiden yritys tapahtuu virheellisessä toiminnossa, ei kannata yrittää suorittaa uudelleen. Esimerkkejä ovat rivin päivittäminen Microsoft Dataversessä, jota ei ole olemassa, toiminto, jonka käyttöoikeuksia käyttäjällä ei ole ja sellaisen ohjelmointirajapinnan päätepisteen kutsuminen, jota ei ole olemassa.

Ota käyttöön uudelleenyritykset vain, jos voit määrittää suorittamisen kaikki vaikutukset ja jos ehdot ovat hyvin tunnetut ja ne voidaan tarkistaa. Muista, että hallintasi ulkopuolella olevista resursseista ja palveluista palautetut virheet voivat kehittyä ajan kuluessa, ja tilapäisen virheen tunnistuslogiikka on ehkä tarkistettava.

Kun kehitetään yksittäisiä osia tai palveluita, joita kutsutaan sovelluksista, varmista, että virhekoodit ja sanomat palautetaan. Tämä auttaa asiakkaita määrittämään, onko epäonnistuneiden toimintojen suorittamista yritettävä uudelleen. Voi olla tarpeen osoittaa, tuleeko asiakkaan yrittää toimintoa uudelleen, esimerkiksi palauttamalla isTransient-arvo. Jos luot verkkopalvelun, palvelusopimuksissa määritetyt mukautetut virheet kannattaa palauttaa.

Sopivan uudelleenyritysten määrän ja toistumisvälin määrittäminen

Optimoi uudelleenyritysten määrä ja toistumisväli käyttötapauksen tyypin mukaan. Jos uudelleenyrityksiä ei tehdä riittävän montaa, sovellus ei voi suorittaa toimintoa loppuun, ja se todennäköisesti epäonnistuu. Jos uudelleenyrityksiä on liian monta tai ne tehdään liian lyhyillä toistumisväleillä, sovellus voi pidättää resursseja pitkään. Tämä vaikuttaa sovelluksen tilaan haitallisesti.

Muuta aikavälin ja uudelleenyritysten määrän arvoja toimintotyypin mukaan. Jos esimerkiksi toiminto on osa käyttöliittymää, toistumisväli määritetään lyhyeksi ja uudelleenyritysten määrä pieneksi. Näin käyttäjien ei tarvitse odottaa vastausta. Jos toiminto on sellaisen pitkäkestoisen tai tärkeän työnkulun osa, jossa prosessin peruuttaminen ja käynnistäminen uudelleen on kallista tai aikaavievää, yritysten välinen aika on hyvä pitää melko pitkänä ja yritysten määrä suurena.

Muista, että sopivien toistovälien määrittäminen uuudelleenyrityksille on vaikein osa onnistuneen strategian suunnittelemisessa. Yleensä strategioissa käytetään seuraavia uudelleenyritysten toistovälejä:

  • Eksponentiaalinen aikaväli. Sovellus odottaa vähän aikaa ennen ensimmäistä uudelleenyritystä. Tämän jälkeen aikaa kasvatetaan eksponentiaalisesti kunkin uudelleenyrityksen jälkeen. Toiminto voi esimerkiksi yrittää toiminnon suorittamista 3 sekunnin, 12 sekunnin ja 30 sekunnin kuluttua.

  • Kiinteät aikavälit. Sovellus odottaa kunkin yrityksen jälkeen yhtä kauan.

  • Yritä heti uudelleen. Joskus tilapäinen virhe on lyhyt. Tällöin toiminnon suorittamisen yrittäminen välittömästi on hyvä keino, sillä virhe on ehkä korjaantunut ennen kuin sovellus lähettää seuraavan pyynnön. Välittömiä uudelleenyrityksiä ei kuitenkaan saa yhtä enempää. Jos välitön uudelleenyritys epäonnistuu, siirry vaihtoehtoisiin strategioihin, kuten eksponentiaalinen toistoväli ja varatoiminnot.

Yleisesti ottaen eksponentiaalisen toistovälin strategiaa kannattaa käyttää taustatoiminnoissa ja välittömän sekä kiinteän toistovälin uudelleenyritysstrategioita vuorovaikutteisissa toiminnoissa. Molemmissa tapauksissa on valittava viiveen ja uudelleenyritysten määrä, jotta kaikkien uudelleenyritysten enimmäisviive täyttää kokonaisvaltaisen viiveen vaatimukset.

Voit halutessasi käyttää kaikkien niiden tekijöiden yhdistelmää, jotka vaikuttavat uudelleenyritetyn toiminnon yleiseen enimmäisaikakatkaisuun. Näitä tekijöitä ovat aika, jonka epäonnistunut yhteys tarvitsee vastauksen saamiseen, uudelleenyritysten välinen aika ja uudelleenyritysten enimmäismäärä. Näiden aikojen kokonaismäärä voi johtaa pitkiin yleisiin toimintoaikoihin erityisesti silloin, kun käytetään eksponentiaalisen viiveen strategiaa, jossa yritysten välinen toistoväli kasvaa nopeasti jokaisen virheen jälkeen. Jos prosessin on vastattava tiettyä palvelutasosopimusta, yleisen toimintoajan, mukaan lukien kaikki aikakatkaisut ja viiveet, on oltava palvelutasosopimuksen määrittämien rajojen sisällä.

Älä ota käyttöön liian aggressiivisia uudelleenyritysstrategioita. Näiden strategioiden toistovälit ovat liian lyhyitä tai uudelleenyrityksiä on liian usein. Ne voivat vaikuttaa haitallisesti kohderesurssiin tai -palveluun. Nämä strategiat voivat estää resurssia tai palvelua palautumasta ylikuormitustilasta, jolloin se jatkaa pyyntöjen estämistä tai hylkäämistä. Tämä skenaario johtaa noidankehään, jossa resurssille tai palvelulle lähetetään yhä useampia pyyntöjä. Tämän vuoksi järjestelmän kyky palautua pienenee entisestään.

Toimintojen aikakatkaisua kannattaa harkita otettavaksi käyttöön silloin, kun valitset uudelleenyritysten toistovälejä välttääksesi seuraavan yrityksen käynnistämisen välittömästi (jos esimerkiksi aikakatkaisun jakso on samanlainen kuin uudelleenyritysten toistoväli).

Voit optimoida uudelleenyritysten määrän ja niiden välisen toistovälin käyttämällä palvelun lähettämien virhekoodien ja viestien virhetyyppiä. Esimerkiksi jotkin poikkeukset ja virhekoodit (kuten HTTP-koodi 503, Palvelu ei ole käytettävissä ja uudelleenyritys -otsikko vastauksessa) voi osoittaa, miten kauan virhe kestää, tai että palvelu epäonnistui, eikä vastaa seuraaviin yrityksiin.

Toimimattomien mallien välttäminen

Yleensä kannattaa välttää käyttöönottoja, jotka sisältävät kaksi samaa uudelleenyrityskoodin tasoa. Vältä suunnitelmia, jotka sisältävät limittäisiä uudelleenyritysmenetelmiä ja jotka ottavat käyttöön uudelleenyrityksen pyyntöhierarkian sisältävän toiminnon jokaisella tasolla, ellei tällaisen suunnitelman käyttämiselle ole erityisiä vaatimuksia. Näissä poikkeustilanteissa voit käyttää käytäntöjä, jotka estävät suuren uudelleenyritysten ja viivekausien määrän. Varmista, että ymmärrät seuraukset. Oletetaan esimerkiksi, että yksi osa tekee pyynnön toiselle, joka puolestaan käyttää kohdepalvelua. Jos otetaan käyttöön uudelleenyritys kolme kertaa molemmissa kutsuissa, palvelun uudelleenyritysten kokonaismäärä on yhdeksän. Useat palvelut ja resurssit ottavat käyttöön valmiin uudelleenyritysmenetelmän. Tutki, miten voit poistaa käytöstä menetelmän tai muuttaa sitä siltä varalta, että uudelleenyritykset on otettava käyttöön korkeammalla tasolla.

Älä koskaan ota käyttöön päättymätöntä uudelleenyritysmenetelmää. Tällöin on todennäköistä, että resurssia tai palvelua estetään palautumasta ylikuormitustilanteista, ja tämä aiheuttaa rajoittamista ja yhteyksien hylkäämistä normaalia kauemmin.

Älä koskaan suorita välitöntä uudelleenyritystä useammin kuin kerran.

Vältä kiinteän uudelleenyritysten toistovälin käyttämistä, kun käytetään Azuren palveluita ja resursseja. Näin erityisesti silloin, kun uudelleenyrityksiä on suuri määrä. Paras tapa tässä skenaariossa on eksponentiaalisen toistovälin strategia.

Uudelleenyritysstrategian testaaminen ja ottaminen käyttöön

Testaa uudelleenyritysstrategia täysin mahdollisimman suuressa määrässä tilanteita erityisesti silloin, kun sen käyttämissä sovelluksissa ja kohderesursseissa tai -palveluissa on suuri kuormitus. Voit tarkistaa toiminnan testauksen aikana seuraavalla tavalla:

  • Injektoi tilapäisiä ja muita kuin tilapäisiä vikoja palveluun. Voit esimerkiksi lähettää virheellisiä pyyntöjä tai lisätä koodia, joka tunnistaa testipyynnöt ja reagoi erityyppisiin virheisiin.

  • Luo malli resurssista tai palvelusta, joka palauttaa todellisen palvelun palauttamien virheiden alueen. Kattaa kaikki virhetyypit, jotka uudelleenyritysstrategia on suunniteltu tunnistamaan.

  • Pakota luoduille ja käyttöönotetuille mukautetuille palveluille tilapäiset virheet poistamalla palvelu käytöstä tai ylikuormittamalla se väliaikaisesti. (Älä yritä ylikuormittaa jaettuja resursseja tai palveluita Azuressa.)

  • Kun asiakkaan verkkosovelluksen vikasietoisuutta testataan tilapäisten virheiden varalta, käytä selaimen kehittäjätyökaluja tai testauksen kehyksen ominaisuutta jäljitellä tai estää verkkopyyntöjä.

  • Suorita suuren kuormituksen tekijä ja samanaikaiset testit varmistaaksesi, että uudelleenyritysmenetelmä ja -strategia toimivat oikein näissä olosuhteissa. Näiden testien avulla voidaan myös varmistaa, että uudelleenyritys ei vaikuta haitallisesti asiakkaan toimintoihin eivätkä pyynnöt vaikuta toisiinsa haitallisesti.

Uudelleenyrityskäytännön määritysten hallinta

Uudelleenyrityskäytäntö on strategian kaikkien elementtien yhdistelmä. Se määrittää tunnistusmenetelmän, joka määrittää, onko virhe todennäköisimmin tilapäinen, käytettävän toistovälin tyypin (esimerkiksi kiinteä tai eksponentiaalinen), toteutuneen toistovälin arvot ja uudelleenyritysten määrän.

Hyödynnä valmista uudelleenyritysstrategiaa tai oletusyritysstrategiaa, mutta vain silloin, kun ne sopivat skenaarioon. Nämä strategiat ovat yleensä geneerisiä. Joissakin skenaarioissa ei ehkä tarvita muuta, mutta on skenaarioita, joissa nämä strategiat eivät tarjoa kaikkia vaihtoehtoja, joita erityiset vaatimukset edellyttävät. Jos haluat määrittää sopivimmat arvot, suorita testaus määrittääksesi, miten asetukset vaikuttavat sovellukseen.

Tilapäisten ja muiden kuin tilapäisten virheiden lokiinkirjaus ja seuranta

Uudelleenyritysstrategian osana voit sisällyttää poikkeusten käsittelyn ja muun instrumentoinnin, jotka kirjaavat uudelleenyritykset lokiin. Satunnainen tilapäinen virhe ja uudelleenyritys ovat odotettuja, eivätkä tarkoita ongelmaa. Säännölliset ja yhä useammin toistuvat uudelleenyritykset sen sijaan usein tarkoittavat ongelmaa, joka saattaa aiheuttaa virheen tai joka heikentää sovelluksen suorituskykyä ja käytettävyyttä.

Kirjaa tilapäiset virheet lokiin varoitusmerkintöinä virhemerkintöjen sijaan, jotta valvontajärjestelmät eivät tunnista niitä sovellusvirheiksi, jotka saattavat käynnistää virheellisiä hälytyksiä.

Voit tallentaa lokimerkintöihin arvon, joka ilmaisee, johtuuko uudelleenyritykset palvelun rajoittamisesta vai muista virhetyypeistä, kuten yhteysvirheistä. Tämän jälkeen voit erotella ne tietojen analyysin aikana. Rajoittamisvirheiden määrän lisääntyminen kertoo usein siitä, että sovelluksessa on suunnitteluvirhe tai Premium-kapasiteettia on lisättävä ympäristössä.

Kannattaa ehkä ottaa käyttöön telemetria- tai valvontajärjestelmä, joka voi käynnistää hälytyksiä, kun virheiden määrä, uudelleenyritysten keskimääräinen määrä tai käytetty aika yleisesti ennen toimintojen onnistumista kasvaa.

Jatkuvasti epäonnistuvien toimintojen hallinta

Päätä, miten jokaisen yrityksen yhteydessä epäonnistuvia toimintoja käsitellään. Tällaiset tilanteet ovat väistämättömiä.

Vaikka uudelleenyritysstrategia määrittää toiminnon uudelleenyritysten enimmäismäärän, se ei estä sovellusta toistamasta toimintoa saman uudelleenyritysten määrän kanssa. Esimerkiksi lomakkeen lähettäminen sovelluksessa voi käynnistää työnkulun. Uudelleenyritysstrategia voi tunnistaa yhteyden aikakatkaisun ja pitää sitä tilapäisenä virheenä. Työnkulku yrittää toiminnon suorittamista uudelleen määritettyjen yrityskertojen verran ja lopettaa sitten. Mutta jos sama käyttäjä tai uusi käyttäjä yrittää lähettää lomakkeen uudelleen, toimintoa yritetään taas, vaikka se epäonnistuu yhä.

Sovellus voi testata palvelun säännöllisesti tai ajoittain käyttämällä pitkiä toistovälejä pyyntöjen välillä tunnistaakseen, milloin se on taas käytettävissä. Sopiva toistoväli riippuu esimerkiksi toiminnon tärkeysasteesta ja palvelun luonteesta. Se voi olla mikä tahansa arvo muutaman minuutin ja usean tunnin väliltä. Kun testi onnistuu, sovellus voi jatkaa normaaleja toimintoja ja siirtää pyynnöt juuri palautetulle palvelulle.

Sillä välin voit ehkä suorittaa vaihtoehtoisia toimintoja ja odottaa, että palvelu on taas pian käytettävissä. Voit esimerkiksi tallentaa palvelun pyynnöt jonoon tai tietosäilöön ja yrittää suorittaa ne myöhemmin. Tai vaihtoehtoisesti käyttäjälle on palautettava sanoma, jossa kerrotaan, että sovellus ei ole käytettävissä.

Muita huomioitavia seikkoja

Kun käytännön uudelleenyritysten määrän ja uudelleenyritysten toistovälien arvot päätetään, tarkista, onko palvelun tai resurssin toiminto osa pitkään suoritettavaa tai monivaiheista toimintoa. Toiminnon jo onnistuneiden vaiheiden kompensoiminen voi olla vaikeaa tai kallista, jos yksi toiminnon vaihe epäonnistuu. Tällöin pitkän toistovälin ja useiden uudelleenyritysten käyttäminen voi olla hyväksyttävää, jos strategia ei estä muita toimintoja estämällä tai lukitsemalla niukkoja resursseja.

Päätä, voiko saman toiminnon yrittäminen uudelleen aiheuttaa tiedoissa epäyhtenäisyyksiä. Jos jotkin monivaiheisen prosessin osat toistetaan ja toiminnot eivät ole ainutkertaisia, epäyhtenäisyyksiä voi esiintyä. Jos esimerkiksi toistetaan toiminto, joka lisää tietueen Microsoft Dataverseen, taulukkoon voi tulla virheellisiä arvoja. Jos toistetaan toiminto, joka lähettää ilmoituksen käyttäjälle, he saattavat vastaanottaa kaksi samaa viestiä.

Päätä niiden toimintojen laajuus, joita on yritetty suorittaa uudelleen. Esimerkiksi uudelleenyrityskoodin käyttöönotto voi olla helpompaa tasolla, joka käsittää useita toimintoja. Tällöin uudelleenyritys koskee kaikkia toimintoja, jos yksi niistä epäonnistuu. Tämä voi kuitenkin aiheuttaa idempotenssiongelmia tai tarpeettomia palautustoimintoja.

Jos valitset uudelleenyrityslaajuuden, joka käsittää useita toimintoja, ota huomioon kaikkien niiden kokonaisviive määrittäessäsi uudelleenyritysten toistovälejä, kun valvot toimintoon kulunutta aikaa ja ennen kuin käynnistät hälytyksiä virheistä.

Power Platform – avustaminen

Seuraavissa osissa kerrotaan menetelmistä, joiden avulla tilapäisiä virheitä voi hallita.

Power Automate

Power Automate sisältää ominaisuuden, joka yrittää suorittaa toiminnon uudelleen, jos se epäonnistuu. Määritä tämä toimintotasolla. Lue lisää riskien vähentämisestä ja virheiden käsittelyn suunnittelusta Power Automate projektissa. Power Automate sisältää myös toimintoja, joilla voi palauttaa mukautettuja virheitä ja tietoja kutsun tehneeseen sovellukseen tai työnkulkuun.

Jotkin tilapäiset työnkulut voivat johtua siirtomäärä- ja pyyntörajoituksista. Lisätietoja automaattisten, ajoitettujen ja välittömien työnkulkujen rajoituksista ja pyyntöjen rajoituksista ja kohdistuksista.

Määritä virheiden ja poikkeusten käsittely pilvityönkuluissa vaikutusalueiden ja suoritusasetusten avulla.

Power Apps

Power Appsin pohjaan perustuvat sovellukset sisältävät ominaisuuden, jolla on mahdollista tarkistaa yhteyden tila. Toiminta voi olla erilaista, jos sovellus on offline-tilassa. Opi kehittämään offline-yhteensopivia pohjaan perustuvia sovelluksia.

Voit myös käyttää Error-, IfError-, IsError- ja IsBlankOrError-funktioita pohjaan perustuvissa sovelluksissa, jos haluat määrittää, mitä virheen jälkeen tehdään.

Lisätietoja tilapäisen virheen käsittelemisestä Power Appsissa on seuraavissa kohdissa:

Azure ja mukautetut yhdistimet

Jos työmäärä yhdistetään Azure-palveluihin, katso, miten tilapäisiä virheitä käsitellään Azure Well-Architected Frameworkin avulla.

Voit hallita mukautettujen yhdistinten vastauksia virheisiin noudattamalla koodauksen standardeja.

Application Insights

Käytä Application Insights -integrointeja virheiden kirjaamiseksi lokiin Power Automatessa ja Power Appsissa seuraavasti:

Liiketoiminnan jatkuvuus ja järjestelmäpalautus Dynamics 365 SaaS-sovelluksille

Luotettavuuden tarkistusluettelo

Katso lisätietoja suositusten kokoelmasta.

Luotettavuuden tarkistuslista