Storing bij AMS-IX werd veroorzaakt door fout tijdens netwerkonderhoud

De storing bij AMS-IX van woensdag werd veroorzaakt door een menselijke fout tijdens netwerkonderhoud in een van zijn datacenters. Dat laat het internetknooppunt weten aan Tweakers. Er is geen apparatuur kapot en de storing was volgens AMS-IX snel op te lossen.

Een woordvoerder vertelt aan Tweakers dat de storing werd veroorzaakt tijdens een zogeheten snaketest. Dat is een test die bijvoorbeeld wordt gedaan bij het in gebruik nemen van een nieuwe netwerkkaart, waarbij het internetknooppunt testverkeer via de nieuwe kaart langs alle poorten laat lopen.

In dit geval was een van de poorten nog onderdeel van het productienetwerk, waardoor een loop werd veroorzaakt op het netwerk van het internetknooppunt. Daardoor ontstond een broadcast storm, waarbij de netwerkkaart probeert alle apparaten op het netwerk aan te spreken. Ook trok de kaart al het netwerkverkeer naar zich toe, waardoor dus een lus ontstond op het netwerk van AMS-IX. Dit had volgens het internetknooppunt tot gevolg dat driekwart van de bgp-sessies verstoord werd en een groot deel van het netwerk tijdelijk down was, waardoor aangesloten klanten te maken kregen met netwerkonderbrekingen.

De storing werd opgelost door de poorten die problemen veroorzaakten, uit te schakelen. Er is volgens het internetknooppunt geen apparatuur kapotgegaan. AMS-IX zegt ook dat de storing hierdoor snel was op te lossen. Het internetknooppunt gaat zijn processen evalueren om de kans op soortgelijke gebeurtenissen in de toekomst te verkleinen.

De storing bij het internetknooppunt vond woensdagochtend om 10.18 uur plaats en de oorzaak was volgens AMS-IX rond 10.45 uur weggenomen, waarna het netwerkverkeer geleidelijk werd hersteld. Rond 11 uur waren alle bgp-sessies hersteld.

Reacties (93)

[robertlinke]

Het internetknooppunt gaat zijn processen evalueren om de kans op soortgelijke gebeurtenissen in de toekomst te verkleinen.

goed.. fouten kunnen worden gemaakt, we zijn allemaal mensen, maar dan moeten we er van leren, en processen opstellen om te zorgen dat dit niet meer gebeurd.

de ITIL mensen bij AMS-IX gaan hun geld goed verdienen de komende tijd

[feuniks]

Dat vind ik persoonlijk altijd een typische Pavlov reactie: er is een keer iets fout gegaan, dus moeten we ervoor zorgen dat dat nooit meer kan gebeuren? En of dat iets kleins is, of een grote ramp, dat maakt mij niet zo veel uit. Ik denk dat dit een exces is van de illusie van een maakbare samenleving. Daarmee zeg ik overigens niet dat je niet goed moet kijken wat er precies gebeurd is en of je hier aan zou willen doen. Maar elke "oplossing" heeft de potentie om zijn problemen te veroorzaken. Te veel procedures en checks hebben het nadeel dat op een gegeven moment mensen zich er niet aan gaan houden en afkortingen gaan zoeken. Met alle procedures duurt iets bijvoorbeeld 5 uur en gaan de managers zeuren. Door niet alle procedures naar de letter te volgen, kan het in 2,5 uur. Iedereen blij, maar wellicht zijn dan juist de belangrijke procedures niet gevolgd, terwijl de onzin regels wel gedaan zijn.

Voor de duidelijkheid: ik ben voor een geaccepteerd risico.

[Reactie gewijzigd door feuniks op 25 juli 2024 07:11]

[robertlinke]

niet geheel mee eens. als iemand die veel met luchtvaart doet, zeg ik dat standaard procedures absoluut levensreddend zijn. en ja het kan wat langer duren, maar dan moet je er nog steeds opletten dat het goed gebeurd.

het gene wat er vaak gebeurd is dat mensen niet weten waarvoor de procedures er zijn, en geloven dat het alleen maar extra werk is en het dan niet doen. als mensen duidelijk weten waarom procedures bestaan, en wat er gebeurd als het niet word gevolgd, kan dat makkelijk voorkomen worden.

