
Kapag pinag-uusapan natin ang mga estratehiya sa pagbangon mula sa sakuna , ang tinutukoy natin ay isang bagay na mas malawak kaysa sa mga simpleng backup: tinutukoy natin ang tunay na kakayahan ng isang kumpanya na patuloy na gumana kapag nagkamali ang lahat. Ang sunog sa data center, ransomware na nag-e-encrypt sa lahat ng server, isang malawakang pagkawala ng network, o isang matagal na pagkawala ng kuryente ay maaaring magdulot ng ganap na paghinto ng isang negosyo nang walang maayos at nasubukang plano.
Ang magandang balita ay ngayon ay mayroon na tayong mga mature na pamamaraan, balangkas, at teknolohiya (on-premise, cloud, hybrid) para sa pagbuo ng matatag na mga plano sa pagbawi mula sa kalamidad (DRP) at mga plano sa pagpapatuloy ng negosyo (BCP). Ang susi ay maging proactive: idokumento kung ano ang gagawin, sino ang gagawa nito, gamit ang anong mga tool, at sa loob ng anong mga timeframe, sa halip na mag-improvise sa gitna ng isang krisis. Sa mga sumusunod na seksyon, makikita mo, sa isang komprehensibo at praktikal na paraan, lahat ng kailangan mo upang magdisenyo, magpatupad, at mapanatili ang isang tunay na epektibong diskarte sa pagbawi mula sa kalamidad, hindi lamang isang dokumento na "lagyan ng tsek ang kahon."
Pagpapatuloy ng negosyo at pagbangon mula sa sakuna: pagsasama-sama ng mga bahagi
Bago talakayin ang mga uri ng plano at teknolohiya, mahalagang maunawaan muna ang dalawang konseptong madalas na nalilito: business continuity planning (BCP) at disaster recovery planning (DRP) . Tinutukoy ng business continuity plan kung paano pinapanatili ng isang organisasyon ang mahahalagang tungkulin nito habang at pagkatapos ng isang seryosong pangyayari; ang DRP ay nakatuon sa kung paano ibabalik ang imprastraktura ng IT at datos na sumusuporta sa mga tungkuling iyon.
Ang business continuity ay tumatalakay sa mga proseso, tao, lokasyon, at mga supplier . Kabilang dito ang mga desisyon tulad ng kung saan magtatrabaho ang mga kawani kung hindi magamit ang pangunahing opisina, kung anong mga minimum na serbisyo ang dapat panatilihin agad, at kung paano unahin ang serbisyo para sa mga kritikal na customer. Sa kabilang banda, ang disaster recovery planning (DRP) ay nakatuon sa mga server, network, database, cloud system, backup, at mga teknikal na pamamaraan sa pagbawi.
Ang parehong plano ay dapat magkasabay: kung walang matibay na DRP, ang BCP ay magkukulang , dahil hindi mo maisasagawa ang mga proseso ng negosyo kung ang mga sistema ay hindi magagamit; ngunit, kasabay nito, ang isang perpektong DRP na hindi isinasaalang-alang ang epekto sa mga operasyon ay hindi rin malulutas ang problema. Sa isip, dapat silang idisenyo nang magkasama, na nagbabahagi ng Business Impact Analysis (BIA), Recovery Time Objectives (RTO), at Risk Perception Objectives (RPO).
Bukod pa rito, ang business continuity at disaster recovery planning (DRP) ay naaayon sa pangkalahatang pamamahala ng panganib ng kumpanya : nakakatulong ang mga ito na mabawasan ang mga pagkalugi sa pananalapi, maiwasan ang mga parusa sa regulasyon, protektahan ang reputasyon, at sa huli ay matiyak ang kaligtasan ng organisasyon sa harap ng matinding krisis.
Ano ang Disaster Recovery Plan (DRP) at bakit ito hindi maaaring pag-usapan?
Ang Disaster Recovery Plan ay isang pormal, nakabalangkas, at naaaksyunang dokumento na tumutukoy kung paano dapat tumugon ang isang organisasyon sa isang malubhang pagkagambala sa mga sistema ng teknolohiya nito. Hindi lamang ito isang listahan ng mga mabubuting intensyon, kundi isang detalyadong hanay ng mga pamamaraan, kontak, responsibilidad, at mga mapagkukunan para sa pagpapanumbalik ng mga serbisyo at data sa loob ng mga katanggap-tanggap na takdang panahon.
Binabalangkas ng isang epektibong Disaster Recovery Plan (DRP) kung aling mga sistema ang kritikal, kung paano ang mga ito pinoprotektahan, bina-back up, at muling binubuo kung sakaling magkaroon ng ganap o bahagyang pagkabigo. Kabilang dito ang lahat mula sa pag-activate ng alternatibong data center o pangalawang cloud region hanggang sa paggamit ng mga snapshot, patuloy na pagkopya ng data, pagpapanumbalik ng database, at maayos na pagsisimula ng mga virtual machine at application.
Ang pangunahing layunin nito ay upang mabawasan ang downtime at pagkawala ng datos , mapanatili ang integridad at seguridad ng impormasyon sa buong proseso. At, napakahalaga, sakop din nito ang mga aspeto ng organisasyon: kung sino ang nagdedeklara ng sakuna, kung sino ang nag-uugnay sa teknikal na tugon, kung sino ang nakikipag-ugnayan sa mga customer, media, o awtoridad, at kung paano idinodokumento ang mga desisyon.
Sa isang patuloy na nagiging digital na kapaligiran, ang pag-asa sa iisang data center o mga sistema na walang redundancy ay parang paglalaro sa apoy. Walang organisasyon ang ligtas sa mga pagkabigo ng hardware, pagkakamali ng tao, mga cyberattack, o matinding pisikal na pangyayari. Ang pagkakaroon ng napapanahon at nasubukang Disaster Recovery Plan (DRP) ay hindi na opsyonal; ito ay naging isang estratehikong kinakailangan, kapwa para sa katatagan at pagsunod sa mga regulasyon, pati na rin para sa pagbuo ng tiwala sa mga customer at kasosyo.
Mga pangunahing uri ng mga sakuna sa teknolohiya na nagbabanta sa mga negosyo
Para makadisenyo ng mahusay na estratehiya sa pagbangon mula sa malulubhang pagkabigo, kailangan mong magsimula sa isang bagay na napakasimple: pag-unawa kung ano ang maaaring masira at paano . Ang mga teknolohikal na sakuna ay mula sa mga pisikal na insidente hanggang sa mga sopistikadong pag-atake o mga simpleng pagkakamali ng tao na may napakalaking kahihinatnan.
Kabilang sa mga pinakakaraniwang uri ng sakuna ay ang mga pagkabigo ng hardware : mga server na nag-o-overheat at nasusunog, mga storage array na humihinto sa pagtugon, at mga router o firewall na nasisira nang walang babala. Ang pagkawala o pagkasira ng mga disk nang walang sapat na backup ay maaaring maging dahilan upang hindi magamit ang mga kritikal na sistema nang ilang oras o araw.
Ang isa pang problema ay ang mga problema sa software : mga update na hindi maayos na nasubukan na nagpapa-crash ng mga application sa negosyo, mga hindi pagkakatugma sa pagitan ng mga bersyon ng operating system at software ng korporasyon, mga bug na sumisira sa data, o mga prosesong nagpapatigil at humaharang sa mga transaksyon.
Hindi natin maaaring kaligtaan ang kategorya ng mga cyberattack : ransomware na nag-e-encrypt ng lahat ng file at database, mga kampanyang phishing na nagnanakaw ng mga kredensyal sa pribadong pag-access, mga pag-atake ng DDoS na sumasalot sa koneksyon, mga panghihimasok na naglalabas ng sensitibong impormasyon, o panloob na sabotahe. Sa mga sitwasyong ito, bilang karagdagan sa pagbawi, kinakailangang pigilan, imbestigahan, at palakasin ang seguridad sa pamamagitan ng mga attack simulator.
Ang pagkakamali ng tao ay nananatiling isang patuloy na pinagmumulan ng mga insidente: aksidenteng pagbura ng mga database, maling pagbabago sa configuration, pagpapadala ng mahahalagang impormasyon sa mga maling tatanggap, o hindi sinasadyang pag-deactivate ng mga hakbang sa seguridad.
Panghuli, may mga problema sa network o data center : matagal na pagkawala ng internet provider, pagkawala ng kuryente nang walang sapat na UPS system, sunog, baha, o pisikal na pinsala sa mga pasilidad ng on-premise o cloud provider. Maaaring maging dahilan ang alinman sa mga pangyayaring ito na maging dahilan upang hindi ma-access ang mga kritikal na aplikasyon o ipinamahaging data ng negosyo sa pagitan ng on-premise at ng cloud.
Mga mahahalagang bahagi ng isang estratehiya sa pagbangon mula sa sakuna
Ang isang mahusay na estratehiya sa pagbawi ay hindi lamang tungkol sa pagsasabing "gumagawa tayo ng mga backup." Dapat nitong saklawin ang lahat mula sa pagtatasa ng panganib hanggang sa pagsubok at pagsasanay , arkitektura ng IT, organisasyon ng pangkat, at panloob at panlabas na komunikasyon.
Ang panimulang punto ay isang masusing pagtatasa ng panganib at pagsusuri ng epekto sa negosyo (BIA) . Kabilang dito ang pagtukoy sa mga banta na may kaugnayan sa organisasyon, pagsusuri ng mga kahinaan (teknikal, pisikal, at organisasyonal), at pagkalkula ng epekto sa operasyon, pananalapi, at reputasyon ng bawat pagkabigo ng sistema. Ang pagsasanay na ito ay magbubunga ng RTO (Recovery Time Objective) at RPO (Recovery Point Objective) para sa bawat serbisyo.
Batay dito, isang plano ng pagpapatuloy ng negosyo ang tinutukoy , na nagbabalangkas kung paano pinapanatili ang mahahalagang tungkulin kapag walang magagamit na mga karaniwang mapagkukunan. Maaaring kabilang dito ang mga alternatibong lokasyon, malawakang pagtatrabaho nang malayuan, mga kasunduan sa mga panlabas na tagapagbigay ng serbisyo, mga pansamantalang pagbabago sa proseso, o kontroladong pagbaba ng antas ng mga hindi kritikal na serbisyo.
Ang isa pang mahalagang elemento ay ang mga patakaran sa pag-backup at pagbawi ng data : ano ang bina-backup, saan, gaano kadalas, gaano katagal, at anong mga teknolohiya ang ginagamit (full, incremental, differential backups, snapshots, hot replication, atbp.). Bukod pa rito, ang pagpapanumbalik sa isang partikular na punto ng panahon ay dapat isaalang-alang upang maalis ang pinsalang dulot ng katiwalian o mga pag-atake.
Ang estratehiya ay kinukumpleto gamit ang isang mahusay na istrukturang plano ng komunikasyon (sino ang magpapaalam kung kanino at sa pamamagitan ng anong channel), isang programa ng mga pana-panahong pagsubok at drill upang mapatunayan na ang lahat ay gumagana sa ilalim ng pressure, at isang pagsasanay at pamamaraan ng kamalayan upang malaman ng mga pangkat kung ano ang gagawin sa isang emergency.
Ang limang pangunahing bloke ng isang komprehensibong plano para sa pagpapatuloy at pagbangon mula sa sakuna
Ang isang modernong diskarte sa pagpapatuloy ng negosyo ay karaniwang nakabalangkas sa paligid ng limang pangunahing plano na magkakaugnay. Ang bawat isa ay sumasaklaw sa iba't ibang aspeto ng pagtugon sa mga malubhang pagkabigo, at sama-samang bumubuo ang mga ito ng isang magkakaugnay na balangkas para sa aksyon.
Ang una ay ang business continuity plan , na nagbabalangkas sa mga hakbang upang makabalik sa "normal" na operasyon pagkatapos ng isang malaking pagkaantala. Kabilang dito ang pagtatasa ng pinsala, pagpapanumbalik ng sistema at datos, pagbibigay-priyoridad sa proseso, pagpapatunay ng antas ng serbisyo, at pormal na pagsasara ng insidente.
Ang pangalawa ay ang planong pang-emerhensya , na nakatuon sa agarang reaksyon sa panahon ng pangyayari: proteksyon ng mga tao, pag-activate ng mga protokol sa paglikas, pakikipag-ugnayan sa mga serbisyong pang-emerhensya, pagbabantay sa mga pisikal na ari-arian at pangunahing koordinasyon hanggang sa maging matatag ang sitwasyon.
Pangatlo ay ang business continuity plan , na tumutukoy kung paano pananatilihin ang mahahalagang tungkulin kapag ang sitwasyon ng krisis ay tumagal. Kabilang dito ang mga alternatibong lokasyon (mainit, mainit, at malamig na mga lugar), remote na trabaho, nabawasan ngunit sapat na mga mapagkukunan ng IT, muling pagtatalaga ng mga tungkulin, at mga contingency plan kasama ang mga supplier.
Ang ikaapat na seksyon ay ang plano sa pamamahala ng insidente , na nagbabalangkas sa pagtuklas, pag-uuri, pagpapalala, at pagsubaybay sa anumang kaugnay na insidente. Tinutukoy nito ang mga tungkulin ng crisis team, ang mga pamantayan para sa pagdedeklara ng isang sakuna, ang paggamit ng isang "war room," mga channel ng komunikasyon, at kung paano idinodokumento ang mga desisyon.
Panghuli, ang plano sa pagbangon mula sa kalamidad ay partikular na nakatuon sa mga teknikal na aspeto: muling pagtatayo ng imprastraktura, pag-activate ng mga replika, pagpapanumbalik ng datos, at pagpapatunay na ang mga kontrol sa impormasyon at seguridad ay buo. Dito inilalapat ang iba't ibang modalidad ng DR (on-premise, cloud, virtualization, DRaaS, atbp.).
Mga uri ng pagbangon mula sa sakuna at mga antas ng kapanahunan
Maaaring pagsamahin ng mga organisasyon ang iba't ibang pamamaraan upang protektahan ang kanilang sarili laban sa mga sakuna. Mula sa pinakasimple hanggang sa halos walang patid na mga kapaligiran, mayroong iba't ibang estratehiya at antas ng katatagan.
Ang pangunahing layunin ay simpleng pag-backup ng data : paggawa ng mga kopya at pag-iimbak ng mga ito sa ibang medium o lokasyon. Mahalaga ito, ngunit hindi sapat, dahil hindi nito kasama ang kinakailangang imprastraktura upang mabilis na maibalik ang mga serbisyo. Higit pa sa pangunahing pamamaraang ito ay ang mga solusyon tulad ng DRaaS (Disaster Recovery as a Service) , kung saan ang isang cloud provider ay kinokopya at nagho-host ng mga pisikal at virtual na server at nangangako sa pamamagitan ng kontrata (SLA) upang i-activate ang mga ito kapag may nangyaring sakuna.
Ang mga snapshot ay nagbibigay-daan sa iyong makuha ang estado ng mga sistema o dami ng data sa mga partikular na punto ng panahon. Ang mga ito ay lubhang kapaki-pakinabang para sa pagbabalik sa dating estado pagkatapos ng pagkasira o mga aksidenteng pagbabago, bagaman ang kanilang pagiging epektibo ay nakasalalay sa dalas ng pagkuha ng mga ito at kung ang mga ito ay nakaimbak sa mga lokasyon na hindi naapektuhan ng insidente.
Kinokopya ng virtual recovery ang imprastraktura ng IT sa mga panlabas na virtual machine (on-premises o cloud). Kung sakaling magkaroon ng sakuna, ang mga VM na ito ay maaaring mabilis na mai-deploy sa produksyon. Gayunpaman, nangangailangan ito ng madalas na pagkopya, sapat na bandwidth, at patuloy na pamamahala ng mga replika.
Kung titingnan ang klasikong balangkas ng disaster recovery , maaari tayong pumunta mula sa Level 0 (walang offsite data o plano) patungo sa Level 7 (lubos na awtomatiko, business-centric recovery). Kabilang sa mga intermediate level ang mga manual backup, automated backup, electronic vault, masinsinang paggamit ng mga snapshot, integridad ng transaksyon (pangunahin sa mga pinansyal na kapaligiran), at, sa Level 6 at 7, halos real-time na replication na may minimal o walang pagkawala ng data at halos awtomatikong proseso ng failover.
Ang pagpili ng tamang antas ay hindi usapin ng teknolohikal na kapritso, kundi ng pagbabalanse ng gastos, panganib, at mga pangangailangan ng negosyo . Hindi kayang bayaran ng isang bangko o ospital ang kahit ilang minutong downtime o hindi pare-parehong data, habang ang isang SME ay kayang tiisin ang ilang oras ng downtime at ilang pagkawala ng kamakailang data kung ang gastos sa pag-iwas dito ay hindi proporsyonal.
Disenyo ng arkitektura at mga pattern ng failover
Ang teknikal na arkitektura ay dapat idisenyo mula sa simula upang mapadali ang pagbangon. Ang pagdaragdag lamang ng DR sa dulo ng proyekto ay hindi sapat. Ang mga active-passive at multi-region deployment pattern ay dapat piliin na naaayon sa RTO/RPO at sa magagamit na badyet.
Sa isang cold standby configuration , ang pangalawang rehiyon o site ay may kaunting imprastraktura na naka-deploy hanggang sa magkaroon ng sakuna. Mura ito, ngunit mabagal ang failover dahil halos lahat ng bagay ay kailangang i-deploy nang sabay-sabay.
Sa isang mainit na standby , ang pangalawang rehiyon ay may mga mapagkukunang naka-deploy at gumagana sa mas mababang kapasidad, na nagbibigay-daan para sa mas mabilis na failover. Sa mga active-active scheme, ang parehong rehiyon ay humahawak sa trapiko at naghahati ng load, na nagpapalaki sa availability ngunit nagpapahirap sa pagkakapare-pareho ng data at nagpapataas ng mga gastos.
Bukod pa rito, mahalagang malinaw na tukuyin kung paano kinokopya ang impormasyon: synchronous replication (walang pagkawala ng data ngunit mas mataas na latency sa pagitan ng mga site) o asynchronous replication (limitadong pagkawala ng data kapalit ng mas mababang latency). Ang karaniwang pamamaraan ay ang paggamit ng synchronous replication sa loob ng parehong rehiyon o availability zone at asynchronous replication sa pagitan ng mga rehiyon na may malalayong heograpiya.
Ang isang komprehensibong disenyo para sa pangalawang rehiyon ay dapat kabilang ang kinakailangang compute layer, topolohiya ng network (mga VNET, subnet, ruta, firewall, security group), mga replicated identity at access service, pagsubaybay at mga alarma, at lahat ng bahagi ng aplikasyon at data. Ang imprastraktura ng network o seguridad ay hindi maaaring i-improvise sa panahon ng krisis; dapat itong lahat ay paunang na-configure at nasubukan.
Mahalaga rin na konseptwal na paghiwalayin ang failover (paglilipat ng workload sa backup region) mula sa failover (pagbabalik sa pangunahing region kapag ito ay naibalik na). Ito ay magkakaibang proseso na may magkakaibang panganib, at pareho itong dapat idokumento at i-automate hangga't maaari.
Mga backup, RTO, RPO at mga partikular na estratehiya para sa mga data center
Ang puso ng anumang disaster recovery plan (DRP) ay nakasalalay sa kung paano pinamamahalaan ang mga backup at kung paano inilalapat ang mga sukatan ng Recovery Time Objective (RTO) at Recovery Point Objective (RPO) . Kung wala ang mga layuning ito, imposibleng malaman kung ang diskarte sa backup ay sapat o hindi sapat.
Ang Recovery Time Objective (RTO) ay nagpapahiwatig kung gaano katagal maaaring mag-down ang isang sistema nang hindi nagdudulot ng hindi katanggap-tanggap na pinsala. Ang Recovery Point Objective (RPO) ay nagpapahiwatig kung gaano karaming pagkawala ng data (sa minuto, oras, araw) ang maaaring tiisin. Ang isang high-volume billing application ay maaaring mangailangan ng RPO na ilang minuto at RTO na wala pang isang oras, habang ang isang internal reporting system ay maaaring magpahintulot ng pang-araw-araw na RPO at RTO na ilang oras.
Sa isang proprietary data center , ang isang DRP ay dapat na detalyado: komprehensibong imbentaryo ng mga asset (hardware, software, lisensya, dependencies), pagsusuri ng epekto, pagtatasa ng mga pisikal na panganib (sunog, baha, pagkasira ng kuryente) at mga lohikal na panganib (mga cyberattack, mga error sa configuration), pisikal na redundancy (UPS, generator, duplicate cooling, redundant network links) at lohikal na redundancy (mga duplicated na server at serbisyo, active-active o active-passive mirror sites).
Dapat malinaw na tukuyin ng pamamahala ng backup ang mga uri ng backup (full, incremental, differential) , mga window ng backup, mga lokasyon (on-site, off-site, cloud, cold storage), disk encryption , mga panahon ng pagpapanatili, mga patakaran sa pag-access, at mga pamamaraan sa pag-verify ng integridad. Walang silbi ang pagkakaroon ng sampung taong halaga ng mga backup kung wala pa itong nasubukan at hindi maibabalik sa tamang oras.
Bukod pa rito, kailangang mayroong espesipikong plano sa komunikasyon para sa mga insidente sa data center (pagbibigay-alam sa mga naka-host na kliyente, pakikipag-ugnayan sa mga nagbibigay ng enerhiya o telekomunikasyon, pag-uulat sa pamamahala), mga mekanismo upang matiyak ang seguridad habang at pagkatapos ng kaganapan (pagpigil sa pag-urong, pagpapanumbalik ng mga kontrol sa pag-access, pagpapatunay na ang narekober na datos ay hindi minanipula) at isang malinaw na iskedyul ng mga pagsasanay at pag-awdit.
Organisasyon ng Pangkat sa Pagbawi at Pamamahala ng DRP
Ang isang disaster recovery plan (DRP) ay hindi kusang tumatakbo. Kailangan nito ng isang mahusay na pangkat na may malinaw na mga tungkulin at matatag na mga channel ng koordinasyon. Depende sa laki ng organisasyon, magkakaroon ng higit o mas kaunting espesyalisasyon, ngunit ang ilang mga profile ay karaniwan.
Sa malalaking kumpanya, karaniwang mayroong Chief Information Security Officer (CISO) , na responsable para sa estratehiya sa cybersecurity at gumaganap ng mahalagang papel sa pagbawi ng insidente, kabilang ang pagtataguyod ng multi-factor authentication . Ang isang IT security team ay karaniwang kumikilos sa paligid ng CISO, sinusubaybayan ang mga network at sistema, tinutukoy ang mga panghihimasok, kinokontrol ang tugon sa insidente, at nagbibigay ng mahahalagang impormasyon sa panahon ng isang sakuna.
Ang mga system at network administrator ang siyang nakakaalam ng mga teknikal na detalye ng imprastraktura: mga server, storage, komunikasyon, VPN, firewall, directory service, atbp. Kung wala sila, magiging napakahirap ibalik ang mga kumplikadong serbisyo o i-diagnose ang mga bottleneck sa panahon ng failover.
Maraming organisasyon din ang may mga IT operations at technical support team na, bagama't hindi palaging namamahala sa seguridad, ay mahalaga sa pag-troubleshoot, suporta sa user, pamamahala ng ticket, at pagsasagawa ng paulit-ulit na teknikal na gawain sa panahon ng recovery.
Hindi nagkukulang ang mga profile sa pamamahala ng peligro at pagsunod , na tumutulong na matiyak na ang DR at diskarte sa pagpapatuloy ay nakakatugon sa mga kinakailangan ng regulasyon ng sektor (pinansyal, kalusugan, pampublikong administrasyon, atbp.) at sa mga patakaran sa seguro o mga kasunduan sa kontrata sa mga kliyente.
Bukod pa rito, ang larangan ng komunikasyon at relasyon sa publiko ay mahalaga sa mga krisis na may panlabas na epekto: responsable ito sa paghahatid ng mga pare-parehong mensahe sa mga kliyente, kasosyo, media at awtoridad, pag-iwas sa mga kontradiksyon at paglabas ng impormasyon na nagpapalala sa pinsala sa reputasyon.
Panghuli, maraming kumpanya ang nagtatalaga ng isang partikular na Business Continuity Manager (BCP Manager) , na siyang nag-uugnay sa iba't ibang plano, tinitiyak na ang mga ito ay nasusubok, na-update at isinasama sa pang-araw-araw na operasyon, at nagsisilbing punto ng sanggunian sa panahon ng mga pagsasanay at totoong krisis.
Mga pamamaraan, automation at simulation: mula teorya hanggang pagsasanay
Isang karaniwang pagkakamali ang paniniwalang sapat na ang pagsulat lamang ng plano. Ang totoo, ang isang Disaster Recovery Plan (DRP) ay magiging kapaki-pakinabang lamang kung ito ay nasubukan sa ilalim ng makatotohanang mga kondisyon , awtomatiko hangga't maaari, at pinapanatiling aktibo. Kung hindi, pagdating ng panahon, walang makakaalam kung ano ang kailangang gawin, o ang mga pamamaraan ay magiging lipas na sa panahon.
Ang mga pamamaraan ay dapat isulat sa paraang masusunod ng sinumang sinanay na operator, kahit na sa ilalim ng pressure. Maipapayo na buuin ang mga ito ayon sa mga antas: mga hakbang sa antas ng component (hal., pagpapanumbalik ng isang partikular na database), mga hakbang sa antas ng data asset (mga set ng mga kaugnay na sistema), at mga hakbang sa antas ng workload (mga kumpletong aplikasyon na may maraming dependency). Dapat din itong magsama ng mga aksyon upang suriin kung ang iyong mga account ay nakompromiso kasunod ng mga insidente ng panghihimasok.
Malaking kakampi ang automation : mga declarative at idempotent script para sa pag-deploy ng imprastraktura, mga CI/CD pipeline na handa sa lahat ng rehiyon, mga orchestrator na nagsasagawa ng mga task sequence na may retry logic at circuit breaker, automated failover para sa mga serbisyong PaaS o IaaS, atbp. Siyempre, ito ay palaging nasa ilalim ng pangangasiwa ng tao, na may mga manual approval point kapag kinakailangan ng panganib.
Dapat maging bahagi ng regular na iskedyul ng organisasyon ang mga drill. Kapaki-pakinabang ang pagsasama-sama ng mga pagsasanay sa ibabaw ng mesa (pagsusuri sa teorya ng mga senaryo at tungkulin), teknikal na pagsubok sa mga kapaligirang hindi pangproduksyon (upang matukoy ang mga depekto sa pamamaraan nang walang panganib), at, kapag pinahihintulutan ng antas ng kapanahunan, maingat na pinlanong mga drill sa produksyon upang mapatunayan na natutugunan ang RTO/RPO sa mga totoong sitwasyon.
Ang bawat pagsasanay ay dapat magbunga ng mga aral na natutunan: susuriin ang dokumentasyon, iakma ang mga pamamaraan, pagbutihin ang mga awtomatikong proseso, at ibigay ang karagdagang pagsasanay sa mga kawaning nagpahayag ng mga pagdududa. Sa paglipas ng panahon, ang layunin ay maging isang halos nakagawiang proseso ang pagtugon sa sakuna, nang walang improvisasyon.
Patuloy na mga update, accessibility, at paggamit ng cloud upang palakasin ang DR
Mabilis na nagbabago ang mga sistema, banta, at ang organisasyon mismo. Samakatuwid, ang plano ng pagbawi ay dapat ituring na isang buhay na dokumento . Walang saysay na pinuhin pa ito tatlong taon na ang nakalilipas kung, mula noon, kalahati ng imprastraktura ay inilipat na sa cloud, naidagdag ang mga bagong aplikasyon ng SaaS, o nagbago ang mga kritikal na proseso.
Inirerekomenda na repasuhin ang Disaster Recovery Plan (DRP) nang hindi bababa sa bawat anim na buwan, o pagkatapos ng mga mahahalagang pagbabago (mga proyekto sa migrasyon, mga bagong linya ng negosyo, mga pangunahing pagbabago sa regulasyon, mga seryosong insidente). Dapat kasama sa bawat repasuhin ang mga pagsasaayos sa mga pamantayan sa pag-activate, mga pamamaraan, mga responsableng partido, at, kung kinakailangan, ang mga layunin mismo ng RTO/RPO.
Mahalaga rin ang pagiging naa-access ng plano sa pagbawi at mga tool sa panahon ng outage. Ang mga dokumentasyon, script, kredensyal, at sertipiko na kinakailangan upang patakbuhin ang DR ay dapat na nakaimbak sa mga lokasyon na madaling makuha, kopyahin sa iba't ibang rehiyon, at magkaroon ng mga kopya offline o kahit na naka-print para sa mga matinding sitwasyon kung saan walang access sa mga normal na sistema.
Panghuli, ang cloud ay naging pangunahing bahagi ng maraming estratehiya ng DR: mula sa mga multi-regional storage backup hanggang sa buong DRaaS o pagkopya ng mga virtual machine at database hanggang sa mga pangalawang rehiyon. Malaki ang nababawasan ng mga serbisyong ito sa gastos at pagiging kumplikado kumpara sa mga ganap na on-premises na backup infrastructure, habang pinapadali rin ang scalability habang lumalaki ang mga pangangailangan ng negosyo.
Kapag pinagsama-sama ang lahat ng ito—mahigpit na pagsusuri ng epekto, inihandang arkitektura, malinaw na mga plano, tinukoy na mga tungkulin, matalinong automation, madalas na mga simulation, at estratehikong paggamit ng cloud—ang organisasyon ay nagsisimula sa pagsisikap at pagsisikap patungo sa pagkakaroon ng tunay na kapasidad na makaligtas sa malulubhang pagkabigo , pagprotekta sa data nito, reputasyon nito, at, higit sa lahat, ang kakayahang magpatuloy sa pagpapatakbo kahit sa pinakamasamang sitwasyon.
