Hostingprovider heeft storing ziekenhuizen opgelost door vervangen componenten

De hostingprovider van ict-dienstverlener ICTZ heeft de storing bij ziekenhuizen opgelost met 'herstelwerkzaamheden op het platform' en heeft componenten vervangen in het datacenter. ICTZ gaat onderzoeken hoe het bedrijf een dergelijke storing in de toekomst kan voorkomen.

ICTZ gaat kijken naar mogelijke andere leveranciers voor de internetverbinding van het datacentrum, zo stelt het bedrijf in een statement aan Tweakers. "We onderzoeken de storing met het datacentrum, de huidige internetprovider en mogelijke andere leveranciers", aldus woordvoerder Pauline Altena. "Na het onderzoek en de evaluatie zal beoordeeld worden welke maatregelen getroffen gaan worden om een dergelijke storing in de toekomst te voorkomen."

Het bedrijf ontdekte de oorzaak van de storing donderdagmiddag. "De verbindingenleverancier van ons datacenter kampte met problemen. Hierdoor konden patiënten zich tijdelijk niet digitaal aanmelden bij hun zorginstelling en zijn zorgverleners overgestapt op reguliere telefoongesprekken in plaats van videoconsulten. De noodzakelijke zorg heeft geen hinder ondervonden en patiëntbehandelingen zijn doorgegaan."

De storing legde het patiëntenportaal van diverse ziekenhuizen plat. Het ging om het Isala-ziekenhuis in Zwolle, de ZorgSaam Zorggroep in Zeeuws-Vlaanderen, de Noordwest Ziekenhuisgroep in onder meer Alkmaar, het Diakonessenhuis in Utrecht, Sint Jans Gasthuis in Weert en het Dijklander Ziekenhuis in onder meer Purmerend.

Reacties (50)

[monotype]

zie UPDATE onderaan

ICTZ is in essentie z'n eigen ISP.

ICTZ opereert als "Autonoom Systeem" op internet. Dit wil zeggen dat ze een "AS-nummer" hebben: AS212922, en ze beheren hun eigen IP-ruimte. Ze zijn een "LIR" oftewel "Local Internet Registry":

https://apps.db.ripe.net/...B1-RIPE&type=organisation

Als je je eigen ISP bent, dan ben je zelf verantwoordelijk voor je aansluiting op het internet. Dit doe je door afspraken te maken met andere partijen over peering (het uitwisselen van verkeer met andere andere Autonome systemen) en transit (het doorsturen van verkeer), en door het "announcen" van je IP-ruimte via BGP.

ICTZ heeft een enkele aansluiting met internet, via Broadband Hosting B.V.

https://bgp.he.net/AS212922

Broadband Hosting B.V. heeft wel meerdere "peers":

https://bgp.he.net/AS24785#_peers

Mischien dat ICTZ z'n ISP-zijn heeft uitbesteed aan Broadband Hosting B.V.
Als dat zo is, dan is de vraag waarom Broadband Hosting het niet wat netter heeft opgelost. Als dat NIET zo is, is de vraag een beetje of ICTZ wel als Autonoom Systeem zouden moeten willen opereren: Als AS hoor je gewoon >= 2 peers te hebben. Snel door het lijstje van AS24785 (Broadband Hosting B.V.) bladerend hebben al hun peers BEHALVE ICTZ zelf ook weer meerdere peers, zoals het hoort.

UPDATE:

Het lijkt er op dat de patientenportalen NIET onder deze ASN vallen, en dat problemen hier ook niets mee te maken hebben. Als het een "slapende" ASN is dan kan ik het wel begrijpen dat ze weinig peers hebben, en daarmee was bovenstaande een beetje een "wild goose chase".

Sorry voor de ruis.

Voor alle getroffen partijen hoop ik dat de storing permanent verholpen is.


Addendum:

In het kader van "full disclosure", via ripe kun je meer info vinden: https://apps.db.ripe.net/db-web-ui/fulltextsearch.

[Reactie gewijzigd door monotype op 22 juli 2024 14:07]

[oscar]

Ben het helemaal met je eens qua hobbygehalte maar ik vraag me af of dit verkeer over the top loopt.

Enkele jaren geleden heb ik aan het netwerkontwerp mogen meewerken voor de verschillende ziekenhuizen en hun partners in zuid Nederland. We waren er snel uit met alle deelnemende partijen, we hebben een inkoopcombinatie gevormd en een glasvezelring aangelegd die alle locaties redundant (fysiek gescheiden) verbindt. Uiteindelijk hebben we de serviceproviders ingekoppeld op een centraal punt via laag 2 (dmv VLANS). Het netwerk liep als een zonnetje, maar probleem wat toen ontstond was de betrouwbaarheid van de connectie van de dienstaanbieder (ik noem geen namen). Dat hebben we opgelost door de dienstaabieders op twee separate locaties in te koppelen.

