Sovelluksen kestävyys: Pidä Windows-sovellukset saatavilla

Johdanto

Windows-sovellukset riippuvat usein paljon enemmän kuin vain palvelimesta, joka isännöi niitä. Tietokannat, identiteettipalvelut, tallennus, portit, verkot ja käyttäjäpisteet voivat kaikki vaikuttaa siihen, pysyykö sovellus käytettävissä häiriöiden aikana. Tämä artikkeli selittää, kuinka IT-tiimit voivat arvioida näitä riippuvuuksia, suunnitella resilienssiä olemassa olevien Windows-sovellusten ympärille, valvoa oikeita kerroksia ja testata, säilyttävätkö palautussuunnitelmat todella liiketoimintatoiminnot, joihin käyttäjät luottavat.

Mikä on sovelluksen kestävyys?

Sovelluksen kestävyys on sovelluksen ja sen ympärillä olevan infrastruktuurin kyky jatkaa elintärkeiden toimintojen tarjoamista häiriön aikana ja toipua ennakoitavasti vian jälkeen.

Häiriö voi olla pieni tai suuri, ja syyt voivat vaihdella laitteiston tai käyttöjärjestelmän vian, sovellusten kaatumisten, epäonnistuneiden päivitysten, tietokantakatkosten, verkkokatkosten, todennusvirheiden, resurssien loppumisen, saatavilla olevien riippuvuuksien tai tietoturvatapahtumien välillä.

Kestävä arkkitehtuuri tunnustaa, että epäonnistumiset ovat vä不可避, ja sen sijaan, että pyrittäisiin estämään jokainen tapaus, IT-organisaatiot pyrkivät rajoittamaan jokaisen vaikutusta ja luomaan hallittuja palautusmenettelyjä palvelun ylläpitämiseksi tai palauttamiseksi.

Sovelluksen kestävyys on enemmän kuin palvelimen käyttöaika

Yleinen virhe on käyttää palvelimen saatavuutta sovelluksen saatavuuden mittarina, joka toimii palvelimella.

Jotta liiketoimintasovellus olisi todella saatavilla, useiden komponenttien on oltava saatavilla samanaikaisesti:

Infrastruktuuri → Käyttöjärjestelmä → Sovellus → Riippuvuudet → Käyttöpolku → Käyttäjäistunto → Liiketoimintaprosessi

Ongelma minkä tahansa tämän ketjun elementin kanssa voi johtaa sovelluksen käytön estymiseen.

Esimerkiksi sovelluspalvelin voi olla kunnossa, vaikka sen tietokanta ei ole käytettävissä. Julkaistu sovellus voi toimia oikein, mutta porttivirhe estää etätyöntekijöitä pääsemästä siihen. Käyttäjät voivat jopa onnistua käynnistämään sovelluksen, mutta heitä voidaan estää suorittamasta tapahtumaa, koska lisenssi, tiedosto tai taustapalvelu ei ole käytettävissä.

Sovelluksen kestävyys tulisi siten mitata käyttäjän kyvyn mukaan suorittaa tarvittava liiketoimintatehtävä, eikä sen mukaan, pystyykö palvelin vastaamaan saatavuus- tai terveyden tarkistukseen.

Miksi sovelluksen kestävyys on erilainen Windows-sovelluksille?

Modernit resilienssikäytännöt keskittyvät yhä enemmän pilvipohjaisiin sovelluksiin, kontteihin, mikropalveluihin ja automatisoituun orkestrointiin. Vaikka nämä ovat arvokkaita lähestymistapoja, ne eivät aina ole sovellettavissa jokaiseen organisaatioon.

Monilla organisaatioilla on perinteisiä Windows-yrityssovelluksia, jotka on kehitetty ennen kuin pilvipohjaiset arkkitehtuurit olivat yleisiä. ERP-ohjelmistot, kirjanpitosovellukset, valmistussovellukset, terveydenhuollon sovellukset, insinöörisovellukset ja sisäisesti kehitetyt sovellukset voivat kaikki olla kriittisiä organisaation toiminnalle.

