Luotettavuus - Disaster Recovery -kuviot | Kuvakkeet |

Luotettavuus - Disaster Recovery -kuviot

Lue lisää hyvin rakennetuista luotettavuuksista → Vahinkotapahtumien palautus ja liiketoiminnan jatkuvuus

Kuvio

Mistä etsiä	Miltä hyvä näyttää
Datan varmuuskopiointistrategia	✅ Viikoittaiset tai kuukausittaiset automatisoidut viennit käyttämällä datan vientipalvelua tai erityistä varmuuskopio- ja palautuspalvelua (kuten Oma). Viennin yleisyys vastaa RPO-vaatimuksia. Ulkoisen objektin tallennustilaan tarvittaessa viedyt kriittisten objektien tiedot.
Metadatan varmuuskopiointistrategia	✅ Kaikki metadata on versioitu Gitissä Salesforce DX -lähdemuodossa. Metadata-muutokset, jotka on otettu käyttöön vain lähdekoodin hallinnasta. CI/CD-putki voi luoda minkä tahansa ympäristön uudelleen säiliöstä. Piste-aikojen palautus on käytettävissä Git-historian kautta.
Tiedostojen varmuuskopiointistrategia	✅ ContentVersion-tietueet, liitteet ja asiakirjat, jotka on viety ulkoiseen tallennustilaan ajoitetusti. Automatisoitu tiedostojen vienti lakisääteisiä säilytysehtoja varten. Ulkoinen arkistointijärjestelmä liiketoimintatarpeita vanhoille tiedostoille.
Varmuuskopioiden vahvistus	✅ Palauta tarkennukset neljännesvuosittain Full-sandbox tai Developer-ympäristöihin. Palauta suorituskirjoissa kuvattuja toimenpiteitä vaiheittaisilla ohjeilla. Testin palautus vahvistaa varmuuskopioiden eheyden ja täydellisyyden ennen katastrofeja.
Palautustestien aikataulu	✅ Vuosineljänneksen osittaiset palautustestit (metadata, tietyt objektit, tiedostojen alijoukot). Vuosittainen täysi palautustarkistus ja täydellinen ympäristön palautus. Opitut oppitunnit dokumentoidaan ja suorituskirjat päivitetään jokaisen testin jälkeen.
Kolmannen osapuolen varmuuskopiointipalvelu	✅ Automatisoitu varmuuskopio, jossa on aikapisteen palautuskyky. Palvelutasosopimus, joka määrittää RPO/RTO. Päivittäinen varmuuskopion suorittamisen automatisoitu vahvistus. Maantieteellinen tarpeeton käyttö useissa alueissa säilytetyillä varmuuskopioilla.
Mukautetut objektit ja kentät	✅ Ajoitettujen datan vientipalvelun suorituskertojen sisältämät mukautetut objektit, joiden kaava- ja yhteenvetokenttien arvot lasketaan uudelleen viennin sijaan (tietueiden noutamiseen ei ole tallennettu arvoa) ja tiedosto- tai liitetiedostojen binääriarvot käsitellään erillisen vientipolun kautta. Monimutkaiset kenttätyypit ja hakusuhteet, jotka on dokumentoitu ja testattu palautusjärjestyksessä.
Tiedostot ja liitteet	✅ ContentDocument- ja ContentVersion-objektit, jotka on viety tiedostobinaarioilla. Varmuuskopioidut asiakirjakirjastot, mukaan lukien kansiorakenteet ja käyttöoikeudet. Viedyt tiedostot ylläpitävät kriittisten asiakirjatyyppien versiohistoriaa.
Sandboxien päivitysstrategia	✅ Tuotanto-organisaatio päivitetään Full-sandboxiin neljännesvuosittain lataustestausta ja katastrofien palautuksen vahvistusta varten. Sandboxin päivitystä käytetään palautusprosessin testinä. Datan peittämistä käytetään päivityksen jälkeen luottamuksellisten tietojen suojaamiseksi testiympäristöissä.
Varmuuskopioiden valvonta ja hälytykset	✅ Automatisoidut hälytykset, kun ajoitetut varmuuskopiot epäonnistuvat tai ne viivästyvät. Mittaristo, joka näyttää varmuuskopiotöiden onnistumissuhteen, valmistumisajan ja datamäärien trendit. Puheluiden eskalointi varmuuskopiovirheille, jotka ylittävät hyväksyttävän viivejakson.

Anti-Mallit