Ik ga ervan uit dat ICTZ ook op laag twee connecteert met de verschillende ziekenhuizen (die vervolgens hun eigen glasvezelringen hebben of de afzonderlijke locaties verbonden met ICTZ). Laten we er vanuit gaan dat ICTZ voor dit soort kritieke toepassingen ook over redundantie heeft nagedacht. Maar wellicht hebben ze dat als verantwoordelijkheid bij de leverancier van de verbindingen gelegd en niet doorgepakt door ook de fysiek gescheiden redundantie te controleren. Het komt vaak voor dat de glasvezels, zelfs van verschillende leveranciers, in een zelfde kabelbed liggen. Een platte lus.

Wat me zorgen baart is dat ICTZ maar beperkt openheid van zaken geeft. In de pers lees je niet het volledige verhaal, maar ook nergens op hun website. Dit is niet meer van deze tijd. Hopelijk worden de klanten wel volledig geïnformeerd.

[Pikoe]

e-mail van ICTZ:

Extra aankondiging werkzaamheden Metro Platform Equinix

Om de kwaliteit van onze dienstverlening te verhogen, passen wij onze hostingomgeving regelmatig aan. Wij vinden het belangrijk dat u tevreden bent en blijft over onze diensten. Veel aanpassingen voeren wij door, zonder dat u daar hinder van ondervindt. Echter, kan het voorkomen dat wij werkzaamheden moeten verrichten waardoor onze diensten tijdelijk niet of beperkt beschikbaar zijn. Uiteraard proberen wij de gevolgen voor u zoveel mogelijk te beperken. Ditmaal betreft het onderhoud door meerdere partijen en zal ook Equinix zelf acties uitvoeren waar we u van op de hoogte willen stellen.

Onderhoud
Op XX oktober a.s. wordt noodzakelijk onderhoud gepleegd door onze datacenter leverancier Equinix aan het Metro Connect netwerk. Hierdoor wordt de volledige verbinding twee maal kortstondig onderbroken in een periode tussen XX en XX uur. Dit betekent voor uw organisatie dat er twee keer een moment van 5 tot 10 minuten geen verbinding mogelijk is met de geleverde diensten.

De volgende diensten zijn op dat moment tijdelijk niet beschikbaar:
Lijst verwijderd wegens bedrijfsgevoelige informatie

Werkzaamheden
Vorige week is een verstoring geweest bij onze leverancier Equinix. Deze verstoring werd veroorzaakt door een XM-chip-storing op één van de lijnkaarten in het core segment van het Equinix Metro Connect netwerk. Deze defecte lijnkaart wordt vervangen door een nieuwe kaart. Tijdens het verwisselen van de kaart zal een korte onderbreking aanwezig zijn. Na het vervangen van de lijnkaart zullen de diensten weer online komen.

Als gevolg van de aangekondigde werkzaamheden is ICTZ genoodzaakt om in samenwerking met leverancier Equinix de internetlijn weer redundant te maken. Om deze redundantie te herstellen dient de internetleverancier configuratie aanpassingen door te voeren naar de configuratie, zoals deze voor de verstoring bestond. Helaas kan dit niet zonder downtime. De internetlijn dient handmatig actief te worden gemaakt in ons datacenter in Amsterdam. Omdat onze firewalls nu geen gebruik maken van het HA-adres dienen we ook de firewall handmatig actief te maken in Amsterdam. Na deze failover is de redundantie weer hersteld en zal de primaire verbinding weer terug worden gesteld naar ons datacentrum in Zwolle.

Wat kunt u doen?
Op basis van deze mail kunt u eindgebruikers informeren dat er onderhoud plaatsvindt waar naar verwachting een korte verstoring van is te verwachten. U kunt relevante leveranciers op de hoogte stellen dat wij een onderhoudswindow hebben, zodat zij eventuele monitoring tijdelijk kunnen aanpassen. Dit is vooral bedoeld om communicatieproblemen te voorkomen tijdens meldingen van verstoringen als gevolg van dit onderhoudswindow.

Het is wenselijk dat bij u een achterwacht bereikbaar is voor vragen van eindgebruikers die indien nodig uitleg kan verschaffen over de geplande werkzaamheden en de mogelijke impact die eindgebruikers kunnen verwachten.

Voor vragen of aanvullende informatie kunt u contact opnemen met de afdeling Klantondersteuning via telefoonnummer: 088-xxxxxxx of via e-mail: [e-mail].