en managers moeten niet alles op en zo korte mogelijke termijn gedaan willen krijgen. ja tijd is geld, maar zo'n storing als dit kost nog vele malen meer, en daar denken ze vaak niet over na. het is allemaal snel snel snel, en dan gaat het juist fout. laat ze maar een keer zeggen doe het goed, dan hoeven we het geen 2e keer te doen

[et36s]

Het is vooral dat laatste managers die overal druk opleggen. Of mogelijk heb ik nog nooit gewerkt met een echt goede manager

[Xerxes249]

Een goede manager legt geen druk maar focus

[7ven]

Een goede manager houd overzicht. Goede medewerkers houden focus.

[rob12424]

Een goede manager bestaat bijna niet!
Je hebt namelijk inzicht en overzicht nodig. De beste manier omdat te verkrijgen is niet als manager maar als meewerkend voorman.

Ze hebben in Duitsland bijvoorbeeld HBO studies waar je bepaalde tijd (zelfs een jaar) op MBO niveau moet meedraaien en als MBO'er ook behandeld wordt. Om zo inzicht te krijgen wat je personeel ongeveer doet.

Het gaat er niet om dat iemand fouten maakt, maar dat iemand verantwoordelijkheid neemt! Een voorbeeld: ik had 2 tijdelijke werknemers onder mijn hoede 1 maakte een fout van 300 miljoen en 1 van 80 euro.

Mijn chef moest kiezen wie hij aan zou nemen. Ik adviseerde die van 300 miljoen aan te nemen en die van 80 euro niet. Je zal denken huh waarom?

Ze dacht dat ze een fout had gemaakt van 300miljoen(ze speculeerde), ze nam gelijk de verantwoordelijkheid zo dat ik snel kon handelen. En zo de kosten kon minimaliseren en het was een opeenstapeling van fouten die maar deels aan haar te wijten waren. Maar omdat ze de verantwoordelijkheid nam kon ik de schade als die er al was beperken.

Die van gespeculeerd 80 euro. Melde niets. Ik trof iets aan, de kabouters hadden het gedaan en de schuld lag bij een ander.

De hoofdreden dat je wilt weten wie de fout heeft gemaakt is simpel:

1. Er van leren.
2. Diegene heeft vaak toch het beste inzicht en overzicht wat er gebeurt is.

Net als met de toeslagen affaire: hoewel mijn gevoel ook zegt de daders ophangen aan de hoogste boom. Ze hebben een fout gemaakt. Wisten dat. Gingen dat verdoezelen. (Waarom, was er toen ingegrepen waren de kosten minimaal geweest)
En nu willen we ze naar het lynchen, maar gaan ze daardoor ooit bewijs leveren en meewerken met de oplossing van het probleem (of eerder de boel nog meer verdoezelen?) En ondertussen is het alleen nog meer een bodemloze put aan het worden! En iemand gaat echt niet meewerken aan zijn eigen veroordeling.

Ik vindt het noemenswaardig overigens dat de AMS-IX zo transparant is over wat er gebeurt is en hoe dit opgelost is. Daar kunnen veel bedrijven nog van leren!

[Reactie gewijzigd door rob12424 op 25 juli 2024 07:11]

[tweaknico]

Een goede manager faciliteert, zorgt voor de omstandigheden en middelen dat iedereen z'n werk naar behoren kan uitvoeren.
Probleem is dat die schaars zijn...
Focus is een gevolg van de beschikbaarheid van zaken om de klus te klaren, omdat er geen afleiding is.
Die afleiding bestaat dan uit alle details zelf moeten regelen, kan ook maar dat gaat dan meer tijd kosten.

[T-men]

De ambtelijke omgeving waarin ik werk staat bol van de procedures. Het aantal managers is daardoor ongeveer net zo groot als het aantal mensen op de werkvloer (helaas is dat niet eens overdreven )
Toch gaat daar nog regelmatig wat fout.

Procedures zijn geen garanties !

[Skit3000]

Procedures werken beter als ze door de mensen op de werkvloer zelf worden gemaakt, waarbij managers hooguit aan de hand van een risicomodel de kaders bepalen.

