Luotettavuus

Salesforce käyttää joustavaa infrastruktuuria useilla alueilla, jossa on automatisoitu vahinkotapahtuma ja infrastruktuuritason joustavuus. Sovellusalusta käsittelee datakeskuksen tarpeettoman käytön, verkkojen saatavuuden ja infrastruktuurin korjauksen ja näyttää sovellusalustan saatavuuden tilan reaaliajassa osoitteesta trust.salesforce.com.

Suunnittelet luotettavuuden kaikelle tällä infrastruktuurilla suoritetulle: datamallit, jotka skaalautuvat hallintarajoituksiin, transaktiot, jotka ennustavat ja palauttavat epäonnistumisia, valvonta, joka havaitsee, kun ratkaisusi poikkeaa saatavuustavoitteista, ja katastrofien palautusmenettelyt, jotka palauttavat liiketoiminnan, kun epäonnistumiset tapahtuvat.

Salesforce-palvelutasosopimus kattaa sovellusalustan, mutta omistat luotettavuuden kaikkiin infrastruktuuritason yläpuolella oleviin kohteisiin. Sinä olet vastuussa omien palvelutasojen tavoitteiden (SLO) määrittämisestä ja saavuttamisesta, eli yrityksesi vaatimista luotettavuustavoitteista. Sovellustason luotettavuus on edelleen vastuullasi sovellusalustan palvelutasosta riippumatta. Sama sovellusalusta, joka takaa saatavuuden, rajoittaa sitä myös: hallintorajoitukset rajoittavat kunkin vuokralaisen resurssin kulutusta siten, ettei yksittäinen vuokralainen voi heikentää sovellusalustaa muille. Ratkaisusi täytyy siis skaalata hienovaraisesti näiden rajoitusten sisällä, eikä se vaadi vain enemmän kapasiteettia.

Epäluotettavat ratkaisut voivat aiheuttaa jatkuvia liiketoimintavaikutuksia. Tuoton kulku hidastuu, kun kaupankäyntialustat eivät ole käytettävissä. Tuottavuus heikkenee, kun sisäiset työkalut epäonnistuvat työnkulun aikana. Trust heikkenee, kun data korruptoituu tai tietueet menetetään. Nämä ongelmat heikkenevät ajan myötä, kun ratkaisuja kerääntyy ja tekninen velka kasvaa.

Luotettavuus ei tarkoita kaikkien virheiden välttämistä. Virheitä tapahtuu jaetuissa järjestelmissä. Luotettavuus tarkoittaa järjestelmien suunnittelua, jotka ennustavat virheitä, auttavat estämään räjähdyksen säteen ja palauttavat palvelun automaattisesti. Luotettavuusvaatimukset vaihtelevat liiketoiminnan vaikutuksen mukaan. Esimerkiksi asiakaskohtainen Experience Cloud -portaali, joka vaatii 99,9%:n saatavuuden, sisältää olennaisesti erilaisia arkkitehtonisia valintoja kuin sisäinen eräraportointiprosessi, joka sietää satunnaisia viiveitä.

Luotettavuus ja suorituskyky ovat läheisessä yhteydessä toisiinsa. Osoitteiden valvonta, vahinkotapahtumien vastaus ja järjestelmän saatavuus. Tämä päällekkäisyys tapahtuu tarkoituksella, ei vahingossa. Eroavaisuutena on suunnitteluaika vs. suoritusaika.

Luotettavuus on se, mitä rakennat järjestelmään ennen sen suoritusta, mukaan lukien:**

• aiemmin mainitut datamallit, jotka skaalautuvat hallintarajoitusten sisällä
• transaktiot, jotka ennustavat ja palauttavat epäonnistumisen
• räjähdyssäteen sisältävät tarpeettomat ja katkaisijat
• palautustavoitteet – palautuksen aikainen tavoite (RTO) ja palautuspisteen tavoite (RPO), jotka määrittävät, miten järjestelmäsi käyttäytyy, kun asiat epäonnistuvat.

Luotettavuus on tärkeää. Se on ratkaisusi rakenteellinen ominaisuus.

Operational Excellence on tapa, jolla voit käyttää, parantaa ja ylläpitää järjestelmää sen käynnistyessä, mukaan lukien:

• käyttöönottokäytännöt, jotka vähentävät muutosten riskiä
• suorituskirjat ja eskalointipolut, jotka opastavat tiimiäsi vahinkotapahtumien aikana
• havaittavuusputket, jotka näyttävät signaalit
• palautussilmukat, jotka parantavat järjestelmää ajan myötä.

Operatiivista huippuosaamista käytetään; se on ratkaisusi ihmisten ja prosessien kuria.

Kahden pilarin välinen yhteinen kohde on seuranta- ja havaittavuuskerros. Valvonta on suunniteltu luotettavuutta koskevaan kysymykseen. Sinun tulisi rakentaa havaittavissa olevia järjestelmiä. Sitä käytetään Operational Excellence -asiantuntemuksena. Tiimisi toimii sen perusteella, mitä nämä järjestelmät kertovat sinulle. Luotettavuus kattaa rakentamasi arkkitehtokuvion, kuten hälytysten kynnysarvot ja terveysmittaristot. Operational Excellence kattaa, miten tiimisi reagoi signaaleihin, kuten suorituskerhoihin ja vastauksiin.

Ota huomioon tämä eroavaisuus: Luotettavuus osoittaa ”säästääkö tämä järjestelmä?” ja Operational Excellence osoittaa ”voiko tiimisi käyttää sitä?”. Täysin luotettava järjestelmä, jota tiimi käyttää ilman suorituskertoja, epäjohdonmukaisia käyttöönottoja tai palautteen silmukoita, voi epäonnistua käytännössä. Käytännöllisesti hyvä tiimi, joka hallitsee hauraita ja heikosti suunniteltuja järjestelmiä, on täynnä vahinkotapahtumia, joita se ei voi estää. Molemmat pilarit ovat välttämättömiä, eikä kumpaakaan korvaa toista.

Luotettavuus ei toimi erillään. Kuten edellisissä osioissa on kuvattu, Operational Excellence on sen lähin kumppani. Nämä kaksi pilaria jakavat havaittavuuskerroksen: Luotettavuus määrittää, mitä rakennat järjestelmään, ja Operational Excellence määrittää, miten tiimisi toimii. Lisäksi Trust vaatii infrastruktuurin, joka kestää hyökkäyksiä ja ylläpitää datan eheyttä: järjestelmä ei ole luotettava, jos se voidaan vaarantaa. Resurssien optimointi estää hallintarajoitusten tyhjentymisen ja varmistaa, että sovellusalusta pysyy luotettavana laajuudeltaan. Kustannusten optimointi tasapainottaa luotettavuusinvestoinnit niiden tarjoaman liiketoiminta-arvon kanssa. Saatavuustavoitteet oikeuttavat niiden saavuttamiseen vaaditun arkkitehtonisen monimutkaisuuden. Yksittäinen pilari ei tuota hyvin rakennettua ratkaisua erillään — Luotettavuus tarjoaa rakenteellisen perustan, jota muut pilarit riippuvat ja vahvistavat.

Käytä näitä periaatteita ohjataksesi arkkitehtuuripäätöksesi sovellusalustan luotettavuuden osalta.

• Jaa työkuorma bulkkauksen avulla. Käsittele useita tietueita yksittäisissä transaktioissa sen sijaan, että luottaisit peräkkäisiin tietuekohtaisiin toimintoihin. Bulkkaaminen jakaa hallintarajoitukset yhteen transaktioon käsiteltyyn erään, noudattamalla näitä rajoituksia ja maksimoimalla läpimenoa. Kokoelmiin perustuva Apex, erätyöt, joilla on määritettävä vaikutusalue, ja joukkona kulutetut sovellusalustan tapahtumat sisältävät tämän periaatteen. Hyvin bulkatut ratkaisut käsittelevät 200 tietuetta, joilla on yhtä monta SOQL- ja DML-lausuntoa kuin yhdellä tietueella peräkkäisessä käsittelyssä. Jaetut työkuormakuvioet tarjoavat kestävyyttä, koska yksittäinen tietueen virhe ei vaikuta koko erän käsittelyyn.
• Oletetaan, että kaikki epäonnistuu. Hallintarajoitukset, sovellusalustan huoltojaksot ja integraatioiden sidonnaisuudet luovat Salesforce multitenant -arkkitehtuuriin liittyviä virhetiloja. Suunnittele nämä sovellusalustakohtaiset virheet alusta alkaen. SOQL-kyselyt ylittävät rivien rajoitukset datavirran perusteella. Apex CPU -aika saattaa vanhentua monimutkaisten laskentojen aikana. Callout-kutsujen aikakatkaisut saattavat tapahtua, kun ulkoiset palvelut ovat hitaita. DML-rivien lukitukset epäonnistuvat, kun samanaikaiset transaktiot törmäävät toisiinsa. Tallennustilan rajoitukset voivat epäonnistua, kun tiedostojen lataaminen palvelimelle kasvaa odottamattomasti. Näiden virheiden varalta suunnittelevat arkkitehtit luovat ratkaisuja, jotka ovat luotettavia ilman manuaalisia toimenpiteitä. Nämä luotettavat järjestelmät havaitsevat lähestyvät hallintarajoitukset, säilyttävät räjähdyksen virheiden käsittelyn kautta ja palauttavat sen automaattisesti uudelleenyrityksillä ja sovellusalustan tapahtumilla.
• Laadi itse palautettavat järjestelmät. Suunnittele ratkaisuja, jotka havaitsevat virheet ja palautuvat automaattisesti ilman ihmisten toimia. Sovellusalustan tapahtumat -ominaisuus ottaa käyttöön mukautettuja uudelleenyrityskuvioita. Toimitus tilaajalle voidaan yrittää uudelleen EventBus.RetryableExceptionilla, vaikka alkuperäisen transaktion toistaminen vaatii mukautetun arkkitehtuurin. Kulkujen virheiden käsittely ohjaa poikkeukset palautuskulkuihin. Apex erottelevat osittaiset virheet - epäonnistunut osa ei estä muita osioita käsittelemästä - mikä mahdollistaa työn osittaisen suorittamisen ja kohdennetun uudelleenyrityksen. Toteuta selkeä uudelleenyrityslogiikka käyttämällä AsyncApexJob-virheiden seurantaa väliaikaista virheiden palautusta varten. Käytä näihin uudelleenyrityskuvioihin eksponentiaalista rästityötä, kun käsittelet väliaikaisia virheitä. Itse palautettavat järjestelmät ylläpitävät saatavuustavoitteita myös työaikojen ulkopuolella tapahtuvien vahinkotapahtumien aikana, kun ihmisvastaajia ei välttämättä ole saatavilla, mikä vähentää toimintakuormaa ja parantaa keskiarvoista palautusaikaa.
• Suunnittele liiketoimintavaatimukset ensin. Määritä palvelutasot todellisten liiketoimintavaikutusten perusteella ennen teknisten ratkaisujen valitsemista. Kaikki komponentit eivät vaadi saatavuutta 5-9. Täsmää luotettavuusinvestoinnit liiketoiminnan kriittisyyteen ja suunnittele hienovarainen heikentäminen tukiominaisuuksille. Realistiset tavoitteet sallivat asiaankuuluvien arkkitehtuurivaihtoehtojen ja välttyvät liialliselta suunnittelulta tai alitason toimitukselta.
• Vahvista palautus tarkentamisen avulla. Ajoita katastrofien palautuksen tarkennuksia, jotka testaavat varmuuskopioiden palautusta, virheenkorjaustoimenpiteitä ja vahinkotapahtumien vastausten toistokirjoja. Palauta Full Copy -sandbox tuotantoympäristöstä varmuuskopioidaksesi palautusprosesseja. Esittele tarkoituksellisia virheitä sandbox-ympäristöissä varmistaaksesi, että valvonta havaitsee ongelmia ja että automatisoitu palautus suoritetaan oikein. Tarkentamiset paljastavat toimenpiteiden, työkalujen ja suorituskirjojen aukkoja ennen kuin todelliset vahinkotapahtumat paljastavat ne. Dokumentoi tarkemmat tulokset ja seuraa havaittujen aukkojen korjaamista. Säännöllinen testaus varmistaa, että palautusominaisuudet pysyvät ajan tasalla ratkaisujen kehittyessä ja tiimin jäsenyyksien muuttuessa.

