Application Resilience: Panatilihing Magagamit ang mga Windows Apps

Pakilala

Madalas na nakasalalay ang mga aplikasyon ng Windows sa higit pa sa server na nagho-host sa mga ito. Ang mga database, serbisyo ng pagkakakilanlan, imbakan, gateway, mga network at mga endpoint ng gumagamit ay maaaring makaapekto kung ang isang aplikasyon ay mananatiling magagamit sa panahon ng pagkagambala. Ipinaliwanag ng artikulong ito kung paano maaring suriin ng mga IT team ang mga nakasalalay na ito, magdisenyo ng katatagan sa paligid ng mga umiiral na aplikasyon ng Windows, subaybayan ang tamang mga layer at subukan kung ang mga plano sa pagbawi ay talagang nagpapanatili ng mga function ng negosyo na umaasa ang mga gumagamit.

Ano ang Application Resilience?

Ang katatagan ng aplikasyon ay ang kakayahan ng isang aplikasyon at ang imprastruktura sa paligid nito na patuloy na magbigay ng mahahalagang function sa panahon ng isang pagkaabala at makabawi nang maaasahan pagkatapos ng isang pagkabigo.

Ang pagkagambala ay maaaring maliit o malaki, at ang mga sanhi ay maaaring mag-iba mula sa pagkabigo ng hardware o operating system, mga pag-crash ng aplikasyon, nabigong mga update, mga outage ng database, mga pagka-abala sa network, mga pagkabigo sa pagpapatunay, pagkaubos ng mga mapagkukunan, mga hindi magagamit na dependencies o mga insidente sa seguridad.

Isang matibay na arkitektura ang kumikilala na ang mga pagkabigo ay hindi maiiwasan, at sa halip na layuning pigilan ang bawat insidente, ang mga organisasyon ng IT ay nagsisikap na limitahan ang epekto ng bawat isa at magtatag ng mga kontroladong pamamaraan ng pagbawi upang mapanatili o maibalik ang serbisyo.

Ang Katatagan ng Aplikasyon ay Higit Pa sa Uptime ng Server

Isang karaniwang pagkakamali ay ang paggamit ng kakayahang magamit ng isang server bilang proxy para sa kakayahang magamit ng aplikasyon, na tumatakbo sa server.

Upang ang isang aplikasyon ng negosyo ay talagang magamit, kinakailangang magamit ang ilang mga bahagi sa parehong oras:

Inprastruktura → Operating system → Aplikasyon → Mga Depende → Daan ng Access → Sesyon ng Gumagamit → Proseso ng Negosyo

Ang isang problema sa anumang elemento sa kadena na ito ay maaaring magresulta sa hindi pagiging available ng aplikasyon.

Halimbawa, maaaring maayos ang isang application server habang hindi ma-access ang database nito. Maaaring maayos ang isang na-publish na application ngunit ang pagkabigo ng gateway ay nagpapahirap sa mga remote na empleyado na ma-access ito. Maaaring matagumpay na ilunsad ng mga gumagamit ang application ngunit mapigilan sa pagkumpleto ng isang transaksyon dahil sa kakulangan ng lisensya, file, o backend na serbisyo.

Ang katatagan ng aplikasyon, samakatuwid, ay dapat sukatin batay sa kakayahan ng gumagamit na maisagawa ang kinakailangang gawain sa negosyo, sa halip na kung ang isang server ay kayang tumugon sa isang availability o health check.

Bakit Iba ang Application Resilience para sa mga Windows Application?

Ang mga modernong kasanayan sa pagtutol ay lalong nakatuon sa mga cloud-native na aplikasyon, mga lalagyan, mga microservices at awtomatikong orkestrasyon. Bagaman ang mga ito ay mga mahalagang pamamaraan, hindi sila palaging naaangkop sa bawat organisasyon.

Maraming mga organisasyon ang may mga legacy na Windows line-of-business na aplikasyon na binuo bago naging karaniwan ang mga cloud-native na arkitektura. Ang ERP software, mga aplikasyon sa accounting, mga aplikasyon sa pagmamanupaktura, mga aplikasyon sa pangangalagang pangkalusugan, mga aplikasyon sa engineering at mga aplikasyon na binuo sa loob ay maaaring maging kritikal sa mga operasyon ng isang organisasyon.

