Downtime Crisis.nl mogelijk veroorzaakt door vergissing

Crisis.nl, bedoeld als informatievoorziening bij rampen, ging woensdag niet offline door te hoge bezoekersaantallen. Het lijkt erop dat een menselijke vergissing ertoe leidde dat de website gedurende anderhalf uur niet te bereiken was.

Woensdag, toen bij een chemisch bedrijf in Moerdijk een grote brand uitbrak, was de website Crisis.nl enige tijd onbereikbaar. Dit terwijl Crisis.nl juist is bedoeld als communicatiekanaal bij calamiteiten. Sommige media concludeerden dat de site onder de grote toeloop was bezweken, maar waarschijnlijk ligt het ingewikkelder. Er was sprake van een aantal problemen, blijkt uit reacties van het ministerie en de hostingprovider.

Een daarvan was dat een medewerker per ongeluk een onjuiste doorverwijzing instelde. Als er geen sprake is van een ramp, verwijst Crisis.nl naar een pagina met informatie over het platform. Op het moment dat er een calamiteit is en het platform moet worden ingezet, moet deze verwijzing handmatig worden aangepast. "Iemand heeft daar een fout gemaakt", zegt Martin Maas van ASP4all, dat de crisiswebsite host, desgevraagd tegen Tweakers.net.

Crisis.nl had naar het subdomein crisis01 moeten doorverwijzen, maar een medewerker vulde bij de doorverwijzing per ongeluk de url van het cms in. Daardoor probeerde Crisis.nl gebruikers door te verwijzen naar de voorpagina van het beheersysteem en leek de site offline te zijn. "Maar de systemen draaiden ondertussen prima", stelt Maas. Het is niet bekend wie de fout heeft gemaakt; dit kan een medewerker bij de overheid zijn geweest, maar ook iemand bij de softwareleverancier.

De foutieve doorverwijzing was echter niet het enige wat speelde. Er zouden ook technische problemen zijn opgetreden, stelt Jean Fransman van het Ministerie van Veiligheid en Justitie. Die problemen waren volgens hem niet aan overbelasting te wijten, maar onduidelijk is wat er precies aan de hand was. "Dat is nu nog niet te zeggen", aldus Fransman.

Op een verklaring op de website van het Nationaal Crisiscentrum wordt aangegeven dat de foutieve doorverwijzing tot gevolg had dat bezoekers toegang verkregen op een manier die normaal alleen is 'voorbehouden aan de redacteuren van de site'. Preventiemaatregelen om de site onder grote druk online te houden, zouden daardoor zijn omzeild. Het lijkt er dus op dat de technische problemen zijn veroorzaakt door de doorverwijzing.

Toen deze problemen waren opgelost, was de website overigens nog steeds niet functioneel. "Er was nog geen content op de website geplaatst", aldus Fransman. Daardoor was de crisispagina nog niet zichtbaar. Uiteindelijk zou Crisis.nl woensdagavond anderhalf uur offline zijn geweest. Woordvoerder Fransman betreurt de problemen en zegt dat ze niet meer voor moeten kunnen komen.

Volgens woordvoerder Jeroen Pluim van TDC Lighthouse, dat het cms van de website leverde, is Crisis.nl zo ontworpen dat deze veel bezoekers aankan. Zo serveert de website bij een calamiteit enkel statische pagina's, die door het cms - dat op een andere server draait - vooraf worden gegenereerd. Dit leidt tot een lagere serverbelasting dan wanneer een pagina bij elk bezoek opnieuw moet worden gegenereerd.

De website van het Nationaal Crisiscentrum was overigens ook enige tijd offline, mogelijk doordat bezoekers die Crisis.nl niet konden bereiken naar de website van het NCC probeerden te gaan. Het is niet de eerste keer dat Crisis.nl offline is op het moment dat de website juist zou moeten werken. In 2007, toen een grote storm voor de nodige problemen zorgde, ging de site ook al offline. Dat kwam wel door overbelasting. De site hield het toen slechts een paar minuten uit.

Reacties (90)

[Dlocks]

Dus eigenlijk moeten we http://crisis01.crisis.nl/ bookmarken.

[Fish]

ehm nee,

want 02,03 en 04 wijzen weer naar http://www.nederlandveilig.nl/noodsituaties/

en >05 staat een lege template
http://crisis05.crisis.nl/nl/content.html

Ze wijken dus af en kunnen potentieel ander ingezet worden

