Genstart i Microsofts sky gav kø i Fakta og Brugsen

2. februar 2018 kl. 06:2212
Genstart i Microsofts sky gav kø i Fakta og Brugsen
Illustration: Siine Fiig.
Medlemskort-tjeneste, som ikke ville starte af sig selv i Microsoft Azure, var onsdag årsag til et minuts ekstra ekspederingstid i COOP's butikker over hele landet.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Tjenester i Microsofts sky, Azure, var årsag til, at kassebetjeningen i COOP's butikker, så som Fakta og Brugsen, gik væsentligt langsommere omkring kl. 18 onsdag over hele landet.

»I forbindelse med et ‘servicevindue’ i Azure havde man ikke fået genstartet alle de nødvendige tjenester. Det betød, at vores kasser, ved bonafslutning, var længere tid om det, end de burde være, og samtlige butikker brugte et minuts tid ekstra på bonafslutning - og samtlige butikker forsøgte at få en forklaring fra vores servicedesk.«

Det forklarer Svend Envoldsen, som er ansvarlig for innovation i COOP Teknologi.

I én Fakta-butik på Østerbro i København gav fejlen anledning til kø med 20 minutters ventetid. Her måtte personalet vente 30 minutter for at komme igennem til COOP's it-support på telefonen. Også andre steder var der køer i COOP's butikker.

Artiklen fortsætter efter annoncen

Fejlen ramte alle koncernens dagligvarebutikker, med omkring 5000 kasser i alt.

Kasser ventede på time out fra sky-tjeneste

»Vi har tjenester som kører i Microsofts sky, Azure. Nogle af de tjenester leverer forskellige oplysninger til kasseapparaterne, i forbindelse med medlemskort og betalinger. «

Årsagen til problemet var en tjeneste, der ikke ville starte op. Kasserne ventede på tjenesten, og da der ikke kom svar fra skyen, 'timede' kasserne ud efter en minut. Tjenesten registrerer blandt andet medlemmernes køb.

COOP ved endnu ikke, hvorfor tjenesten i Azure ikke startede af sig selv. Problemet har ikke opstået tidligere.

»Det er ikke det første servicevindue, vi har haft i de halvandet år, vi har kørt løsningen.«

Microsoft har ifølge Svend Envoldsen ret til at køre de såkaldte servicevinduer, hvor der udføres vedligeholdelse i skytjenesten.

»Hvad der præcis er gået galt ved vi ikke endnu.«

COOP har selv ansvaret at få tjenesterne op, efter servicevinduet er gennemført.

Problemet var løst omkring klokken 19.

12 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
12
4. februar 2018 kl. 01:13

Det er måske også spild af tid at 1200 butikker bruger tid på at stå i kø for at få at vide at der er en kendt fejl.

Når den 5. butik har ringet ind, burde der gå en besked ud til alle butikker om at der er en kendt fejl (at årsagen ikke er kendt endnu er ligegyldigt),

Det kan så være et popup på kasseterminalen eller en sms til butikschefen (ved hjælp af en sms-udbyder, der kan nås fra en mobiltelefon udenom COOPs netværk)

11
2. februar 2018 kl. 15:38

Der var planned maintenance i starten af januar, i forbindelse med Spectre osv. Der har ikke været noget nu her, så det er næppe det.

Det citerede gælder i øvrigt kun for VMs.. Det er slet ikke sikkert det er den type service de har brugt her.

10
2. februar 2018 kl. 14:35

Planned Maintenance events are periodic updates made by Microsoft to the underlying Azure platform to improve overall reliability, performance, and security of the platform infrastructure that your virtual machines run on. Most of these updates are performed without any impact upon your Virtual Machines or Cloud Services (see VM Preserving Maintenance). While the Azure platform attempts to use VM Preserving Maintenance in all possible occasions, there are rare instances when these updates require a reboot of your virtual machine to apply the required updates to the underlying infrastructure. In this case, <em><strong>you can perform Azure Planned Maintenance with Maintenance-Redeploy operation by initiating the maintenance for their VMs in the suitable time window.</strong></em> For more information, see Planned Maintenance for Virtual Machines.

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/manage-availability

9
2. februar 2018 kl. 14:33

Det er ret sjældent der er service vinduer som forårsager at de ting der er kørende oppe i Azure skal genstartes.

Generelt laver de rullende opdatering/genstart af den underliggende infrastruktur, hvor workload blot flyttes rundt imens.

Hvis det er fordi Coop kun har én instans af deres ting kørende, og de har været lukket ned i forbindelse med opdatering af dem, så burde de måske overveje at følge Microsofts anvisninger for hvordan de bør konfigurere deres scaling, så det kan overleve at dele genstartes uden at det hele lukkes ned.

Artiklen mangler desværre lidt oplysninger om hvad der var lukket ned, og hvorfor det var lukket ned - uden det er det svært at gisne mere præcist om, hvorfor det burde skabe problemer.

8
2. februar 2018 kl. 13:06

I AWS arbejder man ikke med service vinduer. Er det noget der er normalt i Azure verdenen?

Det eneste jeg kender til i AWS med service vinduer er RDS, men der kører de typisk over på den spejlede database før de udfører service.

7
2. februar 2018 kl. 11:59

Jeg syne sikke den er imponerende i dag. Derfor tager det også længere tid før man opdager fejlen.

5
2. februar 2018 kl. 11:28

Interessant fænomen, at Coop kunde vælger at udstille leverandøren i medierne. Er det taktisk oplæg til at komme ud af en aftale, genforhandle prisen eller en bod? Er det Coop der har bestilt en forkert løsning, eller valgt et forkert design?

4
2. februar 2018 kl. 11:28

Og måske en kill switch til helt at slå funktionaliteten fra hvis man ved den har problemer. Ingen grund til at vente på et timeout ved man ved det kommer -- uanset hvor kort det end er.

3
2. februar 2018 kl. 10:45

Et minut er i hvert fald lang tid. :-)

2
2. februar 2018 kl. 10:42

Tænker også at man nok skal se på en max svartid målt over X uger/måneder og så sætte timeout til X+5 sekunder.

Hvis man er nødt til at vente i 1 minut inden timeout fordi det somme tider tager så lang tid, så skal man nok nærmere kigge lidt på sin applikation.

1
2. februar 2018 kl. 08:46

Så må vi jo håbe, at COOPs it-afd. får sat lidt overvågning op eller gennemgået en evt. eksisterende en af slagsen, så de opdager, når en tjeneste ikke kører. ;-) I samme ombæring kan de jo overveje at reducere time-out til 30 sek. :-D