Käyttöönoton virheiden lievennysstrategian suunnittelemista koskevat suositukset
Koskee tätä Power Platform hyvin suunnitellun operatiivisen huippuosaamisen tarkistuslistan suositusta:
| OE:11 | Toteuta käyttöönoton lievennysstrategia, jonka avulla käyttöönoton aikana tapahtuvat odottamattomat virheet voidaan palauttaa nopeasti. Yhdistele useita lähestymistapoja, kuten palautus, ominaisuuksien käytöstä poistaminen tai käyttöönottomallisi alkuperäisten ominaisuuksien käyttö. |
|---|
Tässä oppaassa kerrotaan käyttöönoton virheitä käsittelevän standardoidun strategian suunnittelua koskevat suositukset. Kuten muutkin kuormitusongelmat, käyttöönottovirheet ovat väistämätön osa työmäärän elinkaarta. Näin käyttöön saadaan ennakoivasti hyvin suunniteltu, tarkoituksellinen strategia käyttöönoton virheiden käsittelemiseksi. Tällaisen strategian avulla työmäärätiimisi voi tehokkaasti lieventää vikoja mahdollisimman pienellä vaikutuksella käyttäjiin.
Tällaisen suunnitelman puuttuminen voi johtaa kaoottiseen ja mahdollisesti ongelmia koskeviin haitallisiin vastauksiin, jotka voivat vaikuttaa merkittävästi ryhmän ja organisaation yhteistyöhön, asiakkaiden luottamukseen ja talouteen.
Tärkeimmät suunnittelustrategiat
Joskus käyttöönoton käytäntöjen kehittyneisyydestä huolimatta käyttöönotossa on ongelmia. Käyttöönoton turvallisten käytäntöjen ja luotettavan työmäärän toimitusketjun käyttäminen voi auttaa vähentämään epäonnistuneiden käyttöönottojen määrää. Sinun on myös suunniteltava standardoitu strategia epäonnistuneiden käyttöönottojen käsittelemiseksi, kun ne tapahtuvat.
Käyttöönoton epäonnistumisen lievennysstrategia koostuu seuraavista viidestä laajasta vaiheesta:
- Tunnistus: Jos haluat vastata epäonnistuneeseen käyttöönottoon, sinun on ensin havaittava virhe. Havaitseminen voi tapahtua useilla tavoilla, kuten epäonnistuneilla savutesteillä, käyttäjäraporteilla tai valvonta-alustan luomilla hälytyksillä.
- Päätös: Sinun on päätettävä, mikä on paras lieventämisstrategia tietylle vikatyypille.
- Lieventäminen: Sinun on suoritettava tunnistettu lieventämistoiminto. Lievennystoiminto voivat olla varatoiminto, edellisen version palautus tai version käyttöönoton lykkääminen.
- Viestintä: Sidosryhmille ja käyttäjille, joita ongelma koskee, on kerrottava tilasta, kun havaitset ongelman ja selvität sen vastaus hätätilannesuunnitelmasi edellyttämällä tavalla.
- Postmortem: Moitteettomat kuolemanjälkeiset tutkimukset tarjoavat työmäärätiimille mahdollisuuksia tunnistaa parannuskohteita ja luoda suunnitelmia oppien soveltamiseksi.
Seuraavissa osissa kerrotaan näitä vaiheita koskevat eritellyt suositukset.
Tunnistus
Jotta käyttöönottoihin liittyvät ongelmat voidaan tunnistaa nopeasti, tarvitaan käyttöönottoihin liittyviä vankkoja testaus- ja valvontakäytäntöjä. Jotta poikkeamat voidaan havaita nopeasti, voit täydentää työmäärän seurantaa ja hälytyksiä käyttämällä sovelluksen suorituskyvyn hallintatyökalua ja kirjaamalla instrumentoinnin kautta.
Kuntotestaus ja muut laatutestaukset tulee tehdä käyttöönoton jokaisessa vaiheessa. Yhden käyttöönottoryhmän onnistuneiden testien ei tule vaikuttaa seuraavissa ryhmissä tehtävien testien päätöksiin.
Voit ottaa käyttöön telemetriaa, joka vastaa käyttäjien ongelmia käyttöönottovaiheessa. Tämän jälkeen voit nopeasti määrittää, mihin käyttöönottoryhmään tietty käyttäjä on liitetty. Tämä menettely on erityisen tärkeää etenevän julkistamisen käyttöönotoissa, koska niissä voidaan suorittaa useita määrityksiä käyttäjäpohjassa missä tahansa käyttöönoton vaiheessa.
Käyttäjän raportoimiin ongelmiin tulee voida vastata välittömästi. Ota käyttöönottovaihe käyttöön sopivana työaikana, kun koko tukiryhmä on paikalla. Varmista, että tukihenkilöstö on koulutettu eskaloimaan käyttöönotto-ongelmia oikean reitityksen varmistamiseksi. Eskalointien tulisi vastata työmäärän poikkeustilanteiden vastaussuunnitelmaa.
Päätös
Käyttöönotto-ongelman asianmukaisesta lieventämisstrategiasta päätettäessä otetaan huomioon muun muassa seuraavat tekijät:
Käytettävän etenevän julkistamisen mallin tyyppi. Voit käyttää esimerkiksi sinivihreää vihreää mallia tai pienissä osissa tehtävää mallia. Jos käytät sinivihreää mallia, varatoiminto on käytännöllisempi edelliseen versioon palautus. Voit helposti siirtää liikennettä takaisin pinoon, joka suorittaa päivittämättömän määrityksen. Tämän jälkeen voit korjata ongelman ympäristössä, jossa se esiintyy, ja yrittää käyttöönottoa uudelleen sopivalla hetkellä.
Menetelmät, joiden avulla voit ohittaa ongelman. Esimerkkejä näistä ovat ominaisuusmerkinnät, ympäristömuuttujat ja mikä tahansa muu suorituspalvelun määritysominaisuus, jonka voi ottaa käyttöön ja poistaa käytöstä. Joskus ongelman voi ohittaa helposti ottamalla poistamalla ominaisuusmerkinnän käytöstä tai vaihtamalla asetuksen arvoa. Tällöin voit ehkä
- jatkaa käyttöönottoa
- välttää varaskenaarion käyttämisen
- palata edelliseen versioon virheellisen koodin korjaamisen ajaksi.
Työmäärän taso, joka vaaditaan korjauksen käyttöönotossa koodissa. Jos koodin korjaaminen vaatii vain vähän työtä, hotfix-korjauksen käyttöönotto on oikea valinta tietyissä tilanteissa.
Muuttuneen työmäärän tärkeysasteen taso. Liiketoiminnan kannalta tärkeät työmäärät on aina otettava käyttöön rinnakkain, kuten sinivihreässä mallissa, jotta käyttöönotoissa ei ole käyttökatkoja. Tuloksena varasuunnitelman käyttäminen on ensisijainen lievennysstrategia tämän tyyppisissä työmäärissä.
Korjaavat toimet
Seuraavassa on joitakin yleisiä lievennysstrategioita:
Palautus: Palautusskenaariossa palauttaa päivitetyt järjestelmät viimeksi tunnetun hyvän kokoonpanon tilaan.
On tärkeää, että koko työmäärätiimi on samaa mieltä "viimeisen tunnetun hyvän" merkityksestä. Tämä lauseke viittaa kuormituksen viimeiseen tilaan, joka oli kunnossa ennen käyttöönoton aloittamista, mikä ei välttämättä ole aiempi sovellusversio.
Edelliseen versioon palautus voi olla monimutkaista, erityisesti kun siihen liittyy tietojen muutoksia. Rakennemuutokset voivat tehdä edelliseen versioon palautuksesta riskialtista. Niiden toteuttaminen turvallisesti voi edellyttää huomattavaa määrää suunnittelua. Yleinen suositus on, että rakennepäivitysten ovat lisääviä. Tietueita ei tule korvata uusilla tietueilla. Vanhojen tietueiden tulee sen sijaan vanhentua, ja ne tulee säilyttää uusien tietueiden kanssa niin kauan, kunnes niiden poistaminen on turvallista.
Varajärjestelmä: Varaskenaariossa päivitetyt järjestelmät poistetaan tuotantoliikenteen reitityksestä. Kaikki liikenne ohjataan pinoon, jota ei päivitetä. Tämän vähäriskisen strategian avulla voit ottaa koodiin liittyvät ongelmat käsiteltäväksi ilman lisähäiriöitä.
Pienissä osissa tehtävät käyttöönotot eivät ehkä ole suoraviivaisia tai edes mahdollisia riippuen infrastruktuurin ja sovelluksen rakenteesta. Jos on suoritetta skaalaus päivittämättömien järjestelmien kuormituksen käsittelemiseksi, suorita skaalaus ennen edelliseen versioon palaamista.
Ohita loukkaava funktio: Jos voit ohittaa ongelman käyttämällä ominaisuusmerkintöjä tai muun tyyppistä suorituksenaikaista määritysominaisuutta, saatat päättää, että käyttöönoton jatkaminen on oikea strategia ongelmaan.
Toiminnon ohittamisen seuraukset tulee tuntea, ja tästä on kerrottava sidosryhmien jäsenille. Sidosryhmien jäsenten on hyväksyttävä tämä Go forward -suunnitelma. Sidosryhmien jäsenten on määritettävä, miten kauan heikentyneessä tilassa voidaan toimia. Heidän on otettava huomioon tätä määritystä pohtiessaan myös virheellisen koodin korjaamiseen ja koodin käyttöönottoon tarvittava aika-arvio.
Hätäkäyttöönotto (hotfix): Jos pystyt korjaamaan ongelman käyttöönoton puolivälissä, hotfix-korjaus saattaa olla käytännöllisin lieventämisstrategia.
Kuten minkä tahansa muun koodin, hotfix-korjausten on käytävä läpi turvalliset käyttöönottokäytännöt. Mutta hotfix-korjauksen avulla aikataulu nopeutuu huomattavasti. Koodinedistämisstrategiaa on käytettävä kaikissa ympäristöissä. Sinun on myös tarkistettava hotfix-koodi kaikissa laatuporteissa. Voi kuitenkin olla tarpeen lyhentää valvonta-aikoja, ja testejä on ehkä muutettava niiden nopeuttamiseksi. Varmista, että voit suorittaa päivitetylle koodille täydelliset testit mahdollisimman pian käyttöönoton jälkeen. Laadunvarmistustestauksen automaation lisääminen auttaa tekemään testeistä tehokkaita näissä skenaarioissa.
Viestintä
Viestintävastuiden määrittäminen selkeästi on tärkeää, jotta kaaosta tapausten aikana voidaan minimoida. Näiden vastuualueiden avulla on määritettävä, miten työmääräryhmä on yhteydessä tukiryhmiin, sidosryhmien jäseniin ja poikkeustilanteissa vastaavan ryhmän henkilöstöön, kuten poikkeustilanteissa vastaavaan esihenkilöön.
Standardoi toimintosarja, jota työmääräryhmän seuraa tilapäivitysten tarjoamiseksi. Varmista, että sidosryhmien jäsenet ovat tietoisia tästä standardista ja tietävät, milloin päivityksiä voi odottaa.
Jos työmääräryhmän on kommunikoitava suoraan käyttäjien kanssa, selvitä, minkä tyyppisiä tietoja ja yksityiskohtia voidaan jakaa. Kerro työmäärätyhmälle myös muista näihin tapauksiin liittyvistä vaatimuksista.
Jälkiselvittely
Postmortems tulee seurata kaikkia epäonnistuneita käyttöönottoja poikkeuksetta. Jokainen epäonnistunut käyttöönotto on oppimismahdollisuus. Postmortems voi auttaa sinua tunnistamaan käyttöönotto- ja kehitysprosessien heikkoudet ja infrastruktuurin virheelliset määritykset.
Jälkiselvittelyt on aina tehtävä syyllistämättöminä, jotta tapaukseen liittyvät henkilöt voivat turvallisesti jakaa näkemyksiään tulevaisuudessa tehtävistä olevista parannuksista. Postmortem-johtajien tulisi seuranta suunnitelmia tunnistettujen parannusten toteuttamiseksi ja näiden suunnitelmien lisäämiseksi työmäärään.
Huomioon otettavat seikat ja yleiset suositukset
Varmista, että käyttöönottoputki hyväksyy erilliset versiot parametreina, jotta viimeisten tunnettujen toimivien määritysten käyttöönotto on helppoa.
Ylläpidä hallinnan ja tietotasojen yhdenmukaisuutta, kun palataan edelliseen versioon tai version käyttöönottoa lykätään. Avaimet, salaiset avaimet, tietokannan tilatiedot ja määritykset, jotka koskevat tiettyjä resursseja ja käytäntöjä, on määritettävä kuuluvaksi vaikutusalueeseen ja otettava huomioon. Kiinnitä huomiota esimerkiksi infrastruktuurin skaalauksen rakenteeseen viimeisessä tunnetusti toimivassa käyttöönotossa. Määritä, onko määritystä muutettava, kun koodi otetaan käyttöön uudelleen.
Suosi pieniä, usein tapahtuvia muutoksia harvinaisten suurten muutosten sijaan, jotta ero uusien ja viimeksi tunnettujen käyttöönottojen välillä on pieni.
Suorita vikatila-analyysi jatkuvan integraation ja jatkuvan toimituksen (CI/CD) putkille, jotta voit tunnistaa ongelmat, jotka voivat vaikeuttaa lieventämistoimia. Kuten koko työmääräsi, putkilinjasi voidaan analysoida sellaisten alueiden tunnistamiseksi, jotka saattavat olla ongelmallisia, kun yrität tiettyä lieventämistyyppiä.
Käytä automaattista edelliseen versioon palautuksen toimintoa harkiten seuraavalla tavalla:
- Jotkin jatkuvan integroinnin ja jatkuvan toimituksen työkalut, kuten Azure DevOps, sisältävät automaattisen edelliseen versioon palautuksen toiminnot. Voit ottaa nämä toiminnot käyttöön, jos niistä on konkreettista hyötyä.
- Automaattinen edelliseen versioon palautuksen toiminto on otettava käyttöön vasta putken huolellisen ja säännöllisen testaamisen jälkeen. Varmista, että putki on riittävän edistynyt, jotta se kestää ylimääräiset ongelmat, jos automaattinen edelliseen versioon palautus käynnistyy.
- Luota siihen, että automaatio ottaa käyttöön vain tarvittavat muutokset, ja että se käynnistyy vain tarvittaessa. Suunnittele käynnistimet huolellisesti näiden vaatimusten mukaisesti.
Käytä ympäristön mukana toimitettuja ominaisuuksia edelliseen versioon palautuksen aikana. Esimerkiksi varmuuskopiot ja ajankohdan palautus voivat auttaa tallennuksessa ja tietojen palauttamisessa. Tai jos käytät virtuaalikoneita sovelluksen isännöintiin, voi olla hyödyllistä palauttaa ympäristösi tarkistuspisteeseen juuri ennen tapahtumaa.
Testaa koko käyttöönoton virheiden lievennysstrategia usein. Käyttöönoton epäonnistumisen suunnitelma, kuten poikkeustilanteiden vastaussuunnitelmat ja järjestelmäpalautussuunnitelmat, onnistuu vain, jos ryhmä on koulutettu tähän ja jos sitä harjoitellaan säännöllisesti. Kaaostekniikka ja vianruiskutustestaus voivat olla tehokkaita tekniikoita käyttöönoton lieventämisstrategian testaamiseen.
Power Platform – avustaminen
Pipelinesin Power Platform tavoitteena on demokratisoida sovellusten elinkaaren hallinta (ALM) Power Platform asiakkaille ja Dynamics 365 tuomalla palveluun ALM-automaatio sekä jatkuvan integraation ja jatkuvan toimituksen (CI/CD) ominaisuudet.
Microsoft Power Platform Koontityökalujen Azure DevOps avulla voidaan automatisoida yleisiä koonti- ja käyttöönottotehtäviä, jotka liittyvät rakennettuihin Power Platform sovelluksiin.
GitHub-toiminnot, joiden Power Platform avulla kehittäjät voivat rakentaa automatisoituja ohjelmistokehityksen elinkaaren työnkulkuja. Microsoft Power Platformin GitHub-toimintojen avulla voit luoda säilöön työnkulkuja sovellusten luomiseen, testaamiseen, paketoimiseen, julkaisuun ja käyttöönottoon, automatisoinnin suorittamiseen sekä bottien ja muiden Microsoft Power Platformissa luotujen komponenttien hallintaan.
ALM Accelerator on avoimen lähdekoodin työkalu, joka koostuu joukosta sovelluksia, skriptejä ja putkia, jotka on suunniteltu automatisoimaan jatkuva integraatio / jatkuva toimitusprosessi.
Automatisoi testit Azure Pipelinesin avulla.
Power CAT Kitin Copilot Studio avulla voit määrittää perämiehiä ja testejä. Suorittamalla yksittäisiä testejä API-rajapintoja vastaan Copilot Studio (Direct Line), kopilottivasteita arvioidaan odotettuja tuloksia vasten.
Ratkaisujen ympäristömuuttujat tallentavat parametriavaimet ja arvot, jotka sitten toimivat syötteenä muille sovellusobjekteille. Kun parametrit erotetaan kuluttavista objekteista, voit muuttaa arvoja samassa ympäristössä tai silloin, kun ratkaisuja siirretään muihin ympäristöihin.
Power Platform Ympäristöt tarjoavat ajankohdan palautustoiminnon, joka voi auttaa sinua palaamaan takaisin.
Power Platform integroidaan Application Insightsiin, joka on osa Azure Monitor -ekojärjestelmää. Käytä tätä integraatiota seuraavaan:
Vastaanota Dataverse-ympäristön Application Insightsissa sieppaamia diagnostiikan ja suorituskyvyn telemetriatietoja. Sovellusten Dataverse-tietokannassa ja mallipohjaisissa sovelluksissa suorittamien toimintojen telemetria voidaan tilata. Telemetriassa on tietoja, joiden avulla voi diagnosoida virheisiin ja suorituksiin liittyviä ongelmia sekä tehdä niissä vianmäärityksiä.
Yhdistä pohjaan perustuvat sovelluksesi Application Insightsiin. Tämän analytiikan avulla voit diagnosoida ongelmia ja ymmärtää, mitä käyttäjät tekevät sovelluksillasi. Kerättyjen tietojen avulla voidaan tehdä parempia päätöksiä liiketoiminnassa ja parantaa sovellusten laatua.
Määritä Power Automate telemetria , johon Application Insights se virtaa; esimerkiksi valvoaksesi pilvityönkulku suorituksia ja luodaksesi hälytyksiä pilvityönkulku suoritusvirheistä.
Sieppaa telemetriatietoja copilotista Microsoft Copilot Studio käytettäväksi Azuressa Application Insights. Tämän telemetrian avulla voit seurata lokiin kirjattuja viestejä ja tapahtumia, jotka lähetetään copilotiin ja copilotista, käyttäjän keskustelujen aikana käynnistettäviä aiheita ja mukautettuja telemetriatapahtumia, jotka voidaan lähettää aiheistasi.
Toiminnan korkean laadun tarkistusluettelo
Katso lisätietoja suositusten kokoelmasta.