Kunnskapstest for NAIS i produksjon

NAIS leverer runtime og integrerte byggeklosser gjennom kontrakter på høyere nivå. Skymiljøer bruker Kubernetes på GKE og administrerte tjenester under.

Plattformbygging sentraliserer felles kompleksitet uten å flytte produkt- og domeneansvaret fra teamet.

Naisjob representerer endelig arbeid og støtter planlagt kjøring; Application representerer en langlivet workload.

Readiness styrer om instansen er et tilgjengelig trafikkendepunkt. Liveness spør om den bør restartes.

Autoskalering multipliserer nedstrøms bruk. Connection pools, overlapp ved rolling deployment og databasekapasitet må planlegges sammen.

Repository-autorisasjon inngår i den betrodde deployment-veien og begrenser hvilken GitHub-kilde som kan deploye for teamet.

TokenX støtter interne applikasjoner som handler på vegne av innbyggere autentisert gjennom ID-porten.

Workload identity representerer den kjørende applikasjonen. Bruker-/delegert kontekst og faglig autorisasjon må håndteres separat.

Service discovery unngår ekstern eksponering og unødvendige hopp; access policies deklarerer den tillatte tjenestekanten.

Tilkobling, tokenautorisasjon og faglig autorisasjon er separate kontroller. En tillatt nettverkskant er ikke generell forretningsrettighet.

NAIS skiller durability/availability fra backupbeskyttelse mot feilaktig sletting. Teamet eier recovery-krav og konfigurasjon.

Kafka er robust, men NAIS anbefaler at data kan gjenopprettes fra et annet system. Replay, skjemaer og duplikathåndtering trenger design.

Identifikatorer med høy cardinality skader metricsystemer. Bruk avgrensede labels for aggregering og trygg request-spesifikk kontekst i logger eller traces.

Infrastruktur-health beviser ikke produktkorrekthet. SLO-er og faglige signaler må representere tjenesteutfallet.

Produksjonsberedskap kombinerer workload-design, sikkerhet, data, observability, endring, recovery og eksplisitt eierskap. Funksjoner alene er ikke evidens.