Luotettavuus

Valmis

Kuvittele, että johdat kliinistä järjestelmää terveydenhuollon organisaatiolle. Kliinikoilla ja hoitajilla ei ole juurikaan toleranssia käyttökatkoihin. Käyttäjien on päästävä käyttämään kliinisiä IT-järjestelmiä kellon ympäri varmistaakseen, että he tarjoavat aina korkealaatuista hoitoa.

Jotta sovellukset vastaavat kliinikoiden ympäri vuorokauden esittämia vaatimuksia, sovellusten on pystyttävä käsittelemään virheitä, joilla on vain pieni vaikutus käyttäjille. Miten sovellus pidetään toimintakunnossa sekä lokalisoitujen tapausten että laajamittaisten katastrofien osalta?

Tässä osiossa opit sisällymään arkkitehtuurin rakenteeseen elementtejä luotettavuuspilareista.

Mikä on luotettavuus?

Monimutkaisessa sovelluksessa kaikki asiat voivat mennä pieleen missä tahansa mittakaavassa. Yksittäiset palvelimet ja kiintolevyasemat voivat epäonnistua. Käyttöönotto-ongelma saattaa tahattomasti pudottaa kaikki tietokannan taulukot. Kokonaisiin palvelinkeskuksiin ei ehkä saada yhteyttä. Kiristysohjelmatapaus saattaa salata kaikki tietosi pahantahtoisesti. On tärkeää, että sovelluksesi pysyy luotettavana ja kykenee käsittelemään sekä lokalisoituja että laaja-alaisia tapauksia.

Luotettavuuden suunnitteluun kuuluu käytettävyysajan ylläpitäminen pienissä tapahtumissa ja tilapäisissä olosuhteissa, kuten osittaisissa verkkokatkoksissa. Voit varmistaa, että sovelluksesi käsittelee lokalisoituja virheitä integroimalla korkean käytettävyyden kuhunkin osaan. Tämä sovellusrakenne poistaa yksittäiset vikaantumispisteet. Tällainen rakenne myös minimoi infrastruktuurin ylläpidon vaikutukset. Suuren käytettävyyden mallien tavoitteena on yleensä poistaa tapausten vaikutukset nopeasti ja automaattisesti sekä varmistaa, että järjestelmä voi käsitellä pyyntöjä vain vähän tai ei lainkaan.

Luotettavuuden suunnittelussa keskitytään myös tietojen menettämisestä palauttamiseen ja suurempikokoisiin katastrofeihin. Palautuminen tämäntyyppisistä tapauksista edellyttää usein aktiivisia toimia, vaikka automaattiset palautusvaiheet voivat lyhentää palauttamiseen tarvittavaa aikaa. Tällaiset tapaukset saattavat aiheuttaa jonkin verran käyttökatkoja tai pysyvästi menettämiä tietoja. Järjestelmäpalautuksessa on kyse yhtä paljon huolellisesta suunnittelusta kuin suorittamisesta.

Arkkitehtuurin suunnittelun korkea käytettävyys ja hyödynnettävyys suojaa liiketoimintaasi taloudellisilta tappioilta, jotka johtuvat käyttökatkoista ja tietojen menettämiestä. Ne myös suojelevat liiketoimintaasi maineen menetyksiltä, jotka johtuvat asiakkaiden luottamuksen menettämisestä.

Luotettavuuden arkkitehtuuri varmistaa, että sovelluksesi pystyy täyttämään asiakkaille tekemäsi velvoitteet. Haluat varmistaa, että järjestelmäsi ovat loppukäyttäjien käytettävissä ja että ne voivat palauttaa virheistä.

Erittäin suuren käytettävissä olevan arkkitehtuurin luominen

Määritä käytettävyyden palvelutasosopimus, johon vahvistat. Tutki sovelluksen mahdollisia suuren käytettävyyden ominaisuuksia suhteessa käytettävyystasosopimustasi ja selvitä, missä peittosi on oikein ja missä sinun on tehtävä parannuksia. Tavoitteena on lisätä redundanssi arkkitehtuurin osiin, jotta käyttökatkos olisi epätodennäköisempää.

Suuren käytettävyyden suunnittelukomponentteja ovat esimerkiksi klusterointi ja kuormituksen tasaaminen:

  • Klusterointi korvaa yksittäisen näennäiskoneen koordinoiduilla näennäiskoneilla. Kun yksi näennäiskone epäonnistuu tai siihen ei saada yhteyttä, palvelut voivat muodostaa yhteyden toiseen, joka voi suorittaa pyyntöjä.

  • Kuormituksen tasaaminen jakaa pyynnöt palvelun useisiin esiintymiin, havaitsee epäonnistuneet esiintymät ja estää pyyntöjen reitityksen niihin.

Luo arkkitehtuuri, joka voi palautua virheestä

Palautettavuuden parantamiseksi sinun tulee suorittaa analyysi, joka tutkii mahdollisia tietojen menettämistä ja merkittäviä käyttökatkostilanteita. Analyysin tulee sisältää tutustuminen palautusstrategioihin ja kunkin kustannus-/hyöty-kompromissin tarkasteluun. Tämä harjoitus antaa tärkeän kuvan organisaatiosi prioriteeteista ja selventää sovelluksesi roolia. Analyysin tulosten tulee sisältää nämä sovelluksen kestoarvot:

  • palautuspisteen tavoite: Hyväksyttävän tietojen menetyksen enimmäiskesto. RPO mitataan aikayksiköinä, ei tilavuudena. Esimerkkejä ovat "30 minuutin tiedot", "neljän tunnin tiedot" ja niin edelleen. RPO: ssa on kyse tietojen rajoittamisesta ja toipumisesta tietojen menetyksen, ei tietojen varkauden.

  • Palautusajan tavoite (RTO): Hyväksyttävän käyttökatkoajan enimmäiskesto, jossa määrityksesi määrittää käyttökatkon. Jos hyväksyttävä käyttökatkosaika on esimerkiksi kahdeksan tuntia, jos katastrofi ilmenee, RTO-arvo on kahdeksan tuntia.

Kun RPO ja RTO on määritetty, voit suunnitella varmuuskopiointi-, palautus-, replikointi- ja palautusominaisuudet arkkitehtuuriisi näiden tavoitteiden saavuttamiseksi.

Jokainen pilvipalveluntarjoaja tarjoaa palvelu- ja ominaisuuspaketin, joiden avulla voit parantaa sovelluksesi käytettävyyttä ja palautettavuutta. Jos mahdollista, käytä olemassa olevia palveluita ja parhaita käytäntöjä ja yritä vastustaa oman palvelun luomista.

Kiintolevyt voivat epäonnistua, palvelinkeskuksiin ei saada yhteyttä ja hakkerit voivat hyökätä. On tärkeää, että säilytät hyvän maineen asiakkaidesi kanssa käyttämällä käytettävyyttä ja palautettavuutta. Käytettävyys keskittyy käytettävyyden ylläpitoon verkkokatkosten kaltaisten ehtojen kautta, ja palautettavuudella keskitytään tietojen noutamiseen katastrofin jälkeen.

Tarkista tietosi

1.

Oletetaan, että haluat lisätä järjestelmäsi käytettävyyttä tarjotaksesi asiakkaillesi paremman palvelutasosopimuksen. Mikä seuraavista on ohjenuorana, jota voi käyttää?

2.

Mihin seuraavista vaikuttaa määrittämäsi palautuspisteen tavoite (RPO)?