Lue päivitysaikatauluistamme tästä.

Resilientit ratkaisut ylläpitävät korkeaa palvelun laatua, vaikka virheitä tapahtuisi. Jos suorituskyky heikkenee tai palvelu keskeytyy, ratkaisu palautuu nopeasti ja tehokkaasti.

Ratkaisun kestävyyteen perustuu kaksi tärkeintä ominaisuutta:

• Kestävyys: Kun ongelmia ilmenee, ratkaisu kestää ne.
• Elasticity: Kun ongelmat on ratkaistu, ratkaisu palautuu sen ihanteelliseen tilaan tai muotoon.

Jos haluat suunnitella ratkaisusi kestävyyteen, sinun täytyy suunnitella se sekä kestävyyteen että joustavuuteen, mikä varmistaa keston ja nopean palautuksen suunnitelluille ja suunnittelemattomille muutoksille.

Teknologian asiayhteydessä järjestelmä tai ratkaisu on kokoelma toisistaan riippumattomia komponentteja, jotka koordinoivat toisiaan yhteisten tavoitteiden saavuttamiseksi. Jokainen komponentti voi epäonnistua. Näiden komponenttien ongelmat, kuten koodi- ja kokoonpanovirheet sekä verkko- ja laitteistovirheet, voivat aiheuttaa odottamattomia ja epätoivottuja toimintoja. Järjestelmä toimii joustavasti, kun yksi tai useampi komponentti epäonnistuu, mutta koko järjestelmä toimii edelleen tai palaa nopeasti vakaaan tilaan.

Suosittelemme keskittymään kolmeen tärkeimpään tapaan parantaaksesi Salesforce-ratkaisujesi kestävyyttä.

• Sovelluksen elinkaaren hallinta (ALM) — Miten tiimit hallitsevat ohjelmistoja sen koko elinkaaren ajan, ideoinnista poistumiseen
• Vahinkotapahtumien vastaus — Miten tiimit tunnistavat, korjaavat ja estävät ongelmia, jotka vaikuttavat järjestelmän saatavuuteen tai tietoturvaan
• Jatkuvuussuunnitelma — Miten tiimit suunnittelevat, että heidän henkilöstönsä ja järjestelmänsä toimivat edelleen, kun suunnittelemattomat tapahtumat aiheuttavat ongelmia

Sovelluksen elinkaaren hallinta (ALM) on käytäntö, jolla hallitaan ohjelmistoa kokonaisvaltaisesti sen koko elinkaaressa, luomisesta poistamiseen. ALM on järjestelmän kestävän kehityksen kulmakivi, joka kattaa sovelluksen elinkaareen liittyvät henkilöt, prosessit, työkalut ja tieteenalat. Näihin tieteenaloihin sisältyvät DevOps ja toimitusmenetelmät, havaittavuus, testausstrategiat, hallinta ja CI/CD.

Kun yritys käyttää tehokasta ALM-järjestelmää, sen tiimit reagoivat nopeasti muutoksiin ja sen sovellukset pysyvät ajan tasalla liiketoimintavaatimusten kehittymisen kanssa vaarantamatta vakautta tai laatua.

Toisaalta ilman terveellistä ALM-järjestelmää tiimeillä on vaikeuksia sovelluksen elinkaaren kaikissa vaiheissa.

Huonon ALM-järjestelmän oireisiin sisältyy:

• Hitaat ja virheelliset kehityssyklit
• Intensiiviset ja vaikeat käyttöönotot
• Tuotantoympäristöissä ja QA-ympäristöjen jälkeen havaitut vakavat ongelmat tai virheet
• AI-agentit, jotka hallitsevat tai käyttäytyvät epäjohdonmukaisesti
• Julkaisujen vakauttamiseen vaaditut yleiset peruutukset tai hotfix-käyttöönotot

Koska ALM koskee lähes kaikkia ratkaisun osa-alueita, ratkaisullesi selkeiden ja tehokkaiden ALM-käytäntöjen luominen on tärkeä osa arkkitehtuurityötäsi.

Rakenna parempia ALM-käytäntöjä keskittymällä kolmeen tärkeään osa-alueeseen.

• Julkaisujen hallinta — Muutosten suunnittelu, järjestys, hallinta ja siirtäminen eri ympäristöihin
• Ympäristöstrategia — Strategia sovellusten käyttämiseen ja hallintaan kohdeympäristöissä kehityksen ja testauksen aikana
• Signaling-strategia — Määritelmä kriittisille signaaleille ja sovelluksen instrumentaatiolle, joita käytetään virheiden havaitsemiseen ja korjaamiseen järjestelmässä ennen heikentymistä
• Testistrategia — Periaatteet ja standardit, jotka opastavat sinua suunnittelemaan ja suorittamaan testejä sovellustesi onnistumisen mittaamiseksi ALM-prosesseissa

Julkaisujen hallinta käsittää muutosten suunnittelun, järjestyksen, hallinnan ja siirtämisen yhteen tai useampaan ympäristöön. Yksittäinen julkaisu on suunniteltujen muutosten ryhmä, jonka tiimi siirtää kohdeympäristöön samanaikaisesti.

Järjestelmän muutoksen julkaiseminen aiheuttaa siihen riskejä. Jos järjestelmä on vakaassa tilassa ennen muutosta, se siirtyy uuteen tilaan, jossa se on myös alttiimpi tulevien muutosten riskeille. Jos tulevat muutokset käynnistävät ei-hallitun, epävakaan tilan järjestelmässä, ne voivat aiheuttaa kriittisen vahinkotapahtuman. Ratkaisun arkkitehtuurissa kestävien julkaisujen suunnittelu ei ole pelkkää yksittäisten muutosten testaamista tehokkaasti. Se sisältää myös suunnittelun, miten voit tuoda muutoksia järjestelmiisi ja käyttäjiisi turvallisesti.

Tiimisi työskentely riippuu ennustettavista ja paikkansapitävistä julkaisutiedoista. Ota muutostenhallinta- ja käyttöönottoprosesseissasi huomioon, mitä muutoksia voidaan siirtää järjestelmääsi. Määritä julkaisujen hallinta- ja käyttöönottoprosesseissasi, miten – ja kuinka usein – muutokset julkaistaan järjestelmällesi.

Liiketoimintasi sidosryhmät välittävät myös julkaisutiedoista, varsinkin jos ne liittyvät heidän pyyntöihinsä liittyviin ominaisuuksiin tai virheenkorjauksiin. Luo ratkaisullesi Trust ja näytä arvo sidosryhmillesi laatimalla johdonmukaisia ja selkeitä julkaisuaikatauluja ja lähettämällä vakaita julkaisutapahtumia.

Tehokkaan julkaisun hallinnan luominen Salesforcelle:

• Tiiviisti linjassa arkkitehtuurin ja kehityksen hallinnan kanssa. Varmista, että julkaisut on suunniteltu etukäteen, jotta ne vastaavat kaikkia asiaankuuluvia hallintafoorumeja ja -ohjaimia. Ennen kuin aloitat kehityksen, saat kaikki priorisoidut Agentforce tarkastetuksi ja hyväksytyksi tekoälyn neuvoston toimesta. Hanki Agentforcen riskialttiita käyttötapauksia, joita lakisääteinen ja eettinen käyttö -tiimit tarkastavat.Käytä käyttöönoton tarkistuslistoja ja dokumentaatiota seurataksesi käyttöönottoartikkeleita, kuten Agentforce Agentforce API -nimet, hallintatoimintojen perusteella.
• Älä käytä organisaatioihin perustuvia kehitys- tai julkaisuprosesseja. Tämä paradigma vastaa kehitystä ja julkaisemista koskevia vanhempia ja rajoitetumpia teknologioita. Salesforce CLI sallii tiimien käyttää lähdekoodiin perustuvia kehitys- ja julkaisuominaisuuksia.
• Valitse mahdollisimman vakaa vapautumismekanismi. Tällä lähestymistavalla saavutetaan kaksi asiaa. Ensinnäkin se minimoi julkaisuaikojen ja palveluhäiriöiden keston. Toiseksi se sallii erittäin hallitun ja ennustettavan julkaisutavan. Mitä vakaampi julkaisumekanismi on, sitä vähemmän todennäköisesti julkaisut aiheuttavat muutoksia, jotka vaativat korjauksia tai palautuksia. Jos ilmenee odottamaton ongelma, vakaat julkaisumekanismit luovat myös yksinkertaisempia tapoja, joilla tukihenkilöstö tai järjestelmänvalvojat voivat suorittaa peruutuksia.

Tiimisi parhaat julkaisumekanismit ovat vakaimpia vaihtoehtoja, joille tiimilläsi on tarvittavat taidot. Alla on suositeltuja vapautusmekanismeja, jotka on lueteltu vakauden mukaan. Kaikki ne ovat yhteensopivia keskenään, joten käytä useita yhdessä, jos se sopii parhaiten yrityksellesi.