Sovellusten uudelleenarkkitehtuurointi mikropalveluina voi olla äärimmäisen kallista, teknisesti haastavaa tai jopa täysin mahdotonta, jos organisaatio ei hallitse lähdekoodia.

Tällaisissa tapauksissa voi olla merkittävää arvoa tehdä sovelluksen ympärillä olevista toiminnoista kestävämpiä sen sijaan, että yritetään tehdä itse sovelluksesta kestävämpi. Sovellusten julkaiseminen voi olla osa tätä lähestymistapaa pitämällä olemassa olevat Windows-sovellukset keskitettynä infrastruktuurina samalla kun muutetaan tapaa, jolla käyttäjät pääsevät niihin. Tämä voi sisältää muutoksia sovellusta isännöivään infrastruktuuriin, kuten infrastruktuurirajoitusten poistamisen, redundanteiden sovellusisäntien luomisen, vaihtoehtoisten pääsytapojen mahdollistamisen ja sovellusisännän palautusmenettelyjen parantamisen.

Missä tapauksessa Windows-sovelluksen saatavuus voisi epäonnistua?

Sovelluksen kestävyyden rakentaminen alkaa niiden komponenttien löytämisestä, joita tarvitaan sovelluksen onnistuneeseen toimittamiseen isänniltä käyttäjille. Tämä prosessi korostaa mahdollisia vikaantumispisteitä, jotka voivat kaataa koko sovelluksen.

Sovellusalustat

Yksi Windows-palvelimella toimiva sovellus sisältää selkeän yksittäisen vikasietopisteen.

Laitteistoviat, Windows-päivitykset, käyttöjärjestelmän vauriot, resurssien loppuminen tai sovelluksen kaatuminen voivat häiritä jokaista käyttäjää, joka riippuu kyseisestä koneesta. Jos saatavuusvaatimukset sitä edellyttävät, useita sovellushosteja voidaan ottaa käyttöön riippuvuuden vähentämiseksi yhdestä koneesta ja kapasiteetin tarjoamiseksi, kun palvelin ei ole käytettävissä.

Tietokannat, tallennus ja muut riippuvuudet

Monet Windows-sovellukset ovat riippuvaisia sovellushostin ulkopuolisista palveluista. Nämä palvelut voivat sisältää:

• SQL-tietokannat
• tiedostojen jakaminen
• lisensointipalvelimet
• Active Directory
• Verkkotunnusjärjestelmä (DNS)
• sertifikaatit
• APIt
• välikerros
• verkkotallennus
• printtialustat

Toinen sovelluspalvelin tarjoaa vain minimaalista vikasietoisuutta, jos ne jakavat yhteisen tietokannan tai tallennusriippuvuuden, joka ei ole saatavilla. On selvää, että riippuvuuskartoituksen on ulotuttava näkyvän sovellusinfrastruktuurin ulkopuolelle.

Todennus ja identiteetti

Käyttäjät eivät voi käyttää toimivaa sovellusta, jos tarvittava todennusinfra on poissa käytöstä.

IT-tiimien on tunnistettava ne identiteettipalvelut, joista heidän kriittiset sovelluksensa riippuvat, ja varmistettava, että heillä on varajärjestelysuunnitelmat paikoillaan, kun nämä resurssit eivät ole käytettävissä. Active Directory, pilvi-identiteettialustat, monivaiheinen todennus (MFA) -palvelut ja todennusportit voivat kaikki olla luotettavia tarjoamaan saatavuusketjun sovellukselle.

Verkko- ja etäyhteysreitit

Keskitettyjen Windows-sovellusten osalta käyttäjien ja sovellusympäristön välinen yhteys edustaa toista mahdollista vika-aluetta.