[NielsFL]

Procedures moeten in balans zijn met de risico's. In de luchtvaart zijn potentiele gevolgen veel ernstiger. Mensen beseffen dat en zullen daardoor bereid zijn meer procedures nauwkeurig te volgen.

[feuniks]

niet geheel mee eens. als iemand die veel met luchtvaart doet, zeg ik dat standaard procedures absoluut levensreddend zijn. en ja het kan wat langer duren, maar dan moet je er nog steeds opletten dat het goed gebeurd.

Ik ben niet tegen standaard procedures. Als je dat denkt, dan heb je mijn betoog niet goed begrepen. Ik werk zelf heel graag met checklists voor bepaalde zaken. Waarom? Omdat ik dan weet dat ik dingen uniform doe en omdat ik nogal eens gestoord wordt, dus dan weet ik waar ik gebleven ben.
Standaard procedures en checklists betekent alleen niet dat je elk wissewasje in die procedure moet zetten. Dat zou ad absurdum voor een vliegtuig betekenen dat voor vertrek iemand controleert of ieder schroefje vast zit, omdat er ooit eens een keer een vliegtuig is neergekomen, omdat een schroefje los zat. Dat doe je niet. Dan zou er geen vliegtuig op kunnen stijgen, omdat tegen de tijd je het laatste schroefje vast hebt, het eerste al weer los zou kunnen zijn gegaan. Wat doe je wel? Je doet een visuele inspectie van het toestel. (Zie ik iets raars) Je test de belangrijke systemen. Je kijkt of je voldoende brandstof hebt. Dat soort dingen. Dat staat ook in je procedure en dat moet je ook doen. En als er een ongeluk gebeurd en de kans dat dit nog eens gebeurd is groot genoeg, dan zal dat toegevoegd worden aan de handleiding. En als het iets is wat een piloot onder bepaalde omstandigheden gemakkelijk fout kan doen, dan zal daar zelfs dat type vliegtuig op worden aangepast.

[robertlinke]

precies, maar al die stappen die je wel uitvoert staan uitvoerig beschreven en moeten worden afgevinkt om te zorgen dat het wel gedaan is, en ook om te kunnen aantonen dat het gedaan is.

je moet natuurlijk niet alle mogelijke dingen erin proppen, want dan heeft niemand er wat aan, maar als je met kritieke zaken bezig bent dan moet er wel duidelijk staan wat de bedoeling is, en niet oh zal wel goed komen.

[Hogarts]

Je hebt een wezenlijk verschil tussen standaard procedures en elke fout maar willen tegengaan.

Standaard procedures zijn in de regel een overzichtelijk aantal te checken dingen waarbij er over elke toevoeging nagedacht wordt of dat wel toegevoegd moet worden of je het niet beter kan bundelen met 9 andere gelijkwaardige punten naar 1 nieuwe check.

Elke fout maar willen tegengaan leidt tot procedures die ik daadwerkelijk bij sommige bedrijven heb zien oplopen tot 100'en tot 1000'en te checken punten. Dat is voor een mens niet meer te bevatten, die gaat dingen vergeten / overslaan / het duurt te lang. En elke fout ongeacht consequentie is gewoon een toevoeging aan de procedures. Er is ook veelal nooit tijd om de procedures te herzien / optimaliseren / bundelen want men is tig uur bezig met het uitvoeren van de procedures en kan er dus niet over nadenken.

Supersimplistisch / stompzinnig voorbeeld : Vliegtuig doet iets fout omdat de piloot ligt te slapen, piloot zegt dat er geen koffie was.
Standaardprocedures veranderen in dit geval niet (piloot hoort al niet te slapen)
Elke fout maar willen tegengaan leidt tot een extra checkpuntje dat er wel gekeken moet worden of er koffie is anders mag je niet opstijgen.

Morgen gebeurt het weer, maar nu blijkt de piloot geen koffie te drinken maar thee
Standaardprocedures veranderen in dit geval niet (piloot hoort al niet te slapen)
Elke fout maar willen tegengaan leidt tot een extra checkpuntje dat er wel gekeken moet worden of er ook thee is anders mag je niet opstijgen.