• Lukitsemattomat paketit — Lukitsemattomat paketit ovat vakain julkaisuobjekti. Muutosten ottaminen käyttöön asentamalla paketti on nopein ja ennustetuin tapa tehdä muutoksia. Paketit käyttävät versiointia, joka sallii vahvan muutostenhallinnan ja hienosäätämättömät ja järjestelmänvalvojille sopivat periytymiset. Lisäksi paketit vaativat vahvaa metadatan hallintaa, mikä voi auttaa sinua tunnistamaan epähallitut sidonnaisuudet ajoissa. Ne luovat myös auditoitavia kehitysputkia ja artefakteja. Katso Paketointioikeus.
• DevOps Center — DevOps Center sallii toimitustiimien käyttää lähdekoodin hallintaa, työstää muutoksia yhdessä ja määrittää yhteisiä julkaisupolkuja, joilla on vähäisen koodin tai pro-code-taitojen joukot. DevOps Center integroituu lähdekoodin hallintaan ja sallii muutosten ja käyttöönottojen ohjaamisen Osoita ja napsauta -toiminnolla.
• Lähdepohjainen kehitys ja metadatan käyttöönotot käyttämällä Salesforce CLI:a — Jos et voi käyttää paketteja, käytä Salesforce CLI:a lähdekohtaiseen kehitykseen ja metadatan käyttöönottoon. Älä ota metadataa käyttöön käyttämällä vanhempaa package.xml-formaattia, joka noudattaa eri rakennetta kuin suositeltu lähdemuoto. Lähdemuoto kehittynyt tukemaan pakettien kehittämistä, luonnosorganisaatioiden työnkulkuja ja tarkempia muutosten seurantaa sandboxeissa. Muoto on helpommin luettavissa, sallii monimutkaisten metadatatyyppien ja riippuvuuksien irrottamisen ja sallii sinun hallita käyttöönottojen manifesteja paljon tarkemmin.
• Nimeä julkaisusi. Anna julkaisujesi selkeät tunnisteet, jotta tiimisi ja sidosryhmät pysyvät ajan tasalla. Salesforcessa jokaisen suurimman julkaisun nimi alkaa ”Spring”, ”Summer” tai ”Winter”, ja sen jälkeen julkaisuvuosi (esimerkiksi ”Summer ’25”). Jos sinulla ei ole vielä nimeämiskäytäntöä yhtiösi julkaisujen määrittämiseen ja organisoimiseen, luo sellainen ja käytä sitä. Selkeiden julkaisunimien käyttäminen auttaa sinua pysymään järjestyksessä suunnittelun, kehityksen ja toimituksen kaikissa vaiheissa tiimiesi järjestelmissä. Käytä julkaisun nimiäsi suunnitelmassasi kertoaksesi sidosryhmillesi selkeästi, mitkä muutokset tulevat ja milloin. Käytä julkaisun nimiäsi dokumentaatiossasi, muutoslokeissasi, työkuvauksissa, koodin kommentteissa ja lähdekoodin hallinnan haaroissa, jotta voit seurata ja tarkastaa kehitysartikkeleitasi helposti.
• Hallitse riippuvuuksia hyvin julkaisun manifestissa. Salesforce-metadatalla on sisäänrakennetut sidonnaisuudet. Yleinen syy siihen, että Salesforce-käyttöönotot epäonnistuvat, on se, että sidonnaisuuksia ei hallita oikein. Vakiomuotoisen julkaisumekanismin valitseminen, kuten aiemmin kuvattu, voi auttaa paljastamaan epähallitut sidonnaisuudet kehityssyklisi alussa. Eräs tärkeimmistä syistä, miksi lukitsemattomat paketit ovat vakain julkaisuaika, on niiden vahva metadatan hallinta, joka vaaditaan pakettien kehittämiseen ja luomiseen. Jos sinä tai julkaisun hallintatiimisi et ymmärrä Salesforcen metadatatyyppien välisiä sisäänrakennettuja sidonnaisuuksia, et voi ennakoivasti havaita ongelmallisia yhdistelmiä käyttöönotto- ja julkaisumanifestateissasi. Lisätietoja on kohdassa Riippuvuuksien hallinta.

ALM:n kuviot ja vastakuviot näyttävät, miltä oikea ja huono julkaisujen hallinta näyttää Salesforce-organisaatiossa. Käytä kuvioita vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmässäsi uudelleenrakennettavat kohteet.

Lisätietoja Salesforcen julkaisujen hallintatyökaluista on kohdassa Salesforce Tools for Resiliency.

Salesforce tarjoaa useita erilaisia ympäristöjä, joita voit käyttää sovellusten kehitys- ja testaussyklien aikana. Salesforcen tehokas ympäristöstrategia edellyttää, että ymmärrät, miten ympäristöjä käytetään ja miltä hyvä hallinta näyttää. Kehitys- tai testausympäristön hyödyllisyys ALM:ssä riippuu sen uskollisuudesta tuotantoympäristöön ja sen eristyneisyydestä tuotantoympäristöstä.

Hyvä ympäristöstrategia tarjoaa useita etuja.

• Uskollisempi tuotantoympäristö
• Ympäristöjen määritysten ja tiivistämisen nopeuttaminen
• Kehitä ja testaa joustavammin
• Parannettu tietoturva myyntiputkessasi
• Vähemmän melua ja ristiriitoja toimitusvaiheiden aikana
• Onnellisempia kehitystiimejä

Tiimeillä on usein vaikeuksia saavuttaa näitä etuja. Kehitysympäristösi ja strategiasi hyödyntämiseen liittyviä haasteita voi tulla useista eri lähteistä. Yksi todennäköinen lähde on kehitysmallin tyyppi, jota tiimisi noudattavat.

Vanhassa, organisaatioihin perustuvassa kehitysmenetelmässä jokaisen ympäristön tarvittiin tarjoamaan useita toimintoja. Sen lisäksi, että se on paikka, jossa tiimisi tekee erilaisia töitä, sen täytyy olla lähde julkaisuartikkeleillesi (eli metadatalle, jonka haluat ottaa käyttöön julkaisussa). Koska ympäristöjä ei ollut helppo määrittää tai pilkkoa, ne olivat usein täynnä metadatan ristiriitoja tiimien välillä, eivätkä ne vaikuta merkittävästi ALM:n nopeuteen tai joustavuuteen.

Lähdepohjaisen kehitysmallin käyttäminen muuttaa ympäristöjen suhteita julkaisuihisi ja julkaisuartikkeleihisi. Tässä mallissa lähdekoodin hallinta on julkaistavan metadatan lähde. Ympäristöt ovat vain paikkoja, joissa tiimisi työskentelevät.

Lähdepohjaisen kehitysmallin noudattaminen ei kuitenkaan pelkästään takaa hyvää ympäristöstrategiaa. Tiimeillä voi olla vaikeuksia määrittää ehtoja, joilla voi testata ulkoisten järjestelmien integraatioita, kokoonpanoja, jotka ovat riippuvaisia metadatasta, jota ei voi hallita lähdekoodin avulla, kuten hallittuja paketteja tai mukautuksia, jotka ovat riippuvaisia datasta, jne. Joissakin tilanteissa lähdepohjaisen mallin haasteet muistuttavat organisaatioihin perustuvan mallin tyypillisiä haasteita.

Tehokkaan ympäristöstrategian kehittäminen:

• Ota lähdepohjainen kehitys- ja julkaisumalli käyttöön. Lopeta organisaatioihin perustuvien kehitysmallien käyttö. Katso julkaisujen hallinta). Sinun täytyy irrottaa ympäristösi niiden käyttöönotosta luodaksesi terveellistä ympäristöstrategiaa ja terveellisempiä julkaisuja.
• Ymmärrä kunkin ympäristön tukemat työtyypit. Salesforcen tukemilla ympäristötyypeillä on erilaiset ominaisuudet ja rajoitukset. Kun suunnittelet ympäristöstrategiaasi, mieti, mitä ympäristöt voivat ja eivät voi tehdä. Varmista, että tiimisi työskentelevät ympäristössä, jossa heillä on tarvitsemansa ominaisuudet. Katso ohjeet tästä Salesforce-kehitysympäristöjen ja niiden ominaisuuksien yleiskatsauksesta.

Katso tästä taulukosta, mitä ominaisuuksia ja ympäristöjä käytetään useissa yleisissä kehitystehtävissä.

Huomaa lisäksi, että kattava testaus on rajoitettu Agentforce-agenttien, jotka käyttävät ominaisuuksia, kuten Einsteinin datakirjastoa, Knowledge-artikkeleita ja jäsentämättömiä tietoja, ellei sinulla ole Data 360 -sandboxia. Tarvitset myös Data 360 -sandboxin varmistaaksesi tarkat testausehdot.

• Irrota ympäristöjä julkaisuartefakteista. Älä käytä organisaatioihin perustuvaa kehitystä. Käsittele ympäristöjä paikoina, joissa työ tapahtuu tietyn ajan. Kuvittele, että ympäristön metadatan tila on erillään julkaisuartefakteistasi. Jos osa koodista tai kokoonpanosta ”tulee selville” ympäristössä, sen tulisi olla sitoutunut lähdekoodin hallintaan, jolloin siitä tulee julkaisuobjekti.

  • Ympäristöt ovat epävakaita. Rakenna prosesseja, jotta voit luoda ja tuhota niitä mahdollisimman nopeasti.
  • Artefaktit kestävät. Ne kuuluvat lähdekoodin hallintaan.

• Irrota ympäristöjä vapautuspoluista. Tavallisesti näet pakollisia julkaisupolkuja, jotka vaativat muutosten käyttöönottoa tietyissä ympäristöissä. Tavallisesti tätä lähestymistapaa käytetään välityspalvelimen luomiseen sovelluksen vanhenemisen tai julkaisun vakauden vahvistamiseksi. Tiimit voivat myös käyttää sitä yrittääkseen minimoida monimutkaisen testausinfrastruktuurin määrittämiseen tarvittavien ympäristöjen määrää. Lähdepohjaisissa paradigmissa sinulla on enemmän joustavuutta siinä, miten ja missä voit vahvistaa ja testata muutoksia.

  • Julkaisuvaiheita sovelletaan julkaistuihin esineisiin, ei ympäristöihin. Älä luo ympäristöä vain kerätäksesi kaikki tietyn julkaisuvaiheen muutokset. Siksi lähdekoodin hallinta, erityisesti haarautuminen, on tarpeen. Käytä haarautumisstrategioita lähteen hallinnassa organisoidaksesi muutokset, jotka otetaan käyttöön tietyissä ympäristöissä. Riippuen tehtävästä työstä, sinun täytyy ehkä ottaa kaikki julkaisun metadata käyttöön ympäristöön. Haarautuminen sallii sinun tehdä niin. Joitakin poikkeuksia lukuun ottamatta kaikki kehitysympäristöt täytyy päivittää tai tuhota heti, kun työ on suoritettu. Muista synkronoida kaikki metadatan muutokset, jotka tapahtuvat tietyssä ympäristössä — ja jotka haluat säilyttää — lähdekoodin hallintaan.
  • Ympäristöt ovat vain yhtä hyödyllisiä kuin niiden uskollisuus tuotantoon. Optimoi ympäristön määritysten työnkulut tai automatisointi, jotta voit purkaa tai päivittää ympäristöjä mahdollisimman nopeasti. Mieti, että kaikki kokoonpanot, jotka estävät sinua tekemästä nopeampia ja yleisempiä ympäristön päivityksiä, ovat kriittinen riski ALM-prosessiesi yleiselle kestävyyteen. Jos sinulla on siihen liittyviä korjaustöitä, lisää se suunnitelmiisi ja priorisoi se. Tutustu siihen, miten voit käyttää järjestelmässäsi löysemmin yhdistettyjä, moduuleja yksiköitä. Ne sallivat tiimien suorittaa luonnosorganisaatioissa useampia kehitystoimia ja vapauttavat sandbox-rajoituksia muille töille. Älä unohda ominaisuuksia, joita luonnosorganisaatiot tarjoavat testaamaan ominaisuuksia, joita sinulla ei ole tuotantoympäristössä, joko koska et ole ostanut heille lisenssejä tai ottanut niitä käyttöön.
  • Salli yrityskäyttäjien tai loppukäyttäjien käyttää ympäristöjä, joiden avulla he voivat keskittyä heille tärkeisiin asioihin. Älä käytä yleisiä, erottamattomia ympäristöjä, joissa monet eri loppukäyttäjäryhmät tai liiketoiminnan sidosryhmät yrittävät tehdä ALM-työtä. Kutsu ja aktivoi tiettyjä sidosryhmiä tiettyihin ympäristöihin tehdäksesi tiettyjä töitä. Arvioi huolellisesti kaikki prosessit, jotka asettavat loppukäyttäjät tai liiketoiminnan sidosryhmät ympäristöön, jossa on enemmän dataa kuin mitä Partial Copy -sandbox voi tukea. Varmista, että tehtävän työn suorittamiseen tarvittava määrä tietoja. Suunnittele käyttäjien hyväksyntöjen testit ja kehitysvaiheiden alkuvaiheet siten, että ne tapahtuvat mahdollisimman tarkasti yhdessä. Optimoi kaikki testausvaiheet ottaaksesi käyttöön nopeampia ja aikaisempia palaute- ja iterointisykliä kehitystiimeillesi ja loppukäyttäjillesi. Katso testausstrategia.

