Dns-storing Akamai kwam door update softwareconfiguratie

De dns-storing bij Akamai die donderdagavond grote hoeveelheden sites wereldwijd onbereikbaar maakte, kwam door een bug die werd veroorzaakt door een update van een softwareconfiguratie. De storing duurde een uur.

De configuratie-update veroorzaakte om donderdag om 17.46 een bug in het dns-systeem van Akamai. Door deze update terug te draaien, was de storing een uur later verholpen. Dat meldt Akamai in een korte update. Volgens het bedrijf had de storing 'impact op sommige websites van klanten'. Volgens het bedrijf vond er geen aanval plaats op het platform van Akamai. Details over de update en de impact geeft het bedrijf verder niet.

Donderdagavond was een groot aantal websites wereldwijd onbereikbaar door de dns-storing. Veel bedrijven nemen Akamais Edge DNS-dienst af, juist om websites beschikbaar te houden, ook als ze bijvoorbeeld doelwit van ddos-aanvallen zijn. De op IP Anycast gebaseerde dienst van Akamai maakt gebruik van duizenden nameservers in meer dan 140 steden wereldwijd om weerstand te bieden tegen aanvallen.

Dat het een risico is dat sites zo op diensten van grote partijen leunen om bereikbaar te zijn, bleek eerder dit jaar bij een storing van cdn-dienst Fastly. Ook die storing leidde ertoe dat sites wereldwijd onbereikbaar waren. Door de storing bij Akamai waren onder andere sites van media en banken onbereikbaar. De omvang van de storing leek op Downdetector wel groter dan deze werkelijk was: die site maakt gebruik van postings op sociale media om een indicatie van storingen te geven. Veel gebruikers plaatsten meldingen met betrekking tot mogelijke storingen bij Google, AWS en Cloudflare, maar deze bedrijven hebben hun eigen dns-diensten die niet getroffen waren.

Netwerkanalysebureau Thousand Eyes heeft de impact van de storing in kaart gebracht. Volgens het bedrijf verschilde de impact sterk per klant. Een deel van de klanten in Akamai's cdn-netwerk was geheel niet bereikbaar terwijl Amazon dat bijvoorbeeld wel was, omdat het naast Akamai andere cdn-netwerken en zijn eigen dns-dienst gebruikt.

Reacties (124)

Dit is dan ook de reden waarom ops mensen niet van upgrades houden. Altijd een kans dat er wat fout gaat. En vaak is de enige reden om te upgraden dat een product naar end-of-support gaat, niet dat nieuwe functionaliteit nodig is.