Ang muling pagbuo ng mga aplikasyon na ito bilang mga microservices ay maaaring maging napakamahal, teknikal na hamon, o kahit na ganap na hindi maisasakatuparan kung ang organisasyon ay hindi nagkokontrol sa source code.

Sa ganitong mga kaso, maaaring may malaking halaga sa paggawa ng mga operasyon sa paligid ng aplikasyon na mas matatag, sa halip na subukang gawing mas matatag ang mismong aplikasyon. Pag-publish ng aplikasyon maaaring maging bahagi ng diskarte na ito sa pamamagitan ng pagpapanatili ng umiiral na mga aplikasyon ng Windows sa sentralisadong imprastruktura habang binabago ang paraan ng pag-access ng mga gumagamit sa mga ito. Maaaring kabilang dito ang mga pagbabago sa imprastrukturang nagho-host ng aplikasyon, tulad ng pag-aalis ng mga hadlang sa imprastruktura, paglikha ng mga redundant na host ng aplikasyon, pagpapagana ng mga alternatibong pamamaraan ng pag-access at pagpapatupad ng mas tumutugon na mga pamamaraan ng pagbawi para sa host ng aplikasyon.

Sa Aling Kaso Maaaring Mabigo ang Pagkakaroon ng Isang Windows Application?

Ang pagbuo ng katatagan ng aplikasyon ay nagsisimula sa pagtuklas ng mga bahagi na kinakailangan upang matagumpay na maihatid ang isang aplikasyon mula sa kanilang mga host patungo sa mga gumagamit. Itinatampok ng prosesong ito ang mga potensyal na punto ng pagkabigo na maaaring magpabagsak sa isang buong aplikasyon.

Mga Host ng Aplikasyon

Isang aplikasyon na tumatakbo sa isang solong Windows server ay may malinaw na solong punto ng pagkabigo.

Mga isyu sa hardware, mga pag-update ng Windows, pagkasira ng operating system, pagkaubos ng mapagkukunan o pagkabigo ng aplikasyon ay maaaring makagambala sa bawat gumagamit na umaasa sa makinang iyon. Kung kinakailangan ang mga pangangailangan sa pagkakaroon, maaaring maglagay ng maraming host ng aplikasyon upang mabawasan ang pag-asa sa anumang isang makina at magbigay ng kapasidad kapag ang isang server ay naging hindi magagamit.

Mga Database, Imbakan at Ibang Mga Depende

Maraming mga aplikasyon ng Windows ang umaasa sa mga serbisyong panlabas sa host ng aplikasyon. Ang mga serbisyong ito ay maaaring kabilang ang:

• mga SQL database
• file shares
• mga server ng lisensya
• Active Directory
• Sistema ng Pangalan ng Domain (DNS)
• sertipiko
• APIs
• middleware
• imbakan ng network
• imprenta ng imprastruktura

Ang pagpapakilala ng pangalawang application server ay nagbibigay ng minimal na resiliency kung sila ay nagbabahagi ng isang karaniwang database o storage dependency na hindi available. Nagiging maliwanag na ang dependency mapping ay kailangang lumampas sa nakikitang application infrastructure.

Pagpapatotoo at Pagkakakilanlan

Hindi makakapasok ang mga gumagamit sa isang maayos na aplikasyon kung ang kinakailangang imprastruktura ng pagpapatunay ay hindi magagamit.

Kailangan ng mga IT team na tukuyin ang mga serbisyo ng pagkakakilanlan na nakasalalay sa kanilang mga kritikal na aplikasyon at tiyakin na mayroon silang mga plano para sa failover kapag ang mga mapagkukunang ito ay hindi ma-access. Ang Active Directory, mga platform ng pagkakakilanlan sa cloud, mga serbisyo ng multi-factor authentication (MFA) at mga gateway ng authentication ay maaaring asahan upang magbigay ng isang kadena ng availability para sa isang aplikasyon.

Network at Remote Access Paths

Para sa sentralisadong mga aplikasyon ng Windows, ang koneksyon sa pagitan ng mga gumagamit at ng kapaligiran ng aplikasyon ay kumakatawan sa isa pang posibleng domain ng pagkabigo.