Mistä etsiä	Miltä huono näyttää
Varmuuskopiointistrategia	⚡️ Ei automatisoitua varmuuskopiota määritettyä, riippuen vain sovellusalustan infrastruktuurin varmuuskopioista. Kolmannen osapuolen varmuuskopiointipalvelu on määritetty, mutta sitä ei ole koskaan testattu - varmuuskopiot voivat olla korruptoituneita tai keskeneräisiä. Varmuuskopioinnissa käytetyt manuaaliset Data Loader -viennit (ei-yhteensopiva suoritus, puutteellinen kattavuus, ei automatisointia).
Metadatan versiointi	⚡️ Metadata-muutokset, jotka on otettu käyttöön muutosjoukoilla ilman lähdekoodin hallintaa. Ei Git-säiliötä metadatan historialle. Piste-aikojen palautus on mahdotonta - viimeisin tunnettu ja hyvä kokoonpano ei voi palautua tuhoisien muutosten jälkeen.
Varmuuskopioiden vahvistus	⚡️ Varmuuskopiot on määritetty, mutta niitä ei koskaan palautettu testiympäristöön. Ensimmäinen palautusyritys tapahtuu, kun todellinen katastrofi paljastaa puutteellisen vaikutusalueen tai korruptoituja arkistoja. Varmuuskopiointitoimenpiteet, joita varmuuskopiointihenkilöstö on dokumentoinut, mutta ei testannut.
Varmuuskopioinnin vaikutusalue	⚡️ Oletetaan, että datan vientipalvelu kaappaa kaiken, kun kaava- ja yhteenvetokenttien arvoja ei koskaan viedä (dynaamisesti uudelleenlaskettu, ei tallennettu) ja tiedosto- tai liitetiedostobinaarit vaativat erillisen käsittelyn, jolloin aukkoja löydetään vasta palautuksen yhteydessä.
Palautustoimenpiteet	⚡️ Recovery runbook sisältää vanhentuneita vaiheita 2-vuotiaasta arkkitehtuurista. Yksittäisen asiantuntijan testaamat palautusmenetelmät, jotka ovat lähteneet yhtiöstä. Manuaaliset toimenpiteet ovat niin monimutkaisia, että työnkuormituksen aikana suorittaminen aiheuttaa virheitä.
Varmuuskopioinnin yleisyys	⚡️ Kriittisten transaktioiden tiedot varmuuskopioidaan viikoittain, kun liiketoimintavaatimus on 24 tunnin RPO. Varmuuskopiot eivät vastaa liiketoiminnan kriittisyyttä - sama aikataulu kaikille tiedoille tärkeydestä riippumatta. Varmuuskopioaikataulu puuttui valvonnan ja hälytysten puutteen takia.
Säännöstenmukaisuus	⚡️ Varmuuskopioiden säilytysaika lyhyempi kuin mitä säännökset vaativat. Esimerkiksi HIPAA-vastaavuusdokumentaatio (käytäntöjä, riskianalyysejä, BAA-todennuksia, rikkomustietueita) tyhjennettiin ennen kuuden vuoden säilyvyyttä §164.316, tai SOX:n hallitsemat tilintarkastustietueet poistettiin ennen niiden seitsemän vuoden säilyvyyttä. Auditoinnin aikana havaittu vaatimustenmukaisuuden aukko.
Tiedostojen tallennustila	⚡️ Salesforceen tallennetut suuret tiedostot ilman arkistointistrategiaa. Tiedostojen tallennustila kasvaa, kunnes organisaatio lähestyy rajoitusta. ContentVersion-tietueita ei varmuuskopioida - tiedostot häviävät, jos organisaatio korruptoituu. Luottaa käyttäjiin säilyttääkseen henkilökohtaisia kopioita kriittisistä tiedostoista.
Sandboxien testaaminen	⚡️ Full-sandbox ei ole koskaan päivitetty tuotantoympäristöstä - testausympäristö on erilainen kuin tuotantoympäristö. Sandboxin datamäärä 1 % tuotannosta estää realistisen palautuksen vahvistuksen. Sandboxin päivitystä käsitellään haittana eikä katastrofien palautuksen vahvistusmahdollisuutena.
Valvonta	⚡️ Varmuuskopiointityöt epäonnistuvat hiljaa ilman hälytyksiä. Havaitse varmuuskopiovirheitä viikkoja myöhemmin katastrofin aikana, kun varmuuskopioita tarvitaan. Ei mittaristoa, joka näyttää varmuuskopiotöiden onnistumisen trendit. Varapalvelun kuntoa valvotaan vain, kun lasku saapuu.
Salausavaimet	⚡️ Shieldin salaaman datan käsitteleminen turvallisena suojaamatta avainmateriaalia: Avaimien kierrättäminen jättää edellisen datan koskemattomaksi, mutta vuokralaisen salaisuuden tuhoaminen (crypto-shred) tai Bring Your Own Key- tai Vain välimuisti -avainmateriaalin menettäminen tekee salatusta datasta pysyvästi palautettavan. Avainten hallinta jätetään pois palautustoimenpiteistä.
Organisaatioiden väliset sidonnaisuudet	⚡️ Varmuuskopioi yksittäinen ensisijainen organisaatio, kun ratkaisu riippuu yhdistetyistä sovelluksista, ulkoisista integraatioista tai SSO-kertakirjautumisesta: Yhdistettyjen sovellusten salaisuuksia, nimettyjä tunnuksia ja OAuth-valtuutuksia sekä ulkoisia todennusvaltuuksia ei säilytetä datan ja metadatan palautuksessa, vaan ne täytyy määrittää ja valtuuttaa uudelleen ennen kuin palautettu organisaatio voi todentaa itsensä ulkoisiin järjestelmiin. Kun ulkoinen SSO on ainoa sisäänkirjautumiskulku, ei-käytettävissä oleva henkilöllisyydentarjoaja estää sisäänkirjautumisen jopa täysin palautettuun organisaatioon.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
Palautuksen aikainen tavoite (RTO) -määritelmä	✅ RTO määritetty liiketoimintakyvyn perusteella, eikä yhtenäinen koko organisaatiossa. Tuottoon kriittiset operaatiot: minuutista 1 tuntiin. Asiakkaille tarkoitetut palvelut: 1–4 tuntia. Sisäiset työkalut: 4–24 tuntia. Historiallinen raportointi: päivinä. RTO-organisaatiot, jotka on dokumentoitu liiketoiminnan sidosryhmien hyväksynnällä.
Palautuspisteen tavoitteen (RPO) määritelmä	✅ RPO, joka perustuu hyväksyttyyn datan häviöön per kyky. Finanssitransaktiot: near-zero RPO (sekunteina, tapahtumiin perustuva asynkronoitu replikointi). Asiakastietueet: lähes nolla (minuutteina CDC:n kautta). Analytics-data: tunnit (ajoitettu synkronointi). Työnkulun väliaikainen tila: days (ei vaadi replikointia).
Tiimin saatavuus ja roolit	✅ Kaikkien kriittisten roolien ensisijainen henkilöstö ja varapäällikkö. Ei yhtään virhettä operatiivisessa Knowledgessa. Eskalointihakemisto, joka määrittää ensisijaisen vastaajan, ensimmäisen varmuuskopion, toisen varmuuskopion. Järjestelmässä säilytetyt yhteystiedot ovat käytettävissä, kun Salesforce ei ole käytettävissä.
Viestintätoimenpiteet	✅ Vahinkotapahtumien viestintäsuunnitelma, joka määrittää, kuka ilmoittaa käyttäjille, asiakkaille ja esimiehille. Ulkoinen tilasivu, jota isännöidään Salesforcen ulkopuolella käyttäjien kommunikointia varten sovellusalustan käyttökatkosten aikana. SMS-ilmoitusjärjestelmä puhelutiimille, kun ensisijaiset viestintätyökalut eivät ole käytettävissä. Asiakirjoitetut eskaloinnin ajanjaksot (kun eskaloidaan tiimistä esimieheksi esimieheksi).
Toimittajan sidonnaisuuksien kartoitus	✅ Kaikki dokumentoidut kriittiset ulkoiset toimittajat, mukaan lukien Salesforce, integraatiokumppanit ja ISV-paketin tarjoajat. Toimittajan palvelutasosopimukset ja tukijaksot on dokumentoitu (24/7 vs. Vain toimistoaika). Toimittajan eskaloinnin yhteyshenkilöt ja toimenpiteet dokumentoituina. Kriittisille sidonnaisuuksille tunnistetut vaihtoehtoiset tavarantoimittajavaihtoehdot.
Lakisääteiset ilmoitusten velvollisuudet	✅ Pakolliset vahinkotapahtumien ilmoitusvaatimukset, jotka on dokumentoitu toimialan mukaan (finansiopalvelut, terveydenhuolto, valtio). Ilmoitusten ajanjaksot, jotka on määritetty vastaamaan kunkin säännöksen vaatimia ajanjaksoja. Vastuumatriisi, joka määrittää, kuka lähettää ilmoituksia minkälaisiin valvontaviranomaisiin. Malleja, jotka on valmisteltu nopeaa lakisääteistä ilmoitusta varten.
Liiketoiminnan vaikutusanalyysi	✅ Jokainen liiketoimintaominaisuus lajiteltuna tuoton vaikutuksen, käyttäjän vaikutuksen ja lakisääteisen riskin mukaan. Palautuksen priorisointi liiketoiminnan vaikutusten sijoituksen perusteella. Luonnonmullistukseen allokoidut resurssit ovat suhteellisia liiketoiminnan kriittisyyden kanssa. Vuosittain tarkastettu vaikutusanalyysi liiketoimintaprioriteettien muuttuessa.

