Luotettavuuden testausstrategian suunnittelusuositukset
Koskee tätä Power Platform Well-Architected -ratkaisun luotettavuuden tarkistusluetteloa koskevaa suositusta:
| RE:06 | Vikasietoisuus- ja käytettävyysskenaarioiden testi käyttämällä kaaostekniikan periaatteita testi- ja tuotantoympäristöissä. Käytä testausta varmistaaksesi, että hallitut heikentämisen täytäntöönpanostrategiat ovat tehokkaita, aktiivisten virheiden ja simuloitujen kuormien testauksen avulla. |
|---|
Tässä oppaassa käsitellään työkuorman luotettavuuden tarkistamiseen ja optimointiin tarkoitetun luotettavuuden testausstrategian suunnittelusuosituksia. Luotettavuustestaus keskittyy työkuorman vikasietoisuuteen ja käytettävyyteen etenkin ratkaisua suunniteltaessa määritettävissä tärkeissä työnkuluissa. Tässä oppaassa on yleiset testausohjeet sekä vikojen lisäämistä ja kaaostekniikkaa koskevat yleiset ohjeet.
Määritelmät
| Termi | Määritelmä |
|---|---|
| Saatavuus | Aika, jonka sovelluksen työkuorman suorituksen tila on hyvä ilman merkittäviä käyttökatkoksia. |
| Kaaostekniikka | Käytäntö, jossa sovelluksen ja palveluihin kohdistetaan reaalimaailman rasituksia ja vikoja. Kaaostekniikan tarkoituksena on muodostaa ja tarkistaa vikasietoisuus epäluotettavia ehtoja ja puuttuvia riippuvuuksia varten. |
| Vian lisääminen | Järjestelmän vikasietoisuuden testaaminen lisäämällä järjestelmään virhe. |
| Palautuvuus | Tarkoittaa samaa kuin vikasietoisuus |
| Vikasietoisuus | Sovelluksen työkuorman kyky kestää vikatiloja ja palautua niistä. |
Tärkeimmät suunnittelustrategiat
Testaus on välttämätöntä, sillä sen avulla voidaan varmistaa, että työkuorma vastaa luotettavuustavoitteita ja voi käsitellä viat hallitusti. Vian lisääminen testaustyyppi, jossa järjestelmää lisätään tietoisesti vikoja tai rasitteita reaalimaailman skenaarioita simuloiden. Vian lisäämisen ja kaaostekniikan avulla voidaan ennakoivasti löytää ja korjata ongelmat, ennen kuin ne vaikuttavat tuotantoympäristöön. Tässä osassa on yleisiä työkuorman testausta, vian lisäämistä ja kaaostekniikkaa koskevia ohjeita.
Yleiset testausohjeet
Rutiininomaisesti suoritetulla testauksella voidaan tarkistaa nykyiset raja-arvot, tavoitteet ja oletukset. Tavallinen testaus suoritetaan, kun työkuormassa tapahtuu merkittävä muutos. Suurin osa testauksesta tehdään testaus- ja valmisteluympäristöissä. Testien alajoukko kannattaa suorittaa myös tuotantojärjestelmässä.
Testauksen automatisointi auttaa varmistamaan, että testauksen kattavuus ja toistettavuus on yhdenmukaista. Yleiset testaustehtävät kannattaa automatisoida ja integroida muodostusprosesseihin. Vaikka ohjelmiston manuaalinen testaus on pitkäveteistä ja virhealtista, manuaalisesti voidaan tehdä tutkivaa testausta. Jos tapauksiin on kehitettävä automaattinen testaus, manuaalisen testauksen avulla voidaan määrittää kehitettävien testien laajuus.
Varhaisen vaiheen testaus kannattaa ottaa käyttöön, ja silloin vikasieto- ja käytettävyystestaus tehdään kehitysjakson varhaisessa vaiheessa.
Dokumentointimuodon kannattaa olla yksinkertainen, jolloin kenen tahansa on helppo ymmärtää prosessi ja kunkin tavallisen testin tulokset.
Dokumentoidut tulokset kannattaa jakaa soveltuvien tiimien, kuten toiminnallisen tiimin, teknologian johtoryhmän sekä liiketoiminnan ja järjestelmäpalautuksen sidosryhmien kanssa. Tuloksissa on oltava tietoja luotettavuustavoitteiden tarkentamisesta, kun palvelutasotavoitteista (SLO), palvelutasosopimuksista (SLA), palautusaikatavoitteista (RTO) ja palautuskohtatavoitteista (RPO).
Varmuuskopioille kannattaa luoda säännölliset testausvälit. Tietojen palauttaminen eristettyihin ympäristöihin auttaa varmistamaan, että varmuuskopiot ovat kelvollisia ja että palautukset toimivat.
Palautusaikamittarit kannattaa dokumentoida ja jakaa järjestelmäpalautuksen sidosryhmien kanssa. Näin varmistetaan, että palautusta koskevat odotukset ovat asianmukaisia.
Toimialakohtaisten käyttöönoton vakiotestausmenettelyjen käyttäminen auttaa varmistamaan, käyttöönottoprosessi on automatisoitu, ennustettava ja tehokas.
Työkuorman kyky sietää tilapäisiä vikoja on testattava. Lisätietoja on kohdassa Tilapäisiä vikoja koskevat käsittelysuositukset.
Työkuorman tapa käsitellä vikoja riippuvaisissa palveluissa tai muissa riippuvuuksissa testataan käyttämällä vian lisäämistä.
Järjestelmäpalautussuunnitelman vakavia virheitä ja muita vakavia tapauksia koskevan reagoinnin testaaminen.
Työkuorma kykyä heikentyä hallitusti ja minimoida komponentin toimintahäiriön vaikutusalue testataan käyttämällä vian lisäämistä.
Suunniteltujen ja odottamattomien käyttökatkosten hyödyntäminen
Kun työkuorma on offline-tilassa suunnitellun ylläpidon tai odottamattoman käyttökatkoksen vuoksi, kyse on ainutlaatuisesta mahdollisuudesta testaukseen ja ymmärryksen parantamiseen työkuormasta. Seuraavissa osissa on kumpaakin skenaariota koskevia suosituksia.
Suunniteltu huoltokatko
Kun päivityksiä tai korjaustiedostoja varten on varattu suunniteltu ylläpitoaika, komponentteja ja työnkulkuja, joita ylläpitotyö ei koske, voidaan testata. Testit voidaan suorittaa ilman riskiä siitä, että työkuorma heikentyisi odottamatta tai että se jouduttaisiin siirtämään kokonaan offline-tilaan. Jos ylläpito kestää riittävän kauan, myös niitä komponentteja ja työkulkuja, joita ylläpito koskee, voidaan testata ylläpitotyön valmistuttua.
Odottamaton käyttökatkos
Jokaista käyttökatkostapausta kannattaa käyttää mahdollisuutena oppia lisää työkuormasta ja parantaa sen vikasietoisuutta seuraavien, tärkeysjärjestykseen asetettujen ohjeiden avulla:
Työkuorman saaminen takaisin käyttäjien käytettäväksi. Ongelma on ehkä ratkaistava kiertämällä se, ratkaisemalla se kokonaan tai käynnistämällä palautusprosessit.
Käyttökatkoksen juurisyy on selvitettävä ja käsiteltävä. Jos juurisyy voidaan korjata tutkimuksen osana, juurisyy ja sen korjaamiseen käytetyt keinot on dokumentoitava. Jos ongelma vaatii toisen ylläpitoikkunan käyttöä myöhemmin, varmista, että lievennysmittarit voivat käsitellä odotetun kuormituksen perusteellisen testauksen avulla. On varmistettava, että korjaustoimien seuranta on riittävää.
Tarvittaessa on etsittävä samaa ongelmaa tai määrityksen heikkouksia, joissa voi olla samankaltaisia ongelmia, kaikista työkuorman komponenteista. Tätä mahdollisuutta kannattaa käyttää kyseisten komponenttien korjaamiseen ennakoivasti. Tapaushistoriaan tutustumalla voidaan etsiä samankaltaisia ongelmia koskevia malleja koko työkuormasta.
Löydösten avulla voidaan parantaa testausstrategiaa. Juurisyyn ja samankaltaisten ongelmien korjaamisen onnistuminen on varmistettava testaamalla suoraa samaa vikaa.
Vian lisäämistä ja kaaostekniikkaa koskevat ohjeet
Vian lisäämistestauksessa noudatetaan kaaostekniikan periaatteita, sillä siinä korostuu työkuorman kysy reagoida komponenttivikoihin. Vian lisäystä käyttävät testaus tehdään esituotanto- ja tuotantoympäristöissä. Vikatila-analyysista saatuja tietoja käyttämällä voidaan varmistaa, että vian priorisoidut viat testataan ja että käytössä on viat korjaavia korjausstrategioita.
Kaaostekniikan tärkeimmät ohjeet:
Ennakoiva toiminta. Vikojen esiintymistä ei jäädä odottamaan. Vikoja yritetään ennakoida etsimällä ja korjaamalla kaaoskokeiden avulla ongelmat, ennen kuin ne vaikuttavat tuotantoympäristöön.
Vika on hyvä asia. Järjestelmässä esiintyvät viat ovat hyväksyttäviä, sillä niistä voi oppia. Vikoja kannattaa pitää monimutkaisten järjestelmien luonnollisena osana. Niitä kannattaa käyttää mahdollisuutena oppia ja parantaa järjestelmän luotettavuutta.
Järjestelmän rikkominen. Järjestelmän vikasietoisuutta testataan lisäämällä siihen tarkoituksellisesti vikoja tai rasitteita. Reaalimaailman vikoja tai häiriöitä simuloimalla voidaan testata ja parantaa työkuorman palautusominaisuuksia.
Suojauksen muodostaminen. Kaaostekniikan kokeilujen avulla voidaan parantaa työkuorman kykyä estää viat ja palautua niistä.
Kaaostekniikka on keskeinen osa työkuorman tiimikulttuuria ja jatkuva käytäntö eikä lyhytaikainen taktinen toimi vastauksena yksittäiseen käyttökatkokseen. Kaaoskokeilujen suunnittelussa käytetään seuraavaa vakiomenetelmää:
Lähtökohtana on hypoteesi. Kullakin kokeilulla on oltava selkeä tavoite, kuten sen testaaminen, selviääkö työnkulku tietyn komponentin menetyksestä.
Perustoimintatason mittaaminen. On varmistettava, että käytettävissä yhdenmukaiset luotettavuus- ja suorituskykymittarit kokeiluun sisältyvää työnkulkua ja komponentteja varten, jota kokeilun aikaisen heikentyneen tilan vertaaminen on mahdollista.
Vian tai vikojen lisääminen. Kokeen kohteena on oltava tietyt nopeasti palautettavat komponentit. Lisäksi on oltava realistinen käsitys siitä, mikä vaikutus vian lisäämisellä on, sillä se auttaa hallitsemaan kokeilun vaikutusaluetta.
Tuloksena olevan toiminnan seuranta. Kokeilun kohteena olevan yksittäisen työnkulun komponenttien ja koko työnkulun toiminnan telemetrian kerääminen auttaa ymmärtämään tarkasti vian vaikutukset. Vertaamalla kerättyjä mittausarvoja perustason mittauksiin saadaan kokonaiskuva vian lisäämisen tuloksista.
Prosessin ja havaintojen dokumentointi. Tarkkojen muistiinpanojen kirjoittaminen kokeiluista auttaa tulevissa työnkulun rakenteita koskevissa päätöksissä. Tällä tavoin varmistetaan, että ajan mittaan esiin tulleet puutteet korjataan.
Tuloksen määrittäminen ja sen perusteella toimiminen. Työkuorman keskeneräisiin töihin parannuksina lisättävien korjausvaiheiden suunnitteleminen. On varmistettava, että rakenteen parannussuunnitelmat tarkistetaan ja testataan ei-tuotantoympäristöissä käyttämällä samoja prosesseja kuin muissa käyttöönotoissa.
Prosessi, arkkitehtuurin valinnat ja koodi kannattaa tarkistaa säännöllisesti, sillä näin voidaan nopeasti havaita tekniset puutteet, integroida uudet teknologia ja mukautua muuttuviin tarpeisiin.
Vian lisäävissä kokeiluissa
vahvistetaan, että seuranta on käytössä ja ilmoitukset määritetty
tapauksen omistus varmistetaan tarkistamalla suoran vastuuhenkilön määritysprosessi
varmistetaan, että dokumentointi- ja tutkimisprosessit ovat ajan tasalla.
Kaaostekniikkastrategia optimoidaan integroimalla seuraavat suositukset ja huomioon otettavat seikat:
Järjestelmän oletusten haastaminen. Testauksen avulla yritetään parantaa työkuorman vikasietoisuutta ja suunnittelustrategioita. Niinpä onkin etsittävä mahdollisuuksia lisätä vikoja komponentteihin ja työnkulkuihin, joiden odotetaan olevan aiemman kokemusten perusteella luotettavia. Ne eivät ehkä olekaan luotettavia uudessa työkuormassa.
Muutoksen tarkistaminen. Ilman kattavaa, mukaan lukien vian lisäävää testausta käsityksen muutosten jälkeisestä työkuormasta voi olla vaillinainen. On erimerkiksi mahdollista, että työkuormaan tulee uusia riippuvuuksia, jotka eivät ole heti ilmeisiä.
SLA-puskureiden käyttäminen. Kaaostestaus on rajoitettava tapahtumaa palvelutasosopimusten puitteessa, jolloin vältetään käyttökatkoksista aiheutuvat mahdolliset haittavaikutukset. Työnkulun ja komponentin palautustavoitteista on hyötyä testauksen laajuuden määrittämisessä.
Virhebudjetti kannattaa muodostaa sijoituksena kaaostekniikkaan ja vian lisäämiseen. Virhebudjetti on sadan prosentin SLO:n ja sovitun SLO:n saavuttamisen välinen ero.
Kokeilu on lopetettava, jos tämä laajuus ylittyy. Tuntemattomat tulokset ovat kaaostestauksen odotettu tulos. Tavoitteena on löytää tasapaino merkittävän tulostietomäärän keräämisen ja mahdollisimman harvaan tuotantoympäristön käyttäjään vaikuttamisen välillä.
Tiivis yhteistyö kehitystiimien kanssa varmistaa, että sopivia vikoja lisätään. Aiempia tapauksia ja ongelmia voi käyttää apuna. Riippuvuuksien tarkasteleminen sekä kyseisten riippuvuuksien poistamisen tulosten arvioiminen.
Työkuorman kaaostestauksen aikana paljastuneiden komponenttien välisten aiemmin havaitsemattomien riippuvuuksien tunnistaminen ja dokumentointi.
Palautussuunnitelmien muuttaminen tarpeen mukaan kaaostestauksen aikana löydettyjen riippuvuuksien perusteella.
Kokeilujen ja testien tulosten käyttäminen uusien kokeilujen ja testien perustana. Odottamattomien toimintojen noustessa esiin uudet testit voivat koskea suoraan kyseisä toimintoja, mikä antaa mahdollisuuden suunnitella niitä koskevia korjausstrategioita.
Kompromissi: Tuotannossa testaaminen virheen lisäämisen avulla voi häiritä toimintaa ja mahdollisesti aiheuttaa käyttökatkon. Tästä mahdollisuudesta on ilmoitettava avoimesti sidosryhmille. Lisäksi on varmistettava, että käytössä on suojaukset kokeilujen päättämistä varten ja palautussuunnitelmat, joilla lisätyt viat voidaan peruuttaa nopeasti.
Power Platform – avustaminen
Power Automaten staattisten tulosten avulla voit palauttaa kiinteän tuloksen työmäärän testaamista varten.
Power Appsin testimoduuli (esiversio) on Power Platform CLI -komponentti, jolla voi testata erillisiä pohjaan perustuvia sovelluksia Power Appsissa.
Azuren testisuunnitelmat on helppokäyttöinen, selainpohjainen testien hallintaratkaisu. Se sisältää kaikki ominaisuudet, jotka tarvitaan manuaalisen testauksen, käyttäjän hyväksyntä testauksen, tutkivaan testaukseen ja sidosryhmien palautteen keräämisen suunnitteluun.
Jos työkuormassa on Azure-resursseja, Azure Chaos Studio on käytettävissä, Se on hallittu palvelu, joka käyttää kaaostekniikkaa pilvisovelluksen ja -palvelun vikasietoisuuden mittaamiseen, ymmärtämiseen ja parantamiseen.
Jos työmäärä sisältää Microsoft Copilot Studio -agentin, voit määrittää agentit ja testit Power CAT Copilot Studio Kit -ratkaisun avulla. Kun suoritetaan yksittäisiä testejä Copilot Studion ohjelmointirajapintojen avulla (Direct Line), agentin vastaukset arvioidaan odotettujen tulosten perusteella.
Luotettavuuden tarkistusluettelo
Katso lisätietoja suositusten kokoelmasta.