De grap is juist dat je het moet omdraaien. Je moet upgrades omarmen vanuit operations en zo regelmatig mogelijk uitvoeren, zodat het proces volledig onder controle is en blijft. Natuurlijk gaat het soms mis, maar dan voer je gewoon het rollback plan uit (en in een optimale situatie detecteert je load balancer/reverse proxy dat je systemen/VM's/containers die geüpgraded zijn niet goed functioneren en stuurt er helemaal geen verkeer naar toe). Routine erin hebben zorgt voor vertrouwen in je backup en rollback plan.

Dus ik doe ops en ben juist voorstander van vaak upgraden

Tot een manager aan het eind van de dag belt en zegt:

"Hey! Functie X werkt niet meer".

Ohh dan doen we toch gewoon een rollback

"Ja prima, en waar gaat m'n data dan heen van vandaag?"

Mijn klanten kunnen het in ieder geval wel waarderen dat we gezamelijk kijken wat een update oplevert. We hebben al vaak zat moeten constateren dat een update niet nodig is omdat de problemen die worden opgelost niet relevant zijn voor de organisatie.

Als je data van een dag verdwijnt door een rollback, is er iets niet goed met je rollback scenario. Klinkt misschien een beetje bot, maar dat is juist een belangrijk onderdeel, anders kun je toch nooit een rollback doen?

En een upgrade zonder werkend rollback scenario kan nooit (hoe vaak/weinig je ook een upgrade doet), dat is gewoon hard YOLO roepen.

Ik moet het eerste rollback plan (ontwikkelaars daargelaten) nog tegenkomen waarin staat beschreven hoe men tijdens de rollback om denkt te gaan met de data die NA een sql schema change is verwerkt. Laat staan dat men het ook vooraf test..

Maar het is goed om te lezen dat het elders beter is geregeld

Je houdt normaal gesproken bij SQL schema changes er rekening mee dat de vorige versie van je applicatie er ook gewoon mee overweg kan. Extreem versimpeld voorbeeld: voeg een tabel toe, in plaats van wijzigingen in de structuur van een bestaande tabel te maken. Of als dat echt niet mogelijk is, moet er een rollback script worden gemaakt die dit geautomatiseerd voor je doet, wat natuurlijk nodig kan zijn bij major upgrades.

Kan zijn dat je leidinggevende/klant/whatever er geen zin in heeft dat je die tijd erin stopt, dan kun je ze de risico's uitleggen en laten accepteren.

Ik snap ook wel dat je dit natuurlijk niet doet voor de website van de bakker om de hoek. Voor grote applicaties is hier gewoon budget en mankracht voor.

Ter aanvulling: ik ben rondom upgrade processen soms langer bezig met het rollback plan dan het upgrade plan en de upgrade bij elkaar. Dus ik snap dat dat het lastigst is. Maar wel belangrijk.

[Reactie gewijzigd door Cybje op 23 juli 2021 17:06]

Zelfs als zou je de enorme effort nemen om je database changes rollback-baar te maken, wat vaak gewoon niet mogelijk is i.v.m. destructive changes in 2 richten. Data die naar buiten gegaan is, is niet meer terug te draaien.
Je hebt maar 1 rollback moment, en dat is voordat er nieuwe data door je systeem heen gaat.

Je wilt ook geen rollback doen van je data, zeker niet data die is uitgewisseld met externe partijen, je wilt een rollback doen van je applicatie. Daar houd je rekening mee bij ontwikkeling van je applicaties in je database structuur en bijvoorbeeld API versies met externe partijen. Ik zeg ook niet dat het simpel is, maar het is niet onmogelijk vaak. Mensen hebben alleen vaak geen zin om er tijd in te stoppen.

Als je een applicatie framework gebruikt die zelf tabelstructuren aanmaakt ( al dan niet gegenereerd vanuit je eigen code ) dan gaan dit soort dingen in de praktijk toch allemaal net niet zo eenvoudig als in de theorie.

Onze ervaring is dat het vaak eenvoudig is om "gewoon" het probleem te fixen dan het is om terug te gaan naar een vorige release.

Als je je applicatie van de basis opbouwt dan zou je natuurlijk wel rekening kunnen houden met dit soort principes.

Ook kun je dan blue/green deployments toepassen waarbij je een bepaald percentage van je bezoekers uit laat komen op je nieuwe release en eerst even afwacht of die nog bugs tegenkomen voordat je iedereen overzet naar de nieuwe productie release.

In de praktijk echter zijn de meeste van deze technieken te ver gegrepen omdat je applicatie leunt op een framework wat hier gewoon niet goed mee omgaat. Backwards compatibility regelmatig nog wel. Maar forward compatibility garanties zijn toch erg zeldzaam in frameworks.

Als direct duidelijk is dat het eenvoudiger is het probleem te fixen dan het rollback plan uit te voeren, spreekt het voor zich dat je dat moet doen. Ik heb een beetje het gevoel dat iedereen met allemaal uitzonderingen aan het reageren is op mij. Uiteraard zijn mijn reacties niet 100% toepasbaar op alle situaties. Wat zou het leven dan makkelijk zijn.

Inderdaad goed om te lezen en Cybje gaat nu uiteraard uitleggen hoe dat in zijn rollback plan geregeld is.

Het ligt heel erg aan wat voor soort applicatie je werkt. Als jouw applicatie aandelen verhandeld op particuliere aandelenbeursen, dan valt er niks te rollback-en, want de seconde is al voorbij. Dan is het gewoon jammerdebammer (maar dan voor miljoenen euro's )

Als je applicatie allerlei rapportages verwerkt van andere software, dan kan je mogelijk de bronbestanden opnieuw laten aanbieden enz. Er valt niet iets generieks over te zeggen. Sommige applicaties zijn nou eenmaal zo dat een rollback niet mogelijk is zonder dataverlies, maar daar is de applicatie dan ook op ontworpen als het goed is.

Leuk bedacht maar je bent je bewust dat de meeste software/systemen geen rollback scenario's ondersteunen? Daar kun je wel iets op verzinnen maar dat kost soms belachelijk veel geld, in andere gevallen kost het vooral tijd om een rollback te doen, dat betekend dus altijd een verstoring van dienstverlening. Kortom upgrades brengen altijd risico's met zich mee hoe goed jij ook denkt alles voor elkaar te hebben.

Akamai is geen kleine speler hè? Ze zijn hier niet bezig individuele servers te beheren. Zo'n argument komt voor bij een bedrijf wat eigen data en eigen gegevens op een handvol servers en systemen heeft staan, maar niet bij CDNs. Daarnaast is de data binnen een CDN per definitie transient. Het is (zwaar vereenvoudigd) een soort van DNS-cache op steroïden.

zodat het proces volledig onder controle is en blijft. Natuurlijk gaat het soms mis

hmmmm.

JA updates zijn nodig, JA, vaak leveren ze een risico op voor de business.
Iedere update/grade is een verstoring, hoe klein ook. de kunst is om die impact te minimaliseren en soms kan dat inderdaad betekenen dat het verstandiger is om een klus niet uit te voeren of uit te stellen.

Wat ik ook mis in jouw visie is hetgeen waarvoor je het doet. ITIL gelul, maar helaas wel waar: Welke waarde voeg je toe met die ene update/grade voor jouw business? Operations is van (bijna) geen enkel bedrijf core business.
Indien die waarde niet inzichtelijk te maken is... is er ook geen reden om uit te voeren.

Update/upgrades omarmen enkel omdat operations dan in control blijft.. Is in veel bedrijven en instanties geen steekhoudend argument. De meeste management teams die ik heb meegemaakt hakken je kop eraf als je enkel daar mee aan komt. Ja, het is een mooie ondersteuning voor een andere belangrijker argument maar... niet meer dan dat. (Door deze update uit te voeren verkleinen we het risico op xyz en daarnaast blijft operations beter in control waardoor de dienstverlening van een hoger niveau blijft.... zoiets, dan kan het wel.)

Overspannen Sales Manager: "Dus ik kan in het slechtste geval een dag niks verkopen omdat JIJ in control wil zijn?" (bulder, verwensing, etc.)

Dat soort gesprekken gaan nooit goed.

Uiteraard moet het nut hebben om te upgraden, maar dat spreekt mijn inziens voor zich. Je moet niet voor de lol wekelijks upgrades gaan uitvoeren puur als bezigheidstherapie. Maar als er actief ontwikkeld wordt aan systemen (nieuwe features, oplossen bugs, oplossen vulnerabilities) dan heb je zeer regelmatig nieuwe versies en loont het dus ook om zeer regelmatig te upgraden.

Hoe dan ook, het is altijd slim om het proces onder controle te houden. Als je een keer met spoed een upgrade moet uitvoeren, bijv. om een belangrijke kwetsbaarheid op te lossen, dan wil je dat doen met vertrouwen in het upgrade en rollback proces. Alternatief is dat je het systeem uitschakelt, of dat je de kwetsbaarheid laat zitten (met mogelijke hack tot gevolg), maar die opties gaan ook geen gezellig gesprek met je Sales Manager opleveren.

Klopt. Gelukkig hebben de grote productent van software wel een patchkalender. Dan kun je precies zien wanneer de patches eraan komen. Bij Oracle is dat dacht ik elk kwartaal. Als je dan 1 maand wacht en de Oracle support fora in de gaten houdt, zie je vanzelf wanneer er grote problemen zijn.
Wij hebben zelf wel eens problemen gehad bij een upgrade, die we met testen gelukkig hebben gemerkt (niet in eerste instantie gek genoeg) en het duurde even voor we doorhadden dat het echt een probleem in Oracle zelf was en niet persé aan ons. Gelukkig was er een patch voor en konden we aanvullende zaken fixen met instellingen. Maar daar test je voor. In dit geval verwachtten we wel eea aan problemen met de performance omdat het een grote update was en de optimizer aangepast was. Dan heb je zeg maar 100% kans dat er bepaalde queries omvallen. Soms kan er iets crashen door timeouts, maar meestal duurt het dan gewoon erg lang. Dat is dus de reden om de boel te testen en zorgen dat je voldoende tijd daarvoor neemt. Dit soort problemen heb je uiteraard niet bij elke parch (anders zou niemand willen patchen), maar bij een versie upgrade heb je dat vaak wel. Maar zoals gezegd, dat zijn dingen je weet (of zou moeten weten) als specialist en je zorgt dat je daar op plant.

Maar waarom moet ops een reden geven dat ze onderhoud uitvoeren? Iedereen accepteerd het dat de auto jaarlijks voor een beurt moet. Energiecentrales hebben terugkerende stops, raffinaderijen doen turnarounds, waarom zou dat bij software dan anders moeten zijn?

Je moet kunnen aantonen dat het nodig is. Zijn er security redenen? Is er iets instabiel? Missen we functionaliteit die we hard nodig hebben? Lopen we een onnodig ander risico?

Bij ieder voorbeeld dat jij geeft heb je het over machines, machines slijten. Remmen worden slechter, banden verliezen profiel, turbines missen bladen of hebben beschadigde bladen, buizen vertonen haarscheuren. Dat verval en bijkomende risico's en verlies aan rendement is aantoonbaar, bewijsbaar. Er is dus ook daar een aantoonbaar bewezen nut voor het onderhoud. Zonder dat nut zou niemand het doen.

Hetzelfde geld voor IT: ieder onderhoud wat er wordt uitgevoerd betekend dat het bedrijf op dat moment niet zijn core business kan uitvoeren. het kost dus geld. Je moet daarom het nut kunnen aantonen.

het is een weegschaal: DIT winnen we en DIT kost het. (en "kost" is niet enkel geld maar ook tijd, etc.)

Als je security in IT begrijpt dan weet je dat je continu updates moet uitvoeren immers eenmaal een security update gereleased is gaat men gaan reverse engineeren wat die update juist aanpast. Het is het perverse effect van updates uitbrengen, je roept tegen heel de wereld waar je ongeveer een probleem hebt en je geeft files vrij die je kan vergelijken met de oude om precies te bepalen wat voor lek het is.

Daarnaast trek je ook aandacht naar dat specifiek onderdeel, het heeft heel lang geduurd voor het eerste Spectre lek gevonden was maar daarna kwam het een na het andere. Zelfde met de printer spooler, na een eerste lek vind men daar nu het een achter het andere omdat allerhande partijen nu heel expliciet in die richting aan het zoeken zijn.

Een andere factor die vaak in dit soort discussies vergeten word, jij wilt enkel de updates die een duidelijke meerwaarde betekenen en de rest niet, een situatie die ik professioneel maar al te goed ken. Echter die updates bouwen verder op elkaar, ik kan niet applicatie update 25 installeren als update 20-24 niet geïnstalleerd is tenzij update 25 ook de wijzigingen doorvoert van 20-24 maar dat heeft hetzelfde effect:
Plots heb ik 10 bladzijden release notes waarbij je een gigantische big bang aan wijzigingen hebt. Ik wil geen big bangs in updates en productie wilt dat ook niet want als er dan iets fout loopt, begin maar te zoeken als je plots 3 jaar aan updates in 1 keer installeerd.

Daarnaast word dat ook zo niet getest door leveranciers/fabrikanten. Dan krijg je situaties waarbij server B niet meer met server A praat want 2 jaar geleden was er een of andere protocol dat uitgefasseerd was echter server B staat op de laatste versie waar dat protocol volledig uit staat terwijl server A de eerste update om dat protocol uit te faseren nog moet krijgen met alle gevolgen van dien.

Of je update de IPMI waarna de server blijft hangen als je de bios firmware wilt doen omdat de huidige IPMI de oude bios versie niet ondersteund. Dan moet je eerst tussen updates doen of je server is voor de vuilbak, been there done that. (vergelijkbaar probleem met het vorige)

Ik ga volledig akkoord dat updates risico en costs met zich meebrengen maar die moeten gemanaged worden in een lifecycle. Echter als een manager afkomt met enkel updates als ze duidelijk een meerwaarde voor productie betekenen, dan weet ik al dat het prijs is.

De update is er niet voor niets he. Misschien niet direct van invloed op je proces, maar alle fixes die je niet uitvoert zijn als de haarscheurtjes in een mechaniek. Uiteindelijk komt er een keer een update die wel belangrijk is, en dan moet je wel, maar dan kost het meer geld, moeite, en tijd, omdat dit niet een standaard proces is en omdat er dan meer dingen incompatibel zijn omdat je zover achter loopt.

En dan kom je al vlug bij wat @mphilipp zei: updates niet uitvoeren is een dure manier van geld besparen.

Iedereen accepteerd het dat de auto jaarlijks voor een beurt moet.

Iedereen? Grapjas

Als je erg lang geen updates doet /want geen relevante functionaliteit/ en je moet dan ineens iets patchen, dan kun je goed pech hebben en ineens 10 SP level levels omhoog moeten. Dat is een leuke verrassing met regressie testen als je snel een prio 1 CVE security issue wilt oplossen...
#beenthere

Als je bij een normaal bedrijf een update uitvoert, is die server offline voor hoe lang dat duurt. Als dat mis gaat, is die server voor langere tijd afwezig, en kan je niet verder werken. Mogelijk ben je ook data kwijt.

Een CDN werkt alleen niet meer op individueel server-niveau. Als een server offline gaat, merkt, als het goed is, daar niemand wat van, want hoe je met een RAID systeem opzet met redundancy doen deze partijen dat met volledige racks.

Ik weet niet wat er hier misgegaan is, maar normaal zou ik verwachten dat updates staggered uitgevoerd worden, dus dat eerst 1 datacenter aangepakt wordt, en daarna het volgende. Zodat mocht het mis gaan, het grootste gedeelte van je systeem gewoon overeind blijft, en de load-balancers de requests gewoon doorzetten naar de systemen die nog niet geüpdatet zijn. Misschien was dat in dit geval niet mogelijk, of misschien was het een domino-effect waardoor andere servers uitvielen? Geen idee, maar misschien komen we dat ooit nog te weten. Of niet...

Juist, hoe erger je op ziet tegen het upgraden hoe langer de tijd tussen upgrade is, en hoe meer er ondertussen al weer veranderd is. En hoe meer er veranderd is, hoe meer kans op iets brekends waar je geen rekening mee hebt gehouden.

Regelmatig updaten zorgt er voor dat je de updates klein houdt, de impact beter kan overzien, en zoals je al zegt krijg je er routine in wat er weer voor zorgt dat je minder snel fouten maakt.

Komt nog eens bij dat je ook gedwongen wordt door de fabrikant. Loopt je te veel versies achter en je hebt een probleem (hoe klein of nietszeggend ook) het eerste wat ze zeggen is, update maar eerst naar de laatste versie.
Om binnen garantie of support te vallen mag je gewoon simpelweg niet te ver achter lopen en nu met het hele devops gebeuren maken bedrijven achter elkaar updates, elk maand komt er wel een update uit van een product of app. Eerst release dan kijken we wel wat er kapot gegaan is en zetten we het op de backlog.
In een groot bedrijf is het bijna niet te doen om elke maand te patchen (denk aan uptime SLA/DNO's) en dus doe je bijvoorbeeld 4x per jaar (kwartaal updates)
Maar zelfs dat heb je bijna niet meer zelf in de hand door continue exploits die ontdekt worden. Opvallend veel High/high exploits/software bugs zijn er de laatste 2 jaar. Microsoft, Linux, Cisco, Vmware, Citrix.
je blijft maar continue bezig om te patchen.
Ik vraag mij af of dit nu komt door de manier van ontwikkelen en software maken. Het heel Agile/Devops werken. Dus zo snel mogelijk sprintjes maken en releases en later wel kijken of we iets moeten fixen.
Ik ben er nooit fan van geweest als netwerkbeheerder (ontwikkelaars zullen hier anders over denken vermoed ik)
Maar goed, het tempo van patchen/updates is de laatste jaren echt toegenomen en de druk om bij te blijven dus ook. Kans dat het een keertje mis gaat wordt inherent hoger.

Regelmatig upgraden kan alleen als je ook daarvoor regressie testen doet. Maar dat is meestal teveel werk omdat die niet goed herhaalbaar zijn en dusverre met het handje moeten.

Ja, aan alles zit een risico. Elk ding dat je doet met je systeem is risicovol. Daarom is het zaak om je procedures goed voor elkaar te hebben. Bang zijn voor iets (dat geldt voor alles eigenlijk) betekent gewoon dat je a)niet zeker bent van je eigen kunnen en/of b)je niet (goed) voorbereid bent op problemen en/of c)te weinig kennis hebt.

