Havaittavuus ja valvonta - Kuviot
Lue lisää Hyvin rakennettu operaattorien huippuosaaminen → Huomautettavuus ja valvonta
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sovellusalusta | Event Monitoring | ✅ Event Monitoring on suunniteltu alustavaan arkkitehtuuriin, joka kerää korrelaatiotunnuksia, jotka seuraavat pyyntöjä asynkronisten käsittelyketjujen ja ulkoisten integraatioiden kautta |
| Sovellusalusta | Event Monitoring | ✅ Havaittavuus-infrastruktuuri sisällytetään alustavaan sprinttiin sen sijaan, että sitä mukautettaisiin, kun tuotantotapahtumat osoittautuvat mahdottomiksi diagnosoida |
| Sovellusalusta | Integraatio | ✅ Integraation tarkastuspisteet on asetettu tarkoituksella, jotta pyyntöjen seuranta on mahdollista järjestelmän rajojen välillä |
| Sovellusalusta | Sovellusalustan tapahtumat | ✅ Sovellusalustan tapahtumien tietosisällöt on rakennettu liiketoiminnan näkyvyyttä varten transaktioiden merkintöillä ja kontekstilla |
| Sovellusalusta | Mukautettu kirjaaminen lokiin | ✅ Mukautettu lokihallintajärjestelmä kaappaa erilliset tapahtumat ja sisältää kaikki asiayhteystiedot, mukaan lukien käyttäjän henkilöllisyyden, aikaleiman, keston ja lopputuloksen |
| Sovellusalusta | Tilastot | ✅ Tilastot keräävät numeerisia mittoja ajan myötä paljastamalla trendejä, mukaan lukien API-kulutussuhteet, Apex CPU -aikojen jakaumat ja erätöiden onnistumissuhteet |
| Sovellusalusta | Jakattu jäljitys | ✅ Seurat yhdistävät synkronoituja API-kutsuja ei-synkronoituihin käsittelyketjuihin, sovellusalustan tapahtumat tilaajien suorituksiin ja integraatiopyynnöt ulkoisiin järjestelmän vastauksiin |
| Sovellusalusta | Havainnollisuus | ✅ Observatability sallii operaattoreiden vastata järjestelmän toimintatapaan liittyviin kysymyksiin ottamatta käyttöön uutta instrumentaatiota jokaiselle tutkimukselle |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Sovellusalusta | Event Monitoring | ⚡️ Ratkaisu käynnistyy ilman mukautettua lokeja, mikä vaatii suuren refaktoroinnin kuusi kuukautta myöhemmin, kun tuotantotapahtumat osoittautuvat mahdottomiksi yksittäisten sovellusalustan lokien avulla |
| Sovellusalusta | Event Monitoring | ⚡️ Havaittavuus on mukautettu olemassa olevaan ratkaisuun, joka vaatii instrumenttien muutoksia, jotka vaikuttavat useimpiin komponentteihin ja jotka aiheuttavat virheitä toiminnan parantamisen aikana |
| Sovellusalusta | Integraatio | ⚡️ Integrointivirheitä tapahtuu, mutta pyyntöjen polkuja ei voida seurata järjestelmän rajojen yli ilman kattavaa telemetriaa |
| Sovellusalusta | Sovellusalustan tapahtumat | ⚡️ Sovellusalustan tapahtumien tietosisällöillä ei ole toiminnallista kontekstia, joten vahinkotapahtumien tutkiminen riippuu useiden järjestelmien hausta |
| Sovellusalusta | Mukautettu kirjaaminen lokiin | ⚡️ Lokit keräävät riittämättömän asiayhteyden. Tutkimukset vaativat ongelmien toistamista lisätietojen keräämiseksi |
| Sovellusalusta | Havainnollisuus | ⚡️ Esimääritetyt mittaristot eivät voi vastata odottamattomiin kysymyksiin järjestelmän toimintatavoista tuotantoympäristössä |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sovellusalusta | Event Monitoring | ✅ Event Monitoring on käytössä tuotantoympäristöissä, jotka sieppaavat API-käytön, sisäänkirjautumistoimintoja, Apex, SOQL-kyselyitä, Visualforce, Lightning ja raporttien suorituksia |
| Sovellusalusta | Event Monitoring | ✅ Tapahtumalokitiedostot viedään tunneittain keskitetylle lokisovellusalustalle, mikä sallii historian analyysin natiivisovellusalustan säilyttämisen lisäksi |
| Sovellusalusta | Event Monitoring | ✅ Ulkoinen lokien aggregointi sallii korrelaation muiden järjestelmien yritystelemetrian kanssa transaktioiden lopputulosten seuraamista varten |
| Sovellusalusta | Event Monitoring | ✅ Tapahtumalokitiedostot säilytetään vaatimustenmukaisuuden raportointia ja pitkäaikaisten trendien analyysiä koskevien lakisääteisten vaatimusten mukaisesti |
| Sovellusalusta | Proactive Monitoring | ✅ Proactive Monitoring -kynnysarvot on säädetty tarkoituksella organisaatiokohtaisen normaalialueen perusteella oletusarvoisten arvojen sijaan |
| Sovellusalusta | Proactive Monitoring | ✅ Proactive Monitoring havaitsevat API-rajoitusten pikavalinnat, samanaikaiset Apex, SOQL-rivien rajoitusmenetelmät ja rivien lukkojen ristiriidat ennen käyttäjien näkemiä vahinkotapahtumia |
| Sovellusalusta | Proactive Monitoring | ✅ Mukautetut kynnysarvot luovat interaktiivisia signaaleja, joihin tiimit Trust ja toimivat luodakseen jatkuvan parantamisen hyviä syklejä |
| Sovellusalusta | Skaalikeskus | ✅ Scale Centerin perustasot määritetään ratkaisun vakauttamisen aikana ja ne tarkastetaan uudelleen kunkin suurimman julkaisun jälkeen |
| Sovellusalusta | Skaalikeskus | ✅ Skaalauskeskus paljastaa, mitkä operaatiot kuluttavat eniten resursseja, mitkä transaktiot lähestyvät aikakatkaisun kynnysarvoja ja mihin optimointiinvestoinnit vaikuttavat eniten |
| Sovellusalusta | Skaalikeskus | ✅ Maksutapahtumien kesto kasvaa perustason kehotteen tutkimuksesta, joka paljasti viimeisimmän käyttöönoton aikana käyttöönotetut tahattomat N+1-kyselykuviot |
| Sovellusalusta | Määritysten kirjausketju | ✅ Määritysten kirjausketju seuraa kokoonpanon muutoksia, mukaan lukien käyttöoikeuksien muutokset, metadatan käyttöönotot ja suojausasetusten päivitykset, ja säilyttää ne enintään 180 päivää |
| Sovellusalusta | Määritysten kirjausketju | ✅ Määritysten kirjausketju -merkinnät viedään säilytettäväksi 180 päivän kuluttua, kun vaatimustenmukaisuus tai sopimusten vaatimukset vaativat pidempiä historiallisia ajanjaksoja |
| Sovellusalusta | Shield | ✅ Kenttien kirjausketju on valinnaisesti käytössä kentille, jotka sisältävät luottamuksellisia tietoja, muutoshistoriaa vaativia säänneltyjä tietoja tai kriittisiä liiketoimintatietoja |
| Sovellusalusta | Shield | ✅ Kenttien kirjausketju tarjoaa enintään 10 vuoden säilytyksen kentille, joissa historiallisten arvojen ymmärtäminen auttaa toiminnoissa ja vaatimustenmukaisuuden raportoinnissa |
| Sovellusalusta | Terveystarkastus | ✅ Terveystarkastukset ajoitetaan neljännesvuosittain ja löydöt korjataan ympäristöriskien priorisoinnin perusteella |
| Sovellusalusta | Terveystarkastus | ✅ Terveystarkastuksen tulokset tarkastetaan tarkoituksellisesti passiivisen hyväksynnän sijaan. Korvaavat ohjaimet tai erilaiset riskitoleranssit on dokumentoitu |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Sovellusalusta | Event Monitoring | ⚡️ Event Monitoring on käytössä, mutta lokeja ei viedä koskaan, mikä rajoittaa tutkimukset natiiviseen säilytysaikaan ja estää historiallisten trendien analysoinnin |
| Sovellusalusta | Event Monitoring | ⚡️ Tapahtumalokitiedostot säilyvät sovellusalustan tallennustilassa. Ulkoista aggregointia ei toteuteta, mikä estää kapasiteetin pitkän aikavälin suunnittelun |
| Sovellusalusta | Proactive Monitoring | ⚡️ Proactive Monitoring käyttää oletusarvoisia kynnysarvoja, jotka ovat liian luottamuksellisia tai liian rentoja, mikä luo meluisia hälytyksiä, joita tiimit oppivat ohittamaan |
| Sovellusalusta | Proactive Monitoring | ⚡️ Hälytyshälytys tuhoaa Trustin valvontajärjestelmään; tiimit eivät enää vastaa kelvollisiin signaaleihin |
| Sovellusalusta | Skaalikeskus | ⚡️ Skaalauskeskus on käytössä, mutta sitä ei ole koskaan tarkastettu ennakoivasti. Suorituskyky heikkenee hitaasti, kunnes käyttäjät valittavat kuukausien asteittaisen heikentymisen jälkeen |
| Sovellusalusta | Skaalikeskus | ⚡️ Suorituskykytilastoilla ei ole perustason kontekstia. On epäselvää, ovatko 3 sekunnin transaktioajat tyypillisiä, parantavia vai heikentäviä |
| Sovellusalusta | Määritysten kirjausketju | ⚡️ Määritysten kirjausketjua ei viedä. Säilytyksen rajoitukset estävät tietoturvatutkimukset tai vaatimustenmukaisuuden vahvistuksen 180 päivän jälkeen |
| Sovellusalusta | Shield | ⚡️ Kenttien kirjausketju on otettu käyttöön kaikille kentille valikoiden sijaan, mikä luo tallennuskustannuksia ilman vastaavaa yhteensopivuusarvoa |
| Sovellusalusta | Terveystarkastus | ⚡️ Terveystarkastuksen tuloksia ei tarkasteta koskaan. Suojauskokoonpanot heikkenevät perussuosituksista ilman, että niitä hyväksytään tarkoituksella |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sovellusalusta | Käyttäjäkulut | ✅ Kriittiset käyttäjäkulut määritetään liiketoiminnan vaikutusten ja valvotun lopputuloksen perusteella onnistumissuhteille, valmistumisajalle, hylkäyspisteille ja virhesuhteille |
| Sovellusalusta | Käyttäjäkulut | ✅ Kriittisiin kulkuihin sisältyvät tuottoa tuottavat toiminnot (tilausten lähetys, sopimusten suorittaminen, mahdollisuuksien sulkeminen), raskaat toiminnot (sisäänkirjautuminen, haku, tietueiden luominen) ja vaatimat toiminnot (suostumusten kerääminen, tietojen aiheiden oikeuksien täyttäminen) |
| Sovellusalusta | Käyttäjäkulut | ✅ Kulut on instrumentoitu maksutapahtumien merkinnöillä, jotka osoittavat alkamis-, valmistumis-, hylkäämis- ja epäonnistumisvaiheita jokaisessa merkittävissä vaiheessa |
| Sovellusalusta | Käyttäjäkulut | ✅ Tilausten lähetyskulku, joka on instrumentoitu sovellusalustan tapahtumilla kussakin vaiheessa (korin vahvistus, inventaarion tarkastus, maksun käsittely, täydennyksen käynnistin) ja joka näyttää onnistumissuhteen vaiheittain |
| Sovellusalusta | Käyttäjäkulut | ✅ Kulun tason valvonta paljastaa ongelmia, joita ei näytetä komponenttitason valvonnassa, koska virheet voivat tapahtua missä tahansa siirtymisvaiheessa |
| Sovellusalusta | Käyttäjäkulut | ✅ Hälytykset käynnistyvät, kun kulun onnistumissuhteet laskevat hyväksyttävien kynnysarvojen alle tai kesto ylittää viiveen tavoitteet |
| Sovellusalusta | Integraatio | ✅ Integraation terveysvalvonta havaitsee ulkoiset järjestelmävirheet, verkko-ongelmat, todennusongelmat ja nopeusrajoitusmenetelmät ennen kuin se siirtyy käyttäjille tarkoitettuihin virheisiin |
| Sovellusalusta | Integraatio | ✅ Onnistumisasteen valvontahälytykset, kun kriittisten synkronoitujen integraatioiden arvo on alle 99 % |
| Sovellusalusta | Integraatio | ✅ Virheiden jakauman valvontahälytykset, kun uusia virhetyyppejä ilmestyy, joita ei ollut olemassa perustasoissa |
| Sovellusalusta | Integraatio | ✅ Viiveen prosenttiluvun valvonta (p95) -hälytykset, kun synkronoitujen käyttäjäkohtaisten puheluiden kesto on yli 3 sekuntia |
| Sovellusalusta | Integraatio | ✅ Läpimäärän valvontahälytykset, kun yli 80 % tunnetusta tiedonsiirtorajoituksesta tai palvelutasosopimuksen kynnysarvosta |
| Sovellusalusta | Integraatio | ✅ Virranvaihteen tilan valvontahälytykset, kun jokin piiri avautuu osoittamaan ulkoisen järjestelmän heikentymistä |
| Sovellusalusta | Integraatio | ✅ Uudelleenkäynnistyksen tarkastuksen hälytykset, kun jatkuva uudelleenkäynnistyksen suhde ylittää 5 %, mikä osoittaa luotettavuusongelmia |
| Sovellusalusta | Integraatio | ✅ Integraation telemetrian reitit keskitetyille valvontaalustoille, jotka sallivat järjestelmän rajojen välisen korrelaation |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Sovellusalusta | Käyttäjäkulut | ⚡️ Komponentteja valvotaan itsenäisesti osoittaakseen, että ne toimivat oikein, kun taas 12 % käyttäjistä hylkää kriittiset kulut ilman syytä. |
| Sovellusalusta | Käyttäjäkulut | ⚡️ Komponenttien kunnon mittaristot näytetään vihreänä, kun taas käyttäjät eivät voi suorittaa kriittisiä työnkulkuja, jotka paljastavat valvontaarkkitehtuurin virheen |
| Sovellusalusta | Käyttäjäkulut | ⚡️ Käyttäjämatka, joka koskee useita Apex, kulkuja, sovellusalustan tapahtumia ja ulkoisia integraatioita, ei ole näkyvissä loppuun asti |
| Sovellusalusta | Käyttäjäkulut | ⚡️ Kriittisille liiketoimintamatkoille puuttuu välineistö; onnistumissuhteita ja hylkäämispisteitä ei tunneta |
| Sovellusalusta | Integraatio | ⚡️ Integraatioiden virheet havaitaan vasta, kun ne on laskettu käyttäjäkohtaisiin virheisiin, eikä ennakoivasti |
| Sovellusalusta | Integraatio | ⚡️ Integraation telemetria pysyy erillään yksittäisissä järjestelmissä, mikä estää korrelaation ja juurisyyn analysoinnin yli rajojen |
| Sovellusalusta | Integraatio | ⚡️ Valvoa alaisten oireiden hälytyksiä vahingon aiheuttamisen jälkeen sen sijaan, että paljastuisi juurisyistä aikaisin |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sovellusalusta | SLI:t | ✅ Saatavuus SLI:t mittaavat, kuinka monta prosenttia kriittisistä kuluista suoritetaan onnistuneesti käyttäjän näkökulmasta (tarkastetun tuloksen saaminen, ei vain 200 tilakoodin saaminen) |
| Sovellusalusta | SLI:t | ✅ Latency SLI:t mittaavat kestoa operaatioiden suorittamiseen p50:ssä (median), p90:ssä (90-prosenttiili pois lukien poikkeavat arvot), p95:ssä (95-prosenttiili pois lukien pahimmat poikkeavat arvot) ja p99:ssä (99-prosenttiili, joka näyttää pahimmat tapaukset) |
| Sovellusalusta | SLI:t | ✅ Viiveiden tavoitteet vaihtelevat operaation kriittisyyden ja käyttäjän odotusten mukaan (500ms:n haku tuntuu välittömältä, sama kirjoitusviive tuntuu hitaalta) |
| Sovellusalusta | SLI:t | ✅ Läpimäärän SLI:t mittaavat onnistuneiden operaatioiden määrää per aikayksikkö ja paljastavat kapasiteetin käyttöasteen ja kasvustrendit |
| Sovellusalusta | SLI:t | ✅ Läpimeno ja viive paljastavat, säilyttääkö järjestelmä suorituskyvyn kuormituksen lisääntyessä vai heikkenee tilavuuden kasvaessa |
| Sovellusalusta | SLI:t | ✅ Virhesuhteiden SLI:t erottavat virhetyypit toisistaan (käyttäjävirheet, kuten vahvistusvirheet, ja järjestelmävirheet, kuten hallintarajoitusten poikkeukset) |
| Sovellusalusta | SLO:t | ✅ Palvelutasotavoitteet määritetään määrittämällä hyväksyttävät SLI-kynnysarvot liiketoimintavaatimusten perusteella ennen arkkitehtuurikuvioiden valitsemista |
| Sovellusalusta | SLO:t | ✅ Liiketoimintavaatimus ”Myyntiedustajien täytyy nähdä mahdollisuuksien päivitykset 5 sekunnin kuluessa” käynnistää SLO-kertakirjautumisen ”Mahdollisuuden lisätietosivun lataukset suoritetaan 3 sekunnin kuluessa p95-arvona”, joka määrittää arkkitehtuurin päätökset |
| Sovellusalusta | SLO:t | ✅ SLO:t syntyvät liiketoimintavaatimuksista ja vaikuttavat arkkitehtonisiin päätöksiin sen sijaan, että ne määritettäisiin järjestelmän tällä hetkellä saavuttamien tulosten perusteella |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Sovellusalusta | SLI:t | ⚡️ Saatavuus mitataan teknisestä näkökulmasta (200 tilakoodia) käyttäjän näkökulmasta (tarkastetun tuloksen saaminen) |
| Sovellusalusta | SLI:t | ⚡️ Viive mitataan vain median perusteella ymmärtämättä pahinta käyttäjäkokemusta p95- tai p99-prosenttiileillä |
| Sovellusalusta | SLI:t | ⚡️ Virhesuhde SLI:t eivät tunnista käyttäjien virheitä ja järjestelmävirheitä, joten ne peittävät eri ongelmia, jotka vaativat eri ratkaisuja |
| Sovellusalusta | SLO:t | ⚡️ Arkkitehtuuri rakennetaan ensin, sitten SLO määritetään “mitä tahansa tällä hetkellä”, mikä johtaa 12 sekunnin sivujen latausten hyväksymiseen, koska järjestelmän suunnittelu ei koskaan huomioinut käyttäjien vaatimuksia |
| Sovellusalusta | SLO:t | ⚡️ SLO:t perustuvat arkkitehtuuriin eikä liiketoimintaan, ja asettavat tavoitteita sen perusteella, mitä järjestelmä saavuttaa, eikä mitä käyttäjät tarvitsevat |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sovellusalusta | Hälytys | ✅ Vakavuusluokitus reitittää kriittiset vahinkotapahtumat (tuotanto ei ole käytettävissä, datan vioittumisriski, tietoturva vaarantui) välittömästi sivujen vastaanottajille |
| Sovellusalusta | Hälytys | ✅ Korkean vakavuuden vahinkotapahtumat (huono suorituskyky, osittaiset käyttökatkokset) luovat ilmoituksia, joita pyydetään tutkimaan toimistoaikojen sisällä |
| Sovellusalusta | Hälytys | ✅ Varoitukset (kynnysarvot lähestyvät, kokoonpanovirrat) luovat päivittäisiä digest-ilmoituksia ennakoivaa korjausta varten |
| Sovellusalusta | Hälytys | ✅ Hälytyksen konteksti sisältää asiaankuuluvien käyttäjien määrän, virheviestit, pinoseurat, viimeisimmät käyttöönotot, asiaankuuluvat hälytykset ja linkit asiaankuuluviin mittaristoihin |
| Sovellusalusta | Hälytys | ✅ Muotoiltu konteksti lyhentää keskiarvoista hyväksymisaikaa ottamalla käyttöön välitön vakavuusarviointi ja tutkiminen keräämättä perustietoja |
| Sovellusalusta | Hälytys | ✅ Hälytysten ryhmittely estää hälytyksen myrskyjä, joissa satoja asiaan liittyviä hälytyksiä käynnistetään yhden perustana olevan ongelman varalta |
| Sovellusalusta | Hälytys | ✅ Integraation virhe käynnistää yhden hälytyksen, joka on ryhmitetty integraation päätepisteen mukaan ja joka näyttää 156 epäonnistunutta pyyntöä edellisen 5 minuutin ajalta viivekaaviolla, virheiden jakaumalla ja mittariston linkillä |
| Sovellusalusta | Hälytys | ✅ Hälytysten estäminen estää tunnettuja ohittavia ehtoja luomasta hälytyksiä odotettujen huoltojaksojen tai automaattisten korjausjaksojen aikana |
| Sovellusalusta | Hälytys | ✅ Hälytykset estetään ajoitetun huollon aikana, käyttöönoton ensimmäisten minuutin aikana, kun välimuisti on lämmin, ja lyhyiden väliaikaisten virheiden aikana, kun uudelleenyrityslogiikka onnistuu |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Sovellusalusta | Hälytys | ⚡️ Kaikki hälytykset reititetään samaan kanavaan ilman vakavuusluokittelua. Kriittisiä vahinkotapahtumia ei eroteta rutiinivaroituksista |
| Sovellusalusta | Hälytys | ⚡️ Hälytykset eivät sisällä diagnostista asiayhteyttä. Puheluna toimivien insinöörien täytyy kerätä perustietoja erillisten kyselyiden kautta ennen vakavuuden arviointia |
| Sovellusalusta | Hälytys | ⚡️ Integraation virhe luo 156 yksittäistä hälytystä 5 minuutin kuluessa, jolloin puhelinjärjestelmän puhelin on täynnä, jokainen hälytys on identtinen, paitsi aikaleima |
| Sovellusalusta | Hälytys | ⚡️ Hälytyksen myrskyt estävät vastaajia tunnistamasta yksittäisiä ongelmia sadoista niihin liittyvistä oireista |
| Sovellusalusta | Hälytys | ⚡️ Hälytykset syttyvät tunnettujen huoltojaksojen aikana ja väliaikaiset olosuhteet aiheuttavat melua, joka heikentää Trustin valvontaa |
| Sovellusalusta | Hälytys | ⚡️ Hälytyksen väsymys meluista vääriä positiivisia aiheuttaa, että tiimit ohittavat ilmoitukset, jotka heikentävät vastauksen tehokkuutta |