Anti-Mallit

Mistä etsiä	Miltä huono näyttää
RTO/RPO-määritelmä	⚡️ “Järjestelmän tulisi olla luotettava” ilman mitattavissa olevia RTO/RPO-kohteita. IT-tiimin määrittämä RTO/RPO ilman liiketoiminnan sidosryhmiä. Yhtenäistä tavoitteet kaikissa ominaisuuksissa jättämällä kriittisyyden eroavaisuudet huomiotta (“kaikki vaatii 99,999% toiminta-aikaa”).
Tiimin valmius	⚡️ Yksi Salesforce-pääkäyttäjä tuntee katastrofien palautustoimenpiteet ilman dokumentaatiota tai varmuuskopiohenkilöstöä. Puheluiden kierrättäminen sisältää henkilökunnan, joka ei ole koskaan suorittanut palautusmenettelyitä. Ensisijaiset vastaajat eivät ole paikalla katastrofin aikana (loma, sairaus, poistunut yhtiö).
Viestinnän suunnittelu	⚡️ Ei viestintäsuunnitelmaa – sinun täytyy ilmoittaa käyttäjille, kun vahinkotapahtuma on jo käynnissä. Salesforcessa isännöity tilasivu ei ole käytettävissä Salesforcen käyttökatkoksen aikana. Odotusaikoja ilmoittaaksesi esimiehille, kun he yrittävät toipua.
Toimittajan sidonnaisuudet	⚡️ Et ole tietoinen palvelutasosopimuksen ehdoista ennen kuin katastrofi tapahtuu ja odotat 24/7-tukea palveluntarjoajalta, joka kattaa vain toimistoajat. Ei dokumentoituja toimittajien eskalointiyhteyshenkilöitä. ISV-paketin tarjoaja vaaditaan palautukseen, mutta yhtiö ei ole enää liiketoiminnassa.
Sääntelyvaatimukset	⚡️ Et ole tietoinen pakollisista rikkomuksen ilmoitussäännöistä. Löydä 24 tunnin ilmoitusvaatimus, kun 48 tuntia on kulunut. Ei mallia valmisteltu - laati lakisääteisiä ilmoituksia vahinkotapahtuman vastauksen aikana, kun vaatimustenmukaisuuden kello toimii.
Palautuksen priorisointi	⚡️ Yrität palauttaa kaikki ominaisuudet samanaikaisesti katastrofin aikana sen sijaan, että priorisoisit tuottoa vaativia toimintoja. Käytät 8 tuntia sisäisten raportointiominaisuuksien palauttamiseen ennen kuin käsittelet asiakkaille tarkoitettuja tilauksia.
Testaaminen ja tarkennukset	⚡️ Liiketoiminnan jatkuvuussuunnitelmaa ei ole koskaan testattu tarkemmin. Oletetaan, että dokumentoidut toimenpiteet toimivat ilman vahvistusta. Työpöytäharjoituksia vältetään ”aikapuutteen” vuoksi, vaikka päivät kuluu löytämättömistä ongelmista toipumiseen todellisten katastrofien aikana.
Knowledge	⚡️ Disaster Recovery Knowledge keskittyi yhteen johtavaan arkkitehteen, joka ei dokumentoinut mitään. Uudet tiimin jäsenet perehdyttiin ilman katastrofien palautuksen koulutusta. Oletetaan, että kaikki tietävät mitä tehdä katastrofin aikana ilman erityistä koulutusta tai tarkennusta.
Oletuksen vahvistus	⚡️ Palautustoimenpiteet olettavat, että varmuuskopio on käytettävissä 15 minuutin kuluessa, mutta varmuuskopioiden noutaminen kylmästä tallennustilasta kestää 8 tuntia. Oletetaan, että tiimi on paikalla 30 minuutin kuluessa, mutta puheluiden kierrätys- tai eskalointitoimenpiteitä ei ole määritetty. Palautusaikojen arvioinnit perustuvat optimistisiin oletuksiin, joita ei ole vahvistettu testauksen kautta.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
RTO-arkkitehtuurin tasaus	✅ Arkkitehtuurin päätökset vastaavat RTO-sitoumuksia. Minuuttien RTO vaatii automatisoidun vahvistuksen ja lämpimän valmiustilan. Tuntien RTO vaatii komentosarjan palautuksen ja lämpimän valmiustilan. Days RTO hyväksyy manuaalisen palautuksen kylmästä varmuuskopioinnista. Ylikäsittely vältetään, kun liiketoiminta ei oikeuta monimutkaisuutta.
RPO- replikointistrategia	✅ Replikointitapa vastaa RPO-kohdetta. Lähes nollan RPO: ei-synkronoitujen tapahtumien striimaaminen sovellusalustan tapahtumien kautta jokaiselle tietueen tallennukselle (propagation viive sekunteina, vähintään kerran toimitus). Minuuttien RPO: Muuta datan taltiointi asynkroninen replikointi. Tuntien RPO: ajoitettu erän API-nouto. Päiviä RPO: manuaalinen varmuuskopio kiinteällä aikataululla.
RTO-testaus	✅ Palautustoimenpiteet, joita testattiin ajoitetuissa olosuhteissa. Todellinen RTO mitattuna katastrofien palautuksen tarkennusten aikana. Kohde-RTO:n ja saavutetun RTO:n väliset aukot tunnistettiin ja korjattiin. RTO:n voi saavuttaa varapäällikkö, ei vain ensisijaiset asiantuntijat.
RPO-vahvistus	✅ Palautustestien aikana mitatut datan häviöt. Todellinen RPO verrattuna kohteeseen tarkennuksen aikana. Replikoinnin viiveä valvotaan jatkuvasti tuotantoympäristössä. Hälytykset määritetään, kun replikointi jää RPO-sitoumuksen jälkeen.
Kapasiteettikohtainen RTO/RPO	✅ Eri liiketoimintaominaisuuksilla on eri RTO/RPO-kohteita liiketoiminnan kriittisyyden mukaisesti. Sähköisen kaupankäynnin tilauskulku: 15 minuutin RTO, lähes nolla RPO (oikeuttaa usean organisaation aktiivisen ja passiivisen). Sisäinen Knowledge: 8 tunnin RTO, 24 tunnin RPO (oikeuttaa manuaalisen palautuksen varmuuskopiosta).
Kustannusten ja hyötyjen analyysi	✅ RTO/RPO-kohteet tasapainossa toteutuksen kustannusten kanssa. Tiukemmat tavoitteet vaativat kasvavia investointeja. Asiakirjoitettu liiketoimintatapaus, joka näyttää käyttökatkoksen kustannukset, jotka oikeuttavat katastrofien palautuksen investoinnin. Vuosittainen tarkastus vahvistaa, että sijoituksen ja liiketoiminta-arvon välinen tasaus jatkuu.
Palvelutasosopimuksen kohdistus	✅ Ratkaisun RTO/RPO-kohteet ottavat sovellusalustan palvelutasosopimuksen perustason huomioon. Ratkaisu voi tarjota RTO:ta parempaa kuin sovellusalustan perustasolla usean organisaation arkkitehtuurin avulla. Realistiset tavoitteet määrittävät sovellusalustan ominaisuudet perustana.
Palautusominaisuuksien valvonta	✅ Varmuuskopiovaluutan jatkuva valvonta (varmuuskopiovaihe vs. RPO-kohde). Hälytys, kun varmuuskopio jää ajoituksen jälkeen. Automatisoitu vahvistus, että palautusinfrastruktuuri (toissijainen organisaatio, ulkoinen tallennustila) on käytössä.
Automatisoitu vs. manuaalinen palautus	✅ Aggressiiviset RTO-kohteet (minuutteina) vaativat automatisoitua vahinkotapahtumaa minimaalisella henkilön toimenpiteellä. Moderoi RTO-kohteita (tunteina) salliaksesi komentosarjojen palautuksen ihmisen käynnistämisellä. Rentoutuneet RTO-kohteet (päivinä) hyväksyvät manuaalisen palautuksen dokumentoitujen toimenpiteiden mukaisesti.