Dag daarna gebeurt het weer, maar nu blijkt de piloot geen koffie/thee te drinken maar cola
Standaardprocedures veranderen in dit geval niet (piloot hoort al niet te slapen)
Elke fout maar willen tegengaan leidt tot een extra checkpuntje dat er wel gekeken moet worden of er ook cola is anders mag je niet opstijgen.

Oftewel qua standaard procedures verandert er niets, maar qua elke fout maar willen tegengaan heb je nu al 3 checks extra die uitgevoerd moeten worden voordat het vliegtuig mag opstijgen.

[CPV]

Dat vind ik persoonlijk altijd een typische Pavlov reactie: er is een keer iets fout gegaan, dus moeten we ervoor zorgen dat dat nooit meer kan gebeuren.

Precies. Mijn ervaring is dat het documenteren en voorkomen van iets wat een keer fout is gegaan, vrij nutteloos is, omdat de kans dat *dit* nog een keer optreedt heel klein is: men zorgt er wel voor dat *dit* niet meer gebeurt.
Je kunt je beter concentreren op dingen die onverwacht fout kunnen/zullen gaan, maar waarvan je nog niet weet welke dat zijn en daarop procedures bouwen.

[dieAndereGozer]

Dat geldt natuurlijk alleen als het dezelfde mensen blijven, nieuwe werknemers hebben hier geen weet van als je het niet opschrijft.

[feuniks]

Dat geldt natuurlijk alleen als het dezelfde mensen blijven, nieuwe werknemers hebben hier geen weet van als je het niet opschrijft.

Totdat je zoveel documentatie hebt dat je het wel gedocumenteerd hebt, maar je door de hoeveelheid documentatie niets meer terug kunt vinden. Beter 10 pagina's documentatie met de belangrijkste zaken, dan 1000 pagina's die echt niemand gaat lezen.

[dieAndereGozer]

En vandaar dat er dus dingen mis gaan. Goede documentatie betekent niet dat je een dikke bijbel hoeft te schrijven, je kan het per taak afvangen met kleinere documenten.

[Hogarts]

Nieuwe medewerkers hebben ook niets aan 100 pagina's documentatie die ze maar even moeten bestuderen want dan blijft er praktisch niets hangen.

De meeste dingen moet je logisch proberen op te zetten zodat de mensen vanaf een bepaald kennisnivo zelf ook tot die check komen als het relevant wordt.

[Tukkertje-RaH]

Toch zou één enkele fout niet moeten kunnen zorgen voor het downgaan van een bijne hele internet exchange...

In de vliegwereld hebben ze het graag over het Zwitserse kaasplakken model: elke procedure heeft z'n eigen issues en problemen, maar alleen als alle plakken zodanig op elkaar liggen dat de gaten boven elkaar vallen gaan er dingen stuk. En dat is gelukkig niet vaak zo.

Maar als ik hier de root cause analysis lees dat 1 van de poorten nog in het operationele netwerk hing, en dat een snake-test daar meteen een probleem op veroorzaakte, dan lijken er te weinig plakken kaas gebruikt te zijn: te makkelijk ging de boel fout.

En tuurlijk, je kan nooit alle problemen voorkomen al was het alleen al omdat het inderdaad te omslachtig werken is dan. Maar net zo als de NS niet kan roepen dat er 'even' geen treinen rijden vanwege een fout in de planning, wil je ook hier graag dat er wordt geleerd van de fouten en 'iets' (mensen, procedures, techniek) wordt aangepast om te voorkomen dat het weer gebeurt.

[Hogarts]

wil je ook hier graag dat er wordt geleerd van de fouten en 'iets' (mensen, procedures, techniek) wordt aangepast om te voorkomen dat het weer gebeurt.

Waarom zou je iets moeten aanpassen?

Het lijkt me dat er gewoon een procedure is dat er geen snake-test op productie uitgevoerd mag worden.
Dat is hier schijnbaar toch gebeurt, dat betekent niet per se dat ik dan maar iets moet gaan aanpassen.

Je kan op veel voorkomende fouten gaan checken, maar je kan simpelweg niet op alle mogelijke gebeurde fouten gaan checken.
Simpelweg omdat je met de 2e methode altijd per definitie achterloopt en je enkel maar telkens meer tijdverlies introduceert.