Kuvitellaanpa koko ketju:

Käyttäjän laite → Internet tai LAN → portti → sovellushost → taustapalvelut

Mikä tahansa katkos tässä ketjussa voi estää käyttäjiä tekemästä työtään, vaikka sovellus toimisi moitteettomasti. Tämä on erityisen tärkeää hajautetuissa organisaatioissa, joissa sovellus saattaa olla toiminnassa datakeskuksessa, mutta käyttäjille toisessa sijainnissa se on saavuttamattomissa.

Päätelaitteet

Sovelluksen kestävyys ei välttämättä vaadi käyttäjän normaalia työasemaa olevan saatavilla.

Tarjoamalla valtuutetuille käyttäjille keinot käyttää keskitetysti isännöityjä sovelluksia vaihtoehtoiselta laitteelta tai selaimen kautta voidaan varmistaa pääsy, jos kannettava tietokone ei ole käytettävissä, toimisto on saavuttamattomissa tai työntekijöiden on työskenneltävä eri sijainnista.

Sovellusten toimitusarkkitehtuuri voi olla osa laajempaa liiketoiminnan jatkuvuusstrategiaa.

Mikä on prosessi Windows-sovellusten sovelluskestävyyden rakentamiseksi?

Yksikään teknologia ei tee sovelluksesta kestävä. IT-tiimien on sen sijaan vähennettävä vikojen määrää, jotka voivat kaataa koko toiminnon, ja valmistauduttava hallittuihin palautusmekanismeihin niille, jotka pysyvät.

1. Tunnista kriittiset sovellukset ja liiketoimintaprosessit

Kaikki sovellukset eivät vaadi samaa suojaustasoa. Aloita selvittämällä, mitkä sovellukset tukevat ensisijaisia toimintoja, mitkä käyttäjät luottavat niihin ja mikä on niiden käyttökatkosten sietokyky.

Kaksi palautustavoitetta kääntää liiketoimintavaatimukset teknisiksi eritelmiksi. NISTin varautumissuunnittelun ohjeet määrittelee palautumisaikakohteen (RTO) ja palautuspisteen kohteen (RPO) keskeisiksi parametreiksi palautumistarpeiden määrittämiseksi:

• Palautusaika (RTO): hyväksyttävä käyttökatkon kesto ennen palvelun palauttamista.
• Palautuspisteen tavoite (RPO): hyväksyttävän tietohäviön aikaväli, mitattuna ajassa.

Sovellus, jota käytetään intensiivisesti tilausten käsittelyyn, voi olla RTO minuutteina, kun taas talousraportointisovellus, jota käytetään kerran viikossa, voi sietää päiviä käyttökatkoksia.

RTO ja RPO määrittävät sovellukselle tarvittavan suojauksen tyypin: välitön siirtyminen, palveluiden nopea palauttaminen tai vain dokumentoitu palautusmenettely.

2. Kartoitus koko sovelluksen riippuvuusketjusta

Dokumentoi kaikki, mitä sovelluksen on oltava tehdäkseen työnsä.

Älä pysähdy vain suoritettaviin tiedostoihin tai Windows-palvelimeen. Älä unohda tietokantoja, tallennustilaa, todennusta, DNS:ää, verkkoja, sertifikaatteja, lisensointijärjestelmiä, portteja ja ulkoisia palveluja.

Kysy jokaiselta:

Mitä tapahtuu sovellukselle, jos tämä poistuu?

Tämä harjoitus tuo esiin piilossa olevat yksittäiset vikatilanteet ja määrittää palautusjärjestyksen. Sovellushostin palauttaminen ensin ei paljoa auta, jos sen tietokanta, identiteettipalvelu tai tallennustila ei ole vielä saatavilla.

Poista kriittiset yksittäiset vikaantumispisteet

Kun riippuvuuspuu on luotu, määritä, mitkä komponentit on tehtävä ylimääräisiksi liiketoiminnan tärkeyden ja palautustavoitteiden perusteella.