Isipin natin ang kumpletong kadena:

User device → Internet o LAN → gateway → application host → backend services

Ang anumang pagkasira sa kadena na ito ay maaaring pumigil sa mga gumagamit na gawin ang kanilang mga trabaho kahit na ang aplikasyon ay maayos na tumatakbo. Lalo itong mahalaga para sa mga distributed na organisasyon kung saan ang aplikasyon ay maaaring tumakbo sa data center ngunit hindi ma-access ng mga gumagamit sa ibang lokasyon.

Mga Endpoints

Ang katatagan ng aplikasyon ay hindi kinakailangang mangailangan ng normal na workstation ng gumagamit na maging available.

Nag-aalok sa mga awtorisadong gumagamit ng mga paraan upang ma-access ang mga sentral na naka-host na aplikasyon mula sa isang alternatibong aparato o sa pamamagitan ng isang browser ay maaaring matiyak ang access, kung ang isang laptop ay hindi magagamit, ang isang opisina ay nagiging hindi maa-access o ang mga empleyado ay kailangang magtrabaho mula sa ibang lokasyon.

Ang arkitektura ng paghahatid ng aplikasyon ay maaaring maging bahagi ng mas malawak na estratehiya para sa pagpapanatili ng negosyo.

Ano ang Proseso ng Pagtatayo ng Katatagan ng Aplikasyon para sa mga Windows Apps?

Walang solong teknolohiya ang nagpapalakas sa aplikasyon. Sa halip, kailangang bawasan ng mga IT team ang bilang ng mga pagkabigo na maaaring magpahinto sa isang kumpletong function at maghanda para sa mga kontroladong mekanismo ng pagbawi para sa mga nananatili.

1. Tukuyin ang mga Kritikal na Aplikasyon at Proseso ng Negosyo

Hindi lahat ng aplikasyon ay nangangailangan ng parehong antas ng proteksyon. Simulan sa pagtukoy kung aling mga aplikasyon ang sumusuporta sa mga pangunahing operasyon, aling mga gumagamit ang umaasa sa mga ito at ang kanilang pagtanggap sa downtime.

Dalawang layunin ng pagbawi ay isinasalin ang mga kinakailangan ng negosyo sa mga teknikal na pagtutukoy. payo ng NIST sa pagpaplano ng contingency nagtatakda ng Recovery Time Objective (RTO) at Recovery Point Objective (RPO) bilang mga pangunahing parameter para sa pagtukoy ng mga kinakailangan sa pagbawi:

• Layunin ng Oras ng Pagbawi (RTO): isang tagal ng katanggap-tanggap na downtime bago maibalik ang serbisyo.
• Recovery Point Objective (RPO): isang agwat ng katanggap-tanggap na pagkawala ng data, na sinusukat sa oras.

Isang aplikasyon na ginagamit nang labis upang iproseso ang mga order ay maaaring magkaroon ng RTO na ilang minuto, samantalang ang isang aplikasyon para sa ulat sa pananalapi na tumatakbo isang beses sa isang linggo ay maaaring magtiis ng ilang araw na downtime.

Ang RTO at RPO ay nagtatakda ng uri ng proteksyon na kinakailangan para sa isang aplikasyon: agarang paglipat, mabilis na muling pagtatatag ng mga serbisyo o simpleng nakadokumento na pamamaraan ng pagbawi.

2. I-map ang Buong Application Dependency Chain

Dokumentuhin ang lahat ng kinakailangan para magawa ng aplikasyon ang kanyang trabaho.

Huwag huminto sa executable o Windows server. Huwag kalimutan ang mga database, imbakan, pagpapatotoo, DNS, networking, mga sertipiko, mga sistema ng lisensya, mga gateway at mga panlabas na serbisyo.

Para sa bawat isa, itanong:

Ano ang mangyayari sa aplikasyon kung mawala ito?

Ang ehersisyo na ito ay maglalantad ng mga nakatagong solong punto ng pagkabigo at magtatatag ng pagkakasunod-sunod ng pagbawi. Ang pag-restore ng isang host ng aplikasyon muna ay hindi gaanong nakakatulong kung ang database, serbisyo ng pagkakakilanlan, o imbakan nito ay hindi pa available.