[Reactie gewijzigd door Fish op 25 juli 2024 04:12]

[Keypunchie]

Ik vind het ongelooflijk amateuristisch. Het is nu een dag na de ramp en de hoster heeft niet eens de virtual hosts kunnen aanpassen?

Op dit moment wordt er simpelweg op een lelijke (verkeerde) manier geredirect: je krijgt een HTTP 200 (OK) met een of ander siteje dat een stagiair die HTML kan uit armoede maar op de webpagina lijkt te hebben gezet (met daarin een META HTP-EQUIV refresh)

De nette manier is om een HTTP 302 (Temporariliy moved) te geven. Of, nog netter, je past even de hostheaders aan zodat crisis01.crisis.nl ook www.crisis.nl als ServerAlias heeft. (En stop de vhost voor de niet-crisispagina). Dan voorkom je die lelijke "click here" pagina.

Dit is allemaal helemaal niet moeilijk om te scripten en te koppelen aan een "grote rode knop" op het ministerie waar ze de content op de sites zetten..

Een oplossing die ik wel eens in de praktijk heb gebruikt is dat de eigenaar van de website met ftp gewoon een bestandje met de naam "storingspagina_aan" in de directory van zijn site zette. Een cronjob (of scheduled task onder windows) checkt elke 5 minuten op het bestaan van die file en voert een script uit dat even de virtuele hosts configuratie van de storingssituatie kopieert en de webserver-software herstart. Bestand verwijderen en het omgekeerde proces vond plaats.

Misschien ben ik overdreven kritisch, maar ik vind het overkomen als buitensporige onprofessionaliteit. En het kan gebeuren dat in de spanning van de moment zoiets misgaat... Maar dat is toch makkelijk binnen een uur te repareren? En dan niet op zo'n knullige manier als nu?

Het is allemaal tijdens kantoortijden gebeurd. Er is zelfs intussen gewoon een hele werkdag overheen gegaan.

[Reactie gewijzigd door Keypunchie op 25 juli 2024 04:12]

[EBOOZ]

Ik vind dat je helemaal niet overdreven kritisch bent. Ik vind het ook buitengewoon amateuristisch in elkaar gezet. Zeker omdat het een website betreft die informatie moet geven ten tijde van crisis.

Waarschijnlijk kan je het Ministerie nog niet eens echt verantwoordelijk houden voor het geheel, tenzij het uiteindelijk weer allemaal om geld heeft gedraaid. Anders heeft de bouwer van het geheel de plank pittig mis geslagen vind ik.

Als je een knap CMS hebt kan je een standaard site maken en een crisis site. Kwestie van een vinkje aanzetten van welke je wilt gebruiken onder je domeinnaam. Als er crisis is zet je je crisis-site aan en kan je beginnen met nieuwsberichtjes typen.

[Kalief]

Hoe weet de hoster nou dat er een crisis is en dat er iets aangepast moet worden (en wat dan wel)? Dat is de zaak van de eigenaar van de site, toch niet van de hoster.

[koter84]

het verbaast me dat nog niemand iets heeft gezegd over de "cloud"

crisis.nl lijkt me een perfecte kandidaat voor cloud-hosting... want de site kent 2 verschillende "standen" er is geen crisis en er komen 200 mensen per maand.. OF er is een regionale of zelfs landelijke storing en er is veeeel capaciteit nodig om iedereen een pagina te laten zien...

wel slecht overigens dat ze niet weten wie het gedaan heeft... ik hoef het niet te weten, maar als je zegt het probleem te hebben aangepakt, en dat het niet meer voor kan komen... moet je dan niet weten wie dit soort aanpassingen kunnen doen? en dus ook wie het nu gedaan heeft?

[YopY]

...Waarom doen ze zo moeilijk met redirects (waarbij ze (blijkbaar) afhankelijk zijn van een hostingprovider), terwijl het even eenvoudig zou moeten zijn om de homepage in dat CMS aan te passen? Die doet vervolgens een html export naar de standaard indexpagina, en je bent klaar. Dan is het immers een kwestie van een redacteur die een pagina aanpast en de informatie staat online.

Weet iemand overigens welk CMS dat moet zijn? TDC Lighthouse levert nl een aantal CMSsen, zie ik op hun website.

[barryl]

Volgens mij is dit gebaseerd op i-park, het in-house ontwikkeld CMS gebaseerd op coldfusion.