• Laadi eri julkaisupolut erityyppisille muutoksille. Kaikki muutokset eivät vaadi, että samantyyppiset ALM-työt suoritetaan samassa järjestyksessä. Loppukäyttäjien suorittaminen hyväksymistestiä järjestelmän taustakomponenttien pienille muutoksille ei todennäköisesti ole hyvä käyttöaika. Käyttäjien hyväksyntä ja skaalaustestaus voivat kuitenkin olla erittäin arvokkaita mobiilisovelluksen kehityksen alkuvaiheessa. Tunnista eri muutoskategorioiden julkaisupolut, kuten korkea riski, keskitason riski ja matala riski.

  • Korkea riski: Muutokset vaikuttavat asiakkaisiin, kumppaneihin tai kaikkiin sisäisiin käyttäjiin. Muutokset vaikuttavat tietoturvaan tai integraatioon. Muutokset lisäävät monimutkaisia uusia ominaisuuksia.
  • Keskitason riski: Muutokset vaikuttavat sisäisten käyttäjien määritettyyn kynnysarvoon. Muutokset vaikuttavat datamalleihin, datatoimintoja suorittavaan automatisointiin tai integraatioon.
  • Pieni riski: Vaikuttaa suoraan alle määritetyn kynnysarvon sisäisille käyttäjille. Ei sisällä tietoturvaan, datamalleihin tai datatoimintoihin liittyviä automaatioita tai integraatiota koskevia muutoksia.

• Älä salli ylikuormattujen ympäristöjen olemassaoloa. Työn priorisoinnin, rajauksen ja järjestyksen puute johtaa väistämättä ylikuormitettuihin kehitysympäristöihin, joissa on liian paljon, liian paljon ja liian erilaisia töitä. Ylikuormitetut ympäristöt aiheuttavat suurta stressiä, epäselvyyttä ja ristiriitoja kehitystiimien keskuudessa. Ne aiheuttavat myös melua kehitysputkessa ja heikentävät laadunvalvontatehtäviä. Näiden negatiivisten vaikutusten lisäksi ylikuormitetut kehitysympäristöt ovat vakavia uhkia ympäristön ylläpidossa ja turvallisuudessa. Pidä ylikuormitusta ALM-prosessisi mahdollisten ongelmien oireena. Tutki juurisyyn liittyviä ongelmia ja korjaa ne. Jos kohtaat yhä ylikuormituksen, voit ostella lisää sandboxeja.

ALM:n kuviot ja vastakuviot näyttävät, miltä oikea ja huono ympäristöjen hallinta näyttää Salesforce-organisaatiossa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmäsi osa-alueet, jotka täytyy korjata uudelleen.

Lisätietoja Salesforcen työkaluista ympäristön hallintaan on kohdassa Salesforce Tools for Resiliency.

Signalointistrategia määrittää kriittiset signaalit ja sovelluksen instrumentit, joita tarvitaan virheiden havaitsemiseen, diagnosoimiseen ja korjaamiseen ennen kuin ne heikkenevät järjestelmänlaajuisesti. Tehokas instrumentaatio muuntaa sovellukset epäonnistumisen passiivisista uhreista aktiivisiksi osallistujiksi, jotka kykenevät havaitsemaan ongelmia, mukauttamaan toimintatapaansa ja koordinoimaan heikentymistä tarvittaessa.

Kun sovellukset käyttävät kattavaa instrumentaatiota, he voivat säätää itseään stressin aikana, kertoa terveydentilastaan operaattoreille ja osallistua koordinoituihin toipumistoimiin. Nämä ominaisuudet sallivat järjestelmien ylläpitää palvelun laatua, vaikka yksittäiset komponentit kärsivät hädästä. Toisaalta ilman asianmukaista instrumentaatiota sovellukset muuttuvat mustaksi laatikoksi, joka epäonnistuu hiljaa, kunnes ilmestyvät katastrofaaliset oireet. Tiimit reagoivat ongelmiin vasta, kun käyttäjät ovat ilmoittaneet niistä, ja vianmäärityksestä tulee arkeologian harjoitus observaation sijaan.

• Hae sovelluksessa esiintyviä virheitä. Sovellusten täytyy hallita itseään havaitakseen ja reagoidakseen yleisiin virhekuvioihin, jotka ilmestyvät raskaan kuormituksen yhteydessä. Harkitse jonojen täytettä. Kun viestijonot täytetään nopeammin kuin niitä voidaan käsitellä, asentamattomat sovellukset jatkavat töiden hyväksymistä, kunnes muisti loppuu tai aikakatkaistaan. Oikein instrumentoidut sovellukset valvovat jonojen syvyyttä, hylkäyssuhteita ja käsittelyn viiveitä, mikä käynnistää puolustusvastauksia, kun kynnysarvot ylittyvät.

• Käsittele signaaleja tehokkaasti sovelluksen ulkopuolelta: Käyttöjärjestelmän signaalien käsittely edustaa toista kriittistä instrumentaatiopistettä. Sovellusten täytyy rekisteröidä käsittelijöitä päättymisviesteille (SIGTERM, SIGINT) ottaakseen käyttöön hienovaraisen sammuttamisen. Oikein instrumentoitujen sovellusten sulkemisen aikana uusien töiden hyväksyminen keskeytyy, lennon sisäinen pyyntöjen suorittaminen sallitaan, puskurit tyhjennetään, yhteydet suljetaan puhtaalta pöydältä ja palvelun löytämisen rekisteröinti kumotaan. Tämä orkestroitu sammutus estää datan katoamisen ja sallii kuormituksen tasapainottamisen ohjata liikennettä ilman häiriöitä.

• Laite monimutkaisille virheiden skenaarioille: Näiden peruskuvioiden lisäksi sovellusten täytyy käyttää välineitä hienovaraisempia virhetiloja varten. Harmaiden virheiden tunnistaminen, joissa komponentit näyttävät terveiltä joillekin tarkkailijoille ja epäonnistuvat muille, vaatii sisäisten ja ulkoisten signaalien korrelointia. Sovellus saattaa työstää tietokantayhteysjoukkoaan raportoidakseen onnistuneita terveystarkastuksia samalla, kun se seuraa transaktioiden suoritussuhteita, jotka paljastavat heikkenevän heikentymisen. Tehokkaat instrumentointistrategiat keräävät useita observaatiopisteitä.

  • Liiketoimintatilastot seuraavat sovelluskohtaisia onnistumistietoja, kuten tilausten suoritussuhteita tai hakutulosten laatua.
  • Järjestelmätilastot valvovat resurssien käyttöastetta, viiveiden jakaumia ja virhesuhteita.
  • Synteettiset sondit käyttävät jatkuvasti kriittisiä polkuja havaitakseen heikentymisen ennen kuin käyttäjät kohtaavat sen.
  • Jakattu seuranta tarjoaa pyyntötason näkyvyyden palvelurajoittain.

Nämä signaalit paljastetaan standardoiduilla käyttöliittymillä, joiden avulla automatisoidut järjestelmät ja käyttäjät voivat arvioida sovelluksen kuntoa. Itse instrumentaatiosta tulee osa sovelluksen joustavuusstrategiaa, jonka avulla katkaisijat voivat siirtyä virhesuhteiden perusteella, automaattiset skaalaajat reagoivat jonojen syvyyteen ja operaattorit voivat tehdä tietoon perustuvia päätöksiä vahinkotapahtumien aikana.

ALM:n kuviot ja vastakuviot näyttävät, miltä oikea ja huono signaalistrategia näyttää Salesforce-organisaatiossa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmäsi osa-alueet, jotka täytyy korjata uudelleen.

Lisätietoja signaalistrategian Salesforce-työkaluista on kohdassa Salesforce Tools for Resiliency.

Testistrategia on joukko ohjeellisia periaatteita ja standardeja, joilla voit suunnitella ja suorittaa testejä, jotka mittaavat sovellusten onnistumista ja epäonnistumista ALM-prosesseissa. Testausstrategia pitää kaikki testaukseen osallistuvat sidosryhmät ajan tasalla tietyn testin prioriteetista, tarkoituksesta ja vaikutusalueesta. Se auttaa myös projektitiimejä luomaan tehokkaita ja harkittuja testisuunnitelmia.

Tavallisesti kehittäjät tai laadunvalvonnan ja testauksen asiantuntijat osallistuvat tiettyjen testien luomiseen ja suorittamiseen. Testausstrategia auttaa varmistamaan, että nämä henkilöt tietävät, millaisia testejä tietylle projektille täytyy suorittaa ja missä järjestyksessä ne suoritetaan. Testistrategia auttaa myös varmistamaan, että tiimeillä on tarvittavat tiedot, jotta he voivat laatia hyvin muotoiltuja testejä, testisuunnitelmia ja artefakteja (esimerkiksi testidatajoukkoja, laitteita ja liikenteen tai verkko-simulaattoreita).

Tehokas testausstrategia luo selkeän kuvan siitä, miten, milloin, missä ja miksi sinun tulisi suorittaa eri testityyppejä — mukaan lukien yksikkötestit, käyttöliittymätestit ja regressiotestit — eri yhdistelmissä ja ehdoissa nähdäksesi, miten järjestelmäsi ja kaikki lennon aikana tehdyt muutokset toimivat. Tehokas testistrategia tuottaa testejä, jotka näyttävät sinulle, miten hyvin järjestelmä noudattaa ei-toiminnallisia vaatimuksia — kuten skaalattavuutta, luotettavuutta ja käytettävyys — joita voi olla vaikea mitata yhdellä testityypillä.

