Liiketoiminnan jatkuvuuden suunnittelun elementit

Liiketoiminnan jatkuvuustapahtumasta (BCE) toipuminen vaatii järjestelmäkohtaisen suunnittelun ja perusteellisen ymmärtämisen siitä, kuinka kukin tietokone ja verkkokomponentti vaikuttavat kriittisiin liiketoiminnan tuloksiin. Tästä syystä liiketoiminnan jatkuvuuden suunnitteluun (BCP) on sisällytettävä useita dokumentoituja, testattuja ja harjoiteltuja tehtäviä, jotka tukevat:

  • Järjestelmäriippuvuuden kartoitus
  • Suurin sallittu häiriöjakso (MTPOD)
  • Keskimääräinen korjausaika (MTTR)
  • Palautumisajan tavoitteet (RTO)

Yhden tai useamman BCP-tavoitteen virheellinen analysointi voi todennäköisesti aiheuttaa korjaamatonta vahinkoa organisaatiollesi, jos kriittinen liiketoimintaprosessi epäonnistuu.

Järjestelmäriippuvuuden kartoitus

Järjestelmä on harvoin itsenäinen; useimmat järjestelmät ovat osa teknisiä komponentteja, jotka tukevat yhtä tai useampaa liiketoimintaprosessia. Ne toimivat kuin sisäinen IT-toimitusketju. Kuvio A kuvaa joukko järjestelmiä (S n ), jotka tarjoavat tilauksen merkinnän (S1), tilausten käsittelyä (S2), laskutusta (S3) ja toimitusta (S4). S2: lle syötetyt tilaukset viimeistelee S2. Sitten S2 syöttää S3: aan laskutuksen tapahtuessa, ja S4 tuottaa varastoliput. Jokaisen järjestelmän on toimittava odotetusti asiakkaan odottamien tulosten saavuttamiseksi: tuotteen toimittaminen luvatulla tavalla. Näin ollen BCP: n ensimmäinen askel kriittisen prosessin aikana on ymmärtää kaikki tukijärjestelmät.

Kuvio A

Sisäinen järjestelmän toimitusketju

Blogiartikkelin tilarajoitteiden takia en ole sisällyttänyt verkkokomponentteja tähän grafiikkaan. Kunkin järjestelmän välillä on kuitenkin kaapelointi, kytkimet, reitittimet, IPS / IDS jne. Lisäksi pilvipalvelut, jotka tarjoavat täydellisen järjestelmän tai järjestelmäkomponentin, ovat myös tärkeitä osia sisäisessä IT-toimitusketjussa. Sisällytä kaikki verkko- ja pilvipalvelut toimitusketjugrafiikkaasi. Kuvasi on todennäköisesti paljon suurempi kuin minun.

Suurin sallittu häiriöjakso

MTPOD, jota joskus kutsutaan suurimmaksi siedettäväksi seisokkeksi, on kokonaisaika, jolloin liiketoimintaprosessi voi olla toimimaton, ennen kuin yritykselle aiheutuu korjaamatonta vahinkoa. MTPOD sisältää aggregoidun MTTR- ja prosessisykliajan. Syklin aika edustaa ajanjaksoa, joka tarvitaan yhdennetyn iteraation suorittamiseen vaikutusalaan kuuluvasta liiketoimintaprosessista vikakohdasta. Esimerkiksi, jos S3 (kuva A) epäonnistui, sykliaika olisi ajanjakso, joka vaaditaan kaikkien syötteiden käsittelemiseksi S2: ltä ja toimitettavasta tuotteesta.

Keskimääräinen korjausaika

Vaikka MTPOD viittaa tapahtuneeseen prosessiin, MTTR koskee yksittäisiä komponentteja (järjestelmä- ja verkkolaitteita). Se on keskimääräinen aika, joka tarvitaan prosessin epäonnistuneen vaiheen palauttamiseksi normaaliin toimintaan. Aggregate MTTR on keskimääräinen aika, joka tarvitaan kaikkien viallisten järjestelmien tai komponenttien palauttamiseen laajalle levinneen liiketoiminnan jatkuvuuden tapahtuman aikana. MTTR: ​​ään vaikuttavat monet muuttujat, mukaan lukien:

  • Vian tyyppi . Kaapelin vika on paljon helpompi korjata kuin virtalähteen vika.
  • Varaosien saatavuus . Monet organisaatiot pitävät varaosia kriittisten komponenttien, myös kaapeloinnin, varassa. Jos myyjien on tilattava tai asennettava osia, läpimenoajat, matka-ajat jne. Ovat välttämätön osa MTTR: ​​tä.
  • Sisäinen valvontakyky ja taidot . Kuinka kauan tietotekniikkatiimillä kuluu vian tunnistamiseen ja sen syyn selvittämiseen? Henkilöstön asianmukainen koulutus sekä ajan tasalla olevan järjestelmän ja verkon dokumentoinnin ylläpitäminen tukevat kriittisesti tätä pyrkimystä.
  • Sisäisen avainhenkilön saatavuus l. Päivän aika, ilmoitusprosessit ja asianmukainen aikakatkaisun hallinta vaikuttavat henkilöstön saapumiseen, jota tarvitaan liiketoiminnan jatkuvuuden tapahtuman hallintaan.
  • Ylläpito paikallaan . Viralliset sopimukset ja SLA-sopimukset vaikuttavat suoraan myyjän vastaamiseen ja varaosien toimittamiseen kuluvaan aikaan.
  • BCP: n tehokkuus, mukaan lukien katastrofien palauttaminen.