Wat je wel en niet checked blijft gewoon een risico afweging en als het risico 0,0001% is dan ga je er simpelweg niet op checken.

[bzzzt]

er is een keer iets fout gegaan, dus moeten we ervoor zorgen dat dat nooit meer kan gebeuren?

Als het mogelijk is met een verbeterde techniek of proces dit probleem niet weer te hebben is dat toch alleen maar goed? Uiteindelijk kunnen veel processen ook in software worden ondervangen of gecontroleerd dus het hoeft niet altijd uren werk te kosten om minder risico te lopen. Een rood uitroepteken met 'weet je het zeker' had dit misschien al voorkomen.

Voor een organisatie als AMX-IX die als hoogste doel heeft het routeren van grote hoeveelheden data is het niet kunnen routeren zeker wel een ramp, dus alles wat daarmee mis kan gaan zal prio krijgen.

[Kevinp]

Daarom worden dingen extra duur in alle takken van het bedrijf. Risico's accepteren is vaak een betere oplossing. Als we maar met respect en eerlijkheid communiceren. En niet direct met boetes enzo gaan dreigen.

[Hogarts]

Het nadeel alleen met dit soort tussenbedrijven is dat zij tussen bedrijven instaan.

En als nu net een kleiner bedrijf dreigt om te vallen vanwege deze internet-storing en een boete kan dat omvallen voorkomen, dan wordt het toch al snel een ingewikkelder verhaal of je wel of geen boete moet uitdelen.

Simpel voorbeeld : Als je internet uitvalt als consument mag je na 12 uur 2 euro compensatie verwachten.
Oftewel als AMS-IX voor 12 uur uitvalt, dan heb je theoretisch over alle consumenten providers 34 miljoen euro schade. Moeten die providers dat dan maar ophoesten? Of kunnen die toch een boete vragen aan de AMS-IX omdat die fout zat?

En natuurlijk is 34 miljoen een schijntje, maar als AMS-IX echt daadwerkelijk 12 uur uitvalt en je naar zakelijke SLA's gaat kijken dan heb je best kans dat dit best een groot bedrag gaat worden, moet dan alleen de laatste persoon aan het lijntje maar de schade dragen?

[Cybertinus994]

Als een internet provider alleen maar aan de ams-ix hangt en dus geen mogelijkheid heeft om het verkeer anders te routeren als de ams-ix 12 uur stuk gaat, dan is dat absoluut niet de schuld van de ams-ix. Dan is die provider zwaar incompetent bezig.
Naast dat dit niet eens kan. Niet elke partij op internet is bereikbaar via de ams-ix (al dan niet indirect), dus als een provider alleen maar aan de ams-ix hangt, dan hebben zijn klanten een onvolledig internet. Dus een provider kan er altijd omheen routen, want die heeft altijd nog 1 of meerdere transits

[Kevinp]

Misschien moeten we dan gewoon niks behalen.

[SillieWous]

Waar staat dat ze procedures gaan aanpassen? Er staat dat er geëvalueerd gaat worden. Uit die evaluatie kan ook komen dat de huidige processen afdoende zijn, of dat de huidige procedure juist simpeler moet.

Juist bij een situatie die 75% van het verkeer verstoord acht ik het verstandig om i.i.g. te kijken of er iets aangepast moet worden.

[cobis taba]

Dat is niet wat ik in de AMS-IX reactie lees, gelukkig. Daar lees ik "we gaan kijken wat we er van kunnen leren". Daarvan kan de conclusie ook zijn "shit happens, dat is kut, maar moeten we accepteren".

[TabCam]

Zou je dat willen in een 24/7 service provider, ziekenhuis, bij een bank, backups, eventueel met privacygevoelige data etc.? Het gaat dan niet om maakbaarheid maar om zorgvuldigheid.

Hoeveel van degenen die de procedures uitvoeren weten waarom de regels precies zo in elkaar steken? Daarbij ben ik het met je eens dat de managers eigenlijk niet moeten gaan zeuren als het meer tijd kost.