Anti-Mallit

Mistä etsiä	Miltä huono näyttää
Epärealistiset tavoitteet	⚡️ Sitoutuminen 15 minuutin RTO-tilaan ja manuaaliset palautustoimenpiteet, jotka vaativat 4 tuntia. Nolla RPO:a ilman synkronoitua replikointiin perustuvaa infrastruktuuria. IT:n asettamat RTO-kohteet ilman arkkitehtuurin tukea.
Arkkitehtuurin virhe	⚡️ 30 minuutin RTO-sitoumus, mutta ei automatisoituja vahinkotapahtumia ja palautustoimenpiteitä, jotka ovat kokonaan manuaalisia. Nolla RPO-sitoumusta, mutta vain päivittäisiä varmuuskopioita määritetty. Aggressiiviset tavoitteet ilman vastaavia automatisointiin ja tarpeettomuuteen tehtyjä investointeja.
Ei-testatut tavoitteet	⚡️ RTO:ta ei vahvistettu koskaan ajoitettujen katastrofien palautustarkistusten avulla. Oletetaan, että 2 tunnin RTO on saavutettavissa, mutta sitä ei koskaan palauteta aikarajoituksissa. Todellisen katastrofin aikana havaittu, että dokumentoitu 4 tunnin RTO vaatii todellisuudessa 18 tuntia.
Yhtenäiset tavoitteet	⚡️ Kaikki ominaisuudet, joille on kohdistettu sama RTO/RPO, riippumatta liiketoiminnan kriittisyydestä. Sisäinen erien raportointijärjestelmä, joka on suunniteltu viiden yhdeksän pisteen saatavuudelle, kun taas tuotto-kriittisellä verkkokaupalla on sama tavoite. Suuri ylisijoitus ei-kriittisiin ominaisuuksiin ja alitason sijoitus kriittisiin järjestelmiin.
Riippuvuuksien ohittaminen	⚡️ RTO olettaa, että Salesforce-organisaatio palautetaan vain, mutta ratkaisu riippuu siitä, että ulkoinen henkilöllisyydentarjoaja ei ole käytettävissä. RPO olettaa, että datan varmuuskopio on riittävä, mutta integraatiotunnuksia ja kokoonpanoa ei varmuuskopioida. Palautusaikojen arvioinnit eivät huomioi riippuvaisten järjestelmien palautusaikaa.
Replikoinnin aukot	⚡️ Sitoutuminen 15 minuutin RPO-arvoon, mutta muutostietojen datan taltiointi on määritetty vain 3:lle 12 kriittisestä objektista. Sovellusalustan tapahtumien replikointi on määritetty, mutta tapahtumien toimitusvaiheita ei valvota. Replikointiin perustuva infrastruktuuri rikkoutuu ja pysyy huomaamattomana viikkoja katastrofiin asti.
Kustannusten tietämättömyys	⚡️ Sitoudut viiden yhdeksän saatavuuteen ymmärtämättä toteutuksen kustannuksia. RTO-/RPO-kohteet määritetään ilman kustannus-hyöty-analyysiä. Yritys ei halua rahoittaa infrastruktuuria, joka vaaditaan asiakkaille jo sitoutuneille tavoitteille.
Staattiset tavoitteet	⚡️ 5 vuotta sitten määritetty RTO/RPO ei ole koskaan arvioitu uudelleen liiketoiminnan kasvusta ja prioriteettien muutoksesta huolimatta. Tavoitteet säilyvät ennallaan, kun ratkaisu kehittyy ja kriittisyys muuttuu. Vuosittainen tarkastusprosessi poissa.
Asiakirjoissa olevat aukot	⚡️ RTO/RPO-kohteet, jotka on dokumentoitu arkkitehtuuridokumentissa, mutta joita ei ole ilmoitettu liiketoiminnan sidosryhmille. Yritys ei ole tietoinen sitoutuneista palautusmahdollisuuksista. Gap havaittiin, kun liiketoiminta odottaa 1 tunnin toipumista, mutta arkkitehtuuri tukee vain 24 tunnin RTO-kertakirjautumista.
Epätarkkuus	⚡️ Sitoudut ”99,97 %:n saatavuuteen”, kun valvontainfrastruktuuri ei voi mitata tätä tarkkuutta. Tavoitteet, jotka on määritetty väärällä tarkkuudella ja jotka ehdottavat tarkkuutta, kun analyysi perustuu karkeaan arviointiin.
Poissaolon valvonta	⚡️ Ei jatkuvaa palautusominaisuuksien valvontaa. Varmuuskopio jää 2 päivää ajoituksen jälkeen rikkoen RPO-sitoumusta, mutta ilman hälytyksiä. Aktiivisen/passivisen arkkitehtuurin toissijainen organisaatio, joka ei saa replikointipäivityksiä, mutta terveystarkastuksia ei ole määritetty.
Suunnittelu ilman suoritusta	⚡️ Kaunis katastrofien palautussuunnitelma, jolla on aggressiiviset RTO/RPO-kohteet, mutta ei automatisointia, testausta tai vahvistettuja toimenpiteitä. Suunnitelma, joka on luotu vaatimustenmukaisuuden täyttämiseksi, -valintaruutu, mutta sitoumusten takana ei ole toiminnallista todellisuutta.

