Saatavuus- ja suorituskykykuviot
Lue lisää Hyvin rakennettu luotettavuus → korkea saatavuusarkkitehtuuri
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Liiketoiminnan vaikutusanalyysi | ✅ SLO-kertakirjautumiset, jotka on määritetty liiketoimintakyvyn mukaan (esimerkiksi “Mahdollisuuden sulkemiskulku: 99,9 % saatavuus, p95-lähtö alle 2 sekuntia”) teknisen komponentin sijaan |
| Kulun käyttäjädokumentaatio | ✅ Jokaisella kriittisellä käyttäjäkululla on mitattavissa oleva SLO, joka kattaa käytettävyyden, viiveen, läpimäärän, virhesuhteen ja palautusajan, jotka on sidottu todelliseen käyttäjäkokemukseen |
| Arkkitehtuurin päätöstyötietueet | ✅ Käytettävyystavoitteet, jotka perustuvat liiketoiminnan käyttökatkoksen vaikutusanalyysiin ja dokumentoituihin perusteisiin (esimerkiksi sisäinen eräraportti 99 % vs. tuottokriittinen tilausten käsittely 99,95 %) |
| SLO-määritykset | ✅ Realistiset tavoitteet, jotka ottavat huomioon arkkitehtuurin monimutkaisuuden (99 % = sovellusalustan vakiotoiminnot, 99,5 % = peruskäyttöisyys ja aktiivinen valvonta, 99,9 % = usean alueen tietoisuus ja automatisoitu vahinkotapahtuma, 99,95 % = aktiiviset kuviot ja kaaoksen testaaminen, 99,99 % = usean organisaation arkkitehtuuri) |
| Sovellusalustan dokumentaatio | ✅ Ratkaisun SLO:t ovat vähemmän tiukkoja kuin sovellusalustan palvelutasosopimukset (esimerkiksi sovellusalustan 99,9 % palvelutasosopimus → ratkaisun 99,5 % palvelutasosopimus) tarjoavat virhebudjetin sovellustason virheille |
| Valvontakokoonpano | ✅ Palvelutason osoittimet (SLI) voidaan mitata objektiivisesti sovellusalustan instrumentaation avulla: Trust.salesforce.com-käyttöaika, Experience Cloud -analyysi, Event Monitoring API -vastausaika, AsyncApex-töiden suorittaminen |
| Käyttäjäkokemuksen tilastot | ✅ SLO-kertakirjautumiset vastaavat käyttäjien kaikkia matkoja (esimerkiksi “Tapauksen lähetyskulku: kaikki 5 vaihetta suoritetaan 8 sekunnissa p95-käyttäjille”) ei yksittäisten API-käyttöaika |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Arkkitehtuurin dokumentaatio | ⚡️ “Järjestelmän tulisi olla nopea ja luotettava” (ei mitattavissa, ei vaikuta arkkitehtuurin päätöksiin) |
| SLO-määritykset | ⚡️ “Kaikki tarvitsee 99,999% toiminta-aikaa” (peruuttamattomat kustannukset, jotka ohittavat liiketoiminnan kriittisyyden eroavaisuudet tuotto-toimintojen ja sisäisten pääkäyttäjien työkalujen välillä) |
| Valvontastrategia | ⚡️ Infrastruktuurin CPU-valvonta ensisijaisena SLI:nä (sovellusalustan tilastoarkkitehtien ei voida suorittaa toimintoja, eivätkä ne vastaa käyttäjille tarkoitettua käyttökokemusta) |
| Sovellusalustan kapasiteetin suunnittelu | ⚡️ Ratkaisun SLO vastaa sovellusalustan palvelutasosopimusta tarkalleen 99,9 %:illa (ei virhebudjettia sovellustason ongelmille, integraatiovirheille tai suunnitellulle huollolle) |
| SLO-dokumentaatio | ⚡️ SLO-kertakirjautumiset, jotka on määritetty teknisen komponentin sijaan käyttäjäkohtaisen liiketoimintakyvyn perusteella (komponenttien saatavuus on tarpeen, mutta ei riittävä käyttäjäkokemuksen luotettavuuden kannalta) |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Alueellinen käyttöönottostrategia | ✅ Yksi alue -käyttöönotto ja sovellusalustan hallitsema Hyperforce (useat saatavuusvyöhykkeet, automaattinen infrastruktuurin vahinkotapahtuma) tarjoaa 99,9 % SLO:n useimmille ratkaisuille |
| Usean organisaation arkkitehtuuri | ✅ Usean organisaation kuviot vain, kun liiketoiminta vaatii sovellusalustan ominaisuuksien lisäksi taattua RPO/RTO-kertakirjautumista, sääntelyä koskevaa maantieteellistä datan eristämistä tai täydellistä alueellista riippumattomuutta (aktiivinen/passiivinen tai aktiivinen/aktiivinen datan synkronoinnin kanssa) |
| Datan replikointi | ✅ Muutosdatan datan taltiointi kriittisille tiedoille (lähes reaaliaikainen RPO, minuutit), sovellusalustan tapahtumat lähes reaaliaikaisille liiketoimintatapahtumille, ajoitettu Bulk API 2.0 -nouto viitetiedoille (24 tunnin RPO) |
| Sovellusalustan terveysvalvonta | ✅ Trust.salesforce.com-tilojen ilmoitusten ja instanssikohtaisten tilojen API-rajapintojen tila, joka sallii ennakoivan vastauksen vahinkotapahtumiin, huoltojaksojen ja suorituskykyvaikutuksiin |
| Dynaaminen lataustenhallinta | ✅ Ratkaisut reagoivat sovellusalustan kuntoon vähentämällä ei-kriittisten erien käsittelyä heikentymisen aikana, lykkäämällä taustatöitä huoltojaksojen aikana |
| Skaalikeskuksen käyttö | ✅ Scale Centerin viikoittainen tarkastus tunnistaa pitkäaikaiset transaktiot ja toiminnot, jotka kuluttavat suhteettomia resursseja, mikä mahdollistaa arkkitehtuurin korjaamisen ennen kuin käyttäjä vaikuttaa |
| Virheiden havaitsemisen kerrokset | ✅ Monitasoinen tunnistus: sovellusalustan virheet tilan API:n kautta, integraation virheet aikakatkaisun valvonnan kautta, sovellusten virheet poikkeusten kirjaamisen kautta, suorituskyvyn heikkeneminen viive-prosenttiilien kautta, kapasiteettihälytykset Proactive Monitoringin kautta |
| Hälytysten kynnysarvot | ✅ Hälytykset käynnistyvät virhesuhdekuvioissa (esimerkiksi 5 API-aikakatkaisua 60 sekunnissa) tai jatkuvassa heikentymisessä, eivät erillisissä virheissä, jotka ovat normaaleja jaetuissa järjestelmissä |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Usean organisaation suunnittelu | ⚡️ Usean organisaation arkkitehtuuri on toteutettu vain tapauksille ilman asiakirjoitettuja liiketoimintavaatimuksia, jotka oikeuttavat datan synkronoinnin, käyttäjien provisioinnin ja käyttöönoton koordinoinnin monimutkaisuuden |
| Sovellusalustan terveysvalvonta | ⚡️ Ohita Trust.salesforce.com-tilojen ilmoitukset, etsi huoltojaksot, kun käyttäjät raportoivat virheitä (reaktiivinen ennakoivan vastauksen sijaan) |
| Virheiden havaitseminen | ⚡️ Hälytys jokaiselle yksittäiselle virheelle nopeudesta riippumatta (luo hälytyksen väsymyksen, joka peittää kriittiset signaalit); yksi API-aikakatkaisu käynnistää sivuutuksen (ylireagointi normaaliin jaettuun järjestelmän toimintatapaan) |
| Datan replikointi | ⚡️ Ei integraatiokohtaista valvontaa, vain kun käyttäjät raportoivat estettyjä toimintoja (ulkoisen järjestelmän kunnon näkyvyys puuttuu) |
| Tarpeeton strategia | ⚡️ Synkronoitu callout ulkoiseen rikastuspalveluun ilman aikakatkaisua tai varakäyttöä (käyttäjä estetään, kun ulkoinen palvelu on hidas tai ei käytettävissä) |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Real User Monitoring (RUM) | ✅ Todellinen käyttäjän viive, joka mitataan Experience Cloud -analyysillä tai mukautetulla instrumentaatiolla, joka vastaa todellisia verkkoehtoja, laitteen suorituskykyä ja maantieteellistä jakaumaa |
| Synteettinen valvonta | ✅ Automatisoidut transaktiot useista sijainneista, jotka vahvistavat saatavuuden ja suorituskyvyn ennen kuin käyttäjät raportoivat ongelmia (esimerkiksi tilauksen lähetys 15 minuutin välein 3 alueesta) |
| Transaktioiden seuranta | ✅ Monivaiheiset toiminnot, joilla on ajoitus per vaihe, joka tunnistaa pullonkaulakohdat (esimerkiksi vaiheen 3 osoitteen vahvistuksen callout-kutsu aiheuttaa 70 % viiveestä) |
| Kyselyiden optimointi | ✅ Indeksoituja suodattimia käyttävät valikoivat kyselyt, suhdekyselyt, jotka vähentävät matkoja, kyselyiden optimointi huomioi tuotanto-asteikon datamääriä (toimintatapa muuttuu dramaattisesti yli 10 miljoonan tietueen kanssa) |
| Sovellusalustan välimuistin käyttöaste | ✅ Istunto- tai organisaation välimuistiin tallennetut osiot, jotka tarjoavat usein käytettyjä viitetietoja, jotka täytetään valmiiksi onnistuneiden toimintojen aikana ja jotka tarjoavat vanhentuneita, mutta käytettävissä olevia tietoja, kun reaaliaikainen API ei ole käytettävissä |
| Aikakatkaisukokoonpano | ✅ Käyttäjäkohtaiset synkronoidut callout-kutsuja 5-10 sekuntia (vastaava käyttöliittymä), taustasynkronoimattomat callout-kutsuja 30-60 sekuntia (muuttuva ulkoinen suorituskyky), eräkäsittely 120 sekuntia (ei käyttäjää odottamassa); budjetti yhteensä useille callout-kutsuille per transaktio |
| Integraation viiveen valvonta | ✅ p50/p95/p99 viiveen prosenttiluvut per SLO-integraatio per päätepiste; viiveen poikkeamat (vastausajat nousevat ylöspäin) osoittavat, että kapasiteetti on täytetty ennen täydellistä epäonnistumista |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Valvontastrategia | ⚡️ Valvoa vain infrastruktuurin tilastoja (palvelimen suorituskyky, verkon kaistanleveys) ilman kulkujen mittoja käyttäjille (tilastot eivät vastaa todellista käyttäjäkokemusta) |
| Välimuistiin tallennustrategia | ⚡️ Ei sovellusalustan välimuistin käyttöä usein käytetyille viitetiedoille (saman datan toistuvat kyselyt, jotka kasvattavat viiveitä ja kuluttavat SOQL-rajoituksia) |
| Aikakatkaisukokoonpano | ⚡️ Synkronoitu kulun kutsu, jossa on 120 sekunnin aikakatkaisu, jolloin käyttäjä tarkkailee lataavaa spinnaamista 2 minuutin ajan (tarvitsee käyttää 5–10 sekunnin aikakatkaisua varaosalla) |
| Suorituskyvyn testaaminen | ⚡️ Pienimuotoinen testaus pienellä datamäärällä (kyselyiden optimoinnin toimintatapa muuttuu dramaattisesti yli 10 miljoonassa tietueessa, mikä tekee pienimuotoisista tuloksista harhaanjohtavia) |
| Integraation rakenne | ⚡️ Ei transaktiotason seurantaa monivaiheisille työnkuluille (painikkeen päävaihe ei ole näkyvissä aggregaattitilastoissa) |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Vaakasuorat skaalauskuviot | ✅ Työkuorma jaettu useille resursseille: bulkkaaminen käsittelee useita tietueita per transaktio, ei-synkronoitu käsittely jakaa töitä ajan myötä, datan osiointi jakaa kuormituksen rajojen välillä |
| Eräkäsittelykokoonpano | ✅ Optimaalinen erän koon tasapainottama läpimeno- ja hallintarajoitukset (2 000 tietuetta per Apex, 200 tietuetta per käynnistimen kutsu, 25 pyyntöä per Composite API -kutsu) |
| API-suhteen hallinta | ✅ Integraation erä- ja välimuistiin tallentaminen vähentää API-kulutusta, valvoo 24 tunnin API-allokaatiota Edition-version mukaan, kapasiteettisuunnitelma lisää lisenssejä tai rajoittaa kasvuja ennen niiden käyttöä |
| Samanaikainen suoritus | ✅ Osioitujen tietojen rinnakkaiset erätyöt (5 aluekokoonpanon erää, jotka suoritetaan samanaikaisesti), sovellusalustan tapahtumien tilaajat käsittelevät viestiketjuja samanaikaisesti |
| Jonon syvyyden valvonta | ✅ Asynkronoitujen integraatioiden jonojen syvyyden trendit osoittavat, että käsittely jää jäljelle tuotantokurssille, joka vaatii kapasiteetin kasvun tai tuoton optimoinnin |
| Määrän poikkeavuuden havaitseminen | ✅ Maksutapahtumien määrät, jotka ovat merkittävästi odotettua korkeammalla tai odotettua pienemmällä, saattavat tarkoittaa, että prosesseja ei tarvitse tutkia ja rajoittaa |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Eräkäsittely | ⚡️ Käsittele kaikki tietueet järjestyksessä, kun datamäärä vaatii osioituja rinnakkaisia toimintoja (päivämääräkohtainen, tietuetyyppinen tai omistajaan perustuva osiointi sallii samanaikaisen käsittelyn) |
| API-kulutus | ⚡️ Integraatiokuvio lisää 25 % API-kulutusta ilman kapasiteettisuunnitelmaa (Käyttäjille vaikuttavat ”API-rajoitus ylitetty” -virheet yhtäkkiä) |
| Jonojen valvonta | ⚡️ Ei asynkronisen integraation jonon syvyyden valvontaa (käsittely jää tuotantokurssin jälkeen ilman näkyvyyttä) |
| Hallintarajoitusten hallinta | ⚡️ Synkronoidut operaatiot, jotka käsittelevät suuria määriä ja saavuttavat pinon koon tai CPU-aikojen rajoitukset (täytyy siirtyä ei-synkronoituun käsittelyyn, jolla on omat rajoitukset) |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Ominaisuuksien kriittisyyshierarkia | ✅ Määritetyt tasot: Kriittinen (tuotto/vastaavuus, ei koskaan heikennetty), Tärkeä (ydintoimintokulut, heikennetty vain suurten vahinkotapahtumien aikana), Tuki (parannettu käyttökokemus, poistettu käytöstä integroinnin epäonnistumisen aikana), Valinnainen (hyvä käytettävä, poistettu käytöstä raskaan kuormituksen aikana) |
| Viestiketjun katkaisijan toteutus | ✅ Viestiketjujen tilat (Suljettu = normaali, Avoin = epäonnistuu välittömästi kynnysarvon jälkeen, Puoli-avaus = palautustesti); Sovellusalustan välimuisti tallentaa tilan, Sovellusalustan tapahtumat -ominaisuuden kuulutuksen muutokset; avautuu peräkkäisten epäonnistumisten jälkeen (esimerkiksi 10 epäonnistumista) |
| Uudelleenyrityslogiikka | ✅ Exponential backoff väliaikaisille virheille (1s, 2s, 4s, 8s, cap 30-60s); yritä uudelleen verkko aikakatkaisuja ja 5xx virheitä backoff, yritä uudelleen 429 nopeusrajoituksia uudelleen Kokeile uudelleen -Jälkeen-otsakkeen jälkeen; älä koskaan yritä uudelleen asiakkaan 4xx-virheitä tai hallintarajoitusvirheitä samassa transaktiossa |
| Varastostrategiat | ✅ Vaihtoehtoiset tietolähteet (sovellusalustan välimuisti, kun reaaliaikainen API ei ole käytettävissä), oletusarvoinen toimintatapa (vakiosäännöt, kun personalisointipalvelu ei ole käytettävissä), manuaalinen prosessi (pääkäyttäjän käyttöliittymä piilotetuille transaktioille), jono uudelleenyrityksille (Sovellusalustan tapahtumat 72 tunnin toistolla) |
| Virheiden käsittelyarkkitehtuuri | ✅ Epäonnistua nopeasti (vahvista syötettyjä tietoja syötettäessä), epäonnistua huolellisesti (prosessi 197 200 tietueesta, kun 3 vahvistus epäonnistuu), epäonnistua informatiivisesti (loki transaktion tunnuksella, käyttäjäkonteksti, pinoseuranta), epäonnistua turvallisesti (julkaisun osittaiset transaktiot, älä koskaan paljasta sisäisiä tietoja käyttäjille) |
| Palautuksen automatisointi | ✅ Sovellusalustan valvonta käynnistää automatisoidun palautuksen: ei-synkronoidut uudelleenyritysmekanismit, epäonnistuneen käsittelyn kuolleiden kirjaimien jonot, itse parantavat työnkulut, jotka mahdollistavat nopean palautuksen ilman manuaalista interventiota |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Integraation sidonnaisuus | ⚡️ Tilauksen lähetys epäonnistuu kokonaan, kun ulkoisen osoitteen vahvistuspalvelu ei ole käytössä (kriittinen kulku estetty tukitoiminnolla; sen tulisi heikentyä kätevästi manuaalisella tarkastuksella) |
| Viestiketjustrategia | ⚡️ Ulkoisessa callout-kutsussa ei ole katkaisua, jolloin jokainen transaktio odottaa 120 sekuntia aikakatkaisua, kun ulkoinen järjestelmä ei ole käytössä (yksi epäonnistunut integraatio vaikuttaa kaikkiin käyttäjiin) |
| Uudelleenyrityslogiikka | ⚡️ Kokeile uudelleen Apex CPU -rajoituksen ylittävää virhettä välittömästi samassa transaktiokontekstissa (epäonnistuu uudelleen; tulisi asettaa uudelleen jonoon asynkronointitoiminto, jolla on omat rajoitukset) |
| Uudelleenyrityslogiikka | ⚡️ Yritä uudelleen määrittämättömästi, kunnes onnistut (loputon silmukan riski, transaktio ei koskaan suorita loppuun; sen tulisi kattaa uudelleenyritysten enimmäismäärä) |
| Virheiden käsittely | ⚡️ Kokeile kaapattaa lohkoja nielemällä poikkeus ilman lokeja (virhe ei ole näkyvissä operaattoreille, jotka estävät diagnoosin ja korjauksen) |
| Virheiden käsittely | ⚡️ Näytä pinojen seuranta loppukäyttäjälle Lightning (suojausriskit paljastavat toteutuksen lisätiedot, heikko käyttökokemus) |
| Varapolustrategia | ⚡️ Verojen laskentapalvelu ei voi estää kaikkia tilausten lähetyksiä (kriittinen ominaisuus, jolla ei ole varastoa; pitäisi olla jono manuaaliseen käsittelyyn tai käyttää oletusarvoisia hintoja) |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Terveysmallinnus | ✅ Kokonaishuollon tila: Palvelun kunto (transaktioiden onnistumissuhde >99.5% vihreä, 98-99.5% keltainen, <98% punainen), Integraation kunto (kaikki vastaavat vihreä, heikentynyt keltainen, katkaisija avoinna punainen), Datan kunto (synkronoitu virta vihreä, takana keltainen, vanhentunut/epäonnistunut punainen), Kapasiteetin kunto (<70% vihreä, 70-85% keltainen, >85% punainen) |
| Tapahtumien valvonta | ✅ EventLogFile-objektit, joiden toimitus reititetään ulkoiseen SIEM-järjestelmään 24h/1h säilyttämiseksi natiivisten säilytyrajoitusten ulkopuolella; sieppaa API-kutsut, sivunäkymät, raporttien viennit, sisäänkirjautumistoiminnot, Apex |
| Proactive Monitoring -hälytykset | ✅ Jatkuvat arviointipinta-alat API-pyyntöjen rajoitukset (75 % kynnysarvon käynnistimen tutkimus), samanaikaiset Apex, SOQL-rivien rajoitukset, tallennustilan kulutuksen trendit |
| Integraation terveysmittaristo | ✅ Per-integraation tilastot: virhesuhde (<1% tavoite), viive p50/p95/p99 kertauloskirjautumisella, aikakatkaisuhde (<0,1% tavoite), katkaisijan tila, asynkronisen jonon syvyys; rakenteelliset lokit pyynnön tunnuksella, päätepisteellä, vastauskoodilla, kestolla |
| Interaktiivinen hälytyksen rakenne | ✅ Jokainen hälytys määrittää, kuka vastaa, mitä he tarkastavat ja miten he korjaavat ongelmansa. Se sisältää kynnysarvon ylitetty, tämänhetkisen arvon, viimeaikaisen trendin, mittariston linkin, suorituskirjan linkin; vakavuus täsmätään kiireellisyyteen (CRITICAL-sivut, kun he kutsuvat käyttäjien vaikutusta, VAROITUS-sähköpostit, kun he ovat huolissaan trendeistä) |
| Poikkeavuuksien havaitseminen | ✅ Määräpoikkeamat (300 % tyypillisestä kuormituksesta), virhesuhteen poikkeamat (2 % vs. 0,5 % tyypillisiä, vaikka ne olisivat alle 5 % kynnysarvon), viive-vedon (asteittainen nouseva trendi), toimintatavan poikkeamat (tavalliset sisäänkirjautumiskuviot, erätyöt aikataulun ulkopuolella); käytetään tutkinnan ohjaamiseen, eikä käynnistä välitöntä eskalointia |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Tapahtumien valvonta | ⚡️ Event Monitoring käytössä, mutta sitä ei koskaan viety (natiivi säilytys ei riitä trendien analyysiä varten, historialliset tiedot menetetään) |
| Hälytyksen rakenne | ⚡️ Hälytysviesti “Virhe tapahtui” ilman asiayhteyttä, kynnysarvoa tai vastaustoimintoa (luo hälytyksen väsymyksen, operaattorit eivät voi lajitella tehokkaasti) |
| Hälytyksen vakavuus | ⚡️ Käsittele kaikkia poikkeuksia kriittisinä hälytyksi (korkea väärien positiivisten suhteiden määrä aiheuttaa hälytyksen väsymyksen, jolloin kriittiset hälytykset ohitetaan) |
| Terveysvalvonta | ⚡️ Ei aggregaattista terveysmallia, operaattorit ovat täynnä yksittäisiä teknisiä tilastoja, joilta puuttuu järjestelmien välisiä kuvioita |
| Integraation valvonta | ⚡️ Ei integrointikohtaisia virhesuhteita, viiveitä tai katkaisijan tilan seurantaa (integrointivirheet havaittiin uudelleen käyttäjäraporteissa) |
| Kapasiteetin valvonta | ⚡️ Ei Proactive Monitoring- tai Scale Center -tarkistusta (resurssien intensiivisten transaktioiden luotettavuusriskejä ei havaita ennen kuin ne vaikuttavat tuotantoympäristöön) |
Katso inline-esimerkkejä ja yksityiskohtaisia ohjeita kohdasta Reliability Pillar tai selaa Patterns and Anti-Patterns -tutkintaohjelmaa.