3. Alisin ang Kritikal na Nag-iisang Punto ng Pagkabigo

Kapag naitatag na ang dependency tree, tukuyin kung aling mga bahagi ang dapat gawing redundant, batay sa kahalagahan ng negosyo at mga layunin sa pagbawi.

Sa kaso ng paghahatid ng aplikasyon sa Windows, maaaring kasangkutan nito ang pag-deploy ng ilang mga application server sa halip na umasa sa mga kakayahan ng isang solong host. Sa isang layer ng load balancing, ang mga sesyon ay maaaring ipamahagi sa mga instance ng aplikasyon sa panahon ng normal na operasyon. Sa kaso ng pagkabigo ng host, ang mga papasok na koneksyon ay maaaring i-route sa mga malusog na instance ng application server.

Ang pagpaplano ng redundancy ay dapat na batay sa pagsusuri ng dependency, gayunpaman. Ang maraming application server na uma-access sa isang kritikal na database, network gateway o storage layer ay patuloy na nagtatanghal ng isang solong punto ng pagkabigo.

Dapat isaalang-alang ng disenyo ng mataas na kakayahang magamit ang serbisyo ng aplikasyon bilang isang pinagsamang entidad. Para sa mga kapaligiran ng Windows Server na nangangailangan ng redundancy sa antas ng imprastruktura, Dokumentasyon ng Failover Clustering ng Microsoft nagbibigay ng karagdagang gabay sa mga topology ng mataas na kakayahang magamit at pagbawi mula sa sakuna.

4. Paghiwalayin ang mga Aplikasyon Mula sa Bawat Endpoint

Ang pag-install ng isang kritikal na aplikasyon nang direkta sa bawat workstation ng empleyado ay maaaring lumikha ng ibang uri ng isyu sa katatagan. Kung mawalan ng access ang mga gumagamit sa kanilang karaniwang computer, maaari rin silang mawalan ng access sa mga aplikasyon na kailangan nila upang magpatuloy sa pagtatrabaho.

Pagpapa-centralize ng mga aplikasyon sa mga pinamamahalaang Windows host at ang pagpapakita ng interface ng aplikasyon sa mga gumagamit ay nag-aalis ng panganib na ito. Ang data at estado ng aplikasyon ay nakaimbak sa pinamamahalaang Windows host at naa-access ng mga awtorisadong endpoint.

Sa paggawa nito, ginagawa naming available ang aplikasyon sa mga gumagamit kahit na sila ay magpalit ng mga device o lokasyon. Habang ang pag-centralize ng mga aplikasyon ay hindi nag-aalis ng mga isyu sa imprastruktura, nakakatulong ito na ilipat ito sa isang kapaligiran kung saan maaari itong kontrolin ng IT.

Magbigay ng Higit sa Isang Praktikal na Paraan ng Access

Maaaring makamit ang katatagan sa pamamagitan ng pag-iwas sa hindi kinakailangang pag-asa sa isang uri ng endpoint o paraan ng koneksyon.

Depende sa arkitektura ng paghahatid ng aplikasyon, maaaring gumamit ang mga gumagamit ng iba't ibang remote access mga pamamaraan, kabilang ang isang RDP-compatible na kliyente, nakalaang tagapagpatakbo ng aplikasyon, web portal o HTML5 na sesyon ng browser.

Ang mga alternatibong paraan ng koneksyon ay hindi dapat ipagkamali sa redundancy ng imprastruktura. Kung lahat ay umaasa sa parehong nabigong server, ang aplikasyon ay hindi pa rin magagamit.

Nagbibigay sila ng access resilience kapag ang pagka-abala ay nakakaapekto sa normal na aparato ng isang gumagamit, naka-install na kliyente o lokasyon sa halip na ang mismong serbisyo ng aplikasyon.

6. Subaybayan Bago Magdulot ng Pagkaabala

Ang katatagan ng aplikasyon ay hindi lamang tungkol sa pagbawi, kundi ang maagang pagtuklas ay maaaring maiwasan ang pagkasira na humahantong sa isang outage.

