Infrastruktur

Informasjon om support og beredskap

Dette gjør du dersom du opplever at noe ikke fungerer slik det forventes:

  • noe alvorlig galt / nettsiden nede, kontakt oss på telefon 
  • mindre problemer / systemet tregt, send e-post til support@nymedia.no 

Telefon: ring 40 00 79 55 og tast "2" for kundeservice. 
Vi besvarer henvendelser i arbeidstiden mellom 09 og 15:30 på hverdager. 
Utenfor arbeidstid send e-post til support@nymedia.no

I det fleste tilfeller vil våre systemer for overvåkning fange opp problemer før man selv merker og rekker melde inn problemet. Skulle vi ikke følge opp henvendelse med en gang, er vi mest sannsynlig i full gang med å løse problemet. I tillegg vil vi følge med på de ulike verktøyene vi har for å måle ytelse og forsøke gjøre det vi kan, for å komme potensielle problemer i forkant

Vi har ikke alltid mulighet til å overvåke og/eller fange opp problemer i eksterne system. Eksempel på dette er tredjepartssystemer som betalingsleverandører. Denne type problem er også utenfor vår mulighet til å utbedre. Ved slike problem, anbefales det å ta kontakt direkte med den leverandør man har avtale med for f.eks. betaling, ERP-/logistikk-/kassesystemer, VPN-nettverk og andre tredjepartsfunksjoner.

Anbefalinger

Det er svært enkelt å ta ned sitt eget system/nettside. Kjører man en kampanje i den mest traffikerte perioden på dagen, f.eks. på vg.no, hvor man reklamerer med et "Supertilbud" og lenker kampanjen til en "tung" landingsside, da er resultatet at nettsiden går ned. Selv infrastruktur satt opp for automatisk skalering tilpasser seg ikke raskt nok til å ta i mot slik type trafikk uten noen form for forberedelser. 

Eksempler på tiltak man selv gjør for å unngå problemer på sin egen nettside:

  • Styrer man selv produktoppdateringer, anbefales det å ikke gjøre dette i periodene man vet man har mest trafikk
  • Har man f.eks. 100.000 mottakere på e-post/SMS kampanjer, bør disse deles opp i bolker og utsendelse spres utover flere timer på dagtid. Å spe utsendelse utover natten hjelper lite, da alle mottakere vil først se dette "samtidig" på morgenen
  • Skal det kjøres kampanjer på f.eks. vg.no eller tilsvarende "høytrafikk"-sider, herunder store Google Ads-kampanjer, ta kontakt med oss i god tid, dvs. > 1 uke, før kampanjen settes i gang, så vi kan gå i fellesskap se på tiltak som må gjøres
  • Har man på nettsiden funksjoner for å hente ut rapporter på f.eks salg/omsetning, bør dette gjøres i periodene med minst trafikk
  • Følg opp leverandør(er) av de systemer nettsiden er integrert mot, og påse at disse systemene tåler den på trafikken de kan bli utsatt for
  • Gjennomfør stresstester i god tid før viktige kampanjer og/eller perioder man vet man har mye/viktig trafikk

Informasjon om dagens driftsmiljø

De fleste kundesystemer forvaltes fra et miljø hvor en del ressurser deles og enkelte ressurser er eksklusive per system.  

Det et er flere grunner for at det er slik, men i hovedsak gjelder det for kunden:

  • rimeligste alternativ

  • krever ingen kunnskap

  • krever tilnærmet null forarbeid

  • behøver ikke gjøre seg opp en mening over "det tekniske"

  • ingen konkrete krav til drift og forvaltning

Der infrastruktur og forvaltning av systemer skiller seg ut, er dette gjort grunnet konkrete ønsker og behov beskrevet av kunden. I samarbeid med oss har vi så blitt enige om hvilken type løsning som passer best. Noen har krav til en SLA (Service Level Agreement) slik at kundens system/plattform må flyttes ut av et delt miljø og inn i et eget miljø. Eksempeler på krav i SLA kan være oppetidsgaranti, forhold som regulerer hva geografisk risiko man kan akseptere, automatisk tilpasning av ressurser i forhold til varierende behov av trafikk og databehandling med mer. Vi tilbyr derfor ulike type oppsett basert på hvilke behov kunden faktisk har/krever.  

Der ingen konkret driftsavtale/SLA foreligger og/eller legger konkrete føringer, driftes nettsiden fra en felles infrastruktur i AWS, region Frankfurt (eu-central-1), availability zone a (AZ-a). Hver kunde har sin egen "server", men tjenester som SSL-terminering, routing, søk og database deles med flere. Ingen garantier gis til drift/oppetid foruten det AWS tilbyr med tanke på en region, en AZ.