Tehokkaiden testausstrategioiden luominen Salesforcelle:

• Testaa iteratiivisesti, usein ja mahdollisimman paljon automatisoiduilla tavoilla. Suunnittele ja toteuta testien automatisointia, jonka avulla tiimit voivat suorittaa erilaisia testityyppejä eri työkuormille. Orkestroi useita testiajoja, jotka tapahtuvat automaattisesti, kun muutokset tulevat lähdekoodin hallintaan. Tämä lähestymistapa sallii tiimien tunnistaa ja ratkaista regressioita ennakoivasti. Käytä jatkuvaa integraatiota / jatkuvaa toimitusta (CI/CD) tälle toimille, jos se on mahdollista. Jos et tee niin, laadi selkeitä testisuunnitelmia, joiden avulla tiimit voivat suorittaa testien sarjoja ajoissa ja usein itsepalvelutapaansa. Jos käytät Agentforce testausta, luota testauskeskukseen tekoälyn agenttien tarkkojen erätestien suorittamiseksi eri syötteillä varmistaaksesi, että he toimivat oikein eri skenaarioissa.
• Ymmärrä, että kaikki muutokset eivät vaadi kaikenlaisia testejä. Aivan kuten tehokas julkaisuputki sisältää polkuja korkean, keskitason ja pienen riskin sovelluksille, niin myös tehokas testistrategia. Kerro tiimeille selkeästi, miten valita ja noudattaa sopivaa testausjärjestelmää sovelluksille, joilla on erityyppisiä riskejä, käyttötarkoituksia tai monimutkaisuuksia. Lisätietoja on kohdassa Ympäristöstrategia.
• Määritä mitkä testit voidaan suorittaa eri ympäristötyypeissä. Tuotantoympäristö on tärkeä osa tarkkoja testejä, mutta se tarkoittaa eri asioita erityyppisille testeille. Esimerkiksi regressiotestaus vaatii tuotanto-organisaation pysyvyyttä metadatan ja tietyssä määrin datan osalta. Muista määrittää, minkätyyppinen tuotantoon perustuvuus vaaditaan tietylle testijoukolle, ja luokittele selkeästi, minkätyyppiset ympäristöt voivat tukea eri testeille sopivia ehtoja. Katso kunkin ympäristötyypin työtyyppien yleiskatsaus kohdasta Ympäristöstrategia.
• Käytä kestävyyttä, stressiä, suorituskykyä ja skaalaustestejä mitataksesi sovellusten kypsyyttä jatkuvasti. Nämä testit näyttävät, miten julkaistu sovellus on suhteessa tuotantotason tarpeisiin. Suorita nämä testit useita kertoja sovelluksen kehityssyklin aikana uusille tärkeimmille ominaisuuksille. Sinun kannattaa pitää näitä testejä osana vain yhtä kehitysvaihetta, eikä osana jatkuvia tehtäviä. Tiimeille on hyödyllistä saada palautetta sovelluksen suorituskyvystä ajoissa ja usein, mikä auttaa heitä ymmärtämään paremmin, kuinka lähellä sovellus on tai kuinka kaukana se on tuotantotason valmiudesta. Kyky tunnistaa ja ratkaista ongelmia paremmin ennen kuin muutokset siirretään tuotantoympäristöön kannattaa monimutkaistaa monimutkaisempien testien suorittamista usein.
  • Tiedä mitkä testit ovat tärkeitä. Sinulla on todennäköisesti tietty määrä aikaa skaalan tai suorituskyvyn testaamiseen, joten järjestelmäsi kaikkien osa-alueiden testaaminen ei ole käytännöllistä. Kaikkia ominaisuuksia ei käytetä samalla tavalla eikä kaikki skaalan pullonkaulat vaikuta liiketoimintaan samalla tavalla. Varmista, että skaalatestit keskittyvät järjestelmän eniten käytettyihin ja arvokkaimpiin osa-alueisiin. Määritä ja ymmärrä tärkeimmät mahdollisuudet, joilla voit vahvistaa ja parantaa organisaatiosi skaalaa ja suorituskykyä.
  • Tiedä miltä ”hyvältä” näyttää. Scale- ja Performance-testiesi onnistumisen ehtojen määrittäminen on tärkeää. Varmista, että sinä ja kehitystiimisi käytät onnistumisen ehtoja testauksen vertailuarvoina. Varmista myös, että he ilmoittavat toiminnallisista vaatimuksista, joita kehitystiimit noudattavat. Tavallisesti nämä ehdot sisältävät tiettyjen samanaikaisten käyttäjien tuen, joiden vastausaikoja on alle sovittu arvo, sekä palvelutasotavoitteesi (SLO). Määritä tärkeimmät tavoiteehdot ja suunnittele skaalat ja suorituskykytestit varmistaaksesi, että ehdot täyttyvät.
  • Varmista, että sinulla on asianmukaiset ympäristöt. Skaalauksen ja suorituskyvyn testaaminen vaatii tiettyä uskollisuutta tuotantoympäristöön. Datajoukkojesi, pyyntösi demografiset tiedot, pyyntöjen määrät ja työkuormien ominaisuudet muissa kuin tuotantoympäristöissä tulisi vastata tuotantoympäristössä näkemiäsi tietoja mahdollisimman paljon. Sinun täytyy käyttää Full-sandboxia skaalan testaamiseen. Jos organisaatiollasi ei ole Full-sandboxia skaalatestausta varten, et voi suorittaa riittäviä skaalatestejä.
• Varmista, että testaustyökuormat auttavat sinua mittaamaan ei-toiminnallisia vaatimuksia. Muista ottaa huomioon:
  • Testitiedot – Kaikenlaisen testin tulisi tapahtua tuotantoympäristöstä eristetylle datalle. Toteuta Apex-yksikkötesteissä datatehtaan kuvioita varmistaaksesi, että koodi luo omat testitietonsa erillään ympäristötiedoista. Voit myös luoda ja ylläpitää testidatajoukkoja useissa eri muodoissa testataksesi datan latautumistapoja, täyttääksesi kehitysympäristöjä käyttöliittymään perustuvien testien datalla ja auttaaksesi integraatiotestauksessa. Kaikkien testitietojen, riippumatta siitä, säilytetäänkö ne ulkoisena datajoukkona vai datatehtaan koodin luomana pyynnöstä, tulisi poistaa luottamukselliset ja tunnistavat tiedot. Sen tulisi sisältää korruptoituneita, puutteellisia ja muotoiltuja tietoja, jotka tukevat negatiivisia ja rajatason yksikkötestien toimintatapoja.
  • Mock- ja stub-palvelut – Voit käyttää integraatiotestausta varten API-vastausten simuloimiseen malli- ja stub-palveluita. Apex tukee Stub API:a luodakseen imitointikehyksiä käytettäväksi Apex-testeissä. Hocking luodaksesi Hocking-kehyksiä, joita voidaan käyttää Apex. Piilokopioinnit ja pistemerkit voivat auttaa vahvistamaan järjestelmän datan käsittelytapoja, vähemmän riippuen monimutkaisista datatehtaista tai ulkoisista testidatajoukoista. Mykkäykset ja pinot ovat joskus sopivampia käytettäväksi testeissä, joissa tuotantoympäristön kaltainen liikenne tai datamäärät eivät ole relevantteja.
  • Laitteet ja avustavat teknologiat – Tärkein osa sovellusten rakentamista, jotka ovat aktiivisia ja käytettävissä, on varmistaa, että ne vastaavat käyttäjien odotuksia useissa eri laitteissa ja erilaisten avustavien teknologioiden avulla. Käytettävyyden merkityksellinen testaaminen saattaa vaatia enemmän investointeja ja erityyppistä ammattitaitoa suorittaakseen sen tehokkaasti, mutta se on tärkeä osa sitä, miten hyvin käyttäjille tarkoitetut sovelluksesi on rakennettu, kun ne julkaistaan.
  • Simulaattorit – Kun sinun täytyy kopioida tuotantoympäristöön perustuvia määriä käyttäjäpyyntöjä, API-liikennettä tai verkkoviivoja, saatat tarvita työkaluja, jotka simuloivat seuraavia ehtoja. Kaikki testit eivät vaadi tätä investointitasoa. Nämä työkalut ovat usein hyödyllisiä skaalattavuuden ja suorituskyvyn testaamisessa.
  • AI- ja agenttien testaaminen - Testauksen ensisijainen tavoite on vähentää tekoälyn hallusinaatioita, jotka ovat vakuuttavia vastauksia, jotka on valmisteltu ja väärin . Varmista, että tekoälyn käyttötapauksia testataan korostaaksesi yleisiä ongelmia, jotka johtuvat asiakkaan puutteellisesta ymmärryksestä, puuttuvista tiedoista, kentistä, joissa on puutteellista metadataa, ja vanhentuneista tiedoista. Käytä testauskeskusta luodaksesi tarvittavia testitietoja tällaisille testeille.

Seuraava taulukko näyttää valikoiman kuvioita, joita haluat etsiä tai rakentaa organisaatiossasi, sekä vasta-kuviot, joita haluat välttää tai kohdistaa korjaamiseen.

✨ Tutustu ALM:n lisäkuvioihin Kuvioiden ja antikuvioiden tutkintaohjelmasta.

Suojaus- ja sivuston luotettavuustekniikassa (SRE) vahinkotapahtumien vastaus keskittyy siihen, miten tiimit tunnistavat ja käsittelevät tapahtumia, jotka vaikuttavat järjestelmän yleiseen saatavuuteen tai tietoturvaan, sekä siihen, miten tiimit työskentelevät juurisyiden korjaamiseksi ja tulevien ongelmien ehkäisemiseksi. Vahinkotapahtumien vastaus sisältää prosessit, työkalut ja organisaation toimintatavat, joita tarvitaan ongelmien ratkaisemiseksi reaaliajassa ja ongelman ilmestymisen jälkeen.

Arkkitehtinä et välttämättä ole henkilö, joka valvoo ratkaisusi toimintoja päivittäin, kun se julkaistaan. Osana kestävyyttä koskevaa arkkitehtuuria suunnitellaan palautusominaisuuksia, joiden avulla tukitiimit voivat suorittaa ensimmäisen tason diagnoosia, vakauttaa järjestelmiä ja siirtää tutkimuksen ja juurisyiden lieventämisen tehokkaasti kehitys- tai huoltotiimeille. Tiimit, jotka tukevat käyttäjiä suoraan päivittäin, eivät välttämättä ymmärrä järjestelmän arkkitehtuuria tai ole asiantuntevia. On tärkeää, että näillä tiimeillä on työkalut ja prosessit, joita he tarvitsevat päivittäisten toimintojen valvomiseksi, pääsevät käsiksi järjestelmän tietoihin, kun he diagnosoivat mahdollisen vahinkotapahtuman, ja toimivat tehokkaina ensisijaisina vastaajina kaikkiin saatavuutta koskeviin ongelmiin.