Mga tagapagpahiwatig na kapaki-pakinabang sa mga kapaligiran ng aplikasyon ng Windows ay ang paggamit ng CPU, presyon ng memorya, kapasidad ng disk at I/O, paggamit ng network, aktibong sesyon, proseso ng aplikasyon, oras ng pagtugon, nabigong koneksyon at pagkakaroon ng mga nakadependeng serbisyo.

Pagsubaybay sa uso ay mahalaga, dahil ang isang server na paulit-ulit na umabot sa mga limitasyon nito ay maaari pa ring maging online habang unti-unting bumababa ang karanasan ng gumagamit.

Ang mga threshold alert ay nagbibigay-daan sa mga administrador na suriin ang mga precursor ng isang insidente bago mawalan ng access ang mga gumagamit.

7. Magplano para sa mga Pagsabog ng Kapasidad at Paglipat ng Pagsuporta

Isang aplikasyon na nakakaligtas sa mga pagkasira sa antas ng hardware ngunit ganap na hindi makapag-function sa ilalim ng mga tumaas na pangangailangan ay hindi tunay na matatag sa mga pagkasira ng anumang uri.

Ang pagpaplano para sa kapasidad ay dapat isaalang-alang hindi lamang ang mga pangkaraniwang pattern ng paggamit kundi pati na rin ang mga peak dahil sa mga seasonal na pangangailangan, pagbabago ng shift, paglago, o mga kinakailangan sa pagho-host para sa iba pang mga aplikasyon.

Partikular sa mga multi-server hosting na kapaligiran, ang pagkawala ng isang solong server ay dapat isaalang-alang sa pamamagitan ng pagtiyak na ang iba pang mga hosting node ay may ekstrang kapasidad upang tumanggap ng anumang mga proseso na kung hindi man ay isasagawa sa nabigong node.

Kung hindi, ang mga pamamaraan ng fail-over ay maaaring gawing isang malawak na isyu sa pagganap ng sistema ang isang nakahiwalay na insidente.

8. Protektahan ang Data at Konfigurasyon

Ang kapalit na Windows server ay hindi gaanong kapaki-pakinabang kung hindi maibabalik ng IT ang mga bahagi na kinakailangan upang gumana ang aplikasyon.

Ito ay maaaring mangahulugan na ang mga pamamaraan ng backup ay kailangang isama ang data ng aplikasyon, mga database, mga configuration file, mga sertipiko, mga setting ng aplikasyon, mga profile ng gumagamit, configuration ng imprastruktura, mga script at impormasyon sa paglisensya.

Ang estratehiya ay mag-iiba depende sa Recovery Time Objective (RTO) at Recovery Point Objective (RPO) ng aplikasyon.

S higit sa lahat, tiyakin na ang matagumpay na backup ay hindi katumbas ng matagumpay na pagbawi. Dapat subukan ng mga IT team na posible na ibalik ang buong serbisyo ng aplikasyon mula sa protektadong data at configuration.

9. Bawasan ang Blast Radius ng mga Pagbabago

Hindi palaging isang kaso ng hindi inaasahang sakuna ang nagiging sanhi ng mga pagkaantala. Maari rin itong sanhi ng mga ipinatupad na pagpapabuti. Kaya, ang mga patch ng Windows, pag-upgrade ng aplikasyon at driver, mga pagbabago sa patakaran sa seguridad at configuration ay maaari ring magkaroon ng negatibong epekto sa kakayahang magamit ng aplikasyon. Inirerekomenda na iwasan ang paggawa ng katulad na mga pagbabago sa lahat ng production host nang sabay-sabay kung maaari.

Sa isang multi-server na setup, posible na isagawa ang mga pagbabago sa pagpapabuti sa mga yugto, na nagbibigay-daan sa administrator na matiyak na ang lahat ay gumagana nang tama. Ang kakayahang ibalik ang mga pagbabagong ginawa ay mahalaga rin.

Kaya, kapag nagdidisenyo ng mga contingency procedure, dapat isaalang-alang ang mga rollback option. Ang proseso ay dapat na maayos na naidokumento, at dapat malaman ng mga tauhan kung ano ang gagawin kung mabigo ang isang pagbabago, sa halip na basta iwanan ito sa kanilang pasya.

10. Disenyo para sa Maayos na Pagbaba

Ang katatagan ay hindi tungkol sa pagpapanatili ng 100% ng mga normal na function na tumatakbo sa lahat ng oras.