Overordnet beskrivelse av infrastrukturer

High Performance/High Availability (HPHA)

Infrastruktur som skalerer automatisk til å takle tusenvis av påloggede aktive brukere og millioner av sidevisninger/dag. Vi setter opp driftsmiljø for dere som auto-skalerer ytelse over flere servere, aktiverer servere etter behov med mer. I tillegg speiles systemet i minst en ekstra, men gjerne flere "tilgjengelighetssoner" (AZs). Og ved behov for større sikkerhet med tanke på geografiske/politiske hendelser distribueres systemet også i flere regioner. 

STIKKORD:

  • multi zone/region
  • horisontal skalering
  • svært høy driftssikkerhet
  • ekstrem kapasitet
  • høy datasikkerhet
  • høy oppstartskostnad
  • middels til høy driftskostnad

High Performance (HP)

Tilsvarer HPHA, men mangler sikkerhet med hensyn til geografiske og politiske situasjoner. Infrastruktur som skalerer automatisk til å takle tusenvis av påloggede aktive brukere og millioner av sidevisninger/dag. Vi setter opp driftsmiljø for dere som skalerer ytelse etter behov.

STIKKORD:

  • horisontal skalering
  • høy driftsikkerhet med tanke på trafikk
  • ekstrem kapasitet
  • høy oppstartskostnad
  • liten til høy driftskostnad

High Availability (HA)

Systemet settes opp slik at det speiles i minst en ekstra, men gjerne flere "tilgjengelighetssoner" (availability zones). Og ved behov for større sikkerhet med tanke på geografiske/politiske hendelser distribueres systemet også i flere regioner. Slike oppsett benyttes der det er utvidet behov for oppetid og datasikkerhet. 

Har man behov for >99% oppetid, må man velge en slik form for tilnærming

STIKKORD:

  • multi zone/region
  • svært høy driftsikkerhet
  • høy oppstartskostnad
  • middels til høy driftskostnad

Manuelt oppskalere kapasitet

Systemet kjører på ressurser tilpasset normalt behov. I god tid før eventuelle kampanjer man vet vil skape stor pågang, tar man kontakt med oss på forhånd og vi skalerer opp systemet til vesentlig høyere kapasitet. Vi blir også enige om en dato (f.eks. når kampanje avsluttes) for når systemet skal skaleres ned til "normalt nivå".  

STIKKORD:

  • tilpasset bruk av ressurser
  • begrenset økning i driftskostnader
  • kort nedetid ved opp-/nedskalering (2-10 minutter)
  • ekstrakostnad på 5000,- for endring (ytelse opp+tilbake)
  • ekstrakostnad for ekstra ytelse, minste intervall man betaler for er én uke for økt kapasitet

Overskalert server

Systemet kjører på dedikerte ressurser en god del høyere enn hva man behøver sett ut i fra 24/7/365. Dermed er systemt stort sett alltid parat for type aktivitet dere kjører nå. Fullt mulig å "kræsje systemet" med å kjøre en "ekstrem" kampanje til stort antall brukere samtidig, men sjansen begrenses betraktelig med hvor store ressurser man reserverer. 

STIKKORD:

  • betaler for ubrukte ressurser 
  • relativt høy driftskostnad

Normalt nivå

Systemet kjører på ressurser tilpasset normalt behov, sett ut i fra siste måned/år. Man aksepterer treghet i enkelte perioder med unormalt høy trafikk, men vet at det jevner seg ut over tid. 

STIKKORD

  • realativt rimelig
  • god utnyttelse av ressurser / kostnad
  • fungerer utmerket 24/7/365, kan skje foruten noen timer/dager per år

Fergesambandet

En fin analog for nettside og besøk, "fergesambandet":

  • Antall ferjeleier = enkel eller “horistonal” stack
  • Antall ferjer = kapasitet på stack
  • Antall kjøretøy = besøk til nettsiden
  • Type kjøretøy* = type trafikk på nettsiden
  • * motorsykler/person-/lastebiler
     

Nedetidsmatrise

Oversikt over potensiell nedetid per år basert på ofte brukt opptidsgaranti i SLA:

  • 99% : 3d 15h 39m 29s
  • 99,9% : 8h 45m 56s
  • 99,99% : 52m 35s
  • 99,999%: 5m 15s