Voit parantaa tapaa, jolla tiimit reagoivat vahinkotapahtumiin Salesforce-ratkaisuissasi, keskittymällä palautusaikaan, luokitteluun sekä valvontaan ja hälytykseen.

Kun vahinkotapahtuma ilmenee, sen ensisijainen prioriteetti on palauttaa järjestelmät vakaaan toiminta-tilaan. Usein yritykset ajattelevat, että ainoa tapa toipua vahinkotapahtumasta on ”korjata ongelma”. Tämä oletus on oikeudenmukainen, koska tarkka juurisyyn analyysi ja korjaus on tapa, jolla ratkaiset järjestelmässä olevia kriittisiä ongelmia. Ongelman korjaaminen kriisivastauksen alkuvaiheessa ei kuitenkaan ole käytännöllisin tapa. Riippuen vahinkotapahtuman vakavuudesta, jokainen sen sekunti ja sen vaikutus voivat aiheuttaa yritykselle tuoton tai maineen häviämisen.

Juurisyiden diagnosointi ja korjaaminen viivästyttää usein järjestelmän toiminnan palauttamista. Logistisesti ottaen lähestymistapa, joka pyytää vahinkotapahtumien vastaajia käsittelemään juurisyitä, aiheuttaa huomattavan paineen yrityksesi aiheiden asiantuntijoille (pk-yrityksille) ja tukihenkilöstöille. Juurisyiden löytäminen ja korjaaminen vahinkotapahtuman ajankohtana edellyttää, että pk-yritykset ovat valmiina jokaiseen vahinkotapahtumaan, mikä voi estää etulinjan asiakastukihenkilöstön toimia. Se voi myös johtaa siihen, että tiimit julkaisevat muutoksia, jotka puolestaan luovat enemmän vahinkotapahtumia. Loppujen lopuksi tällainen lähestymistapa kasvattaa kustannuksia, kuluttaa kaistanleveyttä eri tiimeille ja johtaa kriisitilanteessa käyttäytymiseen, joka voi heikentää asiakkaan Trustia ja brändin maine.

Oikea vahinkotapahtumien hallinnan paradigma on priorisoida ja keskittyä palautumiseen ensimmäisenä vaiheena. Kun järjestelmä on palautettu vakaudeksi, voit jatkaa syyttömästi kuoleman jälkeisiä toimia, vahinkotapahtumien tutkimuksia, juurisyiden korjausta ja muita vastaavia toimia. Tämä toimintajärjestys sallii vahinkotapahtumien vastauksen henkilökunnan lajitella, diagnosoida ja suorittaa toipumista koskevia toimintatapoja paremmin, ja ilmoittaa asiaankuuluville pk-yrityksille, että he voivat auttaa vain tarvittaessa. Lisäksi se sallii pk-yritysten tunnistaa ja korjata vahinkotapahtuman juurisyitä käyttämällä vähemmän kelloa.

Palautuksen ensisijainen mielipide vahinkotapahtuman vastauksessa:

• Luo ja saavuta palvelutasojen tavoitteita SLO-kertoimilla. SLO:t ovat standardeja, joita kehität sidosryhmäsi kanssa järjestelmän tietyille ei-toiminnallisille vaatimuksille (NFR), kuten suorituskyky tai toiminta-aika. Nämä tavoitteet mitataan palvelutason indikaattoreilla (SLI) tietyltä ajanjaksolta. Ilman SLO-uloskirjautumisia suuri osa vahinkotapahtumien vastaukseen ja monimutkaisten ongelmien vianmääritykseen liittyvästä työstä saattaa tuntua epäjärjestykselliseltä ja reaktiiviselta — esimerkiksi pyytämällä nopeita toimenpiteitä ”pysäyttääksesi tämän tietyn virheen näille käyttäjille, jotka ovat raportoineet sen”. Tämä sykli aiheuttaa usein, että tiimit siirtävät juurisyyn analyysin lähemmäksi vahinkotapahtumien vastausta — koska se näyttää auttavan pysäyttämään reaktiiviset toimintatavat. SLO- ja SLI-uloskirjautumisten luominen on tehokkaampi tapa aloittaa. Mieti seuraavia kysymyksiä luodaksesi SLO-kertakirjautumisia.
  • Mikä on järjestelmäsi NFR-arvo seuraavalle 1–3 vuodelle? NFR voi esimerkiksi sisältää vastausaikoja, pyyntöjen maksimiä ja samanaikaisia käyttäjiä, joita järjestelmäsi täytyy voida tukea.
  • Mitä haluat asiakkaidesi ja heidän käyttäjiensä kokevan? SLO-kertakirjautumiset perustuvat tähän kysymykseen, joka voisi olla ”Käyttäjät voivat suorittaa raportteja nopeasti Salesforcessa”.
  • Mitä voit mitata ja kuinka kauan sinun tulisi mitata sitä? Perusta palvelutasopimuksesi vastaukseen tähän kysymykseen. Edellisen esimerkin mukainen SLI voisi olla ”x% raporteista latautuu keskimäärin n sekunneissa, mitattuna 30 päivän ajanjaksolla”.
• Määritä ja standardoi palautustaktiikoita. Muutosten peruutukset ja korjaustoteutukset voivat auttaa järjestelmää toimimaan uudelleen ja minimoida vahinkotapahtuman vaikutuksen. Asiakirjojen palautustaktiikat ja protokollat, joita asianmukaiset tukitiimiesi tai toimintatiimiesi jäsenet voivat suorittaa. Palautustaktiikat vaihtelevat vahinkotapahtuman tyypin mukaan. Seuraava taulukko näyttää yleisen kehyksen, joka kartoittaa vahinkotapahtumatyypit toipumisen taktiikoihin. Lisätietoja virheiden pisteiden tunnistamisesta ja strategioiden määrittämisestä on kohdassa Availability.

• Määritä selkeät poissaolojen ehdot. Käytä SLO-kertakirjautumistasi määrittääksesi, milloin järjestelmäsi ei ole vahinkotapahtuman tai vaikutuksen tilassa.
• Määritä prosessit vahinkotapahtumien jälkeisille tarkastuksille ja juurisyiden korjaamiseksi. Ota aikaa tarkastaa vahinkotapahtumat, kun palvelu on palautettu. Noudata tarkastusten aikana viattomia tapauksia kuoleman jälkeen. Tee yhteistyötä sidosryhmien kanssa keskittyäksesi luomaan selkeitä tietoja siitä, mitä tapahtui ja miten se tapahtui, sen sijaan, että yritettäisiin kohdistaa virheen tai syyn yksittäisille henkilöille. Käytä erilaisia tarkastusformaatteja tutkiaksesi tapoja ratkaista ongelmia pitkällä aikavälillä.
  • Toiminnon jälkeinen tarkastus keskittyy vahinkotapahtumaan reagointiin. Se on hyödyllinen arvioidaksesi, ovatko asiaankuuluvat vastausprosessit ja taktiikat käytössä.
  • Jälkisyyn liittyvä analyysi keskittyy vahinkotapahtuman juurisyyn. Se voi auttaa tunnistamaan kaikki virheet tai ongelmat järjestelmäsi suunnittelussa ja toteutuksessa, jotka johtivat vahinkotapahtumaan.
• Käytä hyväksyttyjä palautusprotokollasi säännöllisesti. Käytä palautusprotokollia varmistaaksesi, että kaikki osaavat käsitellä vahinkotapahtumia oikein. Käytä sandboxeja ja testiympäristöjä tarjotaksesi tiimeille paikkoja, joissa he voivat harjoitella vahinkotapahtumien simulointia ja palautusta. Käytä myös vahinkotapahtuman jälkeisiä tarkastuksiasi. Kaiken tämän käytännön tekeminen tekee toipumisesta osan insinööri- ja tukikulttuuristasi.

Vahinkotapahtumien vastauksen kuviot ja vastakuviot näyttävät, miltä palautuksen priorisointiarkkitehtuuri näyttää Salesforce-ratkaisussa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmäsi osa-alueet, jotka täytyy korjata uudelleen.

Lisätietoja Salesforce-työkaluista, jotka auttavat sinua palautumaan, on kohdassa Salesforce Tools for Resiliency.

Tekniikan kontekstissa lajittelu sisältää luokkien ja vakavuustasojen kohdistamisen ongelmiin ja tukipyyntöihin. Riippumatta siitä, miten hyvin ratkaisusi on suunniteltu, käyttäjätukussa ilmenee ongelmia ja pyyntöjä. Nämä ongelmat voivat johtua riittämättömästä koulutus- tai muutostenhallinnasta, käyttöliittymän/UX:n aukkoista, odottamattomista loppukäyttäjien toimintatavoista ja kiireellisistä järjestelmäongelmista, joita valvonta tai hälytys ei havaitse.

Tuki- ja toimintatiimien täytyy voida tutkia käyttäjien tukikyselyitä tehokkaasti ja diagnosoida ne nopeasti. Ongelmien lajitteleminen vähemmän vakavien huolenaiheiden suodattamiseksi ja kriittisten järjestelmätapahtumien havaitseminen nopeasti on tärkeä osaaminen näille tiimeille. Huono lajittelu hidastaa kaikkia käyttäjien tukitasoja, pidentää kriittisiä vahinkotapahtumia ja lisää asiakkaidesi ja yrityksesi häiriöiden riskiä.

Vaikka et välttämättä osallistu päivittäisiin toimintoihin tai tukeen, arkkitehtinä sinun vastuullasi on auttaa varmistamaan, että tukitiimisi ja toimintatiimisi voivat lajitella ongelmia tehokkaasti kaikissa ratkaisuissa, joita luot Salesforce-alustalla.

Jos haluat sallia tiimien lajitella ongelmia tehokkaasti Salesforce-ratkaisuissasi:

• Varmista, että tukitiimeillä on käyttöoikeus hyödyllisiin tietoihin.
  • Dokumentoi järjestelmäsi ja designkuviosi. Ratkaisusi lukemisen ja yhdenmukaisuuden varmistaminen on tärkeää, jotta tukihenkilöstösi ymmärtävät järjestelmän, jota he ovat vastuussa tuesta. Tarkasta dokumentaatiostasi, miten tiimit löytävät tietoja ongelmien tai vahinkotapahtumien priorisoinnista järjestelmän eri osissa. Varmista myös, että tiimit voivat nopeasti saada teknisiä tietoja toipumisen taktiikoista vaikutusalueen perusteella. Tarjoa asiaankuuluvia vianmääritysohjeita yleisimpiin Agentforce, kuten Aiheiden luokittelu ja Toiminnon valinta, jotka voivat auttaa tiimejä lajittelemaan käyttöoikeuksiin tai kokoonpanoon liittyviä ongelmia nopeasti.
  • Suunnittele virheenkorjaus mielessäsi. Tukitiimien ja organisaation pääkäyttäjien täytyy ottaa virheenkorjaus ja diagnostiikka käyttöön lajitellakseen käyttäjien ongelmat oikein eri ympäristöissä. Esimerkkejä virheenkorjausystävällisistä kuvioista ovat ne, jotka sisältävät lokien ja mukautettujen virheviestien suorituspolkuihin koko järjestelmässä. Ota tukitiimit käyttöön yleisimmille Agentforce työkaluilla, kuten tapahtumalokeilla ja Agent Builderin perustelunäkymällä.
  • Tunnista vahinkotapahtumien pk-yritykset ja sidosryhmät. Luo luettelo merkityksellisistä pk-yrityksistä tai sidosryhmistä, joiden tulisi voida tukea vahinkotapahtuman jälkeistä toipumista ja joiden tulisi osallistua vahinkotapahtuman jälkeiseen analyysiin.
  • Käsittele viestejä harkiten. Varmista kunkin ratkaisun lähetyksen laatu tukitiimeille tai toimintotiimeille osana julkaisua. Tarjoa koulutus tukihenkilöstöille, jotta he voivat tutustua asiaankuuluvaan järjestelmäarkkitehtuuriin ja esimerkkivahinkotapahtumien vastauskokeisiin. Mieti vahinkotapahtumien jälkeisiä viestejä, mukaan lukien miten tiimisi tulisi dokumentoida tietoja, joita lokit tai tapausten muistiinpanot eivät kerää, sekä miten vahinkotapahtumien vastaajat voivat osallistua juuritason syyn tutkimiseen tai suorittaa käyttäjien hyväksymistestejä korjauksiin.
• Jos sinua kuullaan, pidä toipuminen tärkeimpänä huolenaiheena kaikille.
  • Vastaa nopeasti. Vastaa nopeasti kaikkiin vastaanottamiisi käyttäjien tukipyyntöihin, valvonta-ilmoituksiin ja hälytyksiin.
  • Auta tunnistamaan oireet ongelmista. Tarkasta, onko järjestelmätapahtumassa todellinen ongelma, joka täytyy korjata. Yritä tunnistaa komponentit, jotka sisältävät todelliset ongelmat. Auta varmistamaan, että sovittuja palautustaktiikoita noudatetaan, jotta järjestelmä pääsee nopeasti vahinkotapahtuman tilasta.
• Jos Agentforce tukevat kriittisiä käyttötarkoituksia, varmista, että käytössä on toimivia ja asiaankuuluvia ratkaisuja, jotka voidaan ottaa käyttöön lyhyellä varoitusajalla tarpeettoman käytön toimenpiteenä. Voit esimerkiksi siirtyä käsittelyyn manuaalisesti tai ohjata asiaankuuluviin dokumentaatioihin manuaalista tarkastusta varten.

Vahinkotapahtumien vastauksen kuviot ja vastakuviot näyttävät, miltä tehokkaan lajittelun arkkitehtuuri näyttää Salesforce-ratkaisussa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmäsi osa-alueet, jotka täytyy korjata uudelleen.

Lisätietoja Salesforce-työkaluista, jotka auttavat lajittelussa, on kohdassa Salesforce Tools for Resiliency.

Monitoring ja hälytys ovat laajalti käytettyjä termejä sivuston luotettavuuden suunnittelussa. Järjestelmän kestävyyteen liittyen valvonta arvioi jatkuvasti järjestelmän tämänhetkistä tilaa ja hälytys automaattisesti ilmoittaa sidosryhmille järjestelmän tilaan liittyvistä mahdollisista huolenaiheista. Tehokas valvonta ja hälytys on tärkeä osa järjestelmäsi koon ja kasvun irrottamista tukihenkilöstösi koosta ja kasvusta.

Salesforce tarjoaa useita sisäänrakennettuja ominaisuuksia, joilla voit valvoa järjestelmäsi toimintatapoja. Salesforce tarjoaa myös reaaliaikaisen tapahtumien valvonnan lisäosana tai osana Salesforce Shieldia. Kaikissa Salesforce-ratkaisuissa valvontaan ja hälytykseen tarkoitetut rakenteet tarjoavat:

• Vahinkotapahtumien automatisoidun vastauksen ominaisuudet
• Asiaankuuluvia tietoja oikeille käyttäjille oikeaan aikaan
• Selkeyttää historiallisten näkymien ja trendien analyysien tietoja

Salesforce-ratkaisusi tehokkaan valvonnan ja hälytysten suunnitteleminen:

• Tee automatisoinnista prioriteetti. Vaikka käyttäjien ilmoittaminen kriittisistä tilojen muutoksista on tärkeä osa järjestelmien vakauden ja toiminnan ylläpitämistä, ihanteellisessa arkkitehtuurissa järjestelmä korjaa ongelmat itse, kun se on mahdollista, ja lähettää hälytyksiä vain kiireellisille ongelmille, joita ei voi korjata. Automatisointi voi tehdä hälytyksistä ja raportoinnista hyödyllisempiä ilman itseratkaisuja.
  • Aloita siitä, mitä Salesforce tarjoaa jo. Salesforce Platform tarjoaa sinulle asiaankuuluvia lokeja ja API-rajapintoja valvoaksesi ratkaisusi toimintoja hallintarajoitusten osalta. Lisäksi alusta lähettää hälytyksiä hallintorajoitusten rikkomuksista ja vastaavista ongelmista. Käytä näitä lokeja ja hälytyksiä pohjana tutkiaksesi tapoja, joilla voit automatisoida järjestelmän itserakennuksen, vahinkotapahtumien raportoinnin ja hälytykset. Saatat esimerkiksi ottaa käyttöön automatisoinnin, joka valvoo lokia ja suorittaa sitten palautustoiminnon, kun tietyntyyppinen tapahtuma kirjataan lokiin.
  • Luokittele muutokset järjestelmätilaan ennustettavilla tavoilla. Luo tarkkoja ja hyödyllisiä luokkia tärkeimmille tiloille, joita haluat valvoa ja raportoida. Tutustu näihin kategorioihin, jotka määrität hallitaksesi sovelluksen komponenttien tiloja. Ota käyttöön API-pohjainen ajattelutapa koskien tilojen muutostietojen käsittelyä. Yhtenäiset viestiformaatit ja tilakategoriat yksinkertaistavat automatisointia, raportointia ja hälytyksiä.
  • Sovitaksesi automatisointilogiikkasi yhteen järjestelmäsi muiden osien kanssa. Jos olet laatinut automatisoinnin asianmukaisen virheiden käsittelyn, voit laajentaa näitä kuvioita siten, että luokittelet tilojen muutokset ja reagoit niihin automaattisesti. Voit automatisoida uudelleenyritystoiminnot tilojen muutoksille, joita pidetään palautettavissa olevina. Automatisoi käyttäjille tarkoitetut hälytykset, jos tilojen muutoksia pidetään kriittisinä tai kohtalokkaina.
• Vältä aiheuttamasta melua. Kun käyttäjät näkevät liian monta hälytystä, varsinkin hälytyksiä, jotka eivät vaadi mitään, he alkavat yleensä poistaa kaikki hälytykset käytöstä tai jättää ne huomiotta. Tämä skenaario heikentää kaikkia pyrkimyksiä luoda hyödyllisiä hälytyksiä. Harkitse seuraavia toimia ymmärtääksesi paremmin, kuka vastaanottaa hälytyksiä, mikä käynnistää ne ja milloin ne käynnistetään.
  • Laadi sidosryhmien karttoja. Tunnista ja luokittele ensin sidosryhmäsi varmistaaksesi, että järjestelmäsi lähettää oikeat hälytykset oikeille sidosryhmille oikeaan aikaan.
  • Reititä viestejä käyttäjien käyttöoikeuksien perusteella. Lähetä hälytyksiä vain vastaanottajille, joilla on kyky ja oikeus vastata. Yrityskäyttäjät voivat hyötyä hälytyksistä ongelmista, joita he voivat korjata korjaamalla ongelmia tietueissa, joiden käyttöoikeus heillä on. Jos ongelma vaatii teknistä vastausta, hälytykset tulisi ohjata tukihenkilöstöön.
  • Tee odotetusta vastauksesta selkeä. Lähetä hälytyksiä vain tilanteissa, jotka vaativat ihmisten toimia. Rakenna viestejä osoittaaksesi selkeästi vastaanottajalta odotetun toiminnon. Jos lähetät hälytyksen sidosryhmälle näkyvyyden varmistamiseksi eikä heidän tarvitse tehdä mitään, anna se selkeästi hänen vastaanottamansa viestin versiossa.
  • Tee hälytyksistä ajankohtaisia ja relevantteja. Hälytykset, jotka lähetetään vastauksena tapahtuneisiin virheisiin ja jotka on vielä korjattava, eivät ole yhtä hyödyllisiä kuin mahdollisen virheen hälytykset. Ihannetapauksessa tukihenkilöstö saa hälytyksen heti, kun järjestelmässä ilmenee ongelmallisia oloja, mikä tarjoaa mahdollisuuden ongelmien luokitteluun ennen kuin ne voivat vaikuttaa negatiivisesti liiketoimintaan.

Kuvioiden ja antikuvioiden luettelo näyttää, miltä tehokkaan valvonnan ja hälytyksen arkkitehtuuri näyttää Salesforce-ratkaisussa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmäsi osa-alueet, jotka täytyy korjata uudelleen.

Lisätietoja Salesforcen valvonta- ja hälytystyökaluista on kohdassa Salesforce Tools for Resiliency.

Tämä taulukko näyttää valikoiman kuvioita, joita haluat etsiä tai rakentaa organisaatiossasi, sekä vasta-kuviot, joita haluat välttyä tai kohdistaa korjattavaksi.

✨ Tutustu vahinkotapahtumien vastauksen muihin kuvioihin kohdasta Pattern & Anti-Pattern Explorer.