Ik heb als consultant bij bedrijven en instellingen gezeten waar ze (naar mijn idee puur uit bezuiniging) alleen maar upgrades deden als het echt moest. Voor managers is dat een hele slimme policy, want lekker makkelijk op je begroting. Totdat je er een keer achter komt dat je systeem dermate ver achter loopt, dat je niet eens meer andere software kunt upgraden zonder je OS 2 (TWEE!) major updates te geven. En het leuke is dat op dat systeem waar dat speelde spullen draaiden voor diverse afdelingen, waarmee het coordineren van downtime extra moeilijk werd. Bovendien maak je alles extra ingewikkeld omdat je het OS twee keer moest updaten en maar hopen dat tussendoor al die rommel blijft werken. Dat is dus een dure manier van geld besparen.

Je moet gewoon je systemen up to date houden. Punt. Geen smoesjes verzinnen van duur of moeilijk. Juist als je infra zo belangrijk is, moet je ervoor zorgen dat het up to date is, en dat je backup goed geregeld is, je uitwijk en vooral al je procedures. Dat je personeel goed opgeleid is en deskundig genoeg om die dingen uit te voeren. En natuurlijk dat je precies weet hoe je infra eruit ziet. En dat klinkt logisch, maar ik ben de afgelopen 30 jaar bij genoeg bedrijven geweest (echt grote banken, overheden etc) waar ze gewoon GEEN overzicht hadden van wat er allemaal draaide, welke hardware waar stond en niet eens welke koppelingen er tussen de softwaresystemen bestonden (zowel in- als externe). Er zijn wel mensen die de koppelingen kennen, maar dan moet je soms wel 10 man bij elkaar roepen die dan na veel gezucht en gezoek informatie over die koppelingen produceren. En dan heb je ze meestal niet allemaal, sommige bestaan niet mee en bij sommige in de informatie onvolledig of outdated.

Dáárom is men bang voor updates. Niet omdat updates eng zijn. Updates zijn niet eng; slecht ingerichte en slecht gedocumenteerde systemen in handen van mensen die het eigenlijk niet goed onder controle hebben is eng.