Ik ben voor het nemen van acceptabele risico's maar wie gaat dat bepalen? Daarbij is het voor de AMS-IX niet eens een groot risico, ik denk eerder aan bedrijven die wel van internettoegang afhankelijk zijn en elke vertraging flink geld kan kosten.

[EchoWhiskey]

"Te veel procedures en checks hebben het nadeel dat op een gegeven moment mensen zich er niet aan gaan houden en afkortingen gaan zoeken"

Of dat mensen helemaal niet meer nadenken en gewoon alles doen wat op een checklist staat zonder ook maar 1 sec na te denken.
Daarmee haal je elke vorm van probleemoplossend vermogen uit iemand.

Checklist zijn prima en noodzakelijk maar niet heiligmakend

[Keypunchie]

Deels eens. Wel altijd evalueren na een groot incident!

[hoe de worst gemaakt wordt]
Als het daadwerkelijk niet de moeite is om het strucureel op te lossen, dan zorgt een goeie procesbegeleider wel dat uit de evaluatie iets politiek verdedigbaars als “de documentatie wordt verbeterd”, komt.

Paar aantekeningen in de documentatie en door.
[/hoe de worst gemaakt wordt]

[Reactie gewijzigd door Keypunchie op 25 juli 2024 07:11]

[jcvw]

Zoals er geschreven is in het SRE boek: "The cost of failure is education."

Mensen maken fouten, dus moet het systeem dat ondervangen. Als een goedwillend persoon iets doet dat het systeem onderuit trekt, is dat niet de fout van die persoon, maar van het systeem dat dat niet tegengaat.

Een bekend voorbeeld is het design van de cockpit van de B17 bommenwerper (WW2) waarbij de knoppen voor landingsgestel en flaps hetzelfde waren en vlak naast elkaar. Daardoor crashten veel vliegtuigen bij landing (piloot denkt landingsgestel uit te klappen, maar heeft de verkeerde knop gebruikt waardoor de flaps werden ingetrokken - het vliegtuig is bij landing te traag om nog voldoende lift te heppen bij ingetrokken flaps). Zie https://medium.com/swlh/t...ss-fatal-flaw-694523359eb

Alleen blameless retrospectives/postmortems zorgen ervoor dat mensen geen feiten onder het tapijt vegen en komen uiteindelijk met de root cause naar boven.

Je hebt door de outage de prijs betaald voor de educatie - het enige wat je kunt doen is ervan leren. Het tegenovergestelde is ass-covering...

[Frame164]

Dit zal waarschijnlijk niet meer zo gauw gebeuren, maar het is een illusie om te denken dat je alles met processen kunt dichttimmeren.

[NielsFL]

Procedures zijn een optie, maar idealiter los je dit technisch op. Je maakt het onmogelijk om zo'n test uit te voeren op een productie systeem. Of je zorgt dat het per abuis uitvoeren van zo'n test op productie minder ingrijpende gevolgen heeft. Liefst beide.

Ik ken de snaketest inhoudelijk onvoldoende om concrete suggesties te doen, maar ik kan me niet voorstellen dat dit niet te voorkomen is zonder een goedbedoeld boekwerk van de interne praatclub.

[nnsa]

Testen doe je natuurlijk om 10:15…

[eBait]

Een van de redenen dat er steeds meer IXPs naar EVPN migreren: MAC Address Damping / Flapping Detection - dan was het issue in ieder geval niet groter geworden dan de PE waarop er getest werd. VPLS op schaal blijft een vrij risicovolle bezigheid

[LanTao]

Dat zijn features die vendors ook best voor VPLS zouden kunnen implementeren.

[webfreakz.nl]

Dat kan dus niet, er is bij VPLS alleen communicatie via LDP/BGP over de interfaces, niet over de betrokken MAC adressen. En VPLS multihoming heeft altijd problemen gehad. Om die redenen is juist EVPN gemaakt.

[webfreakz.nl]

Daarvoor bij een snaketest ook gewoon een keten van routed porten maken en interfaces in VRFs plaatsen.

[eBait]

Hoe ga je dan een grotere snake bouwen? Bij AMS-IX gebruiken ze namelijk de PXCs om de klantbekabeling mee te testen, waardoor alle klantpoorten in een testactie worden meegenomen. Als je meer dan twee poorten wil gaan testen is routed echt wel een stuk lastiger dan gewoon een set VLANnetjes doortrekken