Jatkuvuussuunnitelma on avain liiketoiminnan kestävyyteen, joka keskittyy siihen, miten ihmiset ja järjestelmät voivat toimia suunnittelemattoman tapahtuman aiheuttamien ongelmien avulla. Liiketoiminnan jatkuvuussuunnitelmat (BCP) käyttävät ihmisiin keskittynyttä näkymää siitä, miten prosesseja voidaan pitää liikkeellä kriisin aikana. Jatkuvuussuunnitelman tekniset näkökohdat sisältyvät BCP:n katastrofien palautuksen osioihin. Lisätietoja on kohdassa Teknologian jatkuvuus.

Ilman asianmukaisia jatkuvuussuunnitelmia organisaatiosi voi nyt tietää, miten toimia kriisin tai järjestelmän käyttökatkoksen aikana — eikä siis toimia ollenkaan. Epäonnistunut jatkuvuussuunnitelma voi vaikuttaa katastrofaalisesti asiakkaisiin, sidosryhmiin ja yritykseen. Haitallisten tapahtumien jälkeen jokainen hetki, joka kulkee ilman tärkeiden prosessien ylläpitoa tai palauttamista, voi aiheuttaa taloudellisia vahinkoja, maineen vaurioita, työntekijöiden turvallisuutta ja jopa säännösten noudattamista.

Voit parantaa järjestelmien jatkuvuussuunnitelmaa keskittämällä työsi kolmeen osa-alueeseen: liiketoiminnan jatkuvuuden määrittämiseen Salesforcelle, teknologian jatkuvuuden suunnittelemiseen ja varmuuskopio- ja palautusominaisuuksien rakentamiseen.

Yhtiölläsi saattaa olla jo BCP käytössä. Jos se toimii, varmista, että se sisältää Salesforcen. Jos yritykselläsi ei ole BCP-prosessia, luo sidosryhmäsi kanssa sellainen, joka kattaa Salesforce-organisaatiosi.

Salesforcen uskotaan usein olevan asiakastietojen ja tärkeiden liiketoimintaprosessien totuuden lähde monissa liiketoimintaosastoissa. Näin ollen Salesforcen rooli BCP:ssä saattaa erota muista järjestelmistä. Salesforce on todennäköisesti mukana useissa tärkeissä palautusalueissa.

Asianmukaisen liiketoiminnan jatkuvuussuunnitelman luominen Salesforce-järjestelmille:

• Selkeytä palautuksen prioriteetit. Kuten yleisessä lähestymistavassa vahinkotapahtumiin reagointiin, palautumisen täytyy olla järjestelmien ensimmäinen prioriteetti kriisitilanteissa. Monet liiketoimintaan kriittiset palvelut toimivat Salesforcessa ja sen kanssa. Sinun täytyy auttaa sidosryhmiä tunnistamaan oikea prioriteetti eri liiketoimintatoimintojen ja -ominaisuuksien palauttamiseksi. Yleinen kehys voisi olla:
  • Stabiloi tärkeä liiketoimintainfrastruktuuri.
  • Stabiloi asiakaspalvelut.
  • Stabiloi työntekijöiden ja kumppanien palvelut.
• Tilin ekosysteemillesi BCP-järjestelmissäsi. Salesforce ei ole ainoa organisaatiosi järjestelmä. Varmista, että tunnistat Salesforceen integroitavat järjestelmät, AppExchange asennetut ratkaisut ja muut järjestelmät, jotka muodostavat yhteyden Salesforcen dataan tai prosesseihin. Jos toimituskykysi riippuu toimittajista, kysy heiltä heidän jatkuvuussuunnitelmistaan. Arvioi heidän kykyjään ja suunnittele, miten järjestelmäsi pysyvät käytettävissä.
• Integroi BCP-huolenaiheet testausstrategiaasi. Luo BCP:lle testisuunnitelmia ja suorita ne. On erityisen tärkeää testata prosesseihin tai ihmisiin liittyviä BCP-järjestelmäsi osa-alueita, joita ei usein huomioida. Lisää asiaankuuluvia kohteita BCP:stäsi yleiseen ALM-testistrategiaasi. Luo ja noudata huoltoaikataulua tarkastaaksesi testit ja varmistaaksesi, että suunnitelmasi pysyy ajan tasalla.

Jatkuvuussuunnitelman kuviot ja vastakuviot näyttävät, miltä oikea ja huono jatkuvuussuunnitelma näyttää Salesforce-ratkaisussa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmässäsi uudelleenrakennettavat kohteet.

Lisätietoja liiketoiminnan jatkuvuuden määrittämiseen tarkoitetuista Salesforce-työkaluista on kohdassa Salesforce Tools for Resiliency.

Teknologian jatkuvuuden tavoite on varmistaa, että järjestelmän komponenttien ongelmat eivät estä yritystä ylläpitämästä tärkeitä toimintoja. Salesforce priorisoi palveluidemme ylläpitoa mahdollisimman tehokkaasti ja tarjoaa läpinäkyviä tietoja ongelmista. Näet reaaliaikaisia tietoja Salesforcen järjestelmän suorituskyvystä ja ongelmista osoitteesta trust.salesforce.com. Kun rakennat Salesforcen arkkitehtuurin, ratkaisusi hyötyvät sivuston luotettavuudesta, tietoturvasta ja suorituskyvystä, joita Salesforce tarjoaa koko alustalle.

Salesforce-ratkaisusi yleinen jatkuvuus ylittää kuitenkin Salesforcen tarjoamat sisäänrakennetut palvelut. Arkkitehtuurin näkökulmasta Salesforcen teknologian jatkuvuuden suunnittelun täytyy alkaa kysymällä ja vastaamalla kysymyksiin siitä, miten Salesforce soveltuu suurempaan yritysympäristöön. Millaisia järjestelmiä Salesforce integroituu? Miten ulkoiset järjestelmät riippuvat Salesforcen prosesseista tai tiedoista? Mitkä prosessit tai toiminnot ovat riippuvaisia AppExchange Salesforce-organisaatioissasi? Käyttävätkö käyttäjäsi Salesforcea kolmannen osapuolen henkilöllisyydentarjousten tai SSO-kertakirjautumisen kautta?

Teknologian jatkuvuuden parantaminen Salesforce-järjestelmissä:

• Arvioi infrastruktuurisi. Yleisin teknologian käyttökatkosten tai ongelmien korjausstrategia on luoda tarpeettomia palveluita tai järjestelmiä, joihin voit luopua vahinkotapahtuman aikana. Salesforcessa meillä on tarkoituksella tarpeeton arkkitehtuuri, mikä tarkoittaa, että säilytämme kopioita asiakkaidemme järjestelmistä ja palveluista eri fyysisissä sijainneissa. Käytämme useita katastrofien palautustekniikoita, mukaan lukien sivuston vaihtaminen, jotta voimme ohjata käyttäjien liikennettä datakeskuksesta toiseen tarvittaessa. Kysy itseltäsi seuraavat kysymykset tunnistaaksesi, missä saatat tarvita tarkoituksellista tarpeettomuutta.
  • Mitä tapahtuu [X]-palvelun palvelun keskeytyksen aikana? Voimmeko siirtyä kyseisestä palvelusta toiseen?
  • Kuinka kauan [X] kestää palauttaa? Miten se vaikuttaa asiakkaisiimme? Miten se vaikuttaa kumppaneihimme? Miten se vaikuttaa sisäisiin tiimeihin?
  • Entä varmuuskopioinnit ja niiden yleisyys? Voivatko varmuuskopiot tarjota liiketoiminnan tukemiseen tarvittavat tiedot?
  • Onko meillä riippuvuuksia toimittajista? Mitkä ovat heidän BCP-suunnitelmansa?
• Anna toiminta-tuki. Toiminnallinen tuki auttaa tiimejä palaamaan ja toimimaan mahdollisimman nopeasti. Mieti, miten järjestelmäsi voi käsitellä kapasiteettivaatimusten merkittävää kasvua ja odottamattomien muutosten kysyntää, mukaan lukien toimialanlaajuiset, alueelliset tai globaalit muutokset. Varmista, että BCP:si huomioi lisäresurssit tai keskeytysmenetelmät, joita Site Reliability Engineering (SRE) tai tukitiimit saattavat tarvita vahinkotapahtumiin reagoimiseksi tehokkaasti. Toiminnallista tukea koskeviin kysymyksiin sisältyy:
  • Onko teknisillä tiimeillämme työskentelyn jatkamiseen tarvittavat työkalut, jos ne keskeytyvät? Olemmeko simuloineet käyttökatkoksen vahvistaaksemme suunnitelmat tai tunnistaaksemme aukot?
  • Jos katastrofi tapahtuu tietyllä alueella, onko meillä kattavuussuunnitelmia kyseiselle alueelle?
  • Ovatko asiakkaamme globaaleja? Toimivatko ne 24/7?
  • Onko meillä asianmukainen valvonta ja hälytys ilmoittaaksemme asianmukaisille henkilöille virheistä?
• Automaatioi ja testaa palautustaktiikkaasi. Kun ongelma on korjattu, tarkasta missä se tapahtui ja miten se korjattiin. Jos mahdollista, automatisoi palautustaktiikkasi ja säädä prosessiin liittyviä ongelmia korjauksen perusteella. Monet yritykset ajoittavat vahinkotapahtumien simulointeja tietyille palveluille testatakseen järjestelmän kestävyyttä. Esimerkki voisi olla järjestelmänvalvojan tilin simulointi, joka on lukittu tai joka on vaarantunut, tai käyttökatkoksen tai ongelman simulointi AppExchange. Lisätietoja on kohdassa Vahinkotapahtumien vastaus).Kysymyksiä siitä, miten testaus ja automatisointi voivat auttaa sinua palauttamaan palvelut nopeammin:
  • Kuinka usein ajoitamme ja suorittamme vahinkotapahtumien simulointeja?
  • Tiedämmekö, kuinka kauan palveluiden palauttaminen vakaaan tilaan kestää?
  • Onko meillä vakaita toimitusprosesseja?
  • Tiedämmekö, miten voit automatisoida vahinkotapahtuman ja palautuksen?

Käsittele vahinkotapahtuman jälkeisistä tarkastuksistasi saatuja kohteita muiden kehityskohteiden tavoin. Lisää ne suunnittelujärjestelmiisi, jotta voit priorisoida ja työstää niitä.

Jatkuvuussuunnitelman kuviot ja vastakuviot näyttävät, miltä oikea ja huono teknologian jatkuvuussuunnitelma näyttää Salesforce-ratkaisussa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmässäsi uudelleenrakennettavat kohteet.