VP-IT here.. Vaak is de meest dringende reden om geen updates door te voeren in een systeem(architectuur) het mogelijk negatief beïnvloeden van customizations. Maw, je interfaces, customized reporting en/of systeem of hardware compatibilities gaan er mogelijk aan. Dat kost tijd/geld/resources om te mitigaten of te fixen. Bij iedere update moet worden bepaald wat de impact is en wat de onderliggende business case/ROI is. Op basis van die assessment besluit je om een update wel of niet te implementeren. In een multi-nationale setting heb je vaak ook te maken met branches van dezelfde software, het doorvoeren van een update in de root kan voor grote verstoringen zorgen op lokaal niveau. Essentieel is een centrale afstemming hierover en ook dat brengt weer kosten met zich mee. Het laatste argument om niet direct alle updates te implementeren is de impact die updates kunnen hebben op IT-developments. Een nieuwere systeemversie kan leiden tot rework in Dev, Test, of Acceptatie van deliverables...

[Reactie gewijzigd door fisselt op 23 juli 2021 13:48]

Allemaal valide argumenten, en ik heb ze allemaal gehoord. Echter, als je systeem (gelukkig was het maar één van de 8 servers) 2 major OS updates achter loopt, doe je iets niet goed.

Overigens zijn al die argumenten achterhaald door de security en privacy eisen van de laatste jaren. Kom maar eens bij een auditor met zo'n verhaal terwijl je systeem ernstig risico loopt om gehackt te worden. Daar kun je geen verhaal meer bij maken.

Gelukkig zijn er tegenwoordig veel meer methoden om je infra zodanig op te zetten dat je dergelijke problemen niet hebt met je ontwikkelomgevingen, of veel minder snel. En je kunt alles inplannen. Je hoeft niet meteen de dag nadat een update verschijnt te patchen, maar aangezien er altijd een patchkalender is, kun je gewoon vooraf voorbereiden en eventuele patches op kritieke zaken testen op een ander systeem. Patchen maakt deel uit van de lifecycle van een systeem. Al doe je alleen maar de critical patches, maar 4x per jaar een patchronde inplannen is gewoon te doen. Juist als je teveel patches overslaat is het risico op problemen groter omdat de stap groter is. En juist vanwege dat patchen is het belangrijk om inzicht te hebben in wat je allemaal hebt draaien. Dan kun je ook de risico's beter inschatten en eventueel navraag doen bij de leveranciers.

Volledig eens. Ondanks alle ogenschijnlijke hassle is het uiteindelijk prettiger om vaker kleinere updates te doen. Het testen is te overzien en het team blijft geroutineerd.
Na vijf jaar is iedereen echt die obscure interface vergeten. Of de man die altijd als enige de portal kon fixen bleek ineens ergens anders te werken.
Door het gewoon 1 a 2x per jaar op de kalender te zetten raakt de business er ook aan gewend en heb je minder gezeik wanneer er conflicten optreden met business projecten.

Voor de helderheid... Er is niemand die zegt dat er helemaal geen updates doorgevoerd moeten worden; dat is ridicuul en zou erg dom zijn. Zeker waar het security issues/updates betreft..Maar er kan gekozen worden om updates (essential en non-essential) te clusteren en die en-masse te implementeren. Dat scheelt test/acceptatie resources en post implementatie support (omdat je slechts 1 of iig minder updatemomenten hebt). In het kort, ik stuur mijn Operations Department aan om zoveel mogelijk, case by case, samen met de business, te bepalen welke updates wanneer live moeten en om tot een efficiente updateplanning te komen.

Ik heb als consultant meegemaakt wat jij zegt, totaal geen kennis van de eigen infra, onbekende koppelingen en maar van mij verwachten dat ik ze zekerheid kon bieden dat alles zou blijven draaien na een update Maar een van de hoogte/dieptepunten was toch wel de situatie waar sommige eindgebruikers bijna volledige rechten hadden op de betreffende SQL-database van de applicatie om zo op hun eigen manier wijzigingen aan te kunnen brengen omdat ze het niet eens waren met de werkwijze in de applicatie

Volgens mij heb je het over iets anders dan hier speelde.

Naar wat ik lees was bij Akamai sprake van een update in de software configuratie. Lijkt mij dat daarmee instellingen worden bedoeld?

Updates aan software zelf, nieuwe versies, ja natuurlijk zijn die vaak wel degelijk eng. Alsof de exacte impact van te voren helemaal is in te schatten, onder alle omstandigheden. Zijn die updates wel zo lekker gedocumenteerd dan? Vaak redelijk, maar niet meer dan dat.

Het komt allemaal op hetzelfde neer: een wijziging in de software, of dat nou je OS is, een driver of een applicatie.

Impact kun je testen. Ik ga niet alles weer een keer herhalen. Ik spreek uit ruim 30 jaar ervaring in de IT als consultant waar ik bij allerlei bedrijven en instellingen heb gezet en vaak zat te maken heb gehad met upgrades, patches e.d. En inderdaad: soms weet je niet wat je tegenkomt. Daarom is er iets als testen. Als wij een nieuwe Oracle versie moeten uitrollen, zetten we dat eerst op een testsysteem. Dat is tegenwoordig helemaal makkelijk als je op gevirtualiseerde omgevingen draait, maar je moet je spullen eigenlijk altijd zo inrichten zodat je kunt testen en een test/backupsysteem beschikbaar is. Ooit heb ik een analyse moeten doen bij een behoorlijk bouwbedrijf in Nederland die een hele maand aan administratie kwijt is geraakt omdat er geen testsysteem was. Die hadden Baan software (zo lang is dat geleden) op een Sun draaien en dat was de enige Sun in de tent. Dus konden ze hun backupstrategie niet uittesten en die was uiteindelijk ook verkeerd opgezet. Heeft niets met upgrades te maken, maar met het goed inrichten van je systemen en het beschikbaar hebben van een testsysteem. Je moet toch ook elk jaar even kijken of je uitwijk nog werkt?

Het is maar wat je belangrijker vindt, maar ik kan je garanderen dat niet updaten je op enig moment in de staart bijt. Die dag komt, en dan heb je GEEN goed verhaal.

Je doet wat je kunt met testen, en verder een goed noodplan samenstellen voor als de shit hits the fan. Je kunt niet alle risico's afdekken, wat sommige managers wel willen. Dat is onrealistisch op enkele zeer kritische dingen na. Sommige risico's zijn sneller en goedkoper te mitigeren door een goed brandblusteam klaar te zetten.

Die perfecte wereld waar alles gaat zoals jij dat wil, die BESTAAT NIET. Mensen zijn voorzichtig (niet bang) met updates omdat ze zich realiseren dat het ongeacht alle voorzorgsmaatregelen alsnog fout kan gaan, en dat is heel verstandig!

Jaja..dus gewoon in een hoekje gaan zitten en niets doen. Dát is pas verstandig. Dat heet struisvogelpolitiek en dat heeft niet voor niets een negatieve connotatie.

Natuurlijk is er geen perfecte wereld, dat snap ik ook wel. Maar als er één ding is dat ik de afgelopen 30 jaar heb geleerd, is dat een dergelijke policy alleen maar hele dure problemen oplevert, onnodige werkdruk bij de beheerders en uiteindelijk alleen maar vingerwijzen van die eigenwijze managers naar diezelfde beheerders die zonder middelen de boel maar draaiende moeten zien te houden.

En ondertussen moeten er wél allerlei prestigieuze projecten uitgevoerd worden, alles moet perfect werken, maar het mag niets kosten. Beheer wordt alleen maar als onkostenpost gezien. En er valt ook werkelijk geen serieus gesprek mee te voeren. Ze hebben meestentijds geen flauw benul wat ze nou eigenlijk aan het managen zijn. Maar ze kunnen er bij de borrel wél heel mooi over lullen. Gelukkig is dat dan met andere managers,. die hebben tenminste niet in de gaten dat ze uit hun nek lullen.