Windows-sovellusten toimituksessa tämä voi tarkoittaa useiden sovelluspalvelimien käyttöönottoa sen sijaan, että luotettaisiin yhden isäntäpalvelimen kykyihin. Kuormantasauskerroksen avulla istuntoja voidaan jakaa sovellusinstanssien kesken normaalin toiminnan aikana. Isäntäpalvelimen vikaantumisen tapauksessa saapuvat yhteydet voidaan ohjata terveisiin sovelluspalvelininstansseihin.

Varmuus suunnittelu tulisi perustua riippuvuusanalyysiin. Useat sovelluspalvelimet, jotka käyttävät yhtä kriittistä tietokantaa, verkkosiltaa tai tallennuskerrosta, esittävät silti yhden vikasijoituspaikan.

Korkean saatavuuden suunnittelussa on siten otettava huomioon sovelluspalvelu integroituna kokonaisuutena. Windows Server -ympäristöissä, jotka vaativat infrastruktuuritason redundanssia, Microsoftin Failover Clustering -dokumentaatio antaa lisäohjeita korkean saatavuuden ja katastrofipalautuksen topologioista.

4. Erottele sovellukset yksittäisistä päätepisteistä

Kriittisen sovelluksen asentaminen suoraan jokaisen työntekijän työasemalle voi aiheuttaa erilaisen kestävyyshaasteen. Jos käyttäjät menettävät pääsyn tavalliseen tietokoneeseensa, he saattavat myös menettää pääsyn sovelluksiin, joita he tarvitsevat jatkaakseen työskentelyä.

Sovellusten keskittäminen hallinnoituihin Windows-isäntiin ja sovelluksen käyttöliittymän esittäminen käyttäjille eliminoi tämän riskin. Tiedot ja sovellustila tallennetaan hallittavalle Windows-isännälle ja niihin pääsee käsiksi valtuutetut päätelaitteet.

Tällä tavoin teemme sovelluksen käyttäjien saataville, vaikka he vaihtaisivat laitteita tai sijainteja. Vaikka sovellusten keskittäminen ei poista infrastruktuuriin liittyviä ongelmia, se auttaa siirtämään sen ympäristöön, jossa IT voi hallita sitä.

Tarjoa enemmän kuin yksi käytännöllinen pääsytapa

Resilienssi voidaan saavuttaa myös välttämällä tarpeetonta riippuvuutta yhdestä päätepisteen tyypistä tai yhteysmenetelmästä.

Riippuen sovelluksen toimitusarkkitehtuurista, käyttäjät voivat käyttää erilaisia etäkäyttö menetelmiä, mukaan lukien RDP-yhteensopiva asiakas, omistettu sovelluksen käynnistin, verkkosivusto tai HTML5-selaimen istunto.

Vaihtoehtoisia yhteysmenetelmiä ei tule sekoittaa infrastruktuurin redundanssiin. Jos kaikki luottavat samaan epäonnistuneeseen palvelimeen, sovellus on edelleen käytettävissä.

Ne tarjoavat pääsyn kestävyyden, kun häiriö vaikuttaa käyttäjän normaaliin laitteeseen, asennettuun asiakasohjelmaan tai sijaintiin sen sijaan, että se vaikuttaisi itse sovelluspalveluun.

6. Valvo ennen kuin heikkeneminen muuttuu katkoksi

Sovelluksen kestävyys ei liity vain palautumiseen, vaan riittävän aikainen havaitseminen voi estää heikkenemisen katkoksi.

Windows-sovellusympäristöissä hyödyllisiä indikaattoreita ovat CPU-käyttö, muistin kuormitus, levyn kapasiteetti ja I/O, verkkokäyttö, aktiiviset istunnot, sovellusprosessi, vasteaika, epäonnistuneet yhteydet ja riippuvien palveluiden saatavuus.