[Reactie gewijzigd door Pikoe op 22 juli 2024 14:07]

[wica]

Het artikel zegt niet zoveel. Enige zinnige wat er uit halen valt is dat ICTZ afhankelijk was van één enkele internet leverancier.
Wat denk in hun best kwalijk te nemen is, aangezien de dienst die ze leveren.
Voor in de toekomst een 2de leverancier.

[coolkil]

Denk niet dat het hier gaat over internet. Denk dat ze dedicated lijnen afnemen bij een enkele leverancier. Dat hoeft geen probleem te zijn als al die lijnen een losse entiteit zijn.

[Blokker_1999]

Maakt niet uit of het een dedicated lijn is tussen locaties of via het internet gaat. Als de lijn een probleem heeft dan gaat deze neer. Gezien meerdere ziekenhuizen er last van hebben gaat het al niet om een dedicated lijn direct tussen de locaties, in het beste geval dus MPLS. Maar ondanks dat blijft het principe het zelfde. Je wil een tweede, totaal onafhankelijk lijn hebben. Dus niet van dezelfde carrier, niet dezelfde last mile provider.

[Scriptkid]

of je doet het echt goed en zorgt dat je 2de DC hebt ,

Zo vaak gezien dat redudancy toch op een been draait ergens als je maar 1 dc hebt. dus waarom zoveel moeite, energy en kosten steken in iets wat uiteindelijk toch failed, het is net een data backup systeem , kost heel veel en als je het nodig hebt werkt vaak niet.

Dan hoef je helemaal geen redundancy te hebben en werk je met het principe elke DC is een eiland wat zo simple en cost effectief is. Elke fout resulteerd in de zelfde situatie dat een ander server, of eiland het werk over neemt.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 14:07]

[swhnld]

Een 2de DC en maar 1 leverancier van de verbindingen? Je hebt beide dubbel uitgevoerd nodig wil je hoge beschikbaarheid bieden.

[Scriptkid]

nee hoor,

en volgensmij snap je het eiland principe niet helemaal,

Dat houd juist in dat alles kapot mag in een dc omdat het single is uitgevoerd en juist een failover ergens anders heeft staan.

Dat houd ook in dat elk eiland dus zijn eigen provider heeft etc. en dat je het liefst meerdere eilanden heb waar alles op always on techniek draait ,

[swhnld]

Ook die eilanden moeten de data wel synchroniseren, verifiëren, en bereikbaar zijn. Dus zowel ieder ziekenhuis als ieder DC moet minimaal 2 leveranciers hebben voor hoge beschikbaarheid van de lijnen, idealiter 3 via een constructie van meerdere routes. Ik heb de praktijk ervaring daarmee.

[Scriptkid]

je snapt het volgensmij nog steeds niet en zit vast op de oude manier,

Bij nieuwe manier geef je er totaal niks om als een DC uitvalt dus Ha is niet nodig.

Het ziekenhuis zelf (De client) dient natuurlijk wel een 2 de lijn te hebben maar dat is gewoon internet dus een cheap 4G abo is voldoende.

[swhnld]

Als je op laag 1 van het OSI model kijkt zijn er echt wel verbindingen nodig. Of je dan de routing van het verkeer toevertrouwd aan het alomvertegenwoordigde internet, en het cloud noemt en de bovenste 3 lagen van het OSI model, maakt niet uit. De harde kern is dat er ergens CPU's en Storage e.d. zijn die verbonden moeten worden met een GUI die elders in de wereld op een locatie draait.
Zeggen dat een DC uitval niets uitmaakt is zoiets zeggen als dat melk uit pakken komt. Het klopt deels, maar achter die melkpakken zitten fabrieken, veehouders en vee die ook een rol spelen.

[Scriptkid]

ja duh,

Maar dat is exact het zelfde met jouw super duper 6 verschillende kabels en providers in een single data center als de AMS exchange onderuitgaat.

als je vanuit verschillende landen een internet connectie hebt op andere providers is dat geen issue en zorgen je geobalancers of anycast er voor dat hij altijd bij het up running center komt

[Mexxwelll]

Het lijkt makkelijk wat je zegt, maar momenteel heel lastig.

Ik zelf beheer twee datacenters, hierin hebben we 1 ISP met twee breakouts.

Omdat we geen IP blok meer kunnen krijgen is het voor ons onmogelijk om met BGP te adverteren over meerdere ISPs heen.

Resultaat, een ISP voor local breakout en MPLS voor klantlocaties.

Op die manier hebben we een soort van redundante naar het DC toe, maar van WAN naar LAN wordt het een stuk lastiger.