Joh je overdrijft zo enorm, je zit telkens aan het uiteinde van het spectrum terwijl de waarheid een stuk meer naar het midden zit. Ja de meeste managers zijn compleet nutteloos maar waar zeg ik dat je helemaal niets moet doen? Tuurlijk zo nu en dan ga je updaten/upgraden maar ik sta nou niet te springen om dit soort dingen direct door te voeren want elke beheerder weet dat er risico's zijn en anderzijds hey leuk spannend, dat is toch waarvoor je in de IT zit? En nogmaals hoe goed jij het ook in je hoofd uitdenkt of technisch voor elkaar hebt, er zullen dingen fout gaan die jij niet kunt voorzien zelfs na 30 jaar ervaring! Ook dat is IT. Dus als updates niet echt nodig zijn of een te grote impact/risico factor kunnen hebben op de business stel je die soms uit, dat is niks om voor je te schamen maar gewoon je verstand gebruiken.

[Reactie gewijzigd door Terrestrial op 24 juli 2021 10:04]

Dat je personeel goed opgeleid is en deskundig genoeg om die dingen uit te voeren.

Klinkt goed, echter... er is een groot tekort aan personeel die deskundig genoeg is.
Dan kan een bedrijf kiezen uit: #1: Doorgaan met groeien/ontwikkelen zonder deskundig personeel, en meer winst (financieel, PR, ...) maken. #2: Stoppen met groeien/ontwikkelen, totdat er deskundig personeel gevonden en betaald kan worden.
Zelfs als je kiest voor #2, blijft het voor P&O moeilijk om te kunnen oordelen of de sollicitanten wel kunnen wat nodig is voor het bedrijf.

Er zijn wel mensen die de koppelingen kennen, maar dan moet je soms wel 10 man bij elkaar roepen die dan na veel gezucht en gezoek informatie over die koppelingen produceren.

Dat komt mede voor (hoog) verloop van personeel. Dat komt weer door (te) hoge eisen die aan personeel wordt gesteld. Dat komt eigenlijk weer doordat #1 veruit de boventoon voert.

[Reactie gewijzigd door kimborntobewild op 24 juli 2021 22:24]

Er is ook nog zoiets als documentatie. Ik weet dat in deze tijden van hippe methodieken om software te ontwikkelen documentatie een nóg meer ondergesneeuwd onderdeel is, maar daar komt het echt wel op neer. Je hebt ook geen boekwerk nodig om een koppeling te beschrijven; gewoon hoe het heet, wat het doet, met wat het koppelt, werking van de interface, parameters e.d. Iets is beter dan niets.

Maar ja...geen tijd, haast, uitloop, ik ken alle smoesjes. Het grootste probleem is naar mijn idee dat niet heel veel mensen op durven staan en gewoon zeggen dat ze op die manier hun werk niet goed kunnen doen. Maar nee, als Lemmings lopen we gewoon massaal achter elkaar aan, de ravijn in.

In theorie zijn er 3 redenen waarom je een systeem wilt upgraden:
1. Er is een security issue in de door jou gebruikte versie
2. Er zit een bug in de door jou gebruikte versie waar je last van hebt
3. De nieuwe versie heeft een nieuwe feature die je nodig hebt

Overigens kun je upgrades natuurlijk prima voorbereiden op de test en acceptatie omgeving van je software (we doen allemaal OTAP toch? ). Feit wil wel dat hoe lang je wacht, hoe ingewikkelder het wordt. Dus idealiter update je voor een product EOL bereikt.

[Reactie gewijzigd door n9iels op 23 juli 2021 11:09]

En dan nog, van de zandbak, naar de O, T, A en P. Kom je nog foutjes tegen. Het is gewoon ondoenlijk om alles testen.

En als je dan eenmaal klaar bent voor P dan een Blue-Green oplevering doen en/of een Canary release, indien mogelijk natuurlijk

Dit is dan ook de reden waarom ops mensen niet van upgrades houden.

1999 belde, ze willen hun ops mensen terug. Sorry hoor, maar als je niet van upgrades houdt dan upgrade je niet vaak genoeg.

1999 belde, ze willen hun ops mensen terug. Sorry hoor, maar als je niet van upgrades houdt dan upgrade je niet vaak genoeg.

Onzin.

De software en de apparatuur moet gewoon zodanig stevig zijn dat upgrades niet nodig zijn.

CI/CD-pipelines werken alleen maar als u met niet-kritieke software of toepassingen werkt. Op een behoorlijk aantal plaatsen moet elke letter die er aan code gewijzigd wordt, eerst langs een auditor.

"Even updaten" of "vaak updaten" is er dan echt niet bij.

Jouw situatie is meer de uitzondering dan de regel

Juist, U snapt het

Juist, U snapt het

En u blijkbaar ook.

Zie mijn reactie op @lenwar voor vermaak.

De software en de apparatuur moet gewoon zodanig stevig zijn dat upgrades niet nodig zijn.

Dit is natuurlijk onzin als je dit als generiek statement wil zetten. Al is het maar omdat er dagelijks wereldwijd wetgeving veranderd, waar bedrijven en instanties aan moeten voldoen. Allemaal softwareveranderingen/upgrades. (er waren in Nederland in 2020 280 wetsvoorstellen geweest die zijn afgehandeld (ik kan 1-2-3 niet vinden hoeveel er daarvan zijn goedgekeurd, maar al zijn dat er maar 20 van))

Er worden versleutelingsmethoden veranderd/versterkt. Je hoeft dan niet gelijk je hele straat te vervangen op het moment dat je van SHA256 naar SHA512 zou gaan (ik verzin maar wat). Je kan dan zeggen, je had bij SHA512 moeten beginnen, maar als dat er toen nog niet was, dan heb je daar niet zo veel aan.

CI/CD-pipelines werken alleen maar als u met niet-kritieke software of toepassingen werkt

Ook dit is onzin. Bedrijven als Amazon, Netflix, Facebook, Adobe werken allemaal met CI/CD-pipelines en echt niet alleen voor de spellingsfouten van het menu van het bedrijfsrestaurant...

Op een behoorlijk aantal plaatsen moet elke letter die er aan code gewijzigd wordt, eerst langs een auditor.

Dit klopt uiteraard helemaal en dan zal je CI/CD dus stoppen op een bepaalde Acceptatie-omgeving en uiteindelijk een release gecreëerd worden die geaudited wordt

Dit is natuurlijk onzin als je dit als generiek statement wil zetten. Al is het maar omdat er dagelijks wereldwijd wetgeving veranderd, waar bedrijven en instanties aan moeten voldoen. Allemaal softwareveranderingen/upgrades. (er waren in Nederland in 2020 280 wetsvoorstellen geweest die zijn afgehandeld (ik kan 1-2-3 niet vinden hoeveel er daarvan zijn goedgekeurd, maar al zijn dat er maar 20 van))

Bedrijfslogica hoort gescheiden te zijn van de kern van de ICT-systemen, zodat u deze kunt wijzigen zonder het onderliggende systeem te moeten wijzigen. Daarnaast kent wetgeving eigenlijk altijd een aanloopperiode. Als u dat als argument gebruikt, heeft u hooguit 4 update-momenten nodig per jaar onder normale omstandigheden.

Er worden versleutelingsmethoden veranderd/versterkt. Je hoeft dan niet gelijk je hele straat te vervangen op het moment dat je van SHA256 naar SHA512 zou gaan (ik verzin maar wat). Je kan dan zeggen, je had bij SHA512 moeten beginnen, maar als dat er toen nog niet was, dan heb je daar niet zo veel aan.

Doorgaans zijn dat allemaal relatief kleine veranderingen die prima uit te rollen zijn met een jaar vertraging.

Ook dit is onzin. Bedrijven als Amazon, Netflix, Facebook, Adobe werken allemaal met CI/CD-pipelines en echt niet alleen voor de spellingsfouten van het menu van het bedrijfsrestaurant...