Lisätietoja Salesforcen työkaluista teknologian jatkuvuuden suunnitteluun on kohdassa Salesforce Tools for Resiliency.

Varmuuskopioitujen kopioiden palauttaminen datasta tai metadatasta voi auttaa palauttamaan organisaatiosi edelliseen tunnettuun vakaaseen tilaan. Se voi myös tarjota failover-järjestelmän katastrofaalisen järjestelmävirheen tai palvelukatkoksen aikana. Datan ja metadatan varmuuskopioiminen säännöllisesti ja salattujen varmuuskopioitujen kopioiden säilyttäminen turvallisessa sijainnissa parantaa arkkitehtuuria entisestään.

Ilman varmuuskopio- ja palautusstrategioita et voi palauttaa tuotantotietojesi ja metadatan puhtaita versioita, kun ne on korruptoitu vahingossa, kun virheet vahingossa siirtyvät tuotantoympäristöön tai kun suurten tietosisältöjen aikana tapahtuva virhe korruptoi tuotantotiedot. Mikä tahansa näistä skenaarioista voi johtaa siihen, että liiketoiminnan kannalta kriittinen tuotantotietosi korruptoituu tai jopa katoaa pysyvästi. Varmuuskopio- ja palautusteknologian määrittäminen tarjoaa jatkuvuuden suunnittelun lisäksi useita etuja, mukaan lukien suurten datamäärien vähentämiseen tarvittavien strategioiden avulla ja noudattamalla vaatimustenmukaisuuteen liittyviä säilytyskäytäntöjä.

Salesforce-ratkaisusi varmuuskopio- ja palautustrategioiden jatkuvuuden varmistaminen:

• Aloita. Hyvä varmuuskopio- ja palautustrategia on ensin strategian luominen. Yksinkertainen varmuuskopiointi organisaatiosi kaikesta datasta ja metadatasta öisin voi säästää yrityksesi menettämästä tärkeitä tietoja tai toimintoja katastrofin aikana.
• Rajoita varmuuskopioiden käyttöä. Järjestelmän pääkäyttäjät ovat ainoat käyttäjät, joilla tulisi olla pääsy tietojesi varmuuskopioihin. Tämä käyttöoikeusrajoitus estää yrityskäyttäjiä tarkastelemasta varmuuskopiossa olevia tietueita, joita heillä ei olisi oikeutta tarkastella organisaatiossasi.
• Testaa palautusprosessisi säännöllisesti. Riippumatta toteutamastasi varmuuskopio- ja palautusstrategiasta, testaa palautusprosessisi säännöllisesti Full- tai Partial Copy -sandboxissa varmistaaksesi, että se toimii oikein tarvittaessa.
• Tasauta varmuuskopio- ja palautustrategiaasi datan arkistointistrategiasi kanssa. Määritä, mitä varmuuskopioissasi tai arkistoissasi tulisi tapahtua, kun tietueita arkistoidaan tai poistetaan järjestelmästäsi. Katso Datan määrä).

Saatat tarvita tarkempaa varmuuskopiointistrategiaa, jos datasi määrä on niin suuri, ettei täyttä varmuuskopiota tarvitse suorittaa ennen kuin seuraava varmuuskopio käynnistyy. Saatat myös tarvita tarkempaa varmuuskopiointistrategiaa, jos organisaatiosi tiedot muuttuvat niin usein, että päivitykset ovat tärkeitä organisaatiollesi.

Varmuuskopiointistrategiasi tarkentaminen:

• Rajoita varmuuskopiosi tiettyihin objekteihin. Tämä strategia sisältää eri objektien tietueiden varmuuskopioinnin eri aikaväleillä. Pidä mielessäsi, että aliobjektit täytyy varmuuskopioida samalla aikavälillä kuin niiden ylätason objektit, jotta tiedot pysyvät yhdenmukaisina.
• Aikalaatikkojen osittaiset varmuuskopiot. Tämä strategia sisältää täysien varmuuskopioiden (kaikkien tietojen ja metadatan) ja osittaisten varmuuskopioiden (vain edellisen varmuuskopion jälkeen lisättyjen tai muutettujen metadatan ja tietueiden) erottamisen.

*Älä koskaan lopeta täysien varmuuskopioiden suorittamista. On tärkeää huomata, että sinun ei tulisi koskaan poistaa täyttä varmuuskopiointia kokonaan, vaikka datamäärät johtaisivat pitkään suoritusaikoihin. Suunnittele suurille datamääreille säännölliset, mutta harvoin täydet varmuuskopiot (esimerkiksi viikoittaiset varmuuskopiot). Suunnittele myös useammin osittaisia tai objektikohtaisia varmuuskopioita (esimerkiksi öisiä varmuuskopioita tai varmuuskopioita X tunnin välein). Tämä lähestymistapa sallii sinun rakentaa uudelleen täydellisimmän ja tarkimman datajoukon, jota voit käyttää palautusprosesseissasi.*

Jatkuvuussuunnitelman kuviot ja antikuviot näyttävät, miltä oikea ja huono varmuuskopiointi- ja palautusominaisuudet näyttävät Salesforce-ratkaisussa. Käytä niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmässäsi uudelleenrakennettavat kohteet.

Salesforce Backup and Recover on integroidun Salesforce-ratkaisun, joka sisältää Oman palautuksen omasta hankinnasta, joka suojaa tärkeitä tietoja häviöltä tai korruptiolta. Korkean turvallisuuden, helppokäyttöisen ja aina käytettävissä olevan ratkaisumme varmistaa liiketoiminnan jatkuvuuden ja datan keston sekä yksinkertaistaa vaatimustenmukaisuutta.

Käytä Salesforcen varmuuskopiointia ja palautusta välttyäksesi datan katoamiselta, palauttaaksesi itsesi nopeasti datavahinkotapahtumista ja yksinkertaistaaksesi datan hallintastrategiaasi. Voit luoda arvokkaille ja säänneltyille tiedoille varmuuskopiointikäytäntöjä ja palauttaa ne muutamalla napsautuksella.

Automatisoidut päivittäiset varmuuskopiot suojaavat kaikki organisaatiosi tärkeät tiedot, mukaan lukien metadata, sandboxit, hallittujen pakettien tiedot, liitetiedostot ja paljon muuta. Suorita varmuuskopioita tarvittaessa noudattaaksesi palautuspisteen tavoitteitasi (RPO) ja suojellaksesi käyttöönottojasi. Varmuuskopiot ovat aina käytettävissä ja niitä säilytetään turvallisesti ja yhteensopivasti. Jatkuva tietoturva on käytettävissä myös entistä luottamuksellisemmille tiedoille tai transaktioille, mikä mahdollistaa nopeasti muuttuvien kriittisten tietojen nopeamman palautuksen.

Havaitse epätavallisia datatoimintoja, datan katoamista ja korruptiota suoraan sähköpostiisi lähetetyillä ennakoivilla hälytyksillä. Vastaanota reaaliaikaisia hälytyksiä tunnistaaksesi tilastollisia poikkeavuuksia tai luodaksesi sääntöjä, jotka ilmoittavat sinulle epätavallisista datatoiminnoista, mikä auttaa sinua havaitsemaan vahinkotapahtumia nopeammin kuin koskaan ennen.

Salesforcen Varmuuskopio ja palautus nopeuttaa palautusta tarjoamalla tarkkoja tietoja muutoksista, mikä mahdollistaa asiaankuuluvien tietojen nopean tunnistamisen ja palauttamisen. Työkalut, kuten visuaaliset kaaviot, korostavat tarpeettomat muutokset, kun taas helppokäyttöiset palautusominaisuudet palauttavat asiaankuuluvat objektit, kentät ja tietueet tarkasti.

Työkalumme sallivat sinun käyttää varmuuskopioita analyyseihin, auditointeihin ja vaatimustenmukaisuuteen, tarjoavat haettavissa olevaa historiallista dataa, avoimen haun ominaisuuksia menneiden tietojen näkyvyydelle ja vientitoimintoja ulkoisille analyyseille tai varastoille. Tämä muuttaa varmuuskopioiden käyttötarkoitusta ilman lisää Salesforce API -rajapintoja.

Varmuuskopio ja palautus tarjoaa yhden konsolin kaikkien varmuuskopioiden, hallinnan, toimintojen ja vaatimustenmukaisuuden yhdistämiseen. Tämä konsoli sallii sinun käyttää, hallita, mukauttaa ja valvoa kaikkien tuotanto-organisaatioidesi ja sandboxidesi varmuuskopioita. Sen avulla voit myös suorittaa datan aiheiden pyyntöjä varmistaaksesi, että varmuuskopiodataa noudatetaan, ja hallita varmuuskopioaikataulujen, yleisyyden ja säilytyskäytäntöjen mukauttamista täysin.

• Vähennä datavahinkotapahtumien vaikutuksia. Salesforcen Varmuuskopio ja palautus auttaa vähentämään datavahinkotapahtumia, kuten tietoverkkohyökkäyksiä tai haitallisia sisäisiä tai ulkoisia toimintoja, sallimalla käyttäjien palauttaa asiaankuuluvat tietueet ennen vahinkotapahtumaa. Varmuuskopioi ja palauta -ominaisuuden vientiominaisuudet takaavat käyttäjien tärkeiden tietojen jatkuvan käytön ja käytettävyyden.
• ** Estä pysyvä datan katoaminen**. Henkilökohtaiset virheet ovat edelleen tärkein tietojen katoamisen syy. Backup and& Recover tarjoaa tarkan ja nopean ratkaisun näihin virheisiin.
• Täyttää datan vaatimustenmukaisuuden ja lakisääteiset vaatimukset helpommin. Salesforcen Varmuuskopio ja palautus tukee jaettua vastuumallia ja ottaa käyttöön itsepalvelutoiminnot varmuuskopioidesi datan joukkopoistamiselle tai tietojen korjaamiselle.

Lisätietoja Salesforcen varmuuskopiointi- ja palautustyökaluista on kohdassa Salesforce Tools for Resiliency.

Tämä taulukko näyttää valikoiman kuvioita, joita haluat etsiä tai rakentaa organisaatiossasi, sekä vasta-kuviot, joita haluat välttyä tai kohdistaa korjattavaksi.

✨ Tutustu jatkuvuuden suunnitteluun liittyviin kuvioihin kohdasta Pattern & Anti-Pattern Explorer.

Auta meitä pitämään Salesforce Well-Architected ajan tasalla sinulle. Tee kysely saadaksesi palautetta tästä sisällöstä ja kerro meille, mitä haluat nähdä seuraavaksi.