Je wilt niet bij iedere storing alle DNS settings aanpassen.

[bbob]

Uiteindelijk heeft alles met prioriteiten te maken en dus is de vraag heb je dit als ziekenhuis nodig ?

Kan me voorstellen als medische informatie, dossiers, foto's niet lokaal opgeslagen zijn, ja dan moeten die altijd beschikbaar kunnen zijn, dus alles dubbel.

[swhnld]

Laatst met mijn ouders gezien, voor een bezoek moesten ze vragenlijsten in de ziekenhuis cloud invullen. Ze zijn ouder en niet ervaren ermee, en vroegen mijn hulp met inloggen met DigiD, etc.
Zo een omgeving moet het dan wel doen, anders maak je het voor de patiënten alleen maar erger, naast de stress van ziekenhuis bezoek ook de stress dat iets niet lukt wat de dokter je vraagt te doen.

[JeroenH]

Het is nogal offtopic natuurlijk, maar in het algemeen vind ik dat de digitalisering van systemen waarmee letterlijk alle Nederlanders moeten kunnen omgaan, ongeacht leeftijd, opleidingsniveau, taalkennis, afkomst, "mate van handigheid met computers" e.d. te snel gaat. Een beetje Tweaker navigeert moeiteloos langs systemen als DigID en door zo'n patiëntenportaal. Maar (als voorbeeld) iemand van 70 die zijn of haar hele werkzame leven geen computer heeft aangeraakt lukt het gewoon niet zo makkelijkom "even" een verlopen DigID te resetten, een account aan te maken in een patiëntenportaal, een PDF met een verslag te downloaden en bekijken etc. Daar zitten gewoon te veel concepten achter die een dergelijk persoon gewoon niet snapt. Specifiek voor iemand onder medische behandeling is dat nog een extra stressfactor.

Naar mijn mening moeten voor dat soort algemene diensten papieren processen en klassieke loketten nog minimaal tien jaar, en misschien nog wel twintig jaar, overeind gehouden worden.

[bbob]

Zelf als je er mee om weet te gaan moet je nog eens alle voorwaarden elzen waar blijft mijn data.

Vanmorgen formulier van school van mijn kind. App die ze paar keer paar jaar kunnen invullen hoe ze zich op school voelen. Data is onderzoek van een uni. Lees je alles door meld de schoon dat de dat verwijderd zal worden als hij van school gaat. De uni daarentegen zal de data pas na 10 jaar verwijderen. Leuke teksten als beveiligde omgeving, alleen toegang voor onderzoekers.

Vraag me dus hetzelfde af als mijn data bij ziekenhuis ergens in de cloud zit bij aanbieder, hoe veilig is die, wie kan die benaderen maar als deze lokaal niet aanwezig is, ik moet naar ziekenhuis, eerste hulp en mijn dossier is niet op te vragen door een storing wat dan.

[AlphaRomeo]

Een beetje Tweaker navigeert moeiteloos langs systemen als DigID en door zo'n patiëntenportaal.

Correctie: een beetje Tweaker kan met wat manieren en gehannes uiteindelijk zich door zo'n portaal worstellen. Een gewone burger kan dat met hulp van ofwel een goede dosis geluk en meerdere devices, danwel met hulp van een beetje Tweaker ook.

Al met al niet wenselijk. Niet alle portalen en websites zijn gelijk, maar lang niet alle sites zijn goed doordacht. Vaak zit er een hoop vakjargon in, of moet je net het verschil weten tussen een account level, of een digid level. Als je niet dagelijks in die materie zit is het gewoon lastig. Zo'n portaal bezoek je niet elke week namelijk.

[Reactie gewijzigd door AlphaRomeo op 22 juli 2024 14:07]

[Blokker_1999]

Dus in plaats van een reservewiel in de wagen te leggen ga jij een tweede wagen kopen voor het geval je eens lek rijdt.

Als het probleem upstream zit bij je enige ISP dan maakt het niet uit of je 1 of 2 DCs hebt (wie zegt dat ze al geen 2 DCs hebben?). De ISP kan problemen hebben en beide DCs onbereikbaar maken.

2 DCs verhogen sowieso de complexiteit enorm, verhogen de kosten enorm en zijn nog altijd geen enkele garantie dat je geen problemen zult hebben. Voldoende voorbeelden te vinden waarbij een primair DC faalt en de backup er niet in slaagt om over te nemen.

[Scriptkid]

je hebt het nu over active passive DCs , dat is oude wetse manier