Salesforcen toimintojen ymmärtäminen auttaa sinua keskittymään luotettavuuden suunnitteluun siihen, mitä sinä hallitset. Sovellusalusta käsittelee infrastruktuurihäiriöitä, jotka vaativat erityisiä tiimejä perinteisissä IT-ympäristöissä, kuten:

• Monen alueen infrastruktuuri ja virheenkorjaus: Salesforce Hyperforce tarjoaa alueellisille datakeskuksille sisäisten palveluiden automatisoidun asennuksen. Se tarjoaa myös useita saatavuusvyöhykkeitä alueiden sisällä ja datan replikointia infrastruktuuritasolla. Sovellusalusta käsittelee tarpeettomuuden ja saatavuusvyöhykkeiden jakauman alueiden sisällä avoimesti.
• Alustan palvelutasosopimusten sitoumukset: Sopimusluonteisia korjauksia sisältävät takuutut saatavuustasot neuvotellaan asiakaskohtaisesti. trust.salesforce.com julkaisee sovellusalustan tilan ja toiminta-aikahistorian reaaliajassa, mutta kaikki tietyt saatavuustakuut ja niihin liittyvät korjaukset kuuluvat neuvoteltuun sopimukseesi. Tarkasta sopimuksesi ja tämänhetkinen Salesforcen Trust and Compliance -dokumentaatio organisaatioosi liittyvien sitoumusten varalta.
• Infrastruktuurin tarpeeton käyttö: Sovellusalusta ylläpitää tarpeettomia palvelimia, verkkopolkuja, tietokantainfrastruktuuria ja tallennusjärjestelmiä. Infrastruktuuritason vahinkotapahtuma tapahtuu automaattisesti laitteistovirheiden aikana ilman asiakkaan toimia. Sovellusalustan varmuuskopiot suojaavat infrastruktuuritason datan katoamiselta.
• Alustan ylläpito ja päivitykset: Sovellusalustan suuret julkaisut tarjoavat ominaisuuksia ja suojausversioita, jotka ovat Salesforcen hallitsemia yhteensopivia. Sovellusalustan huoltojaksot ajoitetaan ja ne ilmoitetaan osoitteessa trust.salesforce.com. Infrastruktuurin korjaus tapahtuu läpinäkyvästi ilman asiakkaan osallistumista.
• Ydinsovellusalustan terveysvalvonta: Salesforce valvoo infrastruktuurin suorituskykyä, mukaan lukien tietokannan vastausaikoja, verkkoviiveitä, API-yhdyskäytävän kuntoa ja tallennustilan suorituskykyä. Sovellusalustan kunnon tila näytetään osoitteessa Trust.salesforce.com ja se sisältää reaaliaikaisia vahinkotapahtumien päivityksiä. Instanssikohtainen tila on käytettävissä Status API:n kautta.

Nämä sovellusalustan toiminnot luovat perustuksen, johon rakennat. Et hallitse datakeskuksia, provisiointipalvelimia tai suunnittele infrastruktuurin katastrofien palautusta. Sen sijaan olet vastuussa siitä, mitä suunnittelet ja määrität tämän perusteen päälle.

Jaetun vastuun malli määrittää, että sinä omistat luotettavuuden kaikille Salesforcen avulla luomillesi kohteille. Sovellusalustan luotettavuus ottaa työsi käyttöön, mutta ei korvaa sitä. Luotettavuusvastuusi kattavat kuusi toisiinsa liittyvää aluetta:

Palvelutasotavoitteet (SLO) määrittävät luotettavuusvaatimukset mitattavissa termeissä. SLO:t yhdistävät liiketoimintavaatimukset ja teknisen arkkitehtuurin. Ennen kuin valitset teknologioita tai suunnittelet datamalleja, luo SLO-uloskirjautumiset, jotka määrittävät onnistumisen jokaiselle kriittiselle käyttäjäkululle.

SLO:t mittaavat tavallisesti:

• Käytettävyys – kuinka kauan järjestelmä on käytössä ja käytettävissä
• Viive - toimintojen suorittamiseen tarvittava aika, mitattuna prosenttilukuna (p50, p95, p99)
• Throughput - onnistuneesti suoritettujen toimintojen määrä per yksikköaika
• Virhesuhde - epäonnistuvien tai virheellisten pyyntöjen prosenttiosuus
• Palautusaika - kesto, joka vaaditaan vahinkotapahtumien jälkeen

Määritä SLO-kertakirjautumiset liiketoimintaominaisuuden perusteella, äläkä teknisen komponentin perusteella. Käyttäjäkohtaiset ominaisuudet vaativat tiukempia SLO-uloskirjautumisia kuin hallinnalliset tai eräprosessit. Jokaisen SLO:n tulisi olla objektiivisesti mitattavissa käytettävissä olevien instrumentaatioiden avulla.

Palvelutasosopimukset (SLA) ovat sopimusluonteisia sitoumuksia, jotka aiheuttavat epäonnistumisen seurauksia. Kaikki takuutut saatavuustasot ja niiden sopimusluonteiset korjaukset neuvotellaan per asiakas. Tarkasta organisaatioosi koskevat sitoumukset sopimuksestasi ja nykyisestä Salesforcen Trust ja vaatimustenmukaisuuden dokumentaatiosta.

Ratkaisujen SLO-uloskirjautumisten tulisi olla vähemmän tiukkoja kuin sovellusalustan palvelutasosopimukset, jotta virheiden budjetti säilytetään. Jos sovellusalustan palvelutasosopimuksesi ja ratkaisusi palvelutasosopimuksen tavoite on molemmat 99,9 %, kaikki merkittävät sovellusalustan käyttökatkokset kuluttavat virhekustannuksesi suoraan — jolloin sovelluskerroksen vikojen, integrointiongelmien tai suunnitellun huollon varalta ei jää mitään puskuria samalle mittausajanjaksolle. SLO-uloskirjautuminen rikkoutuu muodollisesti vain, kun kumulatiivinen käyttökatkos kuluttaa mittauksen ajanjakson koko virhebudjetin. Jos palvelutasosopimuksellesi ja SLO:lle on määritetty sama tavoite, yksi sovellusalustan vahinkotapahtuma saattaa tyhjentää kyseisen budjetin kokonaan. Kun sovellusalusta tarjoaa esimerkiksi 99,9 %, kohdista ratkaisun SLO-kertakirjautuminen 99,5 %:iin säilyttääksesi hyödyllisen puskurin ongelmista, joita sinun täytyy korjata — sovellusvirheistä, integraatiovirheistä ja käyttöönottoikkunoista.

Palvelutasojen osoittimet (SLI) ovat mittoja, joita käytetään SLO-uloskirjautumisen saavuttamisen arvioimiseen. SLI-objektien täytyy olla objektiivisesti mitattavissa, kerätty johdonmukaisesti ja suoraan sidoksissa käyttäjäkokemukseen.

Salesforce-ratkaisujen SLI-kertakirjautumisiin sisältyy:

• Sovellusalustan toiminta-aika osoitteesta Trust.salesforce.com
• Sivujen latausaika Experience Cloud -analyysien kautta
• API-vastausaika Event Monitoringin kautta (joka vaatii Event Monitoringin lisäosan tai Salesforce Shieldin)
• Transaktioiden onnistumissuhde mukautetun sovelluksen kirjaamisen kautta
• Erätöiden suorittaminen AsyncApexJob-valvonnan kautta

Korkeamman saatavuuden tavoitteet lisäävät monimutkaisuutta ja kustannuksia nopeasti. Ymmärrä arkkitehtuuriset vaikutukset ennen tavoitteiden sitouttamista:

Vältä satunnaisia tavoitteita, kuten "viisi yhdeksää kaikesta". Arvioi sen sijaan käyttökatkosten liiketoimintavaikutuksia per kapasiteetti ja aseta tavoitteet sen mukaisesti. Sisäinen eräraportti, joka sallii 7 tunnin kuukausittaisen käyttökatkoksen, vaatii olennaisesti erilaisen arkkitehtuurin kuin tuotto-kriittinen tilausten käsittely, joka vaatii osa-aikojen palautuksen.

Määritä luotettavuus käyttäjän näkökulmasta, äläkä pelkästään teknisistä tilastoista. Järjestelmä, joka raportoi 99,9 %:n toiminta-ajan, mutta jolla on usein aikakatkaisuja, epäonnistuu käyttäjäkokemukseen perustuvalla luotettavuudella. Käyttäjät huolehtivat työnkulkujensa suorittamisesta onnistuneesti enemmän kuin yksittäisten API-käyttöaika.

Suunnittele SLO-kertakirjautumiset, jotka vastaavat käyttäjien matkoja yksittäisten API-kutsujen sijaan. Monivaiheinen Checkout vaatii, että kaikki vaiheet suoritetaan onnistuneesti hyväksyttävässä ajassa. Mittaa loppukäyttäjien kulkujen suoritussuhteita ensisijaisena luotettavuuden osoittimena. Komponenttien saatavuus on välttämätöntä, mutta ei riittävää käyttäjäkokemuksen luotettavuuden kannalta.

Salesforce Hyperforce tarjoaa alueellisia datakeskuksia, jotka sallivat maantieteellisen jakauman. Sovellusalusta käsittelee infrastruktuurin tarpeettomuuden alueiden sisällä, mukaan lukien useat saatavuusvyöhykkeet, sisäisten palveluiden automaattinen vahinkotapahtuma ja datan replikointi infrastruktuuritasolla. Sovellusalustan palvelutasosopimukset vastaavat tätä infrastruktuurin tarpeettomuutta.

Useimmille ratkaisuille yksialueinen käyttöönotto ja sovellusalustan hallitsema tarpeeton käytettävyys tarjoavat riittävän saatavuuden. Trust Salesforce-infrastruktuuri perushyödyllisyydelle ja ratkaisujen arkkitehtuuri keskittyy sovellustason luotettavuuteen, mukaan lukien vianmäärittävät integraatiokuvioet, hienovarainen heikentyminen ja automatisoitu palautus.

Alueiden sisäinen vianmääritys käytettävyysalueiden välillä tapahtuu automaattisesti ja se sisältyy sovellusalustan palvelutasosopimusten vakiomuotoisiin sitoumuksiin — Salesforce hallitsee tätä avoimesti infrastruktuuritasolla. Alueiden välinen (alueen ulkopuolinen) katastrofien palautus on erillinen maksullinen tarjous, eikä se sisälly oletusarvoisesti mihinkään vakiomuotoiseen versioon. Jos liiketoiminnan jatkuvuutta koskevat vaatimuksesi vaativat alueiden välistä epäonnistumista, dokumentoi tämä riippuvuus erikseen katastrofien palautussuunnitelmassasi, jotta sidosryhmät ymmärtävät sovellusalustan joustavuuden ja ostettujen alueiden välisten DR-ominaisuuksien eroavaisuudet.

Usean organisaation arkkitehtuuri tarjoaa vahvin eristys ja maantieteellisen tarpeettomuuden, mutta monimutkaistaa toimintaansa, mukaan lukien datan synkronointi, käyttäjien provisiointi, käyttöönoton koordinointi ja lisenssien kustannukset. Varata usean organisaation kuvioita skenaarioille, joissa liiketoimintavaatimukset selkeästi oikeuttavat monimutkaisuuden. Oletetaan esimerkiksi, että useat organisaatiot käyttävät seuraavia skenaarioita:

• Yritys vaatii taattua RPO/RTO-kertakirjautumista sovellusalustan ominaisuuksien lisäksi
• Säännökset vaativat maantieteellisen datan eristämistä, liiketoiminnan jatkuvuuden suunnittelu vaatii täydellisen riippumattomuuden yhdestä alueesta
• Organisaation yhdistäminen ei ole mahdollista liiketoimintayksiköiden itsenäisyysvaatimusten vuoksi.

Aktiivinen/epäaktiivinen-kuvio: - Ensisijainen organisaatio tarjoaa kaiken liikenteen normaaleissa olosuhteissa. Eri alueiden toissijaiset organisaatiot pysyvät synkronoituina, mutta toimettomina. Virheenkorjaus tapahtuu ensisijaisen alueen käyttökatkoksen aikana. Tämä ratkaisu tarjoaa yksinkertaisimman usean organisaation kuvion, mutta jättää toissijaisen kapasiteetin käyttämättä. DNS-reititys- tai käyttäjien todennuskerrokset ohjaavat käyttäjät aktiiviseen organisaatioon.

Aktiivinen-aktiivinen-kuvio: - Molemmat organisaatiot tarjoavat tuotantoliikennettä jatkuvasti. Käyttäjät on jaettu maantieteellisen sijainnin, liiketoimintayksikön tai työkuormatyypin mukaan. Aktiivinen-aktiivinen maksimoi kapasiteetin käyttöasteen, mutta vaatii hienostuneen datan synkronoinnin ja käyttäjien reitityksen. Ristiriitojen ratkaiseminen on tärkeää, kun samaa tietuetta muokataan molemmissa organisaatioissa.

Suunnittele datan synkronointi RPO-vaatimusten mukaisesti. Sovellusalustan tapahtumat -ominaisuus tarjoaa lähes reaaliaikaisen tapahtumaviestiketjun kriittisille datan muutoksille. Muutosdatan datan taltiointi tarjoaa muutosten automaattisen seurannan valituille objekteille pienellä kehityksellä. Ajoitettu API- replikointi Bulk API 2.0:n kautta kiinteillä aikavälillä soveltuu vähemmän ajasta riippuvaisiin viitetietoihin.

Käytä datalle, sovellukselle ja integraatiokerroksille tarpeettomia tietoja välttyäksesi yksittäisiltä virheiltä. Kerroksinen redundanssi varmistaa, että yksittäisen kerroksen virhe ei vaikuta järjestelmän yleiseen saatavuuteen.

• Datan tarpeeton käyttö: Sovellusalusta tarjoaa tarpeettoman datan infrastruktuurin varmuuskopioinnin avulla. Täydennä tätä tarpeettomuutta sovellustason replikoinnilla, kun yritys tarvitsee palautusta nopeammin kuin mitä sovellusalustan palautustoimenpiteet tarjoavat. Käytä Muuta dataa taltiointi- tai sovellusalustan tapahtumia replikoidaksesi kriittistä dataa toissijaiseen tallennustilaan tai ulkoisiin järjestelmiin jatkuvasti. Tämä mahdollistaa loogisten vioitusten tai kokoonpanovirheiden palautuksen, joita infrastruktuurin varmuuskopiot eivät voi korjata.
• Sovelluksen tarpeeton käyttö: Suunnittele tilatonta sovelluslogiikkaa, jotta mikä tahansa sovelluspalvelin voi käsitellä pyyntöjä. Vältä palvelinpuolen tilaa, joka estää vaakasuoran skaalautumisen. Käytä mukautettuja metadatatyyppejä ja mukautettuja asetuksia kokoonpanolle, joiden täytyy olla välittömästi käytettävissä kaikissa sovelluspalvelimissa. Tilattoman rakenteen avulla sovelluspalvelin voi käsitellä pyyntöjä riippumatta palvelimen tietyistä tiloista.
• Integraation tarpeeton käyttö: Suunnittele integraatiot, jotka kestävät ulkoisen järjestelmän väliaikaisen käytöstä poistumisen. Toteuta katkaisukuvioita, jotka havaitsevat epäonnistuneet integraatiot. Jonot pyynnöt sovellusalustan tapahtumien kautta, kun ulkoiset järjestelmät eivät toimi, eikä estä käyttäjien toimintoja. Tämä eristää ulkoiset järjestelmävirheet käyttäjille tarkoitetuista toiminnoista.

Valvo Salesforce Platform -sovellusalustan tilaa käyttämällä API-rajapintoja trust.salesforce.com ja instanssikohtaiset API-rajapinnat. Tilaa instanssisi tilojen ilmoituksia saadaksesi hälytyksiä vahinkotapahtumista, huoltojaksosta ja suorituskykyyn liittyvistä vaikutuksista. Sovellusalustan terveysmerkinnät sallivat ennakoivan vastauksen reaktiivisen vianmäärityksen sijaan.

Suunnittele ratkaisuja, jotka vastaavat sovellusalustan kuntoa. Kun sovellusalustan suorituskyky heikkenee, vähennä muiden kuin kriittisten erien käsittelykuormaa. Jätä taustatöitä huoltojaksojen aikana käyttämällä ajoitettujen töiden valvontaa. Poista ei-olennaiset integraatiot käytöstä suojellaksesi käyttäjille tärkeitä toimintoja vahinkotapahtumien aikana. Tämä dynaaminen kuormituksen menetys ylläpitää luotettavuutta kriittisille ominaisuuksille stressaantuneina aikoina.

Käytä skaalauskeskusta tunnistaaksesi pitkäaikaiset transaktiot ja operaatiot, jotka kuluttavat suhteettoman paljon sovellusalustan resursseja. Skaalikeskus tarjoaa transaktiotason näkyvyyden, jotta arkkitehtit voivat havaita luotettavuusriskit ennen kuin niistä tulee käyttäjille tarkoitettuja vahinkotapahtumia. Scale Centerin viikoittainen tarkastus paljastaa rakenteellista korjausta vaativia kuvioita.

Ota virheiden havaitseminen käyttöön useilla tasoilla havaitaksesi ongelmat ennen kuin ne muuttuvat täydellisiksi käyttökatkoksiksi. Kerroksinen havaitseminen tarjoaa syvällisen suojan havaitsemattomilta virheiltä.