Trendien seuranta on ratkaisevaa, sillä palvelin, joka toistuvasti lähestyy rajojaan, voi silti olla online, kun käyttäjäkokemus heikkenee vähitellen.

Kynnysilmoitukset mahdollistavat järjestelmänvalvojien tutkia tapahtuman ennakoivia merkkejä ennen kuin käyttäjät menettävät pääsyn.

7. Suunnittele kapasiteettipiikkejä ja vikasietoisuutta

Sovellus, joka selviytyy laitteistotason vioista mutta on täysin kykenemätön toimimaan lisääntyneiden vaatimusten alla, ei ole todellisuudessa kestävä minkäänlaisiin vikoihin.

Kapacitysuunnittelussa on otettava huomioon paitsi päivittäiset käyttömallit myös kausivaihteluiden, työvuorojen, kasvun tai muiden sovellusten isännöintivaatimusten aiheuttamat huiput.

Erityisesti monipalvelin-hosting-ympäristöissä yhden palvelimen menetys on otettava huomioon varmistamalla, että muilla hosting-solmuilla on ylimääräistä kapasiteettia, jotta voidaan käsitellä prosesseja, jotka muuten suoritettaisiin epäonnistuneella solmulla.

Muuten vikasietoisuusmenettelyt voivat yksinkertaisesti muuttaa eristyneen tapahtuman laajaksi järjestelmän suorituskykyongelmaksi.

8. Suojaa tiedot ja kokoonpano

Vaihdetulla Windows-palvelimella ei ole paljon hyötyä, jos IT-osasto ei voi palauttaa sovelluksen toimimiseen tarvittavia komponentteja.

Tämä voisi tarkoittaa, että varmuuskopiointimenettelyjen on sisällettävä sovellustiedot, tietokannat, konfiguraatiotiedostot, sertifikaatit, sovellusasetukset, käyttäjäprofiilit, infrastruktuurin konfiguraatio, skriptit ja lisenssitiedot.

Strategia vaihtelee sovelluksen palautumisaikakohteen (RTO) ja palautuspisteen kohteen (RPO) mukaan.

Ennen kaikkea on varmistettava, että onnistunut varmuuskopiointi ei tarkoita onnistunutta palauttamista. IT-tiimien tulisi testata, että koko sovelluspalvelun palauttaminen suojatuista tiedoista ja asetuksista on mahdollista.

Vähennä muutosten vaikutusaluetta

Ei aina ole kyse odottamattomasta katastrofista, joka aiheuttaa häiriöitä. Ne voivat myös johtua toteutetuista parannuksista. Näin ollen Windows-päivitykset, sovellusten ja ohjainten päivitykset, turvallisuuspolitiikan ja -konfiguraation muutokset voivat myös vaikuttaa negatiivisesti sovelluksen saatavuuteen. On suositeltavaa välttää samankaltaisten muutosten tekemistä kaikille tuotantopalvelimille samanaikaisesti, jos mahdollista.

Monipalvelinasetuksessa on mahdollista toteuttaa parannusmuutokset vaiheittain, jolloin järjestelmänvalvoja voi varmistaa, että kaikki toimii oikein. Mahdollisuus peruuttaa tehdyt muutokset on myös olennaista.

Näin ollen, kun suunnitellaan varautumismenettelyjä, myös palautusvaihtoehdot tulisi ottaa huomioon. Prosessi tulisi dokumentoida asianmukaisesti, ja henkilöstön tulisi tietää, mitä tehdä, jos muutos epäonnistuu, sen sijaan että se jätettäisiin heidän harkintansa varaan.

10. Suunnittelu sujuvalle heikkenemiselle

Resilienssi ei tarkoita 100 %:n normaalitoimintojen ylläpitämistä ja toiminnassa pitämistä koko ajan.