Kuvio

Mistä etsiä	Miltä hyvä näyttää
Tietojen tarpeeton määrä	✅ Sovellusalusta tarjoaa infrastruktuurin varmuuskopioinnin automaattisesti. Sovellustason replikointi täydentää sovellusalustan varmuuskopiota, kun liiketoiminta vaatii nopeampaa palautusta. Muuta datan taltiointi tai Sovellusalustan tapahtumat -ominaisuus replikoi kriittistä dataa toissijaiseen tallennustilaan jatkuvasti. Replikointi sallii loogisten vioitusten tai kokoonpanojen virheiden palauttamisen, joita infrastruktuurin varmuuskopiot eivät voi korjata.
Sovellusten tarpeeton käyttö	✅ Tilattoman sovelluksen logiikka, joka selviytyy yksittäisistä transaktioiden virheistä. Ei palvelinpuolen tilaa, joka estäisi vaakasuoran skaalautumisen. Mukautetut metadatatyypit ja mukautetut asetukset kokoonpanolle ovat välittömästi käytettävissä kaikissa sovelluspalvelimissa. Mikä tahansa sovelluspalvelin voi käsitellä minkä tahansa pyynnön riippumatta tietystä palvelimen tilasta.
Integraation tarpeeton käyttö	✅ Virranvaihtokuvio havaitsee epäonnistuneet integraatiot. Sovellusalustan tapahtumat -ominaisuus asettaa pyyntöjä jonoon, kun ulkoiset järjestelmät eivät ole käytettävissä, sen sijaan, että se estäisi käyttäjien toiminnot. Ulkoiset järjestelmävirheet, jotka on eristetty käyttäjäkohtaisista toiminnoista. Useita ulkoisia tavarantoimittajien vaihtoehtoja, jotka on tunnistettu kriittisille integraatioille, jotka sallivat tarjoajan vaihdon nopeasti tavarantoimittajan käyttökatkosten aikana.
Usean organisaation kuviot kriittisille työkuormille	✅ Aktiivinen/passiivinen-kuvio: ensisijainen organisaatio tarjoaa kaiken liikenteen, toissijainen organisaatio on synkronoitu, mutta ei käytössä, failover ensisijaisen alueen käyttökatkoksen aikana. Aktiivinen-aktiivinen-kuvio: molemmat organisaatiot tarjoavat tuotantoliikennettä jatkuvasti, käyttäjät maantieteellisen sijainnin tai liiketoimintayksikön mukaan. Usean organisaation perustelu vain, kun liiketoiminta vaatii RPO/RTO-kertakirjautumisen sovellusalustan ominaisuuksien lisäksi.
Usean organisaation datan synkronointi	✅ Muutosdatan datan taltiointi tarjoaa lähes reaaliaikaisen replikoinnin kriittisille tiedoille (15 minuutin RPO). Sovellusalustan tapahtumat -ominaisuus tarjoaa tapahtumien suoratoiston kriittisille transaktioille (lähes nollan RPO). Bulk API 2.0 -ajoitettu replikointi viitetiedoille (24-tuntinen RPO hyväksytty). Ristiriidan ratkaisustrategia, joka on määritetty aktiivisille käyttäjille, kun samaa tietuetta muokataan molemmissa organisaatioissa.
Usean organisaation aktiivinen/passiivinen arkkitehtuuri	✅ Yhdysvaltojen Itä-alueen ensisijainen organisaatio tarjoaa kaiken tuotantoliikenteen. Toissijainen organisaatio Euroopassa, synkronoitu CDC:n kautta, mutta ei käytössä. DNS-reititys- tai todennuskerros ohjaa käyttäjät aktiiviseen organisaatioon. Automatisoidut terveystarkastukset käynnistävät epäonnistumisen, kun ensisijainen organisaatio ei ole käytettävissä 10 peräkkäisen minuutin ajan.
Usean organisaation aktiivinen-aktiivinen arkkitehtuuri	✅ EMEA-käyttäjät Euroopassa, AMER-käyttäjät Yhdysvalloissa käyttäjäprofiilin alue -kentän perusteella. Kaksisuuntainen replikointi jaetuille viitetiedoille (tileille, tuotteille). Alueelliset tiedot säilyvät vastaavissa organisaatioissa (tilaukset, tapaukset). Ristiriitojen ratkaiseminen käyttää asiakkaan päädatalle viimeksi kirjoitettuja/voitettu-arvoja, joilla on alueellinen arvo.
Maantieteellinen jakauma	✅ Hyperforce sallivat maantieteellisen jakauman. Yhden alueen käyttöönotto, jonka sovellusalustan hallitsema tarpeeton käyttöaste on 99,9 %. Useita organisaatioita eri alueilla, jotka otetaan huomioon vain 99,95 %:in vaatimuksille tai lakisääteisten datan residenssien tehtäville.
Ulkoisen järjestelmän tarpeeton käyttö	✅ Kriittisillä ulkoisilla API-rajapinnoilla on ensisijainen päätepiste ja vahinkotapahtumien päätepiste. Viestiketju siirtyy vahinkotapahtumien päätepisteeseen, kun ensisijainen kokemus epäonnistuu. Ulkoiset palvelut, joilla on maantieteellinen tarpeeton käyttöoikeus, ovat suositeltuja yksittäisten alueiden tarjoajille kriittisiä integraatioita varten.
Infrastruktuurin valvonta	✅ Trust.salesforce.com valvotaan status API:n kautta. Tilaa instanssikohtaisia tilan ilmoituksia. Ratkaisu reagoi sovellusalustan kuntoon dynaamisesti vähentämällä ei-kriittistä kuormaa heikentymisen aikana. Skaalikeskus tunnistaa resurssiintensiteettiset toiminnot ennen kuin ne vaikuttavat tarpeettomaan kapasiteettiin.
Virheenkorjauksen automatisointi	✅ Automatisoitu vahinkotapahtuma, jota suositaan manuaalisesti aggressiivisille RTO-kohteille. Terveystarkastukset suoritetaan 1–5 minuutin välein virheiden havaitsemiseksi. Failover decision logic välttää vääriä positiivisia arvoja (vaatii jatkuvan epäonnistumisen, ei väliaikaisia virheitä). Automatisoitu periytyminen, jos myös virheenkorjauksen kohde ei ole terve.
Yksittäiset virhepisteet	✅ Arkkitehtuurin tarkastus tunnistaa kaikki yksittäiset virhepisteet. Jokainen tunnistettu SPOF arvioidaan liiketoiminnan vaikutuksen ja lieventämisen kustannusten perusteella. Korkean vaikutuksen SPOF:t lieventyvät tarpeettomuuden takia. Vähäisen vaikutuksen SPOF-operaattorit, jotka hyväksytään dokumentoiduilla riskien hyväksymis- ja palautusmenettelyillä.
Todennäköisyyksien testaaminen	✅ Ajoitetut vahvistukset vahvistavat automatisoidun vahvistuslogiikan. Varmuuskopiojärjestelmät, joita testattiin latauksen aikana (ei vain myöhässä lämpimässä valmiudessa). Toissijaisen organisaation kapasiteetin vahvistama tuotantomuotojen käsittely aktiivisten/passivisten testien aikana. Jokaisesta testistä saadut kokemukset parantavat automatisointia ja toimenpiteitä.