Ik heb het over nieuwe manieren die allways on gebruiken en dus active zijn in alle DC`s en een active copie hebben.

Net zoals Domein controllers altijd allemaal mee doen en geen redudancy nodig hebben

[Mental]

Leik voorbeeld wat je daar aanhaalt maar in de praktijk voeren domain controllers meerdere taken uit (rollen) die zeker niet allemaal HA te krijgen zijn (wat eigenlijk wel nodig is) Hierboven wordt je een aantal keer uitgelegd dat je in principe gelijk hebt maar dat het in de praktijk toch net ff anders in elkaar steekt (wat je ook snapr, amders roep je geen zaken als alwayson.. Iets wat suggereert dat er in ieder geval iets synced tussen de locaties), misschien is het een mooi moment om eens iets van een ander aan te nemen. Load balancing in de applicatie is leuk maar juist dan is connectivity naar en tussen de verschillende eilanden nog belangrijker.

[Scriptkid]

Nee juist niet,

ze repliceren hun data en er is er 1 master, is de connectiviteit weg dan neemt een van de remaining alles over,

Dat is de hele essentie van een cluster juist daardoor kan alles single redundant zijn omdat elke fout het zelfde resultaat geeft. Het is wel van essensieel belang dat je je applicatie ook op die manier schrijft maar dat is nu juist het nieuwe allways on stuk.

Kijk bijvoorbeeld naar exchange en SQL die dat principe hanteren. Exchange 16 node cluster kan helemaal terug naar 1 server zonder uitval mits er niet meer dan de helft tegelijk uitvalt en er niet meer dan 2 vd 3 datacenters tegelijk uitvallen. Juist daarom is het belangrijk niet met allerlei core routers in active passive mode te zitten want je routing convergence zorgt er voor dat er bij 1 DC uitval meerdere DC impacted zijn. Terwijl eilanden totaal niks met elkaar te maken hebben en lekker door draaien en de slack overnemen.

Veel kleine eilanden zijn veel goedkoper en minder complex dan een groot redudant eiland.

[Reactie gewijzigd door Scriptkid op 22 juli 2024 14:07]

[Mental]

Dus jij synced applicatie data niet tussen ne eilanden? Superhandig! Waar werk je? Dan mijd ik die toko

[Scriptkid]

Even lezen

ze repliceren hun data en er is er 1 master, is de connectiviteit weg dan neemt een van de remaining alles over,

Waar werk je? Dan mijd ik die toko

Microsoft Premier Field Engineer voor Exchange en Office 365

[Reactie gewijzigd door Scriptkid op 22 juli 2024 14:07]

[GeroldM]

Microsoft Premier Field Engineer voor Exchange en Office 365

En die term houdt in dat je de backup media in het datacenter van de ene plek naar de andere mag dragen ofzo?

Wat serieuzer, je redenering klinkt als iemand die niet goed door heeft dat er voor bepaalde zaken ten alle tijden fysieke connecties en synchrononisatie stappen gezet moeten worden. Want anders werkt je concept niet eens, hoe vaak en heftig je dat ook probeert weg te redeneren.

Het overgrote deel van de Cloud-only generatie heeft bitter weinig begrepen van hoe zaken in de praktijk wel moeten werken/worden uitgevoerd. Vaak door een gebrek aan interesse, want het is niet "nieuw" en 'zo werkt alles toch?'. Moet helaas ook vaststellen dat het onderwijs in scholen en universiteiten op dit gebied al jaren behoorlijke steken laat vallen.

Uiteindelijk profiteren daarmee alleen de Cloud-boeren. Waarom? Dit soort Engineers kan alleen nog maar "kaartenhuizen" bouwen in omgevingen in compleet beheer van eerdergenoemde Cloud-boeren. Zo'n beetje dezelfde principes spelen hier als aan het kopen van een huis en het huren van een huis.
Cloud is hetzelfde als het huren van een huis. Alsmaar blijven betalen, zonder kans dat je ooit eigenaar word. En het is ook zeker niet de huurder die rijker uit deze situatie komt.

Maar ja, je bent al gauw "ouderwets" tegenwoordig, wanneer je twee of drie keer nadenkt over hoe wel of niet een Cloud-omgeving te gebruiken is in een oplossing welke voldoet aan (wettelijk vastgelegde) eisen waaraan het bedrijf (of bedrijfsklanten) moet voldoen.

[Scriptkid]

Dat houd in dat ik grote klanten met tussen de 50-500 exchange servers met wereldwijde deployments in meerdere landen help met het ontwerp, opbouw en implementatie van deze servers met prefferd op deze zelfde methode zoals we deze prositioneren in de Preferred architecture.

https://docs.microsoft.co...2019?view=exchserver-2019

Daarnaast helpen we ze bij het balancen en uitwerken van het netwerk stuk voor deze grote clusters.

Maar uit jullie reactie begrijp ik dat je niet goed snapt wat ik bedoel, ik zeg ook helemaal nergens dat er geen replicatie is. ik geef alleen aan dat je alles met single uitgevoerd kunt implementeren. Servers met Single NIC, Single PSU, Disks direct in JBOD.

Je server is al je zwakste schakel het heeft geen nut om daar zware redundancy voor te zetten met veel complexiteit.

Is de lijn up dan vind er synchronisatie via het cluster plaats, Is de lijn er niet dan neemt het majority cluster de taken over en mount eventuwele missende databases.

Maar dat is altijd de zelfde discussie als waarom zouden we geen SAN gebruiken maar een JBOD doen.

Simple antwoord, non redudante scale out is goedkoper en perfomed beter.

Dit is waarom nieuwe applicaties niet meer op hardware geschreven worden als 1 app maar op componenten in service fabric of kubernetes met kleine losse onderdelen die op die zelfde manier schalen.

[Silver7]

Of anders inrichten, dat ze overfailen naar ander datacenter met ander verbinding?

[swhnld]

Moet er wel data gesynchroniseerd zijn via de verbinding tussen de 2 datacenters. Bij een verbinding storing gaat het daar ook mis dan.

[Silver7]

Daarom juist HA opstelling, gaat het fout in ene datacenter, dan moet de andere datacenter het opvangen.

[Sjaakys]

Kwalijk nemen hoeft niet perse, ligt er maar net aan wat er in het SLA staat tussen de ziekenhuizen & ICTZ. Misschien voldoen ze hier nog altijd volledig aan ondanks de tijdelijke downtime. Dan is de keuze aan het ziekenhuis of ze deze SLA accepteren.

Maar gezien de diensten die ICTZ leveren is het inderdaad sterk aan te raden om een back-up lijn te hebben.

[Uberprutser]

Dat is inderdaad vaak aan de orde. Heb met een aanbieder van dit soort diensten gewerkt welke bij ons twee private cloud omgevingen afnamen. Een voor premium (dus met redunantie op elk niveau) en eentje met een soort best effort SLA (was initieel voor test/dev only). Uiteindelijk wilden hun eindklanten gewoon de beste prijs en was uptime niet belangrijk. Het platform zonder redunantie zat dus meestal vol en maar een aantal klanten op de ander.

Doe eens de gok wanneer de pleuris uit brak? Als er geplanned onderhoud (6+ weken vooraf aangemeld) werd gedaan na kantooruren...

[Reactie gewijzigd door Uberprutser op 22 juli 2024 14:07]

[Cybje]

Als bedrijf is te overwegen om klanten helemaal niet die keus te geven. Want afhankelijk van hoe technisch je klanten zijn kunnen ze die keus niet goed maken, hoe goed het bedrijf het ze ook probeert uit te leggen. Uiteindelijk gaat het om klantervaring en je kunt qua SLA wel gelijk hebben als bedrijf, maar als je klanten ontevreden zijn vertrekken ze alsnog naar een andere partij. Nou weet ik alleen niet hoe makkelijk dat is bij dit soort zorg partijen. Sommige hebben wel een flinke vendor lockin door alleen hun eigen applicaties aan te bieden.

[the_stickie]

Nochtans is het best interessant om een value product te hebben waartegen je de andere kan afzetten. Een goedkope lokprijs op een product dat eigenlijk niet helemaal voldoet aan minimum eisen/garanties is op veel markten niet ongebruikelijk.
Ik ben het overigens niet eens dat de klant zijn SLA/uptime niet zou mogen kiezen. Als dienstenleverancier kan je adviseren, en als je dat goed doet zullen ze de juiste oplossing kiezen.
Op gebeid van hosting kan het best interessant zijn genoegen te nemen met minder (SLA) en het risico erbij te nemen. Er zijn zelfs providers die schermen met 'werkelijke uptime' die beter is dan de gegarandeerde, om klanten te overtuigen dat die strikte SLA niet nodig is. Een eventuele calamiteit heeft dan minder impact.

[Cybje]

Ik ben het 100% met je eens, maar wat Uberprutser aangeeft dat de pleuris uitbreekt juist op het platform van de best effort SLA (en ik heb zelf ook wel van die voorbeelden vanuit mijn werkervaring) geeft wel aan dat dat adviseren toch lastig is. Ik heb zelf ook de ervaring dat sommige klanten bewust kiezen voor lagere kosten, maar dan wel onevenredig boos worden bij een aantal uur downtime terwijl ze dat van tevoren is uitgelegd dat dat mogelijk is bij hun keuze. Klanten raken er alleen vaak ook aan gewend dat het al jarenlang probleemloos functioneert.

[Scriptkid]

Je moet een SLA ook andersom uitleggen,

Niet over uptime praten maar over hoeveel dagen per jaar er niet gewerkt kan worden.

99.9% SLA houd gewoon in dat je een Werkdag per jaar storing hebt en dat je klanten dus een werkdag per jaar niet kunnen werken.

Dus 1000 man a 150 euro per uur = 1000*150*8 = 1.200.000 euro per jaar storings onkosten .

ga je naar 99.99% SLA = 1 uur

Dus 1000 man a 150 euro per uur = 1000*150*1 = 150.000 euro per jaar storings onkosten .

De ham vraag is dan kun je voor die 1 miljoen euro de infra upgraden van 99.9 naar 99.99

[Reactie gewijzigd door Scriptkid op 22 juli 2024 14:07]

[OruBLMsFrl]

Een andere vraag is: gaat jouw leverancier die 99,99% hard kunnen maken, of hebben die er slim aan gerekend door een nog veel te veel gelijkend product van 99,95% als 99,99% te verkopen. Prijs verdubbelen, een astronomische 10% boetegeld op het hele jaarcontract aanbieden als zij de SLA niet halen. Jij denkt, dat zit goed, anders durven ze die boete clausule nooit aan. Voor die aanbieder ziet het er dan echter zo uit:

99,9% SLA:
150.000 euro per jaar omzet tegen 100.000 euro kosten en € 1.500 boetegeld (1%)
€ 48.500-50.000 per jaar marge, altijd zoiets 33% van de omzet

99,99% SLA:
300.000 euro per jaar omzet tegen 150.000 euro kosten en als het eens goed misgaat elke drie jaar € 30.000 boetegeld (10%)
€ 120.000-150.000 per jaar marge, schommelend tussen 40% en 50% van de omzet

Dan denk jij, goeie deal zo'n 99,99% SLA voor 'slechts' het dubbele maandtarief, daar ga ik heel veel risico mee vermijden en zo uiteindelijk besparen. Betalen zij je echter fluitend die € 30.000 iedere drie jaar bij een veel te lange storing en maak jij in zo'n jaar alsnog die 1,2 miljoen euro aan storings onkosten. Daardoor heb je dan uiteindelijk niet de door jou verwachte storingskosten van over drie jaar totaal € 450.000, maar opeens € 1.470.000. Uiteraard netjes die € 30.000 restitutie er al afgehaald.

Die aanbieder heel blij met 40% marge zelfs in dat slechte jaar, iedereen toch een bonus. Uiteindelijk alsnog een winstverdubbelaar gebleken vergeleken met het 33% marge product van de 99,9% SLA. Hoe happy ben jij? Ga je van aanbieder wisselen na één keer 8 uur downtime in 3 jaar en een heel fijne klantervaring achteraf waarbij ze ruimhartig excuses aanbieden en die SLA penalty snel beschikbaar stellen? Kan zoiets toch niet ook alsnog bij een andere aanbieder voorkomen?

[Gomez12]

Een SLA zegt helemaal niets over hoeveel dagen per jaar er niet gewerkt kan worden...

Een SLA zegt alleen wanneer je een grijpstuiver terug gaat krijgen bij uitval.

Als een graaf machine per ongeluk de fibers van het DC doorsnijd gaat er niemand kijken welke fibers van SLA-klanten zijn en welke niet, er worden gewoon nieuwe fibers neergelegd en de storing duurt voor alletwee net zo lang.
Alleen met een SLA krijg je een vergoeding, alleen die betaal je in 1e instantie gewoon driedubbel in je contract en is feitelijk niets omdat je altijd gevolgschade hebt die weer buiten de SLA valt.

Of om in jouw voorbeeld te blijven, als die SLA kabel eruit ligt voor 1 dag heb je dus 1,2 miljoen "schade" en vanuit je SLA ga je mogelijk 10.000 terug krijgen...

[Scriptkid]

Dat is dus maar net hoe je het bekijkt,

De hoster mag dus gewoon op 30 december alle servers uit zetten en jij mag dan niet gaan klagen.

dat is dus precies wat je zegt ge accepteerd het dat je 8 uur down time hebt en er niet gewerkt kan worden en dus 1.2 mil schade loopt zonder enig gevolg.

[Gomez12]

Oh, wow maar met een SLA mag je wel gaan klagen als datzelfde gebeurt...
Alleen voor al je geklaag krijg je waarschijnlijk max 10.000 terug..

Waarbij je waarschijnlijk per maand 5.000 extra betaald alleen voor die SLA.

Oftewel qua geld ben je 1,2 mil kwijt + 60.000 - 10.000 maar je mag dan idd wel klagen.

Misschien dat jij je servers uitzet op 30 december om je klanten maar te krijgen naar een hogere SLA, maar een normale leverancier zal dat niet doen.

[Scriptkid]

ik weet niet hoe het bij jullie gaat maar het aantal en duur van de outages op 2x9 vs 4x9 is meestal toch echt wel een groot verschil wat inhoud ja dat je mag klagen als het wel mis gaat maar over een 5 jaar periode gemeten er ook een heel stuk minder mis gaat dan op de 2x9. Oftewel het schade bedrag door outage een stuk lager uitvalt.

Volgens jouw redenatie zou dus niemand naar 4x9 moeten gaan want is duur en je hebt zelfde uptime.

[twiet]

Maak van deze gebeurtenis een kans door er de accountmanager op af te sturen die uitlegt dat als klanten de beste uptime willen, zij het beste af zijn met de premium versie.

Ik werk bij een bedrijf die IT diensten levert zonder 24x7 uptime met flinke maintenance windows. Onze klanten weten dat, accepteren dat en betalen daar ook naar.

[wica]

Ik ben benieuwd, in hoever ICTZ toch nog aansprakelijk is. Ook al wilde de klant(en) niet betalen voor zo'n extra verbinding.

https://www.nu.nl/tech/60...-aan-klant-vergoeden.html

Hoewel er niets op papier stond over het beveiligen van het netwerk, mocht O'Cliance er volgens de rechter van uitgaan dat de beveiliging ook onderdeel van de opdracht was.

[Ootje70]

ICTZ zal met de hostingprovider afspraken moeten maken over redundantie van de infrastructuur componenten. Het is niet ICTZ die de infra beheert, kan zijn dat zij alleen betalen voor een enkelvoudig uitgevoerde infra, dan is het aan de servicemanager om de klanten uit te leggen waarom men de beschikbaarheid niet haalt (als dat met deze storing al het geval is). Dit is het nadeel van werken met een provider, weet je hoe deze de infra geregeld heeft? Wat zijn de afspraken met hen en hoe vertaal je dat door naar diensten die je aanbiedt aan jouw klanten. Wat is de veiligheidsmarge die je hebt...

[Reactie gewijzigd door Ootje70 op 22 juli 2024 14:07]

[PrinsPace]

Beetje zwakke reactie om te zeggen dat noodzakelijke behandelingen geen hinder ondervonden hebben. Ik zou de massa's mensen die ineens handmatig bij de balies moeten aanmelden en waarvoor extra collega's vanachter hun cocktail vandaan getrokken moeten worden toch wel scharen onder de noemer 'hinder'.

[eric.1]

Je reageert op een opmerking over noodzakelijke behandelingen met een opmerking dat ze wel in algemene zin hinder hebben ondervonden

Indien alle noodzakelijke behandelingen zonder al te veel vertraging zijn doorgegaan, dan klopt dat toch?

[PrinsPace]

Edit: Welja, vier maal -1. Ik ben gewoon terecht kritisch op de berichtgeving van ICTZ, gisteren was het eerst al 'het ligt niet aan ons'. Maar zoals hier ook al blijkt in de +3 reactie, hebben ze een zwakke infrastructuur. Daarvoor zijn ze zelf verantwoordelijk, dus aangeven dat noodzakelijke behandelingen geen hinder hebben ondervonden vind ik een zwakke reactie. Je bent als dienstverlener ook verantwoordelijk voor je onderaannemers richting je klanten.

[Blokker_1999]

En jij gaat er van uit dat die +3 comment volledig correct is? Het is een goede analyse, maar we kennen de setup van hen niet. Wij hebben als onderneming ook ons eigen AS nummer, onze eigen peering overeenkomsten maar we hebben in onze DCs daarnaast ook nog eens commerciële internetverbindingen.

[monotype]

Inderdaad, niet volledig correct naar blijkt:

<quote>
Het lijkt er op dat de patientenportalen NIET onder deze ASN vallen, en dat problemen hier ook niets mee te maken hebben. Als het een "slapende" ASN is dan kan ik het wel begrijpen dat ze weinig peers hebben, en daarmee was bovenstaande een beetje een "wild goose chase".
</quote>

[tweakkjoost]

Durf te wedden dat er al grof geld wordt betaald voor dit nieuwe systeem en dit gebruikt gaat worden om de prijs nog wat omhoog te krikken terwijl het standaard al goed geregeld had moeten zijn.