Det tager ikke lang tid at få en servercontainer til at svare. Det tager længere tid at gøre den til en løsning, som nogen kan drive, forstå og stole på efter den første begejstring.
Før I opretter noget i Google Cloud, skal I derfor beslutte, hvem der ejer driften, hvilke data der må passere, og hvordan en fejl bliver opdaget. Containeren er den lette del.
Forstå de to miljøer
Googles opsætning bruger et preview-miljø og en eller flere tagging-servere. Preview bruges til fejlsøgning. Tagging-serverne håndterer den almindelige trafik. De to roller skal ikke blandes sammen i en produktionsplan.
I den aktuelle vejledning til Cloud Run anbefaler Google mindst to instanser i produktionsmiljøet for at mindske risikoen for datatab ved en enkelt fejl. Googles eksempel viser også autoskalering, men det rigtige niveau afhænger af jeres trafik og de opgaver, containeren udfører.
Aftal ejerskab før fakturering
Cloud-projektet bør ikke være bundet til en enkelt konsulents private konto. Aftal virksomhedsadgang, roller, faktureringsansvar og mindst én vej tilbage, hvis den daglige ejer er væk.
- Hvem ejer Google Cloud-projektet?
- Hvem må udgive en ny servercontainerversion?
- Hvem modtager drifts- og budgetalarmer?
- Hvem kan rulle en fejl tilbage?
- Hvor ligger dokumentation og ændringslog?
- Hvornår gennemgås adgange igen?
Det er kedelige spørgsmål. De bliver først spændende, når ingen kan svare på dem under en fejl.
Lav et budget, der kan reagere
Prisen afhænger af region, instanser, ressourcer, trafik, logs og øvrige cloudtjenester. Googles vejledning viser et aktuelt eksempel på cirka 45 amerikanske dollar om måneden for hver af de viste preview- og tagging-konfigurationer. Det er et regneeksempel, ikke et tilbud på jeres løsning.
Opret et budget og en alarm fra begyndelsen. Beslut også, hvad der skal ske, hvis forbruget vokser: Skal instanser begrænses, skal trafikken undersøges, eller skal en ejer bare have besked? En alarm uden en aftalt reaktion er mest en høflig overraskelse.
Brug et førstepartsdomæne bevidst
Google anbefaler et eget underdomæne til produktionsopsætningen. Det skal forbindes korrekt til tjenesten, have HTTPS og passe ind i jeres DNS- og certifikatdrift. Dokumentér, hvem der kan ændre det.
Et førstepartsdomæne ændrer den tekniske vej. Det ændrer ikke automatisk, hvem data sendes videre til, eller om behandlingen kræver samtykke. De valg skal stadig fremgå af tags, politik og test.
Overvåg mere end om URL’en svarer
Googles Cloud Run-vejledning beskriver et /healthy-endpunkt til sundhedskontrol. Brug det, men stop ikke dér. En server kan svare 200 og stadig sende forkerte events til GA4.
- tilgængelighed og svartid
- fejlrater og afviste forespørgsler
- antal events i forhold til kendte forretningshændelser
- uventede destinationer eller ændringer i payload
- instansforbrug og omkostninger
- udløb eller fejl på domæne og certifikat
Begræns logs
Logs kan være nødvendige for fejlsøgning, men de kan også opsamle hele forespørgsler med identifikatorer og andre oplysninger. Beslut derfor på forhånd, hvad der logges, hvem der har adgang, og hvornår det slettes. Kontrollér den faktiske log – ikke kun den ønskede indstilling.
Definér en bestået overdragelse
Før løsningen kaldes færdig, bør en anden end udvikleren kunne finde cloud-projektet, se den aktive version, forstå datastrømmen, modtage en testalarm og rulle tilbage efter en skriftlig vejledning.
Start med et enkelt diagram over browser, servercontainer og destinationer. Sæt en navngiven ejer på hvert led. Hvis et felt stadig hedder »nogen«, er I ikke klar til produktion endnu.
Hvis behov, datastrøm og drift skal afklares før en implementering, kan jeg hjælpe med server-side tracking.
Artiklen er under opdatering
Jeg gennemgår og opdaterer indholdet. Kig forbi igen – eller kontakt mig, hvis du har spørgsmål til emnet.
Kontakt mig