Sa ilang mga kaso, ang pagpapanatili ng operasyon para sa mga pangunahing gumagamit o aplikasyon ay maaaring mas mahalaga kaysa sa pagpapanatili ng lahat ng serbisyo na magagamit para sa lahat ng gumagamit. Maaaring itakda ang mga prayoridad bago mangyari ang isang insidente ng mga koponan ng IT.

Kung mayroong kapasidad na magagamit na maaaring gamitin, maaaring magkaroon ng kahulugan na ilaan ito muna sa produksyon, serbisyo sa customer, pananalapi o iba pang mga tungkulin.

Iyan ay maayos na pagbagsak: pinapanatili ang kakayahang patakbuhin ang mga function na bumubuo ng pinakamalaking halaga sa negosyo, sa halip na hayaan ang pagkabigo ng mga hindi gaanong kritikal na elemento na magdulot ng pagbagsak ng buong sistema.

Paano Dapat Subaybayan ng mga IT Team ang Katatagan ng Aplikasyon?

Ang pagmamanman ng mga indibidwal na server ay maaaring maging kapaki-pakinabang, ngunit ang pagmamanman ng katatagan ay dapat ipakita ang kabuuang serbisyo ng aplikasyon ayon sa pagkakaunawa ng mga gumagamit.

Isang makatotohanang modelo ay binubuo ng ilang mga layer:

Layer	Ano ang Dapat I-monitor	Halimbawa ng Kabiguan
Host	CPU, RAM, disk, OS availability	Server na labis na kargado o offline
Aplikasyon	Proseso at katayuan ng serbisyo	Nabibigo ang aplikasyon
Depende	Database, DNS, pagkakakilanlan, imbakan	Nagsisimula ang aplikasyon ngunit hindi makapag-operate
Access	Gateway, portal, landas ng network	Hindi makakakonekta ang mga gumagamit
Sesyon	Mga aktibong gumagamit, mga pagkabigo, pagkaantala	Ang aplikasyon ay online ngunit hindi magamit.
Pangangalakal na tungkulin	Matagumpay na pagkumpleto ng daloy ng trabaho	Hindi makumpleto ng gumagamit ang kinakailangang gawain.

Ang layer ng business-function ay isa sa pinakamadaling balewalain.

Maaaring ipakita ng mga dashboard ng imprastruktura ang lahat ng server, serbisyo, at landas ng network bilang malusog, habang ang workflow ng isang tunay na gumagamit ay naapektuhan. Mahalaga para sa mga kritikal na aplikasyon na subaybayan ang kanilang kalusugan mula sa pananaw ng operasyon na dinisenyo silang suportahan.

Paano Dapat Subukan ang Katatagan ng Aplikasyon?

Isang arkitekturang may katatagan na hindi kailanman nakaranas ng kontroladong pagkabigo ay naglalaman ng mga hindi nasubok na palagay.

Gamitin ang pagsubok upang suriin ang tugon ng sistema kapag ang mga pangunahing bahagi ay hindi magagamit. Dapat isama sa mga pagsubok ang pagkuha ng isang host ng aplikasyon offline, pagtigil sa isang serbisyo ng aplikasyon, pagsasagawa ng pagkawala ng isang ruta ng network, pag-verify ng pag-uugali ng gateway o load-balancing, pagbawi mula sa backup at pag-access sa aplikasyon mula sa isang alternatibong endpoint.

Dapat lumampas ang mga proseso ng pagsubok sa mga teknikal na aspeto ng pagbawi. Dapat suriin ng mga koponan ng IT kung ang mga alerto ay ipinapadala sa tamang mga administratibong tauhan, ang mga hakbang sa pagbawi ay isinasagawa sa tamang pagkakasunod-sunod, at ang mga gumagamit ay makakagawa ng aktwal na gawain sa negosyo pagkatapos maibalik ang mga serbisyo.

Ang mga operational procedures ay mahalaga sa isang matatag na sistema. Mga pamamaraan ng pag-akyat ng alerto: sino ang tumatanggap ng alerto? Sino ang may awtoridad na magsimula ng failover? Saan nakaimbak ang mga dokumento ng pagbawi at mga kredensyal? Aling dependency ang kailangang umandar muna?