Grappig, maar de bedrijven die u noemt, zijn allemaal nou niet bepaald kritieke infrastructuur.
Waar ik het over heb zijn systemen bij de politie, netbeheerders, telecomoperators en andere organisaties die wel degelijk een bepaalde SLA moeten garanderen.

Een webshop die een paar verkopen mist, een paar chatberichten die niet worden afgeleverd, een paar video's die niet bekeken kunnen worden zijn nauwelijks kritiek te noemen. Ja het kost die bedrijven geld, maar dat is het dan.

En Adobe? Daar haalt u precies dat ene bedrijf aan dat geen CI/CD gebruikt voor de uitrol naar zijn klanten, maar in de laatste stappen met een release-trein werkt.

Dit klopt uiteraard helemaal en dan zal je CI/CD dus stoppen op een bepaalde Acceptatie-omgeving en uiteindelijk een release gecreëerd worden die geaudited wordt

Hoe vaak krijgt zo'n release een audit?
Meestal is dat iedere 6 weken of zelfs langer en is de doorlooptijd al snel een week of 2.

Op dat moment zit u gewoon weer in de situatie van 1999.

Het spijt me, maar ik vind dat de kwaliteit van de software leidt onder het idee dat alles gerepareerd kan worden met een app-update.

En de mensen die roepen dat er vaak geüpdate moet worden en dat de snelheid omhoog moet? Dat zijn de mensen die nog nooit gebeten zijn door het fenomeen van de update die door alle controles heen is gekomen, maar waarvan de update en de rollback-procedure niet blijken te werken.

Vroeg of laat komt dat moment bij ieder bedrijf en iedere programmeur een keer langs. Ik hoop dat als het u overkomt, u de politieke middelen heeft om uw baan te kunnen behouden. Uw technische vaardigheden doen er op dat moment namelijk niet meer toe.

Hey is een lastige kwestie de juiste balans te vinden in de dynamiek van je systeemlandschap. Kritische systemen wil je niet elke twee weken patchen, maar je wilt ook niet maar eens in de 5 jaar upgraden omdat je dan zo'n zondvloed aan regressietests hebt, dat je bijna een greenfield project hebt.

Wachten op EOS is uit mijn ervaring dom. Je kan beter gewoon lekker bij blijven i.p.v. wachten op major breaking changes. En ja er gaat wel eens wat stuk dat valt makkelijk af te vangen.

Als devops consultant ben ik het daar niet mee eens.

Ik houd van updates. Het liefst heb ik er meerdere per dag en juist zo klein mogelijk.

Mijn taak is om software zo snel en zo goed mogelijk naar de klant te krijgen. Een feature die ik (of iemand anders van het team) ‘s ochtends maak wil ik ‘s middags hebben staan bij de klant.

Er zijn heel veel verschillende manieren om zelfs in productie te kunnen testen of je feature goed werkt. Sommige dingen werken op papier namelijk fantastisch maar in de praktijk niet.

Bang zijn voor updates is gevaarlijk en zorgt er voor dat je snel achterloopt, met alle gevolgen van dien (ransomware, datalekken).

Door slimme processen te maken kun je dit ook veilig doen. Kijk naar dit soort fouten. Ja het is vervelend, maar hier leer je van (als het goed is) en ga je je tegen wapenen. Dingen als 4-ogen principe, teststraten, code analyse, circuit breakers, chaos/monkey testing, load balancing, a/b testing, rolling upgrades en blue/green deployments bestaan juist om de downtime minimaal te houden.

En ja dat begint bij ontwikkeling.

Design for resiliency. Shit WILL hit the fan. Zorg ervoor dat jij in controle bent over de fallout die het meebrengt.

Moeten ze niet blindelings alles in productie willen uitvoeren.
Eerst testen, en een backup plan klaarhebben.

Updates zijn tegenwoordig toch een essentieel onderdeel. Alles hangt tegenwoordig aan het internet, dus updates in de vorm van security patches zijn van groot belang.

Updates aan een apparaat wat niet aan het internet hangt is een stuk minder belangrijk en vaak is het dan beter niet te updaten als deze update voor jou niets toevoegt.

Helemaal mee eens
Ik zit nog op Windows 3.11 omdat ik niet van upgrades houd

Als iemand die in ops gewerkt heeft kan ik je zeggen dat ik daar helemaal geen probleem mee had. En ik zie wel het nut in van te updaten, namelijk veiligheid. We zien vaak genoeg wat he gevolg kan zijn van niet te patchen.

En als je het vaak genoeg doet, dan heb je ook goede procedures, inclusief wat te doen in geval van problemen.

Als je slim bent heb je een testomgeving. Dan kun je namelijk zien wat een update doet met jouw omgeving.

Is het gebruikelijk dat er tussen zo'n partij als Akamai en hun klanten een harde SLA ligt? Of is dat meer in de richting van een "best effort"-verplichting? In het eerste geval kan ik me zo voorstellen dat dit soort grapjes Akamai een hoop geld kosten.

SLA's moet je niet zien als 'ik krijg veel geld als het niet doet' of boetes. De meeste vergoedingen zijn in de vorm van kortingen op huidige facturen of 'gratis' extra verbruik.

Een SLA is dus meestal een indicatie hoeveel vertrouwen een leverancier heeft in de dienst.

Die SLA gaat iets van 99,9999% oid zijn. Het is nou niet dat de boel overal dagen plat lag, dit was snel opgelost en het kan zijn dat het nog binnen SLA valt.

In combination, these and other application delivery optimizations enable Akamai to offer our customers a 100% global availability SLA and 100% global performance improvement SLA.

Bron: https://www.akamai.com/us.../application-delivery.jsp

We offer our customers a 100% global availability SLA and a 100% global performance improvement SLA.

Bron: https://www.akamai.com/us...es/cloud-architecture.jsp

Het lijkt er dus op dat ze daadwerkelijk (voor bepaalde klanten) tot payout over zullen moeten gaan.

Is dat dan ook echt 100% in het contract of hebben ze dat voor marketing redenen maar naar boven afgerond?

Waarschijnlijk echt 100%.
Maar de consequentie voor Akamai is meestal beperkt tot b.v. het bedrag dat je die maand aan Akamai hebt betaald (voor de Edge DNS dienst).

Ook in het legal doc staat 100% en bij storing (daar zijn wat voorwaarden aan verbonden), betalen ze maandbedrag terug.

Wiskundig gezien wordt 99,5% afgerond naar 100%, als er wordt afgerond naar 0 decimalen.

In dit geval, een storing van ongeveer een uur, dan heb je 0.0114% downtime, dus dit valt zeker wel binnen 99.9% uptime, maar 99.99% op jaarbasis is al (net) niet meer haalbaar met deze downtime. Nu zijn er niet veel partijen die 99.99% zeggen, maar ze zijn er ongetwijfeld wel.

integendeel, ze claimen 100%

Ah right, ik dacht dat het ging over de SLA van klanten van Akamai die zelf een SLA hebben tegenover hun klanten dan weer, die kunnen dan claims indienen lijkt me.

Ik denk eerder 99,99% of misschien zelfs 99,9%. Voor individuele applicaties is de requirement meestal 5 9's. Dus end-to-end zal flink lager liggen.

Akamai is best een stuk duurder dan Cloudflare en Firefly, ze bedienen dan ook andere klanten met meer essentiële netwerken zoals banken.
Dus het zou mij niks verbazen als ze 5 9s hebben.

Met een SLA van 99,9% uptime hebben ze voor dit jaar nog ongeveer 7 uur en 45 minuten over aan downtime.
https://uptime.is/

Even snel kijkend naar hun Edge DNS service, daar adverteren ze met een een 100% uptime SLA. Dus ja dat grapje gaat ze wel wat kosten. https://www.akamai.com/us/en/products/security/edge-dns.jsp

