Luotettavuuden kompromissit työkuormille Power Platform
Luotettava työkuorma toteuttaa johdonmukaisesti sille määritetyt luotettavuustavoitteet. Se on saavutettava määritetyt vikasietotavoitteet; parhaimmassa tapauksessa se tapahtuu kiertämällä luotettavuuteen vaikuttavat tapahtumat. Todellisuudessa työkuorman on kuitenkin siedettävä kyseisten tapahtumien vaikutus ja hallittava sitä sekä ylläpidettävä toimintoja ennalta määritetyllä tasolla toimintohäiriötilanteessa. Luotettavan työkuorman on palauduttava tiettyyn tilaan myös vakavan virheen aikana annetun ajan kuluessa sidosryhmien keskenään tekemän sopimuksen mukaisesti. Nopean havaitseminen ja palautuksen mahdollistava tapauksiin reagointisuunnitelma on aivan välttämätön.
Työkuorman suunnitteluvaiheessa on otettava huomioon, miten luotettavuuden suunnitteluperiaatteisiin ja kohdan Luotettavuuden suunnittelun tarkistuksen tarkistusluettelo suosituksiin perustuvat päätökset voivat vaikuttaa muiden pilarien tavoitteisiin ja optimointeihin. Tietyt päätökset saattavat olla hyödyllisiä osalle pilareista mutta kompromissi muille. Tässä artikkelissa käsitellään esimerkkejä kompromisseista, joita työkuormatiimi saattaa kohdata suunniteltaessa luotettavuuden työkuorman arkkitehtuuria ja toimintoja.
Luotettavuuden ja suojauksen väliset kompromissit
Kompromissi: Lisääntynyt työmäärän pinta-ala. Suojauspilari priorisoi vähäistä ja rajoitettua pintaa, sillä se minimoi hyökkäysvektorit ja vähentää suojauksen hallintatoimien hallintaa.
Luotettavuus saavutetaan usein replikoinnin kautta. Replikointia voi tapahtua komponentti- ja tietotasolla sekä jopa maantieteellisellä tasolla. Replikoiden tarkoituskin on kasvattaa työkuorman pinta-alaa. Suojauksen kannalta vähäinen ja rajoitettu pinta on parempi vaihtoehto, sillä se minimoi potentiaaliset hyökkäysvektorit ja sujuvoittaa suojauksen hallintatoimien hallintaa.
Vastaavasti järjestelmäpalautusratkaisut, kuten varmuuskopiot, kasvattavat työkuorman pinta-alaa. Ne on kuitenkin usein eristetty työkuorman suorituspalvelusta. Tämä edellyttää suojauksen, mahdollisesti vain järjestelmäpalautusratkaisua koskevien lisähallintatoimien toteuttamista.
Luotettavuustavoitteiden vuoksi arkkitehtuuriin voidaan tarvita pinta-alaa kasvattavia lisäkomponentteja. Tämä lisääntynyt monimutkaisuus kasvattaa työkuorman pinta-alaa lisäämällä uusia komponentteja, jotka on suojattava mahdollisesti tavoilla, joita ei vielä järjestelmässä käytetä. Yleensä näihin komponentteihin liittyy niiden käyttöä tukevia lisäkoodia tai yleisiä luotettavuusmalleja, jotka myös kasvattavat sovelluksen pinta-alaa.
Kun työkuormassa on luotettavuustapahtuma, jota käsitellään aktiivisen tapauksen reagoinnin mukaisesti, kiireellisyys voi aiheuttaa työkuormatiimeille paineita ohittaa suojauksen hallintatoimet, jotka on optimoitu rutiinikäyttöä varten.
Vianmääritystoimet voivat saada tiimin poistamaan suojausprotokollat tilapäisesti käytöstä, jolloin järjestelmä, johon kohdistuu rasitusta, voi altistua lisää tietoturvariskeille. Riskinä on myös se, ettei suojausprotokollia oteta välittömästi takaisin käyttöön.
Suojauksen hallintatoimien rakeiset toteutukset, kuten roolipohjaiset käyttöoikeuksien määritykset tai palomuurisäännöt, lisäävät määritysten monimutkaisuutta ja arkaluonteisuutta, mikä puolestaan lisää mahdollisuuksia virheellisiin määrityksiin. Tämän potentiaalisen luotettavuusvaikutuksen lieventäminen laajojen sääntöjen avulla heikentää kaikkia kolmea Zero Trust -arkkitehtuurin periaatetta.
Julkaisuaallon tai toimittajakirjastojen, kuten kolmannen osapuolen komponenttien tai ratkaisujen, päivitysten käyttäminen potentiaalisesti häiritä kohdekomponentin käyttöä ja aiheuttaa sen, ettei komponentti ole käytettävissä muutoksen aikana. Korjaustiedostojen käytön viivästyttäminen tai niiden välttäminen voi estää potentiaaliset luotettavuusriskit mutta jättää järjestelmän ilman suojausta kehittyviltä uhkilta.
Edellä mainittu seikka koskee myös työkuorman koodia. Se koskee esimerkiksi sovelluksen vanhoja kirjastoja ja komponentteja käyttävää koodia. Jos sovelluksen koodin päivitystä ja käyttöönottoa pidetään pelkkänä luotettavuusriskinä, sovellus altistuu muille suojausriskeille ajan mittaan.
Luotettavuuden ja toiminnan korkean laadun väliset kompromissit
Toiminnan korkean laadun keskeinen osa on kattava työkuorman seurantastrategia. Lisäkomponenttien lisääminen arkkitehtuurin luotettavuuden suunnittelumallien toteuttamisen vuoksi saa aikaan sen, että hallittavia tietolähteitä on enemmän, mikä monimutkaistaa hajautetun seurannan ja näkyvyyden toteuttamista.
Useiden alueiden käyttäminen yhden alueen resurssien kapasiteettirajoitusten ratkaisemiseen ja/tai aktiivinen/aktiivinen-arkkitehtuurin toteuttaminen monimutkaistaa työkuorman toiminnallista hallintaa. Useiden alueiden ja niiden välisen tietojen replikoinnin hallinnan tarve aiheuttaa tämän monimutkaisuuden.
Kun työkuorma vakiintuu luotettavuuskomponenttien ja -mallien lisäyksen ansiosta, toiminnallisten menettelyjen ja artefaktien dokumentointi vie enemmän aikaa.
Koulutus monimutkaistuu työkuorman komponenttien määrän lisääntyessä. Tämä monimutkaisuus vaikuttaa perehdyttämiseen tarvittavaan aikaa ja lisää tietämystä, joka tarvitaan tuotteen etenemissuunnitelmien ja palvelutason ohjauksen seuraamiseen.
Luotettavuuden ja käyttökokemuksen optimoinnin väliset kompromissit
Tiukan testauksen korostaminen voi viivästyttää käyttökokemuksen käyttöönoton kannalta välttämättömien ominaisuuksien julkaisua.
Luotettavuuden optimointi voi painottaa monimutkaisuuden minimointia liikaa, mikä heikentää aktivoivien käyttökokemusten ominaisuuksien, kuten mukautettujen komponenttien ja integrointien, priorisointia.
Luotettavuuden ja suorituskyvyn tehokkuuden kompromissit
Luotettavuusmallit sisältävät usein tietojen replikoinnin selviytyäkseen replikan toimintahäiriöstä. Replikointi lisää viivettä luotettaville tietojen kirjoitustoiminnoille, mikä kuluttaa osan tietyn käyttäjän tai tietovirran suorituskykybudjetista.
Luotettavuus käyttää joskus erilaisia resurssien tasapainottamisen muotoja kuorman jakamiseksi tai jakamiseksi uudelleen terveille jäljennöksille. Täsmäytykseen käytettävä erillinen komponentti vaikuttaa yleensä tasapainotettavan pyynnön tai prosessin suorituskykyyn.
Komponenttien jakaminen maantieteellisten rajojen tai käytettävyysvyöhykkeiden yli laajoista vaikutuksista selviytymiseksi tuo verkon viiveen nämä saatavuusrajat ylittävien komponenttien väliseen viestintään.
Työmäärän terveyden tarkkailuun käytetään laajoja prosesseja. Vaikka valvonta on kriittistä luotettavuuden kannalta, instrumentointi voi vaikuttaa järjestelmän suorituskykyyn. Kun havaittavuus paranee, suorituskyky saattaa heikentyä.
Automaattiset skaalaustoiminnot eivät ole välittömiä, joten ne eivät pysty luotettavasti käsittelemään äkillistä ja dramaattista kysyntäpiikkiä, jota ei voida muotoilla tai tasoittaa. Siksi ylivalmistelu joko suurempien tai useampien esiintymien kautta on kriittinen luotettavuustaktiikka, jolla otetaan huomioon kysyntäsignaalin ja tarjonnan luomisen välinen viive. Käyttämätön kapasiteetti on ristiriidassa suorituskyvyn tehokkuuden tavoitteiden kanssa.
Joskus komponenttia ei voida skaalata kysynnän mukaan, eikä kysyntä ole täysin ennustettavissa. Suurten esiintymien käyttäminen pahimman tapauksen kattamiseksi johtaa jätteen ylivaraukseen tilanteissa, jotka ovat kyseisen käyttötapauksen ulkopuolella.