Ang teknikal na redundancy ay nagbibigay ng kaunting benepisyo kung ang mga proseso upang makuha muli ang access ay hindi nasubukan.

Ano ang Maaaring Maging Checklist ng Resilience ng Aplikasyon?

Bago simulan ang isang kritikal na Windows application na matibay, dapat kayang sagutin ng mga IT team ang mga sumusunod na tanong:

• Aling mga proseso ng negosyo ang umaasa sa aplikasyon?
• Ano ang mga RTO at RPO nito?
• Aling mga server, database, at panlabas na serbisyo ang kinakailangan nito?
• Saan ang mga kritikal na solong punto ng pagkabigo nito?
• Maaari bang tumanggap ng mga gumagamit ang ibang host ng aplikasyon kung mabigo ang isang host?
• Maaari bang kumonekta ang mga gumagamit kung ang kanilang normal na endpoint o lokasyon ay hindi magagamit?
• Sapat ba ang ekstrang kapasidad para sa nabawasang operasyon?
• Aktibong minomonitor ang mga problema sa imprastruktura, dependency, at session?
• Nakapagbibigay ba ng alerto ang mga administrador bago maging outage ang mga mahahalagang threshold?
• Naka-protektahan ba ang data ng aplikasyon at configuration?
• Nasubukan na ba ang pagbawi?
• Maaari bang ibalik ang mga problematikong pagbabago?
• Naka-dokumento ba ang pagkakasunod-sunod ng pagbawi?
• Maaari bang tapusin ng mga gumagamit ang kinakailangang proseso ng negosyo pagkatapos ng pagbawi?

Hindi lahat ng sagot ay nangangailangan ng mamahaling mataas na kakayahang magamit na imprastruktura. Ang tamang antas ng proteksyon ay nakasalalay sa gastos at epekto sa operasyon ng downtime.

Ang mahalaga ay ang mga desisyon sa availability, redundancy, at recovery ay ginagawa nang may layunin, sa halip na ipagpalagay.

Paano Makakatulong ang TSplus na Panatilihing Magagamit ang mga Windows Application?

Para sa mga organisasyon na umaasa sa mga umiiral na Windows application, makakatulong kami na mapabuti ang availability sa pamamagitan ng pag-centralize ng mga application sa mga pinamamahalaang Windows server at paghahatid ng mga ito sa mga gumagamit sa pamamagitan ng mga RDP-compatible na kliyente, RemoteApp-style na access o isang HTML5 web portal. Binabawasan nito ang pag-asa sa mga indibidwal na endpoint ng gumagamit at nagbibigay sa mga IT team ng higit na kakayahang umangkop kapag ang mga gumagamit ay kailangang kumonekta mula sa ibang device o lokasyon.

TSplus Remote Access maaaring suportahan din ang multi-server deployments na may load balancing at gateway-based access. Kapag pinagsama sa mga matatag na database, imbakan, serbisyo ng pagkakakilanlan at networking, ang arkitekturang ito ay maaaring bawasan ang pag-asa sa isang solong application host at makatulong na mapanatili ang access sa mga kritikal na Windows application sa panahon ng pagka-abala sa imprastruktura.

Wakas

Ang katatagan ng aplikasyon ay nakasalalay sa pag-unawa sa kumpletong landas sa pagitan ng imprastruktura at paggamit ng negosyo. Ang redundancy, pagmamanman, backup, pagpaplano ng kapasidad at mga pamamaraan ng pagbawi ay pinaka-epektibo kapag idinisenyo ang mga ito sa paligid ng malinaw na tinukoy na mga dependency ng aplikasyon at mga layunin ng pagbawi.

Para sa mga umiiral na aplikasyon ng Windows, ang katatagan ay kadalasang nagmumula sa pagpapalakas ng kapaligiran sa paligid ng software sa halip na muling itayo ang mismong aplikasyon. Ang pangunahing pagsubok ay nananatiling simple: kapag naganap ang pagkaabala, maaari bang magpatuloy ang mga gumagamit sa pagtatrabaho, o maaari bang ibalik ng IT ang kinakailangang function ng negosyo sa loob ng napagkasunduang oras ng pagbawi?