Skip to main content
Gå til innhold

General principles for running services on AWS

Checklist​

Logging og monitoring​

  • What/how to monitor the application?
    • Metrics
    • Alarms
    • Hvilke eksterne avhengigheter har tjenesten? Bør de monitoreres?
  • What to log? How long should the logs be kept? (How long do we need them, and how long can we keep them; GDPR)
    • access logs
    • application logs
    • audit logs

On-call/vaktordning​

  • Service-level alarms: owned by the individual teams, fired when some portion of their service is not working
  • Company-wide alarms: fired when a significant portion of your business functionality is broken

Availability​

  • What are the SLAs for the application? Do we need to account for AZ/Region failures
  • Resilience, continuity (multi AZ and/or multi region)

Sikkerhet​

  • Spesielle krav til konfidensialitet, integritet?

Design for cloud​

  • auto scale

Design/architect for failure​

  • Resilience to spurious errors that might occurr
  • Transient errors are expected on the Internet and in distributed systems

Backup​

What to back up? Database, files/filesystem, secrets, params, local users in Cognito etc. Backups, and backup procedures should be tested regurlarly (eg. on change)!

  • Objective
    • Recovery time objective
    • Recovery point objective
  • Typer/kategorier:
    • Generational/versioned Purpose: long-term retention/archival
    • Point-in-time (or generational+transaction log) Purpose: Protect against accidental write/delete operations
    • Server instances/resources: Mirror/hot stand-by Purpose: Protect against local hardware failures

Deployment strategy​

  • Hvordan skal nye versjoner rulles ut? Hvordan sikres denne prosessen?
  • Hvordan har man tenkt å korrigere deployeringer som feiler, eller som inneholder bugs? Roll forward/backward?
  • Hvordan skal man oppdatere ressursene i produksjon? Blue-Green / All at once / Canary?
  • Hvordan skal man oppdage feil, helst automatisk via alarmering?
  • Eksempler (flere av disse strategiene kan kombineres):
    • Blue/Green (bør gjøres i samme konto)
    • Canary release (variant av blue/green hvor trafikken flyttes over til Green gradvis over tid)
    • In place (aka “all at once”)
    • Maintainance window (implies downtime)
    • Feature flags
Tip

Don’t do Blue/Green by flip-flopping between 2 AWS accounts. Do it in 1 account Ref: https://youtube.com/watch?v=bSXRF1poE8g&t=41m30s

Div​

  • Hvordan sikre at DB eller andre viktige ressurser ikke slettes/korrumperes ved en feiltagelse?
  • Sjekk SLA og pris for de ulike tjenestene (S3 vs RDS vs EC2 etc)
  • Graceful failure? (Display downtime notification pages and responses? Static stand-by HTML activated via DNS redirection?)
  • Hvordan kommuniseres nedetid/systemarbeid til sluttbruker?
  • [USIT] Hva har Usit gjort som vi nå må gjøre selv?
  • Hvordan og hvem skal følge opp løpende kostnader i AWS?

Definér ansvar:​

  • Hvem har ansvar for hva i applikasjonens livsløp?
  • Hvem har ansvar for monitorering av tjenesten eller enkeltkomponenter?
  • Hvem har ansvar for drift? (Oppgradering/backup etc)
  • Hvem godkjenner endringer?

Hva anser vi har størst risiko i utviklings- og driftsløpet?​

  • Manglende kunnskap om verktøy/plattform? (feks AWS)
  • Manglende kunnskap/ansvar for drift/overvåking?

DevOps​

  • Det er viktig å gjennomføre en rotårsaksanalyse for hendelser i sky, slik at man ikke bare fikser symptomene, men faktisk finner årsaken til uønskede hendelser.