Tere kõigile, minu nimi on Igor Tyukachev ja ma olen talitluspidevuse konsultant. Tänases postituses on meil pikk ja tüütu arutelu levinud tõdede üle, soovin jagada oma kogemust ja rääkida peamistest vigadest, mida ettevõtted talitluspidevuse plaani väljatöötamisel teevad.
1. RTO ja RPO juhuslikult
Kõige olulisem viga, mida olen näinud, on see, et taastumisaeg (RTO) on võetud tühjast küljest. No tühjast-tähjast - näiteks on mõned kahe aasta tagused numbrid SLA-st, mille keegi oma eelmisest töökohast tõi. Miks nad seda teevad? Lõppude lõpuks peate kõigi meetodite kohaselt kõigepealt analüüsima tagajärgi äriprotsessidele ja selle analüüsi põhjal arvutama välja taastamise eesmärgi ja lubatava andmekao. Kuid sellise analüüsi tegemine võtab mõnikord kaua aega, mõnikord on see kallis, mõnikord pole väga selge, kuidas – rõhutage, mida on vaja teha. Ja esimene asi, mis paljudele meelde tuleb, on: «Me kõik oleme täiskasvanud ja mõistame, kuidas äri käib. Ärgem raiskame aega ja raha! Võtame pluss-miinus nagu peab. Peast välja, kasutades proletaarset leidlikkust! Olgu RTO kaks tundi.
Milleni see viib? Kui tulla juhtkonnale raha eest tegevusteks, et tagada teatud numbritega nõutav RTO/RPO, nõuab see alati põhjendust. Kui õigustust pole, siis tekib küsimus: kust sa selle said? Ja pole midagi vastata. Selle tulemusena kaob usaldus oma töö vastu.
Pealegi maksavad need kaks tundi taastumist mõnikord miljon dollarit. Ja RTO kestuse põhjendamine on raha küsimus ja seejuures väga suurtes.
Ja lõpuks, kui tood oma BCP ja/või DR kava esinejatele (kes tegelikult õnnetuse hetkel jooksevad ja kätega vehivad), küsivad nad sarnase küsimuse: kust need kaks tundi tulid? Ja kui te ei suuda seda selgelt selgitada, ei usalda nad teid ega teie dokumenti.
Selgub, et see on paberitükk paberi pärast, unsubscribe. Muide, mõned teevad seda tahtlikult, lihtsalt regulaatori nõuete täitmiseks.
No saate aru
2. Ravi kõige vastu
Mõned inimesed usuvad, et BCP plaan on välja töötatud selleks, et kaitsta kõiki äriprotsesse mis tahes ohtude eest. Hiljuti tekkis küsimus "Mille eest me tahame end kaitsta?" Kuulsin vastust: "Kõik ja rohkemgi veel."
Kuid fakt on see, et plaan on mõeldud ainult kaitsmiseks konkreetne ettevõtte peamised äriprotsessid alates konkreetne ähvardused. Seetõttu tuleb enne plaani koostamist hinnata riskide tekkimist ja analüüsida nende tagajärgi ärile. Riskide hindamine on vajalik selleks, et mõista, milliseid ohte ettevõte kardab. Hoone hävimise korral on üks järjepidevusplaan, sanktsioonisurve korral teine, üleujutuse korral kolmas. Isegi kahel identsel objektil erinevates linnades võivad olla oluliselt erinevad plaanid.
Ühe piiripunktiga on võimatu kaitsta tervet ettevõtet, eriti suurt. Näiteks hakkas tohutu X5 Retail Group tagama järjepidevuse kahe peamise äriprotsessiga (me kirjutasime sellest ). Ja kogu ettevõtet ühe plaaniga ümbritseda on lihtsalt ebareaalne, see on "kollektiivse vastutuse" kategooriast, kui kõik vastutavad ja keegi ei vastuta.
ISO 22301 standard sisaldab poliitika mõistet, millest tegelikult saab alguse järjepidevuse protsess ettevõttes. See kirjeldab, mida me kaitseme ja mille eest. Kui inimesed tulevad jooksma ja paluvad lisada seda ja seda, näiteks:
— Kas lisame BCP-le riski, et meid häkitakse?
Või
— Hiljuti ujutas meie ülemine korrus vihma ajal üle – lisame stsenaariumi, mida teha üleujutuse korral?
Seejärel suunake nad kohe sellele poliitikale ja öelge, et me kaitseme konkreetset ettevõtte vara ja ainult konkreetsete, eelnevalt kokkulepitud ohtude eest, sest need on praegu prioriteet.
Ja isegi kui muudatusettepanekud on tõepoolest asjakohased, pakkuge neid poliitika järgmises versioonis arvesse võtma. Sest ettevõtte kaitsmine maksab palju raha. Seega peavad kõik piiripunkti plaani muudatused läbima eelarvekomisjoni ja planeerimise. Soovitame ettevõtte talitluspidevuse poliitika üle vaadata kord aastas või kohe pärast olulisi muudatusi ettevõtte struktuuris või välistingimustes (andku lugejad mulle andeks, et seda ütlen).
3. Fantaasiad ja tegelikkus
Tihti juhtub, et BCP plaani koostamisel kirjeldavad autorid mingit ideaalset maailmapilti. Näiteks "meil ei ole teist andmekeskust, kuid me koostame plaani nii, nagu meil oleks." Või pole ettevõttel veel mingit osa taristust, kuid töötajad lisavad selle siiski plaani lootuses, et see tulevikus ilmub. Ja siis laiendab ettevõte reaalsust plaanile: ehitage teine andmekeskus, kirjeldage muid muudatusi.
Vasakul on BCP-le vastav infrastruktuur, paremal reaalne infrastruktuur
See kõik on viga. BCP plaani kirjutamine tähendab raha kulutamist. Kui kirjutate plaani, mis praegu ei tööta, maksate väga kalli paberi eest. Sellest on võimatu taastuda, seda on võimatu testida. Selgub, et see on töö töö nimel.
Plaani saab kirjutada üsna kiiresti, kuid varutaristu ehitamine ja raha kulutamine kõikidele kaitselahendustele on pikk ja kulukas. Selleks võib kuluda rohkem kui üks aasta. Ja võib selguda, et teil on plaan juba olemas ja infrastruktuur selle jaoks ilmneb kahe aasta pärast. Miks on sellist plaani vaja? Mille eest see teid kaitseb?
See on ka fantaasia, kui BCP arendusmeeskond hakkab ekspertide jaoks välja mõtlema, mida nad peaksid tegema ja mis aja jooksul. See pärineb kategooriast: “Taigas karu nähes tuleb pöörata karust vastassuunda ja joosta karu kiirust ületava kiirusega. Talvekuudel tuleb oma jäljed katta.”
4. Pealsed ja juured
Neljas kõige olulisem viga on plaani tegemine kas liiga pealiskaudseks või liiga detailseks. Vajame kuldset keskteed. Plaan ei tohiks olla idiootide jaoks liiga üksikasjalik, kuid see ei tohiks olla liiga üldine, et midagi sellist lõppeks:
Üldiselt lihtne
5. Caesarile - mis on Caesari oma, mehaanikule - mis on mehaaniku oma.
Järgmine viga tuleneb eelmisest: ühte plaani ei saa mahutada kõiki tegevusi kõikide juhtimistasandite jaoks. BCP-plaanid töötatakse tavaliselt välja suurte finantsvoogudega suurettevõtetele (muide, meie andmetel Keskmiselt 48% Venemaa suurettevõtetest sattus hädaolukordadesse, millega kaasnes märkimisväärne rahaline kahju) ja mitmetasandiline juhtimissüsteem. Selliste ettevõtete puhul ei tasu püüda kõike ühte dokumenti mahutada. Kui ettevõte on suur ja struktureeritud, peaks plaanil olema kolm erinevat taset:
- strateegiline tase - kõrgemale juhtkonnale;
- taktikaline tase - keskastmejuhtidele;
- ja tegevustasand – valdkonnaga otseselt seotud isikute jaoks.
Näiteks kui me räägime ebaõnnestunud taristu taastamisest, siis strateegilisel tasandil tehakse otsus taastamisplaani aktiveerimise kohta, taktikalisel tasandil võidakse kirjeldada protsessi protseduure ning operatiivtasandil on juhised konkreetsete kasutuselevõtuks. seadmete tükid.
BCP ilma eelarveta
Igaüks näeb oma vastutusvaldkonda ja sidemeid teiste töötajatega. Õnnetuse hetkel avab igaüks plaani, leiab kiiresti oma osa ja järgib seda. Ideaalis peate meeles pidama, milliseid lehti avada, sest mõnikord loevad minutid.
6. Rollimäng
Veel üks viga BCP plaani koostamisel: plaani pole vaja lisada konkreetseid nimesid, meiliaadresse ja muid kontaktandmeid. Dokumendi enda tekstis tuleks märkida ainult isikupäratud rollid ning nendele rollidele tuleks määrata konkreetsete ülesannete eest vastutajate nimed ja nende kontaktid esitada plaani lisas.
Miks?
Tänapäeval vahetab enamik inimesi iga kahe-kolme aasta tagant töökohta. Ja kui plaani teksti kirja panna kõik vastutajad ja nende kontaktid, siis tuleb seda pidevalt muuta. Ja suurtes ettevõtetes, eriti valitsusasutustes, nõuab iga dokumendi muutmine palju kinnitusi.
Rääkimata sellest, et kui tekib hädaolukord ja pead meeletult plaani lehitsema ja õiget kontakti otsima, siis kaotad väärtuslikku aega.
Life Hack: kui muudate rakendust, ei pea te seda sageli isegi heaks kiitma. Veel üks näpunäide: saate kasutada plaani värskendamise automatiseerimissüsteeme.
7. Versioonide puudumine
Tavaliselt loovad nad plaani versiooni 1.0 ja teevad seejärel kõik muudatused ilma redigeerimisrežiimita ja failinime muutmata. Samas jääb sageli arusaamatuks, mis on võrreldes eelmise versiooniga muutunud. Versiooni puudumisel elab plaan oma elu, mida ei jälgita kuidagi. Iga BCP plaani teisel leheküljel peaks olema näidatud versioon, muudatuste autor ja muudatuste endi loend.
Keegi ei saa sellest enam aru
8. Kellelt ma peaksin küsima?
Sageli puudub ettevõtetel BCP plaani eest vastutav isik ja puudub ka eraldi osakond, mis vastutaks talitluspidevuse eest. See auväärne vastutus on pandud CIO-le, tema asetäitjale või vastavalt põhimõttele "te tegelete infoturbega, nii et siin on lisaks BCP". Selle tulemusena töötatakse välja, lepitakse kokku ja kinnitatakse plaan ülalt alla.
Kes vastutab plaani säilitamise, ajakohastamise ja selles sisalduva teabe ülevaatamise eest? Seda ei pruugita välja kirjutada. Eraldi töötaja palkamine selleks on raiskamine, aga ühe olemasoleva lisaülesannetega koormamine on muidugi võimalik, sest kõik püüdlevad nüüd efektiivsuse poole: “Riputame talle laterna külge, et öösel niita,” aga kas see on vajalik?
Otsime BCP eest vastutajaid kaks aastat pärast selle loomist
Seetõttu juhtub sageli nii: töötati välja plaan ja pandi see pikka kasti, et see saaks tolmuga kaetud. Keegi ei testi seda ega säilita selle asjakohasust. Kõige tavalisem lause, mida kliendi juurde tulles kuulen, on: “Plaan on olemas, aga see on ammu välja töötatud, pole teada, kas seda testiti, on kahtlus, et see ei tööta.”
9. Liiga palju vett
On plaane, mille sissejuhatus on viie lehekülje pikkune koos eelduste kirjeldusega ja tänusõnad kõigile projektis osalejatele koos infoga ettevõtte tegemiste kohta. Selleks ajaks, kui kerite alla kümnendale lehele, kus on kasulikku teavet, on teie andmekeskus juba üle ujutatud.
Kui proovite hetkeni lugeda, mida peaksite tegema, kui teie andmekeskus on üle ujutatud?
Asetage kogu ettevõtte "vesi" eraldi dokumenti. Plaan ise peab olema äärmiselt konkreetne: selle ülesande eest vastutav isik teeb seda jne.
10. Kelle kulul bankett toimub?
Tihti pole plaanide koostajatel ettevõtte tippjuhtkonna tuge. Kuid tuge on keskastme juhtkonnalt, kes ei juhi või ei oma talitluspidevuse juhtimiseks vajalikku eelarvet ja ressursse. Näiteks IT-osakond koostab oma BCP plaani oma eelarve piires, kuid CIO ei näe kogu ettevõtte pilti. Minu lemmiknäide on videokonverentsid. Kui tegevjuhi videokonverents ei tööta, siis kelle ta siseelundeid eemaldab? CIO, kes "ei pakkunud". Seega, mis on CIO seisukohalt ettevõttes kõige olulisem? Mille pärast inimesed teda alati “armastavad”: videokonverentsid, mis muutuvad koheselt ärikriitiliseks süsteemiks. Ja ärilisest vaatenurgast - noh, ei mingit VKS-i, mõelge vaid, me räägime telefoniga, nagu Brežnevi ajal ...
Lisaks arvab IT-osakond tavaliselt, et tema peamiseks ülesandeks katastroofi korral on ettevõtte IT-süsteemide töö taastamine. Kuid mõnikord pole teil vaja seda teha! Kui on äriprotsess hirmkallile printerile paberitükkide trükkimise näol, siis ei tasu teist sellist printerit varuks osta ja rikke korral kõrvale panna. Võib piisata paberitükkide ajutisest käsitsi värvimisest.
Kui ehitame IT-s pidevat kaitset, peame kasutama tippjuhtkonna ja ettevõtete esindajate tuge. Vastasel juhul saate IT-osakonnas nukkudes lahendada teatud hulga probleeme, kuid mitte kõiki vajalikke.
Selline näeb välja olukord, kui DR-plaanid on ainult IT-osakonnal
10. Testimist ei toimu
Kui plaan on, siis tuleb seda katsetada. Neile, kes standardeid ei tunne, pole see sugugi ilmne. Näiteks ripuvad teil kõikjal „avariiväljapääsu” sildid. Aga öelge, kus on teie tuleämber, konks ja labidas? Kus on tuletõrjehüdrant? Kus peaks asuma tulekustuti? Kuid kõik peaksid seda teadma. Meile ei tundu üldse loogiline kontorisse sisenedes tulekustutit leida.
Võib-olla peaks plaani katsetamise vajadust ka plaanis endas mainima, kuid see on vastuoluline otsus. Igal juhul saab plaani lugeda toimivaks ainult siis, kui seda on vähemalt korra testitud. Nagu eespool mainitud, kuulen väga sageli: “Plaan on olemas, kogu infrastruktuur on ette valmistatud, aga see ei ole fakt, et kõik läheb nii, nagu plaanis kirjas. Sest nad ei testinud seda. Mitte kunagi".
Kokkuvõttes
Mõned ettevõtted saavad analüüsida oma ajalugu, et mõista, millised probleemid võivad juhtuda ja kui tõenäolised need on. Uuringud ja kogemused näitavad, et me ei saa end kõige eest kaitsta. Jama, varem või hiljem juhtub iga ettevõttega. Teine asi on see, kui valmis olete selleks või sarnaseks olukorraks ja kas suudate oma äri õigel ajal taastada.
Mõned arvavad, et järjepidevus seisneb selles, kuidas kõrvaldada kõikvõimalikud riskid, et need ei realiseeruks. Ei, asi on selles, et riskid realiseeruvad ja me oleme selleks valmis. Sõdureid treenitakse mitte lahingus mõtlema, vaid tegutsema. Sama on BCP-plaaniga: see võimaldab teil oma äri võimalikult kiiresti taastada.
Ainus seade, mis ei vaja BCP-d
Igor Tjukatšov,
Talitluspidevuse konsultant
Arvutussüsteemide Disaini Keskus
"Jet Infosüsteemid"
Allikas: www.habr.com