[webfreakz.nl]

Meerdere VRFs met elk 2 interfaces erin?

[MischaBoender]

Die engineer zal deze week niet met een heel erg prettig gevoel naar zijn werk gaan denk ik...

Maar ja, waar gehakt wordt vallen spaanders. Laten we het er op houden dat het een goed leermomentje was voor AMS-IX.

[Verwijderd]

Hij/Zij/Het moet waarschijnlijk gebak meenemen voor iedereen. Zo doen we dat hier namelijk

[QuatroXL]

Daar beginnen wij niet meer aan, zeker in de Corona tijd dat we veel thuis zaten en weinig bewegen. Wij hadden namelijk een flatervlaai voor dit soort ongelukjes. Dit alles stond dan weer beschreven in een (taart)bodem procedure.

[CPV]

Ik ken een afdeling die de omgekeerde procedure had: als de standby in zijn week niet opgepiept was, trakteerde hij/zij de collega's om ze te bedanken voor hun zorgvuldige werk.

[Dorank]

Deze week? Collegas die hier een loop creeeren worden hier nog jaren aan herinnert.

[Polderviking]

Fijne werksfeer zal je hebben op de vloer.

[Plofkotje]

Ach, is bij networking teams best normaal.. ik word ook nog dagelijks herrinnerd bij een klant over een fuckup van 10 jaar geleden, en zo hebben we allemaal wel een goed verhaal over elkaar waar we elkaar bijna elke dag aan herrinneren.

[0siris]

Het was dan ook woensdag, en woensdag is gehaktdag.

[Maurits van Baerle]

Ik heb wel eens een flinke fout gemaakt tijdens mijn eerste echte baan na de universiteit en eentje die ons flinke reputatieschade opleverde.

Een van mijn bazen destijds reageerde daarop door af te spreken dat ik voortaan altijd verantwoordelijk was voor die specifieke klus. Want als er íemand in de organisatie was die zo'n fout nooit meer zou maken dan was ik het wel. En zijn reactie heb ik zelf ook weer veel van geleerd.

[OxWax]

Als je tenminste wist wat de fout veroorzaakte?

[Maurits van Baerle]

Ja hoor, haast en niet genoeg opletten in mijn geval.

[True]

Voor AMS-IX vind ik dit nogal knullig.

[anpat]

Alleen waar gewerkt word kunnen er fouten gemaakt worden. Zo ook daar dus.

[wildhagen]

Ken je dat gezegde, die oud-Hollandsche tegeltjesspreuk:

---
Waar mensen werken, worden fouten gemaakt.
Mensen die weinig werken, maken weinig fouten.
Ik ken mensen die helemaal geen fouten maken
---

In andere woorden, fouten zijn nu eenmaal onvermijdelijk, waar mensen werken. Ook al heb je procedures en richtlijnen, één keer een foutje kan toch grote impact hebben.

[niqck]

Kreeg ik 25 jaar van mijn (toen) baas te horen: alleen hij die niets doet, kan niets verkeerd doen.

Wijsheid die ik tot op vandaag nog steeds aan collega's meegeef.

[Zezura]

Waar mensen werken worden fouten gemaakt 🙂

[Tristan]

Soms is juist niets doen geheel verkeerd. Denk aan het niet ingrijpen bij een straatruzie oid.

[Verwijderd]

of als Rusland weer eens een ex Soviet land binnenvalt...

[RoestVrijStaal]

"Waar gehakt wordt, vallen spaanders"

[Frame164]

Hoe zou jij dit soort fouten voorkomen?

[webfreakz.nl]

Als je nou een snaketest gaat draaien op de (bijna?) grootste internet exchange ter wereld, waarom staat dan in hemelsnaam dat productie VLAN op die lijnkaart? Ze hebben in het verleden vaker outages gehad met loops om ze een verkeerd VLAN hadden geplaatst.

Ik zou een 100G Spirent / IXIA hebben en al die porten een klein /31 subnet geven, in VRFs plaatsen en end-to-end 100G routing doen om die lijnkaart, SFPs en CRC checks te testen.