Normaal gesproken komen mensen via een Squid proxy binnen, en halen daar de content vandaan. crisis01.crisis.nl heeft 3 IP-adressen, welke via DNS round-robin wordt verdeeld onder 2 geografisch gescheiden datacenters met elk een eigen uplink naar het internet.

In geval van een crisis wordt de DNS aangepast (de Time-To-Live staat op 10 minuten). http://crisis01.crisis.nl wordt dan afgehandeld door een aantal Squid proxy-servers achter een hardware loadbalancer. Squid zorgt ervoor dat het bron-systeem (CMS) niet wordt overbelast.

De redactie werkt weer op een gescheiden server waar men de content kan aanleveren.

Op zich lijkt het redelijk goed in elkaar te steken, maar het blijft mensenwerk: iemand moet de DNS omgooien naar de rampensite. Blijkbaar ging dit mis. Ook slordig dat dit pas na anderhalf uur werd verholpen...

Overigens vraag ik me af wat er gebeurt wanneer er twee rampen tegelijk plaatsvinden ;-)

[humbug]

Klinkt als heerlijk ingewikkeld. Maar goed, laten we bij het begin beginnen
Een Squid proxy, dat is mooi maar haalt gelijk de noodzaak van statische pagina's onderuit. Je moet enkel zorgen dat je dynamische pagina's door Squid gecacht worden om te zorgen dat de load op je servers laag blijft.

Dan het DNS en 2 geografische locaties probleem. Dat is een leuke manier om meerdere locaties online te hebben zodat als 1 locatie afbrand je nog steeds online bent. Helaas is het ook een vrij instabiele manier aangezien als je gebouw in de fik staat nog steeds 50% van je bezoekers naar het brandende gebouw gestuurd worden. Beter is dus een vorm van global load balancing waarbij de servers weten of de andere site al dan niet online is en alle gebruikers bij een probleem naar het goede datacenter gestuurd worden. (Al zijn de oplossingen daarvoor ook niet perfect, het is betrouwbaarder dan 2 IP addressen in je DNS)

Daarna verlies je me compleet. In het geval van een crisis wordt het DNS aangepast? WTF? In het geval van een crisis publiceer je nieuwe content naar je webservers (Op beide locaties) en ben je klaar. Tenminste zo zou het moeten werken)