Joissakin tapauksissa avainkäyttäjien tai -sovellusten toimintojen ylläpitäminen voi olla tärkeämpää kuin kaikkien palveluiden pitäminen kaikkien käyttäjien saatavilla. Prioriteetteja voidaan määrittää ennen tapahtumaa IT-tiimien toimesta.

Jos kapasiteettia on saatavilla, jota voidaan käyttää, voi olla järkevää kohdistaa se ensin tuotantoon, asiakaspalveluun, rahoitukseen tai muihin toimintoihin.

Se on sulavaa heikkenemistä: kyky säilyttää toiminnallisuudet, jotka tuottavat eniten liiketoiminta-arvoa, sen sijaan että vähemmän kriittisten elementtien epäonnistuminen saisi koko järjestelmän kaatumaan.

Miten IT-tiimien tulisi valvoa sovellusten kestävyyttä?

Yksittäisten palvelimien valvonta voi olla hyödyllistä, mutta resilienssin valvonnan tulisi heijastaa koko sovelluspalvelua käyttäjien näkökulmasta.

Realistinen malli koostuu useista kerroksista:

Kerros	Mitä valvoa	Esimerkki epäonnistuminen
Isäntä	CPU, RAM, levy, käyttöjärjestelmän saatavuus	Palvelin ylikuormittunut tai offline
Sovellus	Prosessin ja palvelun tila	Sovelluksen kaatuminen
Riippuvuus	Tietokanta, DNS, identiteetti, tallennus	Sovellus käynnistyy, mutta ei voi toimia.
Pääsy	Portti, portaali, verkkopolku	Käyttäjät eivät voi yhdistää
Istunto	Aktiiviset käyttäjät, viat, viive	Sovellus on verkossa mutta käyttökelvoton
Liiketoimintatoiminto	Menestyksekäs työnkulun loppuunsaattaminen	Käyttäjä ei voi suorittaa vaadittua tehtävää

Liiketoimintatoimintokerros on yksi yksinkertaisimmista, joita on helppo ohittaa.

Infrastruktuurin hallintapaneelit voivat näyttää kaikki palvelimet, palvelut ja verkkopolut terveinä, kun taas todellisen käyttäjän työnkulku on vaarantunut. On tärkeää, että kriittiset sovellukset seuraavat terveyttään niiden tukemien toimintojen näkökulmasta.

Miten sovelluksen kestävyys tulisi testata?

Resilienssiarkkitehtuuri, joka ei ole koskaan kokenut hallittua vikaa, sisältää testaamattomia oletuksia.

Käytä testauksia arvioidaksesi järjestelmän vastausta, kun keskeiset komponentit eivät ole käytettävissä. Testien tulisi sisältää sovellushostin vieminen offline-tilaan, sovelluspalvelun pysäyttäminen, verkkoreitin menetyksen simulointi, portin tai kuormantasauskäyttäytymisen tarkistaminen, varmuuskopiosta palauttaminen ja sovelluksen käyttö vaihtoehtoisesta päätepisteestä.

Testiprosessien tulisi ulottua palautuksen teknisten näkökohtien ohi. IT-tiimien tulisi tarkistaa, lähetetäänkö hälytykset oikeille hallintohenkilöille, suoritetaananko palautusvaiheet oikeassa järjestyksessä ja pystyvätkö käyttäjät suorittamaan todellisia liiketoimintatehtäviä palveluiden palauttamisen jälkeen.

Toimintamenettelyt ovat olennainen osa kestävää järjestelmää. Hälytyksen eskalointimenettelyt: kuka vastaanottaa hälytyksen? Kuka on valtuutettu aloittamaan siirtyminen? Missä palautusasiakirjat ja käyttöoikeustiedot säilytetään? Mikä riippuvuus on saatava toimintaan ensin?

Tekninen redundanssi tarjoaa vain vähän hyötyä, jos pääsyn palautusprosessit eivät ole olleet testattuja.

