Aula gik ned efter Corona-udmelding: »Forældre må vente lidt endnu«

Jeg ved ikke om det kun er mig, men når man udvikler centrale services som Aula, Eboks, politi.dk og meget andet, bliver disse services så overhoved stress testet i forbindelse med f.eks. Krisesituationer hvor trafikken øges X gange over hvad "normalt" er?

Jeg forstår ikke hvordan disse applikationer kan gå ned grundet øget trafik hvermindre vi snakker et X Tbp/s angreb.

Er applikationen så dårligt skruget sammen at den fysisk ikke kan følge med, har de servere der hoster applikationen for få resourcer, er miljøet for dårligt, f.eks. En VM med 1 CPU og 1024 MB RAM?

Jeg forstår ikke hvordan disse applikationer kan gå ned grundet øget trafik hvermindre vi snakker et X Tbp/s angreb.

Da det offentlige som regel er Du er Billigst, Du får opgaven, så ville det ikke undre mig om Aula kører på en 80486 ude i en eller andens carport

bliver disse services så overhoved stress testet i forbindelse med f.eks. Krisesituationer hvor trafikken øges X gange over hvad "normalt" er?

En anden muligjhed var at kunne lukke bestemte kategorier af brugere ude, så prioriterede brugere kan arbejde. Men det var nok bedre at have eller kunne skaffe kapacitet nok. Udenrigsministeriets hjemmeside havde jo også en del problemer forleden.

Det er ikke rimeligt, at et system som AULA skal kunne tåle en panikbelastning som den foreliggende. Det er derimod et helt naturligt designkrav, at der findes en "panikknap", som bruges til at nedsætte antallet af logons - nøjagtigt som Skat i forbindelse med slutopgørelsen.

Argumentet om, at dette er en ny situation holder ikke. Jeg kan let forestille mig andre paniksituationer omkring en skole eller en kommune, ganske vist ikke landsdækkende, men aligevel.

ETHVERT udbredt it-system til kommunikation, herunder avisernes og tv's hjemmesider, for slet ikke at nævne Politi og Beredskab, skal NATURLIGVIS kunne håndtere enhver paniksituation - det kan være nødvendigt med kvote-logon som for Skat.

Det er bare endnu et eksempel på manglende rettidig omhu.

Det er ikke rimeligt, at et system som AULA skal kunne tåle en panikbelastning som den foreliggende. Det er derimod et helt naturligt designkrav, at der findes en "panikknap", som bruges til at nedsætte antallet af logons - nøjagtigt som Skat i forbindelse med slutopgørelsen.

Der er jeg faktisk uenig. Såvidt jeg ved så kører Aula faktisk i skyen - som netop er designet til at gøre det rigtig nemt (som i rigtig nemt!) at autoskalere når der er behov.. så det ikke vil koste meget, at lade skyen autoskalere ressourcer, når der kortvarigt er behov for det.. Hvis bare man havde designet sin software rigtigt og testede at koden rent faktisk virkede efter hensigten, når trafikmængderne steg.

Så når man nu netop hoster i skyen, så er det rimelig sørgeligt man har glemt at teste skaleringen :(

Det er ikke rimeligt, at et system som AULA skal kunne tåle en panikbelastning som den foreliggende. Det er derimod et helt naturligt designkrav, at der findes en "panikknap", som bruges til at nedsætte antallet af logons - nøjagtigt som Skat i forbindelse med slutopgørelsen.

Det ved jeg ikke om jeg er enig i fordi jeg ikke kender tallene for hvor stor 'panikbelastningen' var i denne situation. Udenrigsministeriets webside gik også ned og det er trods alt bare en tekst side. Den køre noget sitecore CMS på en windows server. Gennemgående er der efter min mening bare alt for mange problemer med offentlige danske websider.

Der er jeg faktisk uenig. Såvidt jeg ved så kører Aula faktisk i skyen - som netop er designet til at gøre det rigtig nemt (som i rigtig nemt!) at autoskalere når der er behov.. så det ikke vil koste meget, at lade skyen autoskalere ressourcer, når der kortvarigt er behov for det..

Vi ved at Aula er hosted på AWS. Vi ved ikke om det bare er et par Windows VMs med IIS og SQL Server i IaaS, eller faktisk er bygget på skalerbare PaaS teknologier

Der er jeg faktisk uenig. Såvidt jeg ved så kører Aula faktisk i skyen - som netop er designet til at gøre det rigtig nemt (som i rigtig nemt!) at autoskalere når der er behov..

Kombit har fortalt, at de havde 10 servere snurrende da statsministeren lukkede skolerne. Ved morgenstund plejer de at have 100 servere i gang.

Nu var det her jo ikke en incident. De rigtige myndigheder vidste, at skolerne ville blive lukket ned i god nok tid.

Man kunne nok godt have forudset, at der ville blive 'run' på Aula. Man kunne nok godt have forudset, at der burde være allokeret flere ressourcer. Man kunne nok godt have forudset, at løsningen skulle kunne skallere. ...

Det bunder nok i, at man ikke havde de rigtige procedurere, ansvarsfordeling etc. etc. Sådan noget kedeligt IT organisatorisk noget , som ikke giver priser når, der uddeles offentlige innovations priser.

Man har også haft en fokusering på C og i mindre grad I og meget lidt på A delen når det kommer til IT sikkerhed,

// Jesper

Såvidt jeg ved så kører Aula faktisk i skyen - som netop er designet til at gøre det rigtig nemt (som i rigtig nemt!) at autoskalere når der er behov.. så det ikke vil koste meget, at lade skyen autoskalere ressourcer, når der kortvarigt er behov for det..

opskalering koster penge .....

Portaler som fx Aula kunne måske skrives, så de brugte HW mere effektivt?

-sarcasmoff

Jeg har ventet 24 år på at danskere opdager hvordan, men foreløbig er det kun et 37 år gammelt trick: agregering, der bruges (i fx Varnish). Nå, det bliver (måske) efter 3. bølge ...

opskalering koster penge .....

Ja? - og som jeg skrev: "så det ikke vil koste meget, at lade skyen autoskalere ressourcer, når der kortvarigt er behov for det.."

Og iflg. anden kommentar har de normalt 100 instanser kørende - og men de havde "tilfældigvis" kun 10 kørende da det blev udmeldt? og ingen autoskalering? (for ellers tænder aws jo bare for flere servere når loadet øges, hvilket det lyder som om de jo ellers anvender, når de har 100 kørende normalt).

Jeg tænker også der er nogen der har glemt at teste deres procedurer (og automatikken) ordentligt.

Måske de benytter tidsbestemt skalering i stedet for at måle på belastning? Og så er der garanteret også (læs: forhåbentligt) et loft på antallet af instanser, så uanset hvad var skidtet nok røget i hegnet. ;D

Og så er der garanteret også (læs: forhåbentligt) et loft på antallet af instanser, så uanset hvad var skidtet nok røget i hegnet

Så havde de forhåbentlig meldt ud mængden af trafik var gået over det loft de havde valgt at kunne håndtere.. så det virkede "planlagt".. istedet for udmelding om at "noget hardware gik i stykker"