Suunnittele hälytysten kynnysarvot, jotka tasapainottavat aikaisen havaitsemisen väärien positiivisten kanssa. Hälytys, kun virhesuhteet ylittävät kynnysarvot tai jatkuva heikentyminen tapahtuu, ei yksittäisten virheiden varalta. Yksittäiset virheet ovat normaaleja jaetuissa järjestelmissä. Virhekuvio osoittaa, että luotettavuusongelmat vaativat huomiota.

Salesforce-hallintarajoitukset rajoittavat kunkin vuokralaisen resurssin kulutusta usean vuokralaisen alustalla, jotta yksikään vuokralainen ei voi heikentää muiden suorituskykyä. Nämä eivät ole satunnaisia rajoituksia, vaan ne ovat rakenteellisia rajoja, jotka määrittävät ratkaisun suunnittelun. Tutustu hallintorajoituksiin ennen luotettavan arkkitehtuurin suunnittelemista. Ratkaisut, jotka lähestyvät säännöllisesti hallintarajoituksia normaalin kuormituksen ollessa käytössä, epäonnistuvat todennäköisesti stressin vuoksi.

Arkkitehtuurin päätöksiin vaikuttavat kriittiset hallintarajoitukset:

Suunnittele transaktiot, jotka suoritetaan hyvin rajoitusten sisällä, jopa ruuhka-aikojen aikana. Rakenna marginaali kohdistamalla 70 % hallintorajoituksista toiminta-alan enimmäisrajoitukseksi normaaleissa olosuhteissa, varaamalla 30 % odottamattomille nousijoille. Tämä puskuripalvelu tukee väliaikaisia kuormituksen kasvua, tavallisesti ylittämättä kovia rajoituksia.

Bulkkaaminen on Salesforcen perus skaalattavuuskuvio. Käsittele useita tietueita yhdessä transaktiossa yksittäisten tietuetoimintojen sijaan. Bulkkaaminen vähentää hallintorajoituksen kulutusta ja kasvattaa läpimenoa. Jokaisen Salesforce-arkkitehtuurin täytyy hallita bulkkauskuvioita, koska ne tukevat kaikkia skaalattavia ratkaisuja.

Suunnittele kaikki Apex, eräluokat ja integraatiot käsitelläksesi tietueiden kokoelmia tehokkaasti. Kerää ensin tietueiden tunnisteet ja käsittele sitten kaikki tietueet, joilla on yksi kysely ja DML-lausekkeet. Käytä kartoja ja joukkoja tehokkaisiin hakuihin yksittäisten kyselyiden sisäkkäisten silmukoiden sijaan. Kokoelmaan perustuva käsittely parantaa tehokkuutta järjestyksessä tietuekohtaisten lähestymistapojen sijaan.

Tietueiden käynnistämän automatisoinnin täytyy käsitellä 200 tietuetta per käynnistimen kutsu, koska sovellusalustan prosessit käynnistävät suorituksen enintään 200 tietueen erissä. Lightning Data Service suorittaa erätoiminnot automaattisesti, mutta mukautettujen komponenttien täytyy toteuttaa joukkokuvioita erikseen suorittaessaan DML-toimintoja.

Ei-synkronoitu käsittely jakaa työt ajan myötä sen sijaan, että yritettäisiin suorittaa ne välittömästi yhden transaktion hallintarajoituksissa. Käytä asynkronisia kuvioita, kun operaatiot käsittelevät suuria datamääriä, jotka ylittävät synkronisten hallintarajoitusten rajoitukset, ovat riippuvaisia ulkoisista järjestelmistä, joilla on muuttuvia vastausaikoja, voivat sietää myöhästyneitä suorituskertoja tai vaativat synkronisen CPU:n rajoituksia pidempää suoritusaikaa.

Salesforcen asynkroniset ominaisuudet ja niiden soveltuvuus arkkitehtuuriin:

• Apex-erä: Käsittele suuria tietueiden määriä enintään 2 000 tietueen erissä per suoritusmenetelmä. Erä tarjoaa erilliset hallintarajoitukset per osio ja epäonnistumisen erottamisen — epäonnistunut osio ei estä muita osioita suorittamasta loppuun. Tämä mahdollistaa osittaisen onnistumisen ja kohdennetun uudelleenyrityksen. Ota käyttöön mukautettu uudelleenyrityslogiikka väliaikaisille virheille seuraamalla AsyncApexJob-objektin epäonnistuneita osioalueita ja keräämällä kohdennetut erätöitä uudelleen. Käytä erässä datan siirtoja, ajoitettuja joukkopäivityksiä ja suuria datan käsittelytapoja. Organisaatiossa voi olla enintään viisi käynnissä olevaa tai suoritettavaa erätyötä samanaikaisesti. Muut työt asetetaan jonoon Apex Flex -jonossa (enintään 100 työtä Pidossa-tilassa) ja suoritetaan automaattisesti, kun ajat ovat auki.
• Jonoon lisättävä Apex: Suorita asynkronisia töitä ketjutusominaisuudella ottaaksesi käyttöön monivaiheiset työnkulut ja monimutkaisten objektien parametrit. Queueable Apex jakaa organisaationlaajuisen DailyAsyncApexExecutions-rajoituksen, joka on 250 000 suoritusta 24 tunnissa, kaikille muille asynkronoiduille Apexille — erä-, tuleva- ja ajoitettu Apex — sen sijaan, että sillä olisi oma Queueable-kohtainen rajoitus. Käytä Queuable Apexia monivaiheisille orkestrointi- ja integraatiotyönkuluille, jotka vaativat peräkkäistä käsittelyä ja parempaa valvontaa kuin @future-metodit.
• Sovellusalustan tapahtumat: Sovellusalustan tapahtumia käytetään julkaise/tilaa-tapahtumien arkkitehtuurissa, joka irrottaa julkaisijat tilaajista. Tapahtumat toistuvat 72 tunnin säilytysaikana (3 päivää). Yli 72 tunnin pidennetty säilytys on saatavilla maksullisena lisäosana — tarkasta nykyiset enimmäisrajoitukset ja GA-tila uusimmasta Salesforce Platform -tapahtumien dokumentaatiosta ennen kuin sitoudut palvelutasosopimusten velvoitteisiin, jotka ovat riippuvaisia laajennetusta toistamisesta. Käytä sovellusalustan tapahtumia tapahtumiin perustuvaan automatisointiin, järjestelmien väliseen integraatioon ja reaaliaikaiseen datan suoratoistoon. Sovellusalustan tapahtumat tarjoavat luonnollisia asynkronisia rajoja transaktiovaiheiden välillä.
• Ajoitettu Apex: Suorita töitä kiinteällä aikataululla käyttämällä CRON-lausekkeita System.schedule()-palvelusta. Työ voidaan ajoittaa tapahtumaan enintään kerran tunnissa — CRON sekunteja- ja minuutteja-kenttien täytyy käyttää kiinteitä arvoja, ei asteikkoja. Pysy enintään 100 ajoitetun Apex sisällä per organisaatio yhdistämällä samankaltaisia operaatioita yksittäisiin ajoitettaviin luokkiin.

Kun datamäärät ylittävät käytännön käsittelyn rajoitukset, jopa bulkkaus- ja asynkronointikuvioissa, jaa tiedot loogisten rajojen yli salliaksesi samanaikaisen käsittelyn. Datan osiointi muuntaa suuret peräkkäiset operaatiot pienemmiksi rinnakkaisiksi operaatioiksi, jotka suoritetaan nopeammin ja pysyvät hallintarajoitusten sisällä.

• Päivämääräperusteinen osiointi: Käsittele tietoja ajanjaksoissa, mukaan lukien tämän kuukauden transaktiot tai viime vuosineljänneksen tapaukset. Arkistoi historiallisia tietoja Big-objekteihin tai ulkoiseen tallennustilaan pitääksesi työjoukon hallittavissa. Useimmat transaktiokyselyt keskittyvät viimeaikaiseen dataan, jolloin aikaan perustuva osiointi on luonnollisesti tehokasta.
• Tietuetyypin osiointi: Käsittele eri tietuetyyppejä itsenäisesti, mukaan lukien Kumppanitapaukset vs. Asiakastapaukset tai Yritystilit vs. SMB-tilit. Erilliset erätyöt per tyyppi sallivat rinnakkaisvalinnan. Tietuetyyppi korreloi usein erillisten liiketoimintaprosessien kanssa, mikä oikeuttaa itsenäisen käsittelyn.
• Owner-pohjainen osiointi: Jaa käsittely tietueen omistajan mukaan, esimerkiksi käsittelemällä kunkin myyntialueen mahdollisuudet erikseen. Omistajiin perustuva osiointi on erityisen tehokasta, kun se yhdistetään jakomalliin, koska tietoturvaa noudatetaan olemassa olevien mekanismien avulla. Omistajiin perustuva osiointi sallii käsittelyn kuormituksen maantieteellisen jakauman.

Suunnittele tulevia kapasiteettivaatimuksia liiketoiminnan kasvun perusteella, äläkä reagoida tyhjentämisen rajoittamiseksi. Kapasiteetin ennakoiva suunnittelu estää sovellusalustan resurssien loppumisen aiheuttamat luotettavuustapahtumat.

• Käyttäjälisenssit – henkilöiden määrän kasvu johtaa API-kutsujen allokaatioon ja tallennusoikeuksiin per käyttäjä
• Datan tallennustila - maksutapahtumien määrät ja säilytyskäytännöt, jotka edistävät tallennustilan kulutusta (suunnitellaan nimellisesti vähintään 10–20 %:n vuosikasvua)
• API-kutsut - integraatioiden määrä ja yleisyys, jotka edistävät 24 tunnin API-allokaatiota (jokainen uusi integraatiokuvio lisää toistuvaa kulutusta)
• Käsittelykapasiteetti - Erätöiden määrä ja monimutkaisuus, jotka edistävät asynkronisen käsittelyn jonoja ja samanaikaisten suoritusten rajoituksia