Qua belasting kun je (je hebt statische pagina's) gewoon meer proxy's parallel zetten en wordt je productie webserver dus nauwelijks belast. Een hardware loadbalancer (of beter 2) per locatie is een optie maar eerlijk gezegd kan ik me nauwelijks voorstellen dat die echt wat staat te doen. Een simpele software loadbalancer (pfsense, LVM ) kan zonder problemen bijhouden welke proxies werken en de data doorsturen. De forward rules zijn namelijk extreem simpel (geen condities, geen sessies) en de data gaat niet door de load balancer dus dat geld kun je beter in je zak houden.

Een gescheiden publicatie systeem is natuurlijk een must have.

Dus wat heb je nodig.
2x PFSense (of Red Hat Piranha) als load balancer (Of doe eens gek 2x een F5 met Global Load Balancing functie) Dus 1 per datacenter
3 keer Liferay (2x voor productie) 1 per datacenter + 1x voor het systeem waar de redactie op werkt.
Squid proxies zoveel je denkt nodig te hebben

Hiermee ben je klaar en heb je nog geen cent uitgegeven aan software en hardware. Je hebt echter wel een productie kwaliteit load balancer en een productie kwaliteit CMS met alle features die je maar kan denken. In praktijk wil je misschien je productie CMSen dubbel uitvoeren zodat die wat meer load aankunnen en je locatie niet gelijk op zijn gat ligt bij een crash van een server en voor dezelfde reden waarschijnlijk ook twee load balancers per locatie (en firewalls)

Serverhardware toevoegen naar wens maar de benodigde software voor een project als dit kost dus 0,00 Euro. Het enige wat je kwijt bent is het salaris van een goede consultant. Tijd om dit te bouwen: Een weekje. Nu mag jij mij vertellen hoeveel crisis.nl gekost heeft aan consultancy en software development

[Verwijderd]

de homepage in dat CMS aan te passen? Die doet vervolgens een html export

Kijk, dat zijn al twee handelingen. Bij elke handeling kan iets fout gaan. Heb jij al eens aan een redacteur moeten uitleggen wat een html export is? Denk niet vanuit je eigen vaardigheden, maar probeer je te verplaatsen in de medewerker die de taak moet uitvoeren.

[humbug]

Zo moeilijk is het allemaal niet en YopY heeft gewoon gelijk. Het CMS kan gewoon rechtstreeks naar www.crisis.nl publiceren. Net zoals het naar crisis01.crisis.nl kan publiceren. Dus in plaats van. Redacteur schrijft het nieuws. CMS publiceert naar crisis01.crisis.nl en Jantje past handmatig de URL op www.crisis.nl aan. Krijg je Redacteur schrijft het nieuws. CMS publiceert naar www.crisis.nl en Jantje blijft er met zijn vingers vanaf. Scheelt dus 1 handeling en verandert niets aan de overige twee.

De website komt op mij sowieso amateuristisch over. Ja, statische pagina's zijn sneller dus prima als je een CMS gebruikt dat die pagina's aanmaakt en op de site zet. Die beslissing kan ik begrijpen. Maar dat doorverwezen?

Ik kan me indenken dat dit een soort van poor mans load balancer is maar dan nog. Zelfs als je aparte subsites en servers voor elke ramp wil hebben laat je de redirect "gewoon" op basis van content in de load balancer doen (of als je geen geld hebt door de apache server via mod_proxy) Homepage ervoor waar men uit de lijst van huidige rampen kan kiezen (automatisch gegenereerd uit het CMS natuurlijk) en klaar ben je. Maar het is veel simpeler om alles op 1 (set van) server(s) te draaien zodat je CMS maar 1 site naar alle servers in je webserver farm hoeft te sturen. Schaalt ook nog een stuk beter doordat alle servers beschikbaar zijn voor alle requests voor alle gelijktijdige rampen.

Daarnaast maakt iedereen wel eens een fout. Maar kom op, je vult het verkeerde adres in en je merkt dat niet? En nadat je daar op gewezen bent, kost het uren om het op te lossen? Ook is het vreemd dat er "nog geen content aanwezig was". Na al die problemen en uren vertraging was er nog geen redacteur die enige content voor de ramp in het CMS had getypt? Want die redacteur had natuurlijk wel gewoon toegang tot het CMS moeten hebben en het CMS had gewoon de content naar crisis01.crisis.nl kunnen publiceren. Dat heeft allemaal namelijk niets te maken met de doorverwijzing vanaf www.crisis.nl

Nee, als ik me verplaats in de mensen die de taken hadden moeten uitvoeren dan zie ik veel gepruts en een houtje touwtje product. Als je de redacteur kan uitleggen, typ hier de content in en druk op deze knop om het te publiceren dan maakt waar je naartoe publiceert weinig uit. De kritiek richt zich dus niet op de redacteur maar op degene die de site ontworpen heeft en besloten heeft dat iemand handmatig een linkje naar crisis01.crisis.nl moet aanpassen en dat zodra dat fout gaat de complete site plat gaat en niet meer te herstellen is.

[MuddyMagical]

En daarom is het veel makkelijker om een grote knop te maken met de tekst
'Activeer Crisis.nl'
Hoe moeilijk is het nu om dit te automatiseren?

[Mellow Jack]

Super super super makkelijk.... dit soort dingen zijn niet goed te praten, zelfs een MBO (niv 4) leerling kan zoiets voor je bouwen daar hoef je dus echt geen expert programmeur voor zijn

[Reactie gewijzigd door Mellow Jack op 25 juli 2024 04:12]

[sfranken]

Dus? Je kunt het door het CMS laten doen en aan de front-end alleen een knop 'CRISIS' zetten. CMS doet de rest.

[disheaver]

Toen deze problemen waren opgelost, was de website overigens nog steeds niet functioneel. "Er was nog geen content op de website geplaatst",

Klopt ook niet echt. Ik heb hem vrij snel bezocht, en kreeg meestal een offline/overbelast error (op http://remote01.crisis.nl/) maar een paar keer een pagina met informatie over de brand.

Zowieso, je gaat toch eerst enig inhoud op een crisis-site plaatsen en dan pas hem online (door verwijzing) zetten? Erg vaag allemaal...

[Sundog]

Dit komt door de manier waarop de hulpverlening processen werken en de wettelijk geregelde verantwoordelijkheden bij het bestrijden van dit soort incidenten.

De verantwoordelijkheid voor de informatie voorziening voor burgers bij incidenten ligt bij de lokale overheid.
Bij kleine incidenten gebeurd dit door bijv de politie of brandweer woordvoerder, maar bij opschaling verschuift dit naar de bestuurlijke tak, bijvoorbeeld afdeling voorlichting van de gemeente.
De betrokken gemeente beslist dan of men crisis.nl wil inzetten (Dat is niet verplicht), bijvoorbeeld omdat de eigen website de aantallen bezoekers niet aan kan.

De gemeente vraagt vervolgens het inzetten van crisis.nl aan, en een van te voren getrainde "redacteur" levert vervolgens de content aan die via crisis.nl zichtbaar wordt gemaakt. (Dit gebeurd via het CMS).
Omdat je niet van te voren weet wat voor informatie nodig is, kan je niet een standaard bericht klaar zetten....

Ik zeg niet dat dit een makkelijk proces is, maar wil alleen aangeven hoe en waarom het zo geregeld is.
(Trouwens crisis.nl is vaker ingezet het laatste jaar, zonder bereikbaarheid problemen. )

[Elmo_nl]

Theorie v.s. praktijk: van de website http://www.asp4all.nl/oplossingen.php

Zo garanderen we u optimale veiligheid van uw bedrijfsgegevens die via het internet toegankelijk zijn. We zijn onverstoorbaar: we hebben twee datacenters die nooit uitvallen, ook de stroom en de koeling niet. Bovendien beschikken we over een disaster recovery systeem.

[Rinzwind]

Het probleem bij zo'n disaster recovery systeem is dat het nooit getest wordt
In bedrijfsleven zie je ook vaak handen vol geld weggegooid worden omdat iemand denkt dat ik dan veilig is... terwijl ze er vervolgens niets mee doen, niet testen, maar half werkt, of bij problemen problemen geeft

[Powermage]

Heel knap, maar meerdere datacenter zeggen dat hun stroom niet 'down' kan, evenals het netwerk of de koeling, maar uit ervaring weet ik dat het toch echt geregeld gebeurt. beweren dat dit niet kan is vrijwel onmogelijk.

[Kalief]

De site viel anders inderdaad niet uit. De foute redirect functioneerde immers. De kritiek aan de hostingprovider is dus makkelijk maar misplaatst.

Overigens lijkt het me handiger als ipv een redirect of een 'knop' het cms zelf regelmatig polst of via een andere locatie een actiecommand is ingevoerd. Dan kan ergens in een crisiscentrum op een site die heel ergens anders staat een opdracht 'het is nu crisis' worden ingevoerd, het cms merkt dat door te pollen na een tijdje op en verandert van content.

[Gunner0616]

Haha, wat een claim. Wat nou als Nederland van de kaart word geveegd, zouden die websites dan nog steeds werken?

[Marcelloz]

Beetje vreemd dat ze het niet direct controleren.... Meestal als je zo'n wijziging doet, dan controleer je toch direct of crisis.nl de juiste pagina toont.

[kimborntobewild]

Misschien alleen intern getest, en niet extern. En als 't intern wel werkt, valt 't niet zo snel op. Maar duidelijk is dan dat de procedures niet goed zijn.

[Verwijderd]

Blijkt dus dat mensen die niet weten wat ze aan het doen zijn met DNS instellingen maar beter met hun vingers ervan af moeten blijven...

[DutchStoner]

Wie zegt dat het een DNS redirect is? Sterker nog, het lijkt me vrij onwaarschijnlijk. Dan zou de website er namelijk stukje langer 'uitgelegen' hebben. Ik denk dat er in het .htaccess bestand een fout stond.

Terugkoppertje; als je niet precies weet wat er fout is gegaan kan je beter met je vingers van de 'reageer' knop afblijven

[Reactie gewijzigd door DutchStoner op 25 juli 2024 04:12]

[yannickie111]

Dit is wel slordig, dit moet goed voorbereid zijn dat zoiets niet kan gebeuren.

Misschien een idee om eens per maand, of eens in de paar maanden de crew die de site online moet zetten te laten trainen?
Net zoals nu ook gebeurd bij het luchtalarm? Want ook het luchtalarm mag natuurlijk niet falen op het moment supreme.

[AW_Bos]

Toch raar dat er nog e.e.a geconfigureerd moet worden aan een CMS om hem voor een crisissituatie werkend te krijgen.

Het logische zou zijn dat er een kopje aan/uit in het beheer paneel is, en dat verdeling over de juiste servers al voor-geconfigureerd is.

Het zou kunnen dat een medewerker zonder enige kennis van het systeem dus maar wat ingevuld heeft, en dit zou niet mogen....