Zulk soort SLA worden wel meer gebruikt, alleen niet vaak 100%. Microsoft heeft voor Office 365 bijv een 99,9% SLA waardoor ze er toch nog onderuit kunnen komen om een aardig aantal uur down te kunnen zijn zonder dat ze hoeven uit te betalen.

[Reactie gewijzigd door Facerafter op 23 juli 2021 11:05]

Hoezo gaat ze dat geld kosten? Er is een verschil tussen wat men roep in de advertentie en wat in het daadwerkelijke contract staat. Lijkt mij dat er in de kleine lettertjes wel ergens staat dat die 100% uptime gebaseerd is op een "best effort" en dat daadwerkelijke uptime kan varieren.

"Gain peace of mind by extending your DNS to the edge, with high availability and performance, and resilience against DDoS attacks backed by a 100% uptime SLA."
Sorry maar 100% uptime SLA is 100% uptime SLA. In de documentatie staat het ook
"Capabilities
• High Availability — Leverage the Akamai Intelligent Edge
Platform, with thousands of DNS servers in more than 1,000
points of presence worldwide, to provide a high level of
DNS service availability. Edge DNS comes with a 100%
uptime service level agreement (SLA), providing you with
confidence that your customers and employees can reliably
connect to your website and application servers."

zie jij ergens staan wat de SLA-breach penalties zijn? Een SLA niet halen is 1 ding, de vergoeding ervoor is iets anders. Of het effectief een payout gaat zijn en hoe hoog daar ben ik nog niet zo zeker van

so what ?
het kan mooi zijn om een SLA van 100% te geven, als er contractueel niets bepaald is van wat er gebeurd als de SLA niet gehaald wordt, dan maakt de SLA niet zo veel uit.
boete betalen of x gratis maanden of slecht rapport, wordt apart besproken en kan voor elke klant verschillend zijn.

https://www.digitalmarket.../services/135149961934692
Dit is van een reseller:

The Akamai platform has a 100% availability SLA.
Should the service be unavailable as defined as a period of at least two consecutive failed attempts six minutes apart by a single agent to GET the Customer test file from the Service while succeeding to GET the test file from the Customer Origin Server (directly, or via a Site Shield region if applicable). If an outage is identified by this method, the Customer will receive (as its sole remedy) a credit equal to Customer’s or such domain’s committed monthly service fee for the contracted security service for the day in which the failure occurred, not to exceed 30 days of fees.

Die 100% claim maakt vooral het contract en de administratie simpel.
De service fee is maar een scheintje tov de schade die de klant heeft als het bedrijf uit de lucht is.
Het is vooral een maatstaf om te kijken hoeveel vertrouwen een leverancier in zijn product heeft en niet iets dat je schade vergoed.

True, waarschijnlijk hebben ze het wel aardig slim verpakt. Ik kan hun daadwerkelijke SLA niet vinden maar ik ken er toevallig eentje van een andere grote partij (New Relic) die het ook wel creatief oppakt als men onder de uptime garantie komt. Stukje uit de SLA van New Relic om je een voorbeeld te geven

The Service will be considered available so long as Customer is able to log in to its interface and view Customer Data ("Service Availability"). The applicable Service Availability will be calculated as a percentage of: (1) the total number of minutes in a month after (2) subtracting any periods of unavailability during such month from the total number of minutes in a month. New Relic will use commercially reasonable efforts to maintain Service Availability of at least 99.8% during any calendar month.

In the event the Service Availability drops below: (i) 98.5% for two consecutive calendar months during the Subscription Term, or (ii) 96.5% in any single calendar month, Customer may request to terminate the relevant Service with no penalty. Such termination will be effective as of the end of the then-current billing period and no additional fees will be charged.

Je krijgt dus geen geld maar je mag onder bepaalde voorwaarden "kosteloos" weg. Daar heb je als bedrijf helemaal niks aan aangezien je dan een dikke vette migratie hebt als je volledig in New Relic zit bijvoorbeeld.

Dat is wel het gebruikelijke, als ze adverteren met 100% SLA dan is de verwachting dat zal dat ook in het contract staan. Bij dit soort services zullen veel enterprise klanten niet akkoord gaan met best effort want het gaat om critical business services. Dat betekent dus dat de klant geld verliest of misloopt als de service down is, die zullen daar dan altijd compensatie voor willen.

100% SLA is belachelijk om te adverteren. Je moet altijd iets aan speelruimte ("error budget") meerekenen, juist voor ongelukjes bij rollouts en updates. Zie https://sre.google/sre-bo...ent_unreliability-budgets
Daarnaast heb je bij een service met veel "negens" (bij 100% SLA dus zelfs oneindig veel negens) absoluut geen reactietijd meer om het te fixen. Daarnaast gaan SLAs gaan meestal niet over een heel jaar maar over een kwartaal of zelfs per maand.

99.999% uptime SLA -> 5.26 minuten downtime acceptabel / jaar, 1.3m /kwartaal
99.99% uptime SLA -> 52.6 minuten downtime acceptabel/jaar, 12.96m / kwartaal
99.9% uptime SLA -> 8.76 uur downtime acceptabel/jaar, 2.16h / kwartaal

Zie deze tabel

Merk op dat beschikbaarheid uitdrukken in percentages eigenlijk onhandig en misleidend is; het lijkt heel hoog totdat je het gaat omrekenen naar uren/jaar.

In de industrie is het al decennia gebruikelijk om te spreken over MTBF (mean time between failure) en MTTR (mean time to repair).

Het maakt immers nogal wat uit of je in een jaar tijd een hele dag uit de lucht bent, of 24 keer een uur...

En dan hebben we ook nog de MTTM (Mean Time To Mitigate).

Waar het mij om ging: Als je een hele strikte SLA hebt, knijp je ook de mogelijkheid af tot vooruitgang. Zie https://sre.google/sre-bo...ent_unreliability-budgets

De SLA van Akamai is 100%. Het leuke aan SLAs is dat er zelden wordt afgesproken dat er contant geld wordt uitgekeerd. In plaats daarvan credits/korting oid.

In het verleden een provider gehad die een bepaalde uptime garandeerde en er was een keer storing (was zelf niet eens thuis) maar kreeg netjes een mailtje "excuses, SLA van deze maand is niet gehaald er worden geen kosten in rekening gebracht voor 1 maand"
In princiepe geen cash geld maar een maand geen rekening is ook geld natuurlijk

In het geval van Akamai krijg je een periode gratis dienstverlening:
The Akamai platform has a 100% availability SLA.
Should the service be unavailable as defined as a period of at least two consecutive failed attempts six minutes apart by a single agent to GET the Customer test file from the Service while succeeding to GET the test file from the Customer Origin Server (directly, or via a Site Shield region if applicable). If an outage is identified by this method, the Customer will receive (as its sole remedy) a credit equal to Customer’s or such domain’s committed monthly service fee for the contracted security service for the day in which the failure occurred, not to exceed 30 days of fees.

Maar in de praktijk zal je zien, dat als jij significante kosten maakt door niet-beschikbaarheid van een 100%-SLA dienst, dat je dan ook andere stappen kunt gaan ondernemen. Stel dat een bedrijf significante kosten heeft gemaakt (door bijvoorbeeld gemiste inkomsten e.d.) dan kan je ze prima aansprakelijk houden voor een deel van de kosten daarvan. Want 100% is 100%. Uiteraard moet je dan wel kunnen aantonen dat het daar door kwam.

dan kan je ze prima aansprakelijk houden voor een deel van de kosten daarvan. Want 100% is 100%

Nee, dat kan je niet. Want in het contract staat keurig hoeveel vergoeding je krijgt en met welk maximum.
En daar heb je je handtekening onder gezet, dus meer word het niet.

De maximale aansprakelijkheid is dan ook altijd een hekel punt bij contract onderhandelingen.

Is een SLA een garantie op een oplossing of op tijdig reageren/handelen?