Käytä Proactive Monitoring -ominaisuutta arvioidaksesi organisaation kapasiteetin käyttöä jatkuvasti. Proactive Monitoring havaitsee kapasiteettiriskit, mukaan lukien API-käytön lähestyvät pyyntöjen rajoitukset, tallennustilan rajoitukset lähestyvät ja erätöiden jonojen syvyys ylittää kestävän kehityksen tasot. Viikoittainen kapasiteettitarkastus sallii hankintojen liidiajan lisälisensseille tai rajoituksille ennen liiketoiminnan vaikutusten ilmestymistä.

Vahvista skaalattavuuden oletukset lataustestauksella ennen tuotantoympäristön käyttöönottoa. Lataustestit paljastavat hallintarajoitusten ongelmia, integraation pullonkauloja ja kapasiteettirajoituksia, joita ei näytetä alhaisen volyymin kehitystestauksessa. Testaa tuotanto-asteikon datamääriä ja samanaikaisuutta vahvistaaksesi luotettavuuden realistisissa olosuhteissa.

• Datan määrän testaaminen: Täytä tuotanto-asteikon datamääriä Full Copy -sandboxissa vahvistaaksesi kyselyiden suorituskyvyn todellisella datavirheellä, suhteiden syvyydellä ja tietueiden määrillä. Testaa yli 10 miljoonaa tietuetta, kun tuotanto saavuttaa kyseisen skaalan. Kyselyiden optimoinnin toimintatapa muuttuu dramaattisesti, kun datamäärä kasvaa, mikä voi johtaa pienimuotoisiin Skaalaustesteihin.
• Käyttäjien samanaikaiset testit: Simuloi samanaikaisen käyttäjän enimmäiskuormitus vahvistaaksesi transaktioiden läpimäärän ja ristiriidan. Käytä hyväksyttyjen organisaatioiden käytettävissä olevia skaalatestejä simuloidaksesi tuotantotyökuormia sandbox-ympäristöissä ennen käyttöönottoa. Samanaikainen suoritus paljastaa lukitusongelmat, joita ei näytetä yhden käyttäjän testauksessa.
• API-lataustestaus: Luo huipputason API-määrät vahvistaaksesi integraation skaalattavuuden, nopeusrajoitusten käsittelyn ja katkaisijan toimintatavan kestävän latauksen aikana. API-lataustestit paljastavat, toimivatko uudelleenkokeilulogiikka ja virheiden käsittely oikein stressiolosuhteissa.
• Skaalaustesti: Skaalaustesti on Salesforce-tuote, jota käytetään tuotantotyökuormitusten simuloimiseen Full Copy -sandbox-ympäristöissä, jotka on skaalattu vastaamaan tuotantokapasiteettia. Skaalaustesti suoritetaan Hyperforcen Full Copy -sandboxeille. Tuotantoinstanssisi ei tarvitse olla Hyperforcessa käyttääkseen sitä. Luot testisuunnitelmia tuotanto-organisaatiossasi, kun testit suoritetaan sandboxille. Käytä Skaalaustesti vahvistaaksesi hallintarajoitusten rajoitukset, asynkronisen käsittelyn läpimeno ja integraation vastauksen toimintatavan huippukuormituksen olosuhteissa ennen suuria käyttöönottoja.

Selkeä heikentäminen ylläpitää ydintoimintoja, kun muut kuin kriittiset komponentit epäonnistuvat. Suunnittele järjestelmät, jotka priorisoivat kriittiset käyttäjäkulut virheiden aikana tuettujen ominaisuuksien sijaan. Kaikilla ominaisuuksilla ei ole yhtä tärkeää liiketoimintaa, ja arkkitehtuurien tulisi vastata näitä prioriteetteja.

Määritä ominaisuuksien kriittinen hierarkia:

Tämä hierarkia sallii arkkitehtien suunnitella heikentämiskäytäntöjä, jotka ylläpitävät liiketoiminnan jatkuvuutta myös osittaisten järjestelmävirheiden aikana. Käyttäjät haluavat vähemmän toimintoja kuin täydellistä käytöstä poistamista.

Katkaisukuvio estää vaiheittaiset virheet, kun integraatiot eivät ole käytettävissä. Sen sijaan, että kerääntyisit aikakatkaisuja, jotka kuluttavat transaktioiden aikaa ja hallintarajoituksia, havaitse virhekuvioita ja lopeta epäonnistuvien järjestelmien kutsuminen. Viestiketjut aiheuttavat nopean epäonnistumisen hitaan epäonnistumisen sijaan.

Viestiketjussa lukee:

• Suljettu - normaali toiminta, pyyntöjen kulku ulkoiseen järjestelmään suunnitellusti
• Avoin - virheiden kynnysarvo ylittynyt, pyynnöt epäonnistuvat välittömästi yrittämättä ulkoisia puheluita, säästää resursseja
• Half-open - palautustestijakso, rajoitetut pyynnöt ulkoisten järjestelmien testaamiseksi palautuksen havaitsemiseksi ennen kuin piiri suljetaan kokonaan

Toteuta katkaisijoita käyttämällä sovellusalustan välimuistia tallentaaksesi kaikkien transaktioiden käytettävissä olevia piirastojen tiloja. Käytä sovellusalustan tapahtumia kuuluttaaksesi tilojen muutoksia koko organisaatiossa. Kulunvaihtologiikka tarkastaa tilan ennen ulkoisten puheluiden yritystä välttyäksesi kuluttamattomilta callout-rajoituksilta tunnetusti epäonnistuneille järjestelmille.

Väliaikaiset virheet ovat normaaleja jaetuissa järjestelmissä. Verkon keskeytykset, väliaikainen vapaat palvelut ja nopeusrajoitusvastaukset ratkaistaan usein sekunneissa. Käytä uudelleenyrityslogiikkaa, joka toistaa epäonnistuneet toiminnot progressiivisten viiveiden jälkeen epäonnistumisen sijaan välittömästi.

Eksponenttinen rästityö estää uudelleenyritysten myrskyt, jotka täyttävät palautettavat järjestelmät. Ensimmäinen uudelleenyritys voi tapahtua 1 sekunnin jälkeen, toinen 2 sekunnin jälkeen, kolmas 4 sekunnin jälkeen ja neljäs 8 sekunnin jälkeen. Enimmäisviive 30–60 sekuntia, riippumatta eksponenttisesta kasvusta. Tämä rästityylinen kuvio tarjoaa epäonnistuneille järjestelmille aikaa toipua, mutta rajoittaa niiden kokonaiskestoa.

Täsmää uudelleenyritysstrategia virheen tyyppiin.

• Verkon aikakatkaisut: Yritä uudelleen lyhyellä aikavälillä (operaatio ei välttämättä saavuttanut palvelinta)
• Rajoitusvirheet (429): Yritä uudelleen Kokeile uudelleen -otsakkeen arvon tai nopeusrajoituksen nollausajan jälkeen
• Palvelin virheet (5xx): Yritä uudelleen eksponenttisella rästityksellä, koska palvelin saattaa olla väliaikaisesti ylikuormitettu
• Asiakassovelluksen virheet (4xx paitsi 429): Älä yritä uudelleen, korjaa pyyntö virheellisesti syötettynä.
• Governor limit -virheet: Älä yritä uudelleen samassa transaktiossa, jonota se uudelleen asynkronointitoimintona, jolla on omat rajoitukset, esimerkiksi julkaisemalla epäonnistumistapahtuman, jonka ei-synkronoitu tilaaja käsittelee uudelleen palautuksilla uusien transaktioiden rajoituksissa

Varastostrategiat määrittävät vaihtoehtoisia lähestymistapoja, kun ensisijaiset metodit epäonnistuvat, mikä mahdollistaa jatkuvan toiminnan heikentyneissä olosuhteissa.

• Vaihtoehtoinen tietolähde: Nouda dataa sovellusalustan välimuistiistunnosta tai organisaation osiosta, kun reaaliaikainen API ei ole käytettävissä. Täytä välimuisti valmiiksi onnistuneiden toimintojen aikana. Välimuisti tarjoaa vanhentuneita, mutta käytettävissä olevia tietoja, mikä on parempi kuin täydellinen virhe monissa käyttötarkoituksissa.
• Oletusarvoinen toimintatapa: Käytä liiketoimintasääntöjä, kun personalisointi- tai rikastuspalvelu ei ole käytettävissä. Käsittele oletusarvoilla ja merkitse rikastettavaksi, kun palvelu palautuu. Oletusarvoinen toimintatapa ylläpitää läpimenoa pienemmän tarkkuuden kustannuksella.
• Manuaalinen prosessi: Ota manuaalinen suoritus käyttöön, kun automatisointi epäonnistuu. Tarjoa pääkäyttäjän käyttöliittymä piilotettujen transaktioiden suorittamiseen. Manuaalinen varastointi estää datan katoamisen ja ylläpitää liiketoiminnan jatkuvuutta, kun automatisointi heikkenee.
• Jono uudelleenyritykselle: Tallenna sovellusalustan tapahtumissa tai mukautetuissa jonojen objekteissa olevat toiminnot käsiteltäväksi, kun ulkoinen järjestelmä palautuu. Sovellusalustan tapahtumien toisto 72-tuntisen vakiomuotoisen säilytyksen avulla tilaaja voi toipua väliaikaisten virheiden jälkeen tietojen katoamatta.

Määritä asiaankuuluvat aikakatkaisut kaikille integraatiokutsuille. Salesforce vaatii enintään 120 sekuntia callout-kutsun kokonaisaikaa per transaktio. Budjetoi tällä kertaa kaikki callout-kutsut yhdellä transaktiolla välttyäksesi keskeytettyjen yhteyksien transaktioiden ajalta.

Aikakatkaisussa huomioitavia asioita:

• Käyttäjille lähetetyt synkronoidut callout-kutsut: Käytä enintään 5-10 sekuntia ylläpitääksesi interaktiivista käyttöliittymää, koska käyttäjät eivät yleensä odota kauemmin
• Taustasynkronoimattomat callout-kutsut: Käytä 30–60 sekuntia mukauttaaksesi muuttujien ulkoista suorituskykyä ilman, että käyttäjä odottaa
• Erin käsittelyn callout-kutsut: Käytä täyttä 120 sekuntia, kun käyttäjä ei odota vastausta****
• Useita callout-kutsuja per transaktio: Budjetoi kaikkien callout-kutsujen kokonaisaika, esimerkiksi kolme callout-kutsua 10 sekunnissa, jotka kuluttavat 120 sekunnin budjetista 30 sekuntia.

Lyhyet aikakatkaisut epäonnistuvat nopeammin, jolloin varastrategiat voivat osallistua nopeammin. Pidemmät aikakatkaisut parantavat hidasta mutta toimivaa ulkoista järjestelmää. Tasapainotuksessa huomioitavat asiat perustuvat siihen, odottaako käyttäjä vastausta ja onko käytettävissä varastrategioita.

Suunnittele kattava virheiden käsittely muuntaaksesi epäonnistumiset kaatumisista hallituksi heikentymiseksi:

• Virhe nopeasti: Vahvista input-arvot ja edellytykset syöttöpisteissä. Tarkasta hallintorajoituksen kulutus ennen kalliita toimintoja. Havaitse virheet välittömästi virheellisen tilan laajentamisen sijaan useiden käsittelysarakkeiden kautta. Aikainen havaitseminen vähentää räjähdyksen sädettä ja yksinkertaistaa virheenkorjausta.
• Virheellinen: Ylläpidä käyttäjien kykyjä, vaikka toiminnot epäonnistuisivat osittain. Jos 3 tietueesta 200 erän vahvistus epäonnistuu, käsittele onnistuneet 197 tietuetta ja raportoi 3 epäonnistumista koko erän epäonnistumisen sijaan. Osittainen onnistuminen on parempi kuin erätoimintojen kokonaisvirhe.
• Epäonnistui informatiivisesti: Kirjaa virheet lokiin transaktion tunnuksella, käyttäjän kontekstilla, input-parametreillä ja pinoseurannalla. Riittämätön virheiden konteksti on tärkein ongelman nopean ratkaisemisen este. Jokaisen virhelokin tulisi sallia vastaajan ymmärtää, mikä epäonnistui, miksi ja miten toistaa.
• Virhe turvallisesti: Varmista, että virheet eivät vaaranna datan eheyttä tai tietoturvaa. Palauta osittaiset transaktiot sen sijaan, että jättäisit tiedot epäjohdonmukaiseen tilaan. Älä koskaan paljasta sisäisten virheiden lisätietoja loppukäyttäjille, koska pinojäljet paljastavat toteutustietoja, jotka ovat hyödyllisiä hyökkääjille.

Palautuksen aika -tavoite määrittää hyväksyttävän käyttökatkoksen enimmäismäärän katastrofin jälkeen. RTO määrittää arkkitehtuuripäätökset, jotka koskevat vahinkotapahtumien automatisointia, varmuuskopiotiheyttä ja palautustestien investointeja. Eri liiketoimintaominaisuudet oikeuttavat eri RTO-investointeja. Koska RTO on käyttökatkos, jonka käyttäjäsi kohtaavat suoraan, tavoitteen puuttuminen johtaa pitkäaikaisiin käyttökatkoksiin ja asiakkaiden Trustin heikentymiseen.

RTO vaihtelee liiketoimintakyvyn mukaan:

Määritä RTO per kapasiteetti ennen kuin suunnittelet katastrofien palautusrakennetta. RTO määrittää teknologian valinnan, automatisointiin tehtävät investoinnit ja testauskäytännöt. Aggressiivisemmät RTO-kohteet vaativat enemmän automatisointiin ja tarpeettomuuteen tehtyjä investointeja.

Palautuspisteen tavoite määrittää hyväksyttävän datan häviöikkunan, jota mitataan ajan myötä. RPO määrittää varmuuskopioinnin yleisyyden, replikointistrategian ja synkronointikuvion. Tiukempi RPO vaatii useammin datan replikointia, mikä parantaa monimutkaisuutta ja kustannuksia. Koska RPO on datan menetys, jonka yrityksesi käsittelee, tavoitteen puuttuminen voi tarkoittaa kadotettuja transaktioita ja tietueiden korjaamattomia aukkoja.

Tasapainottaa RPO-vaatimuksia kustannusten ja monimutkaisuuden kanssa. Lähes nollan RPO vaatii jatkuvaa datan replikointia ja merkittäviä infrastruktuuriinvestointeja. Päivittäinen varmuuskopio tarjoaa 24 tunnin RPO-kertauloskirjautumisen vähällä monimutkaisuudella. Useimmat organisaatiot voivat sietää jonkin verran tietojen häviämistä muussa kuin taloustiedoissa.

Sovellusalustan infrastruktuurin tarpeeton käyttö suojaa infrastruktuurin virheiltä, mutta se kopioi käyttäjien virheiden, virheellisten käyttöönottojen ja integrointivirheiden tulokset, jotka aiheuttavat eniten datan katoamista. Varmuuskopioita käytetään näiden sovellustason virheiden palauttamiseksi, eikä sovellusalustan luotettavuuden korvaamiseksi. Toteuta varmuuskopiointistrategioita, jotka kattavat datan, metadatan ja tiedostot, koska ne vaativat eri varmuuskopiointimenetelmiä:

• Datan varmuuskopioinnit: Toteuta kattava varmuuskopiointistrategia, joka käsittelee sekä dataa että metadataa. Vie kriittisiä objekteja käyttämällä natiivia datan vientipalvelua — joka 7 päivää Enterprise Edition-, Performance Edition- ja Unlimited Edition -versioissa; joka 29 päivää Professional Edition -versioissa ja sitä uudemmissa versioissa. Vientitiedostot ovat käytettävissä 48 tuntia sähköposti-ilmoituksen lähettämisen jälkeen, pois lukien viikonloput, ennen kuin ne poistetaan automaattisesti. Määritä automatisoitu latausprosessi, jotta tiedostoja ei menetetä pysyvästi. Käytä Metadata API:a ja Salesforce CLI:a (sf-projektin haku) versioiden hallintaan organisaation kokoonpanoon, mukautettuun koodiin ja deklaratiiviseen automaatioon lähdekoodin hallintajärjestelmässä, kuten Git. Käsittele metadatan varmuuskopiointia osana CI/CD-vakioputkea. Täydennä datan varmuuskopiointia erillisillä varmuuskopiointi- ja palautuspalveluilla, kuten omistettu, joka palauttaa tietueen ajankohtaiselta, tarkka tietuetason palautus ja säilytys, joka ylittää natiiviviennin. Natiivi tietojen vienti ei tue ajankohtaista palautusta, ja kolmansien osapuolten työkalut ovat tarpeen, jos RTO/RPO vaatii tarkkoja palautusikkunoita. Testaa palautustoimenpiteitä säännöllisesti. Varmuuskopio, jota ei ole koskaan palautettu, on todentamaton oletus.
• Metadatan varmuuskopiot: Versio hallitsee kaikkia metadataa käyttämällä Salesforce DX -lähdemuotoa Git-säiliöissä. Metadatan version hallinta sallii kokoonpanon palauttamisen nopeasti vioittumisen tai tahattoman muutoksen jälkeen. Jokaisen käyttöönoton tulisi olla toistettavissa lähdekoodin hallinnasta. Git-metadata tarjoaa ajankohtaisen palautuksen kokoonpanolle.
• Tiedostojen varmuuskopiot: Vie ContentVersion-tietueita, liitteitä ja asiakirjoja ulkoiseen tallennustilaan. Salesforce toimii parhaiten aktiiviselle datalle, ei tiedostojen pitkäaikaiselle arkistoinnille - vie tiedostoja ulkoiseen tallennustilaan lakisääteistä säilyttämistä varten. Ota käyttöön automatisoitu tiedostojen vienti lakisääteisille säilytysehtoille, jotka ylittävät sovellusalustan ominaisuudet.
• Vahvistus: Palauta varmuuskopioita säännöllisesti luonnosorganisaatioihin tai kehittäjien sandboxeihin vahvistaaksesi toimenpiteiden ja varmuuskopioiden eheyden. Todentamattomat varmuuskopiot epäonnistuvat usein tarvittaessa, koska niiden vaikutusalue ei ole täydellinen tai ne ovat korruptoituneita arkistoja. Ajoita neljännesvuosittainen palautuksen vahvistus havaitaksesi ongelmia ennen katastrofeja. Valvo varmuuskopioiden tuoreutta palautuksen vahvistuksen lisäksi. Hälytys, kun viimeisin onnistunut varmuuskopio on odotettua vanhempi - esimerkiksi kun viikoittainen vienti ei ole suoritettu yli 8 päivään. Tämän vahvistuksen avulla hiljaa epäonnistunut varmuuskopiointityö ilmestyy välittömästi seuraavan tarkennuksen sijaan.

Suunnittele RPO- ja usean organisaation vaatimukset vastaava replikointi:

• Muutostietojen taltiointi (CDC): Tilaa seurattujen objektien tapahtumien muutokset. CDC tarjoaa luonti-, päivitys-, poisto- ja peruutustapahtumia, joiden kenttäarvoja on muutettu. Tarjoaa lähes reaaliaikaisen replikoinnin käyttämällä vähäistä kehitysvaikutusta tuetuille objekteille, mukaan lukien vakiomuotoisille ja mukautetuille objekteille. Riippuen päivittäisestä toimitusrajoituksesta Edition-version perusteella.
• Sovellusalustan tapahtumat: Mukautettu tapahtuma-arkkitehtuuri liiketoimintatapahtumien ja tilojen muutosten replikoimiseen. Joustavampi kuin CDC, joka tukee mukautettuja tietosisältöjä ja monimutkaisia tapahtumarakenteita, mutta vaatii selkeää julkaisulogiikkaa käynnistimissä tai prosesseissa. 72 tunnin toistohyökkäyksen standardi sallii tilaajan väliaikaisten virheiden palauttamisen.
• Ajoitettu API- replikointi: Schedule API - replikointi on eränouto Bulk API 2.0:n kautta kiinteällä aikataululla. Se on yksinkertaisin toteutus, jossa RPO on yhtä kuin noutoaste. Ajoitettu API- replikointi soveltuu ei-kriittisille tiedoille, joissa lähes reaaliaikaista suoritusta ei tarvita, esimerkiksi viitetiedoilla tai historiallisilla analyyseillä.
• MuleSoftin orkestroima replikointi: MuleSoft Anypoint Platform tarjoaa monimutkaisille usean järjestelmän replikointien topologioille orkestroinnin, transformaation ja valvonnan. Sen käyttö soveltuu Salesforcen ja useiden ulkoisten järjestelmien replikointiin, mikä vaatii hienostunutta reititys- ja transformaatiologiikkaa.

Testaa katastrofien palautusta ajoitetuilla tarkennuksilla, jotka vahvistavat ihmiset, prosessit ja teknologiat yhdessä:

• Taulukkokorjaukset: Tiimi tutkii katastrofitapaamisia ja keskustelee rooleista ja päätöspisteistä ilman todellisia epäonnistumiskertoja. Tämä toiminto on edullinen ja se paljastaa toimenpiteisiin liittyviä aukkoja ja viestintähäiriöitä. Suorita työpöytäharjoituksia säännöllisesti pitääksesi tiimisi valmiina henkilöstön muutoksen yhteydessä.
• Osittainen vahinkotapahtuma: - Testaa tiettyjä palautustoimenpiteitä, kuten metadatan palauttaminen lähdekoodin hallinnasta, datan palauttaminen varmuuskopiopalvelusta tai sandboxien päivitys. Tämä vahvistaa tekniset toimenpiteet, joilla on rajoitettu liiketoiminnan vaikutus. Suorita säännöllisesti ja kierrä testatut toimenpiteet kattaaksesi kaikki palautusmahdollisuudet vuosittain.
• Full failover drill: Täysi virheenkorjaus on täydellinen virheenkorjaus katastrofien palautusympäristöön tuotantoympäristössä. Se tarjoaa parhaan mahdollisen luottamuksen, mutta vaatii liiketoiminnan koordinointia ja käyttäjäviestintää. Suorita tämä tarkennus vuosittain kriittisille järjestelmille. Täysi virheenkorjauksen tarkennus vahvistaa koko palautuskyvyn, mukaan lukien katkaisutoimenpiteet ja käyttäjän viestintä.

Dokumentoi oppitunteja jokaisen tarkentamisen jälkeen. Päivitä suorituskirjat löydösten perusteella. Palautusominaisuudet saattavat heikentyä, kun tiimit muuttuvat ja ratkaisut kehittyvät. Käsittele DR-dokumentaatiota elävinä esineinä, jotka vaativat säännöllistä huoltoa kertaluonteisten toimitusten sijaan.

Liiketoiminnan jatkuvuus ulottuu teknisen palautuksen lisäksi ihmisiin, prosesseihin ja toimittajien sidonnaisuuksiin:

• Tiimin saatavuus: Asiakirjojen eskalointitoimenpiteet ja kriittisten roolien varmuuskopiohenkilöstö. Varmista, ettei toiminnallisessa Knowledgessa ole yhtään virhettä. Ensisijaiset vastaajat eivät välttämättä ole käytettävissä katastrofien aikana, mikä tekee varmuuskopioiden henkilöstöstä kriittistä.
• Ilmoitustoimenpiteet: Määritä, miten vahinkotapahtumat ilmoitetaan käyttäjille, asiakkaille ja esimiehille. Luo viestintäkanavia, jotka toimivat, kun ensisijaiset työkalut (esimerkiksi ulkoiset tilasivut tai SMS-ilmoitusjärjestelmät), mukaan lukien Salesforce, eivät ole käytettävissä.
• Toimittajan sidonnaisuudet: Kartoita ulkoisten toimittajien riippuvuudet, jotka ovat tärkeitä ratkaisun toiminnalle. Asiakirjojen eskalointipolut ja sopimusten palvelutasosopimukset jokaiselle kriittiselle toimittajalle, mukaan lukien Salesforcelle, integraatiokumppaneille ja ISV-paketin tarjoajille. Ymmärrä esimerkiksi, ketkä toimittajista tarjoavat 24/7-tukea ja ketkä tarjoavat vain toimistoaikoja, jotka vaikuttavat palautuksen ajoittamiseen.
• Sääntelyvelvoitteet: Tunnista ilmoitusvaatimukset, jotka johtuvat pitkäaikaisista käyttökatkoksista. Finanssipalveluiden, terveydenhuollon ja valtion sopimukset vaativat vahinkotapahtumien ilmoittamisen usein tiettyinä ajanjaksoina. Vaatimusten noudattamatta jättäminen voi aiheuttaa sääntely- ja lakiriskiä, jotka molemmat vaikuttavat katastrofien yhdistelmään.

Määritä terveysmalli, joka kerää useita signaaleja yhteen järjestelmän yleiseen terveydentilaan. Terveysmallit näyttävät toiminta-tilat yhdellä vilkaisulla ilman yksityiskohtaisten tilastojen analyysiä. Esimerkiksi:

Suunnittele terveysmittaristoja, jotka näyttävät toiminta-tilan välittömästi. Terveystila opastaa toiminnallista vastausta, mukaan lukien normaalit toiminnot vihreässä tilassa, tehostettu valvonta keltaisessa tilassa ja aktiivinen vahinkotapahtumien vastaus punaisessa tilassa.

Sovellusalustan tilan signaalit (jotka on kuvattu aiemmin kohdassa Sovellusalustan terveysvalvonta) paljastavat, milloin Salesforce-infrastruktuuri heikkenee, mutta eivät miten oma ratkaisusi suoriutuu.

Augmentoi nämä signaalit ratkaisukohtaisella havaittavuudella:

• Tapahtumien valvonta: Event Monitoring sisältää yksityiskohtaisia lokeja, jotka sieppaavat API-kutsut, sivujen tarkastelukerrat, raporttien viennit, sisäänkirjautumistoiminnot ja Apex. EventLogFile-objektit tarjoavat lokeja 24 tunnin (päivittäin) tai 1 tunnin aikavälillä – tuntikohtainen toimitus vaatii Event Monitoring -lisäosan tai Salesforce Shieldin. Säilytystä voi määrittää enintään 365 päivään Määritykset-valikon kautta, mutta laajennettu säilytys vaatii Salesforce Shieldin tai Event Monitoring -lisäosan. Ilman lisäosaa lokitiedostoja säilytetään 1 päivä. Reititä tapahtumia ulkoiseen Suojaustiedot ja tapahtumien hallinta -järjestelmään (SIEM) tai lokien aggregointialustaan korrelointia, hälytyksiä ja säilyttämistä varten natiivirajoituksen ulkopuolella. Käytä Event Monitoring -ominaisuutta havaitaksesi poikkeavia API-kulutuskuvioita, tunnistaaksesi Apex ja tarkastaaksesi datan käyttöoikeudet säännellyissä ympäristöissä.
• Skalauskeskus: Skaalikeskus tarjoaa transaktiotason näkyvyyden pitkäaikaisiin toimintoihin, rivien lukkojen ristiriitoihin ja resurssiintensiteettisiin transaktioihin. Skaalikeskus sallii arkkitehtien tunnistaa luotettavuusriskit tietyistä transaktiokuvioista ennen kuin ne aiheuttavat vahinkotapahtumia käyttäjille. Viikoittaiset tarkastukset voivat paljastaa optimointimahdollisuuksia.
• Ennakoiva valvonta: Proactive Monitoring sallii organisaation kunnon jatkuvan arvioinnin, suorituskyvyn ja skaalattavuusriskien havaitsemisen. Proactive Monitoring tarjoaa hälytyksiä API-pyyntöjen rajoituksista, samanaikaisista Apex, SOQL-rivien rajoituksista ja tallennustilan kulutuksen trendeistä. Se on saatavilla asiakkaille, joilla on oikeutus Allekirjoitus onnistui (aiemmalta Allekirjoitukset tuki) — se ei sisälly itsepalvelutoimintoon vakiomuotoisissa Edition-versioissa.

Seuraa sovellusten suorituskykyä käyttäjän näkökulmasta, äläkä infrastruktuurin näkökulmasta:

• Real User Monitoring (RUM): Mittaa todellista käyttökokemusta Experience Cloud -analyysien tai mukautettujen instrumentaatioiden avulla. RUM kaappaa todellisen viiveen, joka vastaa todellisia verkkoehtoja, laitteen suorituskykyä ja maantieteellistä jakaumaa. Synteettinen valvonta ei voi replikoida tätä varianssia.
• Syntemaattinen valvonta: Suorita automatisoituja transaktioita säännöllisesti useista sijainneista vahvistaaksesi saatavuuden ja suorituskyvyn. Synteettinen valvonta havaitsee ongelmat ennen kuin käyttäjät raportoivat niistä. Toteuta synteettistä valvontaa ajoitetulla Apexilla, suorita kriittisiä toimintoja ja raportoi tuloksia sovellusalustan tapahtumien avulla.
• Transaktioiden seuranta: Monimutkaiset monivaiheiset operaatiot, joilla kerätään aikataulua per vaihe. Tarkasta seuraavaksi, mikä viiden vaiheen työnkulun vaihe tuo viiveen käyttöön. Älä käsittele koko kulkua mustana kenttänä. Vaihetason ajoitus paljastaa optimointimahdollisuudet, joita ei näytetä aggregaattitilastoissa.

Valvo kaikkia ulkoisia integraatioita käyttämällä virhesuhteita, viive-prosentteja ja läpimenoa. Integraatioiden virheet ovat tärkein luotettavuustapahtumien syy:

• Virhesuhde - Virheitä palauttavien puheluiden prosenttiosuus (tavoite: <1 % terveelle integraatiolle)
• Latency - Vastausaika, joka mitataan p50, p95, p99 (määritä SLO per integraatio aikakatkaisun budjetin perusteella)
• Timeout-suhde - Prosenttiosuus, jolla määritetty aikakatkaisu (tavoite: <0,1 %) ylitetään
• Sulkuikkunan tila - Avoin tila osoittaa jatkuvaa virhettä, joka vaatii välittömästi huomiota
• Jonon syvyys - Asynkronisten integraatioiden kasvava jono osoittaa, että käsittely on tuotantokurssin jälkeen

Kirjaa kaikki integraatiopuhelut lokiin pyynnön tunnuksella, päätepisteellä, vastauskoodilla ja kestolla. Tämä data sallii nopean juurisyyn analysoinnin, kun integraatioiden virheet vaikuttavat luotettavuuteen. Integrointilokien tulisi ottaa aggregointi- ja trendienanalyysi käyttöön.

Suunnittele hälytyksiä ongelmiin ennen kuin ne vaikuttavat käyttäjiin, ja ota käyttöön ennakoivat vastaukset:

• Toiminnalliset hälytykset: Jokaisella hälytyksellä on määritetty vastaustoiminto ja kohdistettu vastaaja. Hälytykset, joilla ei ole selkeää vastausta, aiheuttavat väsymystä ja piilottavat kriittisiä signaaleja. Hälytysten suunnittelun tulisi kattaa, kuka vastaa, mitä he tarkastavat ja miten he korjaavat ongelmansa.
• Oikea kiireellisyys: Sivulta ilmoittava henkilöstö käyttäjiin vaikuttavista virheistä. Lähetä sähköpostia heikentyneelle suorituskyvylle. Lisää päivittäiseen tiivistelmään ongelmia, jotka koskevat trendejä. Täsmäämättömät kiireellisyydet aiheuttavat joko hälytyksen väsymyksen ylikäyttämisestä tai puuttuvat vahinkotapahtumat alikäyttämisestä.
• Kontekstiin perustuvat ilmoitukset: Lisää ylittynyt kynnysarvo, tämänhetkinen arvo, viimeaikainen trendi ja linkki asiaankuuluvaan mittaristoon tai suorituskirjaan. Salli vastaajien aloittaa diagnoosi välittömästi keräämättä asiayhteyttä. Jokaisen hälytyksen tulisi sisältää tarpeeksi tietoja lajitteluun ilman lisäkyselyitä.
• Storm suppression: Kun useat järjestelmät epäonnistuvat samanaikaisesti, estä tarpeettomat hälytykset. Yksi hälytys, joka ilmoittaa integraation sovellusalustan virheestä, toimii paremmin kuin 50 yksittäistä integraation virhehälytystä, jotka piilottavat juurisyyn.

Poikkeavuuksien havaitseminen tunnistaa epätavalliset kuviot ja voi osoittaa, että staattiset kynnysarvon hälytykset eivät näe uusia ongelmia:

• Määrän poikkeamat: Transaktioiden määrät, jotka ovat merkittävästi odotettujen päivittäisten kuvioiden ylä- tai alapuolella, saattavat tarkoittaa, että prosessit eivät toimi tai että käyttäjien käyttöoikeuksissa on ongelmia.
• Virhesuhteen poikkeamat: Virhesuhteet, jotka ovat korkealla verrattuna samaan aikaan edellisen viikon perustasoihin, heikkenevät asteittain ennen kynnysarvon rikkomusta.
• Viiveen poikkeamat: Useiden päivien aikana nousevat vastausajat osoittavat, että kapasiteetti on kyllästetty tai suorituskyky on regressiossa.
• Käyttäytymisen poikkeamat: Epätavalliset sisäänkirjautumiskuviot, odottamattomat API-käytön pikavalinnat ja ajoitettujen ajanjaksojen ulkopuolella suoritetut erätyöt voivat osoittaa epäilyttävää käyttöä.

Proactive Monitoring tarjoaa sovellusalustan tason poikkeusten havaitsemisen ilman lisämäärityksiä asiakkaille, joilla on Allekirjoituksen onnistuminen -oikeus. Täydennä sitä sovelluskohtaisella poikkeusten havainnolla ulkoisiin Analytics-alustoihin viedyille mukautetuille SLI-osoitteille. Käytä poikkeuksien signaaleja ohjataksesi tutkimusta sen sijaan, että käynnistäisit välittömän eskaloinnin, koska poikkeusten havaitseminen sisältää korkeampia väärien positiivisten hälytysten määrää kuin kynnysarvon hälytykset.

Käytä tätä tarkistuslistaa arkkitehtuurin tarkastuksissa, ennen tuotantoympäristön käyttöönottoa ja säännöllisesti jatkuvaa luotettavuuden arviointia varten.

Luotettavuustavoitteet ja SLO-uloskirjautumiset

• Määritä SLO-kertakirjautumiset kaikille kriittisille käyttäjille ennen suunnittelun aloittamista
• Laadi käyttäjäkokemukseen liittyviä mitattavissa olevia SLI-kertakirjautumisia, äläkä vain infrastruktuurin tilastoja
• Aseta realistisia saatavuustavoitteita liiketoiminnan vaikutusanalyysin perusteella, äläkä satunnaisia tavoitteita
• Varmista, että ratkaisujen SLO-uloskirjautumiset ovat vähemmän tiukkoja kuin sovellusalustan palvelutasosopimukset tarjotaksesi virheiden budjetin
• Asiakirjojen saatavuustavoitteet ja perustelu arkkitehtuurin päätöstyötietueissa

Korkea saatavuus -arkkitehtuuri

• Datan, sovelluksen ja integraatiokerrosten suunnittelun tarpeettomuus
• Seuraa sovellusalustan kuntoa Trust.salesforce.com:in ja instanssien tilojen API:n kautta
• Toteuta sovellusten terveystarkastuksia sovellusalustan tilasta riippumatta
• Harkitse usean organisaation arkkitehtuuria vain, kun liiketoimintavaatimukset selkeästi oikeuttavat monimutkaisuuden
• Suunnittele automatisoitu virheenkorjaus testatuilla suorituskirjoilla usean organisaation kuvioille

** Skaalattavuus ja kapasiteetin suunnittelu**

• Suunnittele transaktiot, jotka suoritetaan 70 %:n sisällä hallintarajoituksista normaalin latauksen aikana
• Toteuta bulkkauskuvioita kaikissa Apex, eräluokissa ja integraatioissa
• Käytä asynkronista käsittelyä synkronointirajoituksia ylittäville operaatioille
• Kerää kaikki API-integraatiot erissä sen sijaan, että tekisit yksittäisiä tietuekutsuja
• Suorita lataustestejä tuotanto-asteikon datamääriin ennen käyttöönottoa
• Valvo kapasiteetin käyttöä OrgLimits API:n tai mukautetun Apexin kautta ja ilmoita hälytyksestä, kun kulutus lähestyy 70 %:n toiminta-aukkoa
• Projektin kapasiteettivaatimukset, jotka perustuvat 12 kuukauden kasvun odotuksiin
• Jaa raskaan datan osiin päivämäärän, tietuetyypin tai omistajan perusteella salliaksesi samanaikaisen käsittelyn, kun määrät ylittävät peräkkäiset rajoitukset

Virheiden toleranssi ja kestokyky

• Suunnittele graceful degradation määritetyillä ominaisuuksien kriittisyyden tasoilla
• Käytä katkaisimia kaikille ulkoisten järjestelmien integraatioille
• Käytä uudelleenyrityslogiikkaa eksponenttisella rästityksellä väliaikaisille virheille
• Määritä toiminnon tyypille sopivat aikakatkaisut (5–10 sekuntia käyttäjälle, 30–60 sekuntia asynkronointi)
• Suunnittele varastrategioita käyttämällä sovellusalustan välimuistia ja jonoihin perustuvia kuvioita
• Toteuta rakenteellinen virheiden käsittely riittävällä diagnostisella asiayhteydellä

Vahinkotapahtumien palautus ja liiketoiminnan jatkuvuus

• Määritä RTO ja RPO per liiketoimintaominaisuus ennen suunnittelua
• Ota käyttöön automatisoitu varmuuskopiointi tiedoille, metadatalle (lähdekoodin hallinnalle) ja tiedostoille
• Vahvista varmuuskopioiden palautusmenetelmät neljännesvuosittain muissa kuin tuotantoympäristöissä
• Valvo varmuuskopioiden tuoreutta ja hälytyksiä, kun ajoitettu varmuuskopio on erääntynyt
• Suunnittele datan replikointistrategia, joka vastaa RPO-vaatimuksia
• Suorita katastrofien palautustesti vuosittain (taulukkoluvun neljännesvuosittain)
• Asiakirjojen liiketoiminnan jatkuvuustoimenpiteet, mukaan lukien toimittajien eskalointipolut

Seuranta ja havaittavuus

• Terveysmallin määrittäminen palvelun, integraation, datan ja kapasiteettien signaalien yhdistämiseksi
• Sovellusalustan tilojen ilmoitusten tilaaminen Salesforce-instanssillesi
• Ota käyttöön todellinen käyttäjien valvonta kriittisille Experience Cloud -kuluille
• Valvo integraation kuntoa virhesuhteella, viiveellä ja katkaisijan tilalla
• Suunnittele interaktiivisia hälytyksiä määritetyillä vastaustoimenpiteillä ja omistajuudella
• Reititä Event Monitoring -dataa ulkoisiin sovellusalustoihin pitkäaikaista säilyttämistä ja analysointia varten
• Käytä Proactive Monitoring and Scale Centeria luotettavuuden riskien jatkuvaan arviointiin
• Käytä poikkeusten havaitsemista määrälle, virhesuhteelle ja viivekuvioille havaitaksesi staattisten kynnysarvojen ohittamat heikentymiset

Jaa palautetta hyvin rakennetusta kehysjärjestelmästä.