Mikä voi olla sovelluksen kestävyyslista?

Ennen kuin IT-tiimien on ryhdyttävä kriittiseen Windows-sovellukseen, niiden tulisi pystyä vastaamaan seuraaviin kysymyksiin:

• Mitä liiketoimintaprosesseja sovellus tukee?
• Mitä ovat sen RTO ja RPO?
• Mitä palvelimia, tietokantoja ja ulkoisia palveluja se vaatii?
• Missä ovat sen kriittiset yksittäiset vikaantumispisteet?
• Voiko toinen sovelluksen isäntä hyväksyä käyttäjiä, jos yksi isäntä epäonnistuu?
• Voivatko käyttäjät muodostaa yhteyden, jos heidän normaali päätepisteensä tai sijaintinsa ei ole saatavilla?
• Onko riittävästi varausta heikennettyyn toimintaan?
• Valvotaanko infrastruktuuri-, riippuvuus- ja istuntongelmia aktiivisesti?
• Ilmoitetaanko järjestelmänvalvojille ennen kuin tärkeät rajat muuttuvat katkoiksi?
• Onko sovellustiedot ja -asetukset suojattu?
• Onko palautusta oikeasti testattu?
• Voidaanko ongelmalliset muutokset peruuttaa?
• Onko palautusprosessi dokumentoitu?
• Voivatko käyttäjät suorittaa vaaditun liiketoimintaprosessin palautuksen jälkeen?

Kaikki vastaukset eivät vaadi kalliita korkean saatavuuden infrastruktuureja. Oikea suojauksen taso riippuu kustannuksista ja käyttökatkosten vaikutuksesta.

Tärkeää on, että saatavuus-, redundanssi- ja palauttamispäätökset tehdään tarkoituksellisesti, eikä niitä oleteta.

Miten TSplus voi auttaa pitämään Windows-sovellukset saatavilla?

Organisaatioille, jotka luottavat olemassa oleviin Windows-sovelluksiin, voimme auttaa parantamaan saatavuutta keskittämällä sovellukset hallinnoituihin Windows-palvelimiin ja toimittamalla ne käyttäjille RDP-yhteensopivien asiakasohjelmien, RemoteApp-tyylisen pääsyn tai HTML5-verkkoportaalin kautta. Tämä vähentää riippuvuutta yksittäisistä käyttäjäpisteistä ja antaa IT-tiimeille enemmän joustavuutta, kun käyttäjien tarvitsee yhdistää toiselta laitteelta tai sijainnilta.

TSplus Etäyhteys voi myös tukea monipalvelin käyttöönottoja kuormantasaamisen ja portaalipohjaisen pääsyn avulla. Kun se yhdistetään kestäviin tietokantoihin, tallennukseen, identiteettipalveluihin ja verkottumiseen, tämä arkkitehtuuri voi vähentää riippuvuutta yhdestä sovellushostista ja auttaa ylläpitämään pääsyä kriittisiin Windows-sovelluksiin infrastruktuurin häiriöiden aikana.

Päätelmä

Sovelluksen kestävyys riippuu infrastruktuurin ja liiketoiminnan käytön välisen täydellisen polun ymmärtämisestä. Varmuus, valvonta, varmuuskopiointi, kapasiteettisuunnittelu ja palautusmenettelyt ovat tehokkaimpia, kun ne on suunniteltu selkeästi määriteltyjen sovelluksen riippuvuuksien ja palautustavoitteiden ympärille.

Olemassa oleville Windows-sovelluksille kestävyys tulee usein ohjelmiston ympäristön vahvistamisesta sen sijaan, että sovellusta itsessään rakennettaisiin uudelleen. Avainkysymys on edelleen yksinkertainen: kun häiriö tapahtuu, voivatko käyttäjät jatkaa työskentelyä, tai voiko IT palauttaa tarvittavan liiketoimintatoiminnon sovitun palautusajan puitteissa?