En MAC limiting op die porten zetten.

[Reactie gewijzigd door webfreakz.nl op 25 juli 2024 07:11]

[air2]

Geen ams-ix runnen is mijn tactiek. Heb dit probleem echt nooit . /s

[Reactie gewijzigd door air2 op 25 juli 2024 07:11]

[kroegtijger]

Ben er ook nog nooit tegenaan gelopen

[Reactie gewijzigd door kroegtijger op 25 juli 2024 07:11]

[Firestorm666]

Let op de /s

[GameNympho]

Menselijke fout, kan gebeuren.

[g_v_rijn]

Netjes dat de 'veroorzaker' is achterhaald.
Note: je kan niet alles voorkomen (met processen & regels) Interactie van mens en/of machine is er -links of rechtsom- dus fout blijft altijd mogelijk.

[Reactie gewijzigd door g_v_rijn op 25 juli 2024 07:11]

[CyberTijn]

Een paar jaar geleden was er ook een storing bij AMX-IX veroorzaakt door een loop in een customer VLAN.
nieuws: Internetknooppunt AMS-IX kampt met uitval - update 2

Het blijft mensenwerk wat we doen met z'n allen. Kwestie van lering uit trekking, je (change)processen verbeteren en weer door.

[LanTao]

Het lijkt op dezelfde oorzaak (het onterecht vrijgeven van switchpoorten voor testen), alleen toen hadden ze het na zeven minuten door en onder controle; nu duurde het ruim een half uur.

[Kruitdamp]

Bijzonder, wij kregen een update dat er wel zaken fysiek hersteld moesten worden.

[Tenocticatl]

Oeh het zal de betreffende medewerker wel even dun door de broek zijn gelopen toen hij/zij zag wat er mis ging .

[HoppyF]

Ondanks alle procedures kan zoiets gebeuren.
Op een gegeven moment kun je een reeds geteste procedure op een testomgeving uitvoeren in productie en kan er even zo goed wat mis gaan door een verkeerde actie.
Pluspunt voor de AMS-IX om dit eerlijk toe te geven.
Daarmee verdien je respect ipv een slap verhaal op te hangen.
Eerlijkheid duurt het langst.

[OxWax]

Ben eens benieuwd naar de oorzaak bij het spoort verleden weekend.

[HoppyF]

Falend backup systeem?
Al dan niet in combinatie met menselijk falen?
Jaren geleden heb ik mij al verbaasd over het bestaan van VMS (OpenVMS) bij ProRail.
Oud OS niet meer ondersteund enz.
Niet iets wat je moet willen.

[OxWax]

Ik kende het niet maar (VMS wiki)

This allows clustered applications and data to remain continuously available while operating system software and hardware maintenance and upgrades are performed,[26] or if part of the cluster is destroyed.[27] VMS cluster uptimes of 17 years have been reported

[HoppyF]

VMS op zich is betrouwbaar en stabiel.
Maar aan alles komt een eind, zo ook VMS.
Vaak durven bedrijven een migratie naar een nieuw systeem niet aan.

[SPARCie64]

(Open)VMS wordt nog wel ondersteund/doorontwikkeld (door een bedrijf genaamd VSI, is zelfs bezig met een port naar X64

[HoppyF]

Zou kunnen, ik ben er al een tijdje uit.
Het voormalige Digital, Compaq en HP zullen zich er denk ik niet meer mee bezig houden.
Bij één mijn vorige werkgevers heb ik diverse collega’s gehad uit het VMS tijdperk.

[SPARCie64]

HP/HPE heeft het aan VSI uitbesteed

[Plofkotje]

OpenVMS wordt nog best veel gebruikt bij grote bedrijven en wordt zelfs nog gewoon 100% gesupport (en op dit moment geport van Itanium naar x86) door VMS Software (https://vmssoftware.com/) en daarvoor door HPE.

Niks niet ondersteunds aan OpenVMS

[HoppyF]

Ok, is allemaal off-topic maar ik spreek over jaren geleden.
Er waren toen zeker support problemen ivm oudere versies VMS.
Migratie naar een ander platform was toen erg lastig.
Maar goed staat los van de AMS-IX.