Jokaisella komponentilla on organisaatiollesi yksilöllinen MTTR. SLA: n säätäminen, tapahtumien reagoinnin dokumentointi ja harjoittaminen sekä avainhenkilöiden päivystyksen varmistaminen ovat esimerkkejä olosuhteista, jotka voivat lyhentää MTTR: ​​tä.

Palautumisaika Tavoite

RTO on kohta, jossa vikaantuneiden laitteiden on oltava toimintakykyisiä annetulla prosessijaksoajalla (katso kuva B. ). Kokonaismäärä MTTR ei voi ylittää RTO: ta. Jos niin tapahtuu, tarvittavan tulosteen tuottamiseen kuluva aika ylittää MTPOD: n. Katastrofin palauttamisharjoitukset ovat hyvä esimerkki RTO: n testaamisesta. Jos prosessin palautusjakso ylittää RTO: n, MTTR-säädöt ovat tarpeen yhdelle tai useammalle talteenotetulle prosessikomponentille.

Kuvio B

Pilvipalvelut vaikuttavat MTPOD: ään

Liiketoiminnan jatkuvuuden tapahtumien suunnittelun hallitseminen on suhteellisen helppoa, kun kaikki komponentit ovat organisaation omassa tietokeskuksessa. Vaikeuksia voi kuitenkin syntyä, jos pilkkopalveluntarjoajan valinnassa ja sopimusneuvotteluissa ei käytetä asianmukaista huolellisuutta. Kuvio C kuvaa, miltä esimerkkiprosessimme voi näyttää, jos tilaukset siirretään palveluntarjoajalle. Organisaatiolla ei enää ole suoraa hallintaa prosessien jatkuvuuden ylläpitämiseen tarvittavasta infrastruktuurista, alustoista tai ohjelmistoista.

Kuvio C

Yhden tai useamman järjestelmän siirtäminen pilvelle tarjoaa organisaatiolle yhden merkittävän edun: katastrofaalisten tapahtumien vaikutusten hillitseminen. Esimerkiksi tämän organisaation tietokeskuksen katoaminen vaatii S2: n, S3: n ja S4: n palauttamisen. S1: n ainoa palautustoiminto on kuitenkin yhteyden palauttaminen S2: een. Tämän avulla määritetyn RTO: n saavuttaminen on paljon helpompaa.

Ongelmia voi syntyä, kun vika on palveluntarjoajan sivustolla. SLA-sopimukset, seuraamukset, asiakasauditoinnit ja sopimusvelvoitteet hallitsevat ja seuraavat S1: n MTTR: ​​tä esimerkissämme. Palveluntarjoajan maine, jota tukevat keskustelut olemassa olevien asiakkaiden kanssa, on hyvä mittari palveluntarjoajan halukkuudesta ja kyvystä toipua odotetussa MTTR: ​​ssä. Joka tapauksessa palveluntarjoaja, joka ei voi palautua RTO: n sisällä vaikutusalaan kuuluville liiketoimintaprosesseille, ei todennäköisesti ole oikea ratkaisu yrityksellesi.

Viimeinen sana

Liiketoiminnan jatkuvuuden tapahtumista toipuminen tilanteissa, joissa liiketoimintaprosessit epäonnistuvat, vaatii erityistä huomiota MTPOD: hon. MTTR: ​​n säätäminen kaikille järjestelmä- ja verkkokomponenteille auttaa saavuttamaan MTPOD: n RTO-elementin. Se riippuu useista tekijöistä, mukaan lukien perimmäisten syiden nopea havaitseminen sekä palautushenkilöstön saatavuus ja kyky.

Sykliaika on toinen tärkeä tekijä laskettaessa MTPOD: ta. Ensimmäisen tulossarjan tuottamiseen tarvittava aika, kun joukkueet ovat palauttaneet prosessin, eivät voi ylittää jäljellä olevaa ajanjaksoa RTO: n ja MTPOD-päätepisteen välillä. Jos näin on, todennäköinen ratkaisu on muutokset aggregoituun MTTR: ​​ään.

Yhden tai useamman prosessikomponentin siirtäminen pilveen voi vähentää aggregoitunutta MTTR: ​​tä katastrofaalisen tapahtuman tapahtuessa. Oikea toimittaja, jota hallitsee oikeudenmukainen mutta aggressiivinen asiakasvalvonta SLA-sopimuksista ja sopimusvaatimuksista, voi helpottaa palauttamista. Väärä palveluntarjoaja voi ajaa pilvipalvelimen ylläpitämää komponenttia MTTR: ​​tä RTO: ien ulkopuolelle. Valitse viisaasti.

© Copyright 2020 | mobilegn.com