Bij dat laatste kan je alsnog lang down zijn zonder geld te moeten betalen maar moet je wel de (afgesproken) inspanning om het op te lossen leveren, waarmee je dus alsnog aan de SLA kan voldoen.

De exacte uptime garantie weet denk ik niemand en zal misschien wel per partij anders zijn.

[Reactie gewijzigd door watercoolertje op 23 juli 2021 11:04]

hangt van je contracten af.
in veel gevallen hab je binnen SLA's tijden als TTR, (TTF) & TTS
Time To response : "we hebben je vraag ontvangen"
TT Fix : "we hebben je systeem weer (iet wat) bereikbaar/werkbaar
TTS: "we hebben het probleem opgelost"
en veelal komt er een M voor te staan. Mean - gemiddeld
en dan kan je ofwel boete clausules hebben, beoordelingen of bonussen.

Een SLA vertaalt zich niet automatisch naar een hoeveelheid geld. Ook in een SLA kan je "best-effort" afspreken.

Ja denk niet dat de Rabobank iets vaags als best effort clausule heeft met de duurste van de 3 CDNs.

Zoals de meeste contracten op dit niveau en zeker met essentiële diensten zoals encryptie sleutels van banken staan er gewoon keiharde voorwaarden in.

Dat zeg ik niet, dat was ook niet de vraag.
Verder kan je wel in de SLA afspraken maken, maar dat zegt natuurlijk niks of en hoe snel iets opgelost wordt.

Inderdaad, als er een service level afgesproken is dat het binnen drie uur opgepakt wordt, wil niet zeggen dat het binnen drie uur opgelost wordt. Die 99,9% staat leuk op een SLA, en natuurlijk slaat de klant de leverende partij hiermee om de oren, maar vaak na een downtime wordt een SLA goed doorgelezen. De SLA’s die ik ken zijn niet zo simpel te doorgronden.

Naar wie wil je overstappen met al je spullen?

Interessante hier is dat je bij Akamai Edge DNS een 100% uptime SLA hebt. Ik kan de tekst van die SLA alleen nergens vinden.

Over het algemeen krijg je een deel van je maandelijkse kosten aan die dienstverlener terug. Voorbeeldje:
https://cloud.google.com/compute/sla

Als je bedrijf compleet onbereikbaar is en je daardoor geen omzet draait is die paar honderd of duizend euro die je terugkrijgt van Akamai niet heel erg relevant...,

[Reactie gewijzigd door bartvb op 23 juli 2021 11:49]

More info: https://www.thousandeyes....-edge-dns-outage-analysis

Hoe langer de supply-chain van een service hoe meer dit kan gebeuren...

Als je afhankelijk bent van externe partijen, die services draaien van andere partijen, die software updates doorvoeren en dan wordt je eigen service aangetast, zonder dat je hier controle over hebt...

Dit zal enkel meer en meer voorkomen, het is een wirwar van afhankelijkheid van enkele lijnen code.

Er wordt snel gemakkelijk software 'gerecycleerd' ; dit werkt goed dus gebruiken we die library/service en hop, iedereen blij

"[..]bleek eerder dit jaar bij een storing van cdn-dienst Fastly."..
De storing bij Fastly was vorige maand. Zo lang geleden was het dus niet.

In ieder geval, ben ik echt tegen de centralisering van het internet, wat in feite op deze manier gebeurt. Tuurlijk, zo'n dienst gebruiken neemt voordelen met zich mee, maar vooral op korte termijn.
Je kunt het vergelijken met bijvoorbeeld Swapfiets, voor een maand een fiets huren is goedkoop, maar als je dat een jaar of twee doet had je toch beter je eigen fiets kunnen kopen.

Dat is niet wat een CDN beoogt. Een CDN zet de data dicht bij de gebruiker neer. Youtube is snel doordat de filmpjes deels worden opgeslagen in Nederland. Een cache of Proxy is nog meest vergelijkbaar, echter een CDN wordt vooraf gevuld niet dmv requests van gebruikers.

Dan heb je het over het verschil tussen een push en een pull CDN, Akamai Delivery is een voorbeeld van het laatste. De eerste bezoeker op een edge triggered het vullen van de cache aan de hand van rules die voor betreffende hostname zijn ingesteld.

Ja kan beide denk ik, niet heel relevant.

Daar denkt Akamai heel anders over

Dit is niet echt te vergelijken met een fiets huren. Als je zelf de infrastructuur moet gaan opzetten voor de diensten die Akamai levert ben je al snel heel veel geld kwijt, om nog maar te zwijgen over de uren die je voortdurend kwijt gaat zijn om hetzelfde service niveau te leveren als Akamai doet. Bovendien kan er ook dan gewoon iets stuk gaan waardoor je downtime heb als website.
Het enige voordeel is dat niet het halve internet eruit ligt, maar dat maakt de individuele bedrijven die deze dienst afnemen niet zoveel uit in hun afweging om wel of niet gebruik te maken van een dienst als Akamai.

Ik ben alleen bang dat het in het geval van dit soort diensten niet echt gaat om het "eigen fiets kopen" maar meer je eigen fiets bouwen, en juist dat stuk valt vies tegen ben ik bang. Uberhaupt al de vraag waar je gekwalificeerd en ervaren personeel vandaan haalt voor het bouwen van een de(r)gelijke CDN service voor je miljardenbedrijf.

Overigens begrijp ik wel je punt tegen centralisering op deze wijze. Het risico toont zich wel op deze manier.

Het was, zover ik heb begrepen inderdaad een update die de problemen veroorzaakte, maar het systeem dat er voor moet zorgen dat een foutieve update gestopt wordt, werkte ook niet goed.

in dit geval lijkt het alsof ze de update overal tegelijk uitgevoerd hebben.
wanneer er dns servers in meer dan 140 steden staan zou het dan niet beter zijn gefaseerd uit te rollen over een periode van X dagen zodat problemen niet meteen alle klanten wereldwijd treffen.
alleen kritieke updates zoals security zou je misschien globaal uit willen rollen.

Het systeem dat er voor zorgt dat een foutieve update tegengehouden wordt, werkte ook niet goed. Daarom werd de update alsnog verder doorgevoerd.

Was dat systeem out door een slechte update?

Dat klinkt in mijn oren als een Git pipeline die onbedoeld door is gegaan door een slechte of niet werkende check.

Volgens mij weten heel veel mensen niet eens hoe groot Akamai is en hoevaak ze er zelf (min of meer) mee te maken hebben zonder dat ze het weten. Veel van de websites die plat lagen wisten waarschijnlijk niet eens dat ze afhankelijk waren van Akamai ergens in de hele chain..

Voor mensen die het interessant vinden, Akamai doet ook redelijk wat onderzoek hieromtrent dat in verschillende rapporten gecompileerd wordt.
https://www.akamai.com/us...e-of-the-internet-report/
Voor een druilerige zaterdagmiddag...

Klant van me heeft een site via Vultr VPS in A'dam draaien. Paar bestellingen via formulier via de site zijn gisteren niet aangekomen. Kan dat de oorzaak zijn? Ze zitten wel in de dbase gelukkig.

Akamai heeft een 100% uptime garantie, in de 7 jaar dat ik met ze werk hebben ze geen downtime gehad en daarvoor is het ook nooit gebeurt naar eigen zeggen.
Updates als deze lopen over tiers, en systeem dat activatie automatisch terugdraait bij fouten heeft geen rollback gedaan. Dat zal nog wel een interessante analyse worden.

Voor mensen die zeggen dat dit niet op productie uitgevoerd moet worden of in maintenance windows: realiseer je dat dit een globaal bedrijf is, er is geen moment dat onderhoud goed uitkomt. Er zitten enorm veel quality-checks op de releases, die automatisch een rollback horen te triggeren(alleen op die manier is netwerk van deze schaal te beheren).