Järjestelmänpalautusstrategian suunnittelua koskevat suositukset
Koskee tätä Power Platform hyvin suunnitellun luotettavuuden tarkistuslistan suositusta:
| RE:07 | Toteuta jäsenneltyjä, testattuja ja dokumentoituja liiketoiminnan jatkuvuuden ja järjestelmänpalautuksen (BCDR) suunnitelmia, jotka ovat linjassa palautustavoitteiden kanssa. Koko järjestelmän ohella suunnitelmien on katettava kaikki komponentit. |
|---|
Tässä oppaassa kuvataan suositukset luotettavan järjestelmäpalautusstrategian luomiseksi työmäärälle. Sisäisten palvelutasotavoitteiden (SLO) tai jopa asiakkaillesi takaamasi palvelutasosopimuksen (SLA) saavuttamiseksi sinulla on oltava vankka ja luotettava järjestelmäpalautusstrategia. Epäonnistumisia ja muita merkittäviä ongelmia on odotettavissa. Valmistelusi näiden tapausten käsittelyä varten määrittävät, kuinka paljon asiakkaasi voivat luottaa siihen, että yrityksesi palvelee heitä luotettavasti. Järjestelmäpalautusstrategia on merkittäviin tapauksiin valmistautumisen selkäranka.
Määritelmät
| Termi | Määritelmä |
|---|---|
| Vikasieto | Tuotannon työmäärän liikenteen automaattinen ja/tai manuaalinen siirto pois käytöstä olevalta alueelta vaikutusalueeseen kuulumattomalle alueelle. |
| Varapalautus | Tuotannon työmäärän liikenteen automaattinen ja/tai manuaalinen siirto pois vikasietoalueelta takaisin ensisijaiselle alueelle. |
Tärkeimmät suunnittelustrategiat
Tässä oppaassa oletetaan, että luotettavuuden suunnittelussa on jo suoritettu seuraavat tehtävät:
Kriittisten ja muiden työnkulkujen tunnistaminen.
Virhetila-analyysin (FMA) suorittaminen työnkuluille.
Luotettavuustavoitteiden määrittäminen.
Vankan testausstrategian suunnitteleminen.
Luotettava työmääräarkkitehtuuri on luotettavan järjestelmäpalautusstrategian perusta. Ota luotettavuus huomioon jokaisessa työmäärän luomisen vaiheessa varmistaaksesi, että sinulla on tarvittavat komponentit tehokkaaseen palautukseen, ennen kuin aloitat järjestelmäpalautusstrategiasi suunnittelun. Tämä perusta varmistaa, että työmäärän luotettavuustavoitteet, kuten palautusaikatavoite (RTO) ja palautuskohtatavoite (RPO), ovat käytännöllisiä ja mahdollisia saavuttaa.
Järjestelmäpalautussuunnitelman ylläpitäminen
Järjestelmäpalautussuunnitelma on työmäärän luotettavan järjestelmäpalautusstrategian avain. Suunnitelman pitäisi olla elävä asiakirja, jota tarkistetaan ja päivitetään säännöllisesti ympäristön muuttuessa. Jaa suunnitelma asianomaisille tiimeille (toiminnot, teknologiajohtajuus ja liiketoiminnan sidosryhmät) säännöllisesti (esim. 6 kuukauden välein). Pidä se erittäin hyvin käytettävissä olevassa suojatussa tietosäilössä, kuten OneDrivessä.
Noudata näitä suosituksia järjestelmäpalautussuunnitelman kehittämiseksi:
Määritä selkeästi, mikä on katastrofi ja vaatii järjestelmäpalautussuunnitelman aktivoinnin.
Katastrofit ovat suuren mittakaavan ongelmia. Ne voivat olla alueellisia käyttökatkoja, Microsoft Entra ID:n tai Azure DNS:n kaltaisten palvelujen käyttökatkoja tai vakavia haitallisia hyökkäyksiä, kuten kiristysohjelma- tai DDoS-hyökkäyksiä.
Sisällytä järjestelmäpalautussuunnitelmaan esimerkkejä virhetiloista, joita ei katsota katastrofeiksi, kuten yksittäisen resurssin pois käytettävistä oleminen tai häiriö, jotta operaattorit eivät vahingossa käynnistä järjestelmäpalautuseskalaatioitaan.
Perusta järjestelmäpalautussuunnitelma FMA-dokumentaatioon. Varmista, että järjestelmäpalautussuunnitelmasi tallentaa vikatilat ja lievennysstrategiat käyttökatkoksille, jotka määritetään katastrofeiksi. Jos päivityksiä tarvitaan, päivitä sekä järjestelmäpalautussuunnitelma että FMA-asiakirjat samanaikaisesti, jotta ne pitävät paikkansa, kun ympäristö muuttuu tai kun testauksessa paljastuu odottamattomia toimintatapoja.
Määritä työmäärätiimin sisäiset roolit ja vastuualueet selkeästi ja ymmärrä mahdolliset liittyvät ulkoiset roolit organisaatioissasi. Jos katastrofin aiheuttaa ulkoisen palvelun, kuten Microsoft Entra ID:n, käyttökatkos, varmista, että sinulla on määritettynä rooli, joka vastaa viestinnästä ulkoisen osapuolen kanssa ja voi jakaa päivityksiä työmäärätiimille. Rooleihin pitäisi kuulua seuraavat:
- Katastrofiksi julistamisesta vastaava osapuoli
- Tapauksen suljetuksi julistamisesta vastaava osapuoli
- Toimintoroolit
- Testaus- ja vahvistusroolit
- Sisäiset ja ulkoiset viestintäroolit
- Jälkiselvittelyn ja juurisyyanalyysin (RCA) johtavat roolit
Määritä eskalointipolut, joita työmäärätiimin on noudatettava, jotta palautustilasta ilmoitetaan sidosryhmille.
Sisällytä määritetty järjestys, jossa työmäärän komponentit pitäisi palauttaa, jotta vaikutuksia on mahdollisimman vähän. Palauta esimerkiksi tietokannat ja käynnistä pilvivirrat uudelleen, ennen kuin palautat sovelluksen.
Erittele kunkin komponentin palautusmenettely vaiheittaiseksi oppaaksi. Sisällytä mahdollisuuksien mukaan näyttökuvia ja menettelyn suorittamisen edellytykset. Tee esimerkiksi luettelo tarvittavista komentosarjoista tai tunnistetiedoista, jotka on kerättävä.
Määritä tiimisi vastuut verrattuna pilvipalvelun isännöintipalvelun tehtäviin. Microsoft Esimerkiksi on vastuussa PaaS: n (alusta palveluna) palauttamisesta, mutta olet vastuussa tietojen uudelleenhydratoinnista ja määritysten soveltamisesta palveluun.
Selvitä tapauksen juurisyy ja toteuta lieventäviä toimia, ennen kuin aloitat palautuksen. Jos tapauksen syynä esimerkiksi on suojausongelma, korjaa kyseinen ongelma, ennen kuin palautat vaikutusalueen järjestelmät vikasietoympäristöösi.
Jos sinun on otettava sovelluksesi uudelleen käyttöön vikasietoympäristössä, käytä työkaluja käyttöönottoprosessin mahdollisimman laajaa automatisointia varten. Varmista, että Azure-jaksosi on esikäyttöönotettu ja määritetty oikein vikasietoympäristöissä, jotta voit välittömästi aloittaa käyttöönotot. Käytä automatisoituja kattavia käyttöönottoja, joissa on manuaalisia hyväksyntäportteja tarvittaessa, varmistaaksesi johdonmukaisen ja tehokkaan käyttöönottoprosessin. Kun käyttöönottoprosessin vaihe vaatii manuaalisia toimia, dokumentoi manuaaliset vaiheet. Määritä roolit ja vastuut selkeästi.
Automatisoi mahdollisimman suuri osa menettelystä. Käytä uudelleenyrityslogiikkaa välttääksesi ajan hukkaamisen komentosarjoihin, jotka ovat juuttuneet vialliseen tehtävään. Koska näitä komentosarjoja suoritetaan vain hätätilanteissa, virheellisesti kehitetyt komentosarjat eivät saa aiheuttaa lisävahinkoa tai hidastaa palautusprosessia.
Muistiinpano
Automaatioon liittyy riskejä. Koulutuettujen operaattoreiden on seurattava automatisoituja prosesseja huolellisesti ja puututtava tilanteeseen, jos jossakin prosessissa kohdataan vaikeuksia. Olemalla perusteellinen järjestelmänpalautusharjoituksissa voit pitää riskin siitä mahdollisimman pienenä, että automaatio reagoi virheellisiin esiintymiin. Testaa suunnitelman kaikki vaiheet. Simuloi havainnointia luodaksesi hälytyksiä ja käy sitten läpi koko palautusmenettely.
Järjestä järjestelmäpalautusharjoituksia
Järjestelmäpalautuksen testauskäytäntö on olennaisen tärkeä hyvän järjestelmäpalautussuunnitelman kannalta. Monilla toimialoilla on vaatimustenmukaisuuskehyksiä, joissa vaaditaan säännöllisiä järjestelmäpalautusharjoituksia. Toimialasta riippumatta säännölliset järjestelmäpalautusharjoitukset ovat kriittisiä menestyksen kannalta.
Suosituksia onnistuneiden järjestelmäpalautusharjoitusten toteuttamiseen:
Suorita vähintään yksi tuotannon järjestelmäpalautusharjoitus vuosittain. Kuivaharjoitukset tai tuotannon ulkopuoliset harjoitukset auttavat varmistamaan, että osalliset osapuolet tuntevat roolinsa ja vastuunsa. Nämä harjoitukset myös auttavat operaattoreita kehittämään tuntemusta noudattamalla palautusprosesseja. Kuitenkin vain tuotannon harjoitukset todella testaavat järjestelmäpalautussuunnitelman ja RTO- ja RPO-mittareiden validiteetin. Käytä tuotannon harjoituksia selvittääksesi komponenttien ja työnkulkujen palautusprosessien kestoja varmistaaksesi, että työmäärälle määritetyt RTO- ja RPO-tavoitteet ovat saavutettavissa. Varmista niiden toimintojen osalta, jotka eivät ole sinun hallinnassasi, kuten Microsoft Entra ID:n käyttökatkokset, että nämä toiminnot sisältävien työnkulkujen RTO- ja RPO-tavoitteet ottavat huomioon mahdolliset viiveet, jotka eivät ole hallinnassasi.
Käytä kuivaharjoituksia uusien operaattoreiden kouluttamiseksi järjestelmäpalautuksen prosessien ja menettelyjen osalta. Vanhempien operaattoreiden olisi annettava uusille operaattoreille aikaa suorittaa roolinsa ja pitäisi etsiä parannusmahdollisuuksia. Jos uudella operaattorilla on huolia tai epäselvyyksiä johonkin menettelyn vaiheeseen liittyen, tarkasta kyseinen menettely varmistaaksesi, että se on kirjoitettu selkeästi.
Huomioitavia seikkoja
Järjestelmäpalautusharjoitusten järjestäminen tuotannossa voi aiheuttaa odottamattomia vakavia virheitä. Muista testata palautusmenettelyt muissa kuin tuotantoympäristöissä alustavien käyttöönottojen aikana.
Anna tiimillesi harjoitusten aikana mahdollisimman paljon ylläpitoaikaa. Kun suunnittelet ylläpitoaikaa, käytä palautuksen mittaustuloksia, jotka tallennetaan testauksen aikana, lyhyin tarvittu aika -kiintiöinä.
Järjestelmäpalautusharjoitusten kypsyessä selviää, mitä menettelyjä voidaan suorittaa rinnakkain ja mitkä on suoritettava peräkkäin. Oleta harjoitusten alkuvaiheessa, että kukin menettely on suoritettava peräkkäin ja että tarvitset jokaisessa vaiheessa ylimääräistä aikaa odottamattomien ongelmien käsittelemistä varten.
Vikasieto-ominaisuudet
Microsoft Liiketoimintasovellukset tarjoavat liiketoiminnan jatkuvuus- ja järjestelmäpalautusominaisuudet (BCDR) kaikkiin tuotantoympäristöihin Dynamics 365- ja Power Platform Software as a Service (SAAS) -sovelluksissa. Lue, miten varmistat, että Microsoft tuotantotietosi kestävät alueellisia käyttökatkoksia.
Luotettavuuden tarkistusluettelo
Katso lisätietoja suositusten kokoelmasta.