Anti-Mallit

Mistä etsiä	Miltä huono näyttää
Yksittäiset virhepisteet	⚡️ Koko ratkaisu on riippuvainen yhdestä ulkoisesta API-rajapinnasta ilman varaosaa. Mukautetun toimialueen tarjoaja on SPOF – jos tarjoaja epäonnistuu, käyttäjät eivät voi käyttää Experience Cloudia. Yksittäisen integraation käyttäjätili – jos se ei ole käytössä, kaikki integraatiot epäonnistuvat.
Todentamaton tarpeeton käyttö	⚡️ Usean organisaation aktiivinen/passiivinen arkkitehtuuri määritetty, mutta ei koskaan testattu. Toissijainen organisaatio ei ole synkronoitu, mutta terveystarkastuksia ei ole määritetty. Ensimmäinen failover-yritys tapahtuu todellisen katastrofin aikana, kun toissijainen organisaatio on korruptoitunut tai ei toimi.
Datan synkronoinnin aukot	⚡️ Aktiivinen/passiivinen usean organisaation CDC- replikointi on määritetty 5:lle kriittiselle objektille. Virheenkorjaus tapahtuu, mutta toissijaisesta organisaatiosta puuttuu 80 % vaaditusta datasta. Replikoinnin viiveen valvonta poissa - toissijainen organisaatio 3 päivää ensisijaista, mutta ei hälytyksiä.
Epätosi ylimääräinen	⚡️ Oletetaan, että usean alueen arkkitehtuuri, kun molemmat organisaatiot ovat itse asiassa isännöineet samaa Hyperforce. Tarpeettomat ulkoiset API-rajapinnat, jotka käyttävät itse asiassa samaa upstream-todentajaa. Useita integraatiopolkuja, jotka reitittävät kaikki saman virhepisteen läpi.
Tilallinen arkkitehtuuri	⚡️ Sovelluslogiikka riippuu muistissa olevasta tilasta, joka estää vaakasuoran skaalan. Yksi sovelluspalvelin säilyttää kaikki käyttäjäistunnon tilat - palvelimen uudelleenkäynnistys kirjaa kaikki käyttäjät ulos. Staattiset resurssit, jotka on tallennettu sovelluksen muistiin sovellusalustan välimuistin sijaan, mikä aiheuttaa epäjohdonmukaisuutta eri palvelimilla.
Ei katkaisijoita	⚡️ Ulkoinen integrointi epäonnistuu ja jokainen transaktio odottaa täyttä 120 sekunnin aikakatkaisua. Kaikki käyttäjät vaikuttavat siihen, kun yksi ulkoinen järjestelmä ei ole käytettävissä. Ei virheiden eristämistä - yksi epäonnistunut integraatio heikentää koko sovellusalustan suorituskykyä.
Vain manuaalinen failover	⚡️ Usean organisaation arkkitehtuuri, jossa on vain manuaaliset virheenkorjaustoimenpiteet. Vaatii 2 tunnin toimenpiteen käynnistääkseen epäonnistumisen liiketoiminnan aikana. Automatisoituja terveystarkastuksia ei otettu käyttöön. Failover-päätös vaatii päällikön hyväksynnän, joka viivästyttää palautusta.
Kapasiteettisuunnitelman virhe	⚡️ Toissijainen organisaatio aktiivisessa ja passiivisessa arkkitehtuurissa, joka kattaa 20 % tuotantomuodosta. Virheenkorjaus tapahtuu, mutta toissijainen organisaatio ei voi käsitellä täyttä tuotantoliikennettä. Aktiivinen arkkitehtuuri, jossa molempien organisaatioiden kapasiteetti on 85 % ja joka ei jätä tarpeettomia tietoja, kun yksi organisaatio epäonnistuu.
Kokoonpanovaihe	⚡️ Ensisijaiset ja toissijaiset organisaatiot eroavat ajan myötä, koska käyttöönottoja ei synkronoitu. Metadata otettu käyttöön ensisijaiselle, mutta ei toissijaiselle. Failover paljastaa toissijaisen organisaation, joka käyttää 6 kuukauden vanhaa koodiversiota.
Ylikäsittely	⚡️ Usean organisaation arkkitehtuuri, jossa on aktiivinen ja aktiivinen replikointi sisäisille pääkäyttäjien työkaluille, joita 5 henkilöä käyttävät. Usean organisaation monimutkainen toiminta, jota liiketoiminnan kriittisyys ei perustele. Eräraportoinnin 99,999%:n saatavuustavoite hyväksytty 99%.
Maantieteellinen väärinkäsitys	⚡️ Oletetaan, että Hyperforce “monen alueen” tarjoaa usean organisaation ominaisuuksia automaattisesti. Et ymmärrä, että yksi organisaatio on aina yhdessä alueessa ja useat alueet vaativat useita organisaatioita. Maantieteeseen perustuva päällekkäisyys on mahdotonta yhden organisaation arkkitehtuurilla.
Integraation kopiointi	⚡️ Kaikki integraatiot synkronoidaan ilman asynkronointia. Ulkoinen järjestelmä ei ole käytettävissä estää käyttäjiä. Ei jonomekanismia - transaktiot epäonnistuvat, jos ulkoinen järjestelmä ei toimi väliaikaisesti. Käyttäjät eivät voi jatkaa, kun integroinnin tuki ei ole käytettävissä.