Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Typfout in commando leidde tot grote storing Amazon S3 en downtime veel websites

Door , 118 reacties, submitter: HyperioN

De storing bij clouddienst Amazon S3 die downtime veroorzaakte bij veel Amerikaanse websites en diensten, kwam doordat een medewerker een typfout in een commando maakte. Daardoor haalde de Amazon-medewerker veel meer servers offline dan de bedoeling was.

Het is onbekend wat de typfout precies was, maar de medewerker wilde met het commando een paar servers offline halen voor het proces van in rekening brengen van S3-diensten, meldt Amazon. Door het commando verkeerd in te voeren, ging het index-subsystem offline. Dat is het systeem dat alle servers indexeert en dus de locatie en metadata bevat van alle S3-servers in de regio. Daardoor werd het onmogelijk om veel servers te gebruiken.

Het herstarten van het index-subsysteem was vrij snel gedaan, maar veel servers hadden inmiddels een backlog van requests en het duurde daardoor langer voordat alles weer normaal functioneerde. De storing vond dinsdagavond Nederlandse tijd plaats.

Door de storing waren veel Amerikaanse websites en diensten geheel of deels onbereikbaar. Veel sites en diensten gebruiken de diensten van Amazon. Onder andere Imgur, Medium, Slack, Yahoo webmail, Quora, Trello en Runkeeper ondervonden gevolgen van de problemen.

Amazon neemt diverse maatregelen om te zorgen dat de storing niet meer zal voorkomen. De belangrijkste daarvan is dat de tool die de medewerker gebruikte om enkele servers offline te halen niet meer in een keer de belangrijkste servers kan beheren. Ook wil Amazon zijn index-subsystem sneller kunnen herstarten.

Door Arnoud Wokke

Redacteur mobile

03-03-2017 • 07:42

118 Linkedin Google+

Submitter: HyperioN

Reacties (118)

Wijzig sortering
Het probleem was niet zo dat er iets te veel servers down gehaald werden, het probleem was dat de infra er blijkbaar niet goed reageerde terwijl dat wel de bedoeling had moeten zijn.
While this is an operation that we have relied on to maintain our systems since the launch of S3, we have not completely restarted the index subsystem or the placement subsystem in our larger regions for many years. S3 has experienced massive growth over the last several years and the process of restarting these services and running the necessary safety checks to validate the integrity of the metadata took longer than expected.
Heel kort door de bocht, er zouden minimaal 10 servers moeten zijn, en per ongeluk werd het aantal servers naar 5 gebracht. Het systeem zou dit weer gewoon naar 10 moeten brengen, maar dat ging niet zo goed als de keren dat het van 8 naar 10 moest gaan.
Nu gaan ze hun tooling aanpassen dat je niet meer het aantal servers onder 8 kan krijgen. Maar ze moeten nog steeds het probleem in recovery fixen waarvan ze niet op de hoogte waren.
Wat mij ook opviel, was dat Apple ook 17 systemen down had, alle icloud toepassingen lagen eruit dinsdag.
Zijn Amazon en Apple partners in het zelfde data center missc? weet iemand of het met elkaar te maken had?
Apple heeft zijn diensten draaien bij Amazon, Azure maar ook Google Cloud (Bron) maar is ook erg bezig om met eigen datacenter te bouwen zodat ze niet afhankelijk zijn van Amazon, Azure en Google Cloud. De twee datacenters komen in elk geval in Europa en zouden dit jaar waarschijnlijk in gebruik genomen worden.

Wat ik uit de verhalen heb begrepen is dat ze met name niet tevreden zijn over de snelheid van de huidige clouddiensten. Ook willen ze het aantal storing hiermee omlaag brengen.

Bron 1
Bron 2
Bron 3
Apple maakt gebruik van AWS en ook Azure.
Amazon ICT beheerders kunnen met geen enkel commando Apple servers offline halen.
Als heel S3 eruit ligt klapt Apple er ook gewoon uit :+
Tjah, erg lullig voor die medewerker. Shit happens. Maar eigenlijk nog erger dat 1 enkele medewerker dit perongeluk kan doen. Zou toch proberen wat safeguards in te bouwen of dat er een 4-eyes check dient plaats te vinden op moment dat er een grote transactie of potentieel gevaarlijk commando wordt gedraaid.

Dat doen wij met verschillende systemen op het werk. Vaak ook het 2x overtikken van een commando alvorens het echt wordt uitgevoerd. Bij een mismatch krijg je dan sowieso al een waarschuwing. Dit doen wij bijvoorbeeld ook bij het verwijderen van systemen. Je moet dan 2x de naam intikken alvorens de echte delete plaatsvindt. Copy pasten werkt in die schermen niet.

Of een check die naar een collega gaat die bevestigd wat je aan het doen bent. Gebeurt dan weer bij grote transacties. Lastig maar het voorkomt al jaren veel fouten.
Nee Nee Nee erg lullig voor die medewerker. Shit happens.

Typisch voorbeeld van slechte impact analyse. Als de impact juist was bepaald had men geweten wat de gevolgen hadden kunnen zijn van een typo. Een public cloud provider van deze omvang kan het zich niet veroorloven om dit soort fouten te maken. De downtijd is opgebruikt voor een periode van 3,5 jaar. Maw men heeft nu al in maart zoveel downtijd gehad dat ze de komende 3,5 jaar niks meer mogen laten uitvallen (S3). Overigens wordt S3 als 4 digit available 99,99 verkocht. Hier zie je overigens wel heel duidelijk het verschil. Bij traditionele IT bedrijven spreekt men van penalties die al gelijk in 10Ks kunnen lopen. Hier spreekt men van service credits wat discount is op de servicekosten van S3. Das nogal een verschil. Amazon kan dus gewoon besluiten heel de flikkerseboel te upgraden tegen een discount van 10 - 20% op de servicekosten van die maand. Weet dat iedereen die naar de cloud gaat? Nee geloof ik niks van.

Edit (bij dit soort constructies is de SLA voor veel bedrijven waardeloos. De SLA beschrijft de discount na een lagere score dan 99.0% uptime van 25%. In theorie kan het zo zijn dat ze zelfs 32% outage hebben, 2 dagen in de week dus, je toch maar 25% discount krijgt op het S3 tarief. Das toch bizar dat men dat pikt?)

Anyway dit had gewoon voorkomen kunnen worden door de change met een hogere impact te classificeren met daarbij standaard een 4 of 6 ogen procedure. Gaat het dan nog fout dan zijn de mensen niet geschikt.

[Reactie gewijzigd door InsanelyHack op 3 maart 2017 12:05]

Anyway dit had gewoon voorkomen kunnen worden door de change met een hogere impact te classificeren met daarbij standaard een 4 of 6 ogen procedure. Gaat het dan nog fout dan zijn de mensen niet geschikt.
Sommige fouten kun je gewoon niet voorzien, ongeacht het aantal ogen dat je er op zet of hoe hoog de classificatie ook is of hoe vaak je van tevoren ook hebt getest en hoe capabel de mensen ook zijn. Shit happens.

Wat er in mijn mening echt toe doet is hoe men met fouten omgaat en hoe men gaat voorkomen dat dit nogmaals optreedt.
Dat weten we inmiddels. Amazon geeft gewoon wat geld terug. Case closed.
Nee dat is wat het naar de klant te doet. Ik zijn opmerking ging het om wat er bij Amazon intern vervolgens plaatsvind.

Daar zal men niet te gedetailleerd op in gaan.
De interne drive zal alleen veranderen als de penalties serieuze proporties aannemen. Als er een klein deel van de service fee wordt terugbetaald ipv de business claim van klanten dan is dat peanuts. Wat boeit het Amazon als je 500 euro betaald voor de service en je dan met pijn en moeite 25% terugbetaald krijgt. De mensen die dit snappen kosten al meer dan 100 euro per uur.
De penalty is qua imagoverlies al enorm.

Dat zal nu echt wel reden zij tot actie. Daar hebben ze de extra penalties in dit geval niet meer bij nodig.
Amazon komt daar mee weg en terecht ook. Ze zeggen dat S3 als lowest storage tier wordt aangeboden. Je architectuur zal ook onder de loupe moeten worden genomen of de resilliancy wel goed genoeg is. Dat is ook de uitdaging voor veel architecten. Traditioneel IaaS architecturen migreren naar Amazon vereisen meer resilliancy technieken en dat werkt sterk prijsverhogend.
> Sommige fouten kun je gewoon niet voorzien,

Maar dat betekent niet automatisch dat men deze fout niet kon voorzien. Dat is het argument van toet-toet, niet dat ze zogenaamd alle fouten moeten kunnen voorzien. Het doel van de organisatie is om de 99,99 SLA te halen. Dan tellen excuusjes als 'ja maar je kan niet alles voorzien' niet. Het gaat erom dat je met alle voorziene fouten je 99,99 haalt, en dat is nu niet gebeurd.
Ik zit dit nog na te lezen. Ik ben het er gewoon niet mee eens. Dit soort fouten worden juist wel door 4 of 6 ogen vermeden. Weet je wel hoe dat echt moet? Het betekend dat twee of 3 analysten allemaal dezelfde change uitvoeren. Na iedere executie stap worden deze vergeleken en bevestigen ze elkaar wat deze stap is. Dan juist wordt voorkomen dat er typos kunnen plaatsvinden. Het nadeel is dat het traag werkt maar dit is wel een beproefde methode heb ik ervaren.
Shit does not happen by it's self, it is made by an asshole.
Alleen in een omgeving die er niet toedoet worden nooit fouten gemaakt die impact hebben.

Bij dit soort incidenten is het belangrijk om drie kanten op te kijken:
1. wat zijn de factoren die tot de handeling leidden (kan dat anders)
2. wat had dit kunnen voorkomen in de uitvoering
3. Wat kan in geval van dit incident helpen met sneller herstel of reductie van impact.

Maar dan nog hoor. Heb het overal gezien, van superprofessioneel tot cowboy-bedrijf: fouten worden gemaakt. Van juniors die met te weinig ondersteuning een te zware taak moeten doen, tot een zeer professioneel beheerteam dat ondanks onderhoudsdraaiboek en stappenplan en gedetailleerde planning beide poten van een dubbel uitgevoerde High-Available omgeving weet down te krijgen.

Belangrijkste is dat een organisatie er vervolgens open voor staat om er van te leren, in plaats van hard te schreeuwen en het onderliggende probleem niet aan te pakken. Dat zijn de organisaties waarbij het maar zelden voorkomt versus de organisaties "Schering&Inslag".
Tja we zijn mensen dus fouten zijn voorgeprogrammeerd.

Het laat natuurlijk wel zien dat de hele infrastructuur eigenlijk gewoon een kaartenhuis huis.
Stel dat je nu een sysadmin hebt die doordraait en slecht wil. Die kan eenvoudig een domino effect genereren.

Vaak kies je voor een cloud dienst voor betrouwbaarheid en uptime, je moet je echter de vraag stellen of dat ook zo is ?
Het laat natuurlijk wel zien dat de hele infrastructuur eigenlijk gewoon een kaartenhuis huis.
Welke infrastructuur is dat niet?
1 defecte trein en half NL heeft vertraging, 1 zwaar ongeluk en je komt niet meer in/uit een stad en 1 keer noodweer en Europa heeft een tekort aan groente.

De gemiddelde IT infrastructuur is 10x robuuster dan praktisch elk ander aspect van een gemiddeld bedrijf. Welk bedrijf heeft een 2de kantoor volledig ingericht en draaiend om direct te kunnen 'switchen'. Of die mensen die 'onmisbaar' zijn in de organisatie hebben een fail-over (iemand die alleen maar 'erachteraan loopt'?
Het lastige is dat veel in IT land bestaat uit 'de enige'. De enige database voor de planning van een transportbedrijf, terwijl 1000 vrachtwagens rondrijden. De betrouwbaarheid van die database is waarschijnlijk geweldig als je die vergelijkt met hoeveel 'downtime' en 'gepland onderhoud' de vloot vrachtwagens heeft, echter is er geen alternatief als het misgaat.

Maar goed, zo kon ik laatst HR niet bereiken vanwege een 'field day' en regelmatig is er niemand te bereiken, maar het wel compleet onacceptabel vinden als het HR systeem een storing heeft... Volgens mij heeft HR vaker 'storing' dan hun systeem :+
Thanks voor dit geweldige inzicht. Zo had ik het nog niet bekeken :)
Tjah, het artikel geeft ook niet alle details dunkt mij. Nu lijkt het net alsof hij zich even vertikte in een CLI. Ben het verder met je eens. Vind wel dat dit soort gevaarlijke transacties voorzien moeten worden van extra beschermingen. Hoe dat dan ook uitziet.

[Reactie gewijzigd door Alpha89 op 3 maart 2017 08:30]

M.a.w: "Als het pijn doet, moet je het vaker doen!"

En nog eentje uit het boekje: "Als je alles onder controle hebt, ga je niet hard genoeg"

Je mag best fouten maken, als de klant impact maar 0 of minimaal is. Dat wordt de business namelijk snel zat.

[Reactie gewijzigd door java-artist op 3 maart 2017 11:08]

Vooral punt 2, daar mag gerust op meerdere plekken gekeken worden om een probleem te ondervangen. Ze kunnen nu wel het tooltje aanpassen, maar als het maar even kan zouden ze op de hele weg moeten kijken welke aanpassingen dit kan voorkomen. Daarbij ook goed de afweging maken welke aanpassing wel en welke niet wenselijk is.

Als dit commando om wat voor reden buiten het tooltje om gestuurd word zou het toch ook fijn zijn als er niets fout gaat, cq. ergens tegengehouden worden.
Fouten worden overal gemaakt waar mensen werken. Sterker nog, jij en ik maken ze ook.
4-eyes check maakt alles duurder en na 1000x routine-matig geen probleem te zien kijk je er de 1001x keer gewoon over. Een 4-eyes check werkt wel goed in situaties waar fouten te verwachten zijn en wat vaker voorkomen.
waarschijnlijk is er wel een 4 ogen principe, maar heeft iemand er overheen gelezen. amerikaans, dus SOX omgeving, dus 4 ogen principe (kan het me niet anders voorstellen dat dit bij dergelijke IT zaken ook zo geldt).
Zowat je hele reactie is fout, jij moet dringend eens opzoeken wat SOX inhoudt...

bvb
-Is niet alleen voor Amerikaanse bedrijven
-Niet alle Amerikaanse bedrijven moeten zich aan SOX houden
-SOX houdt niet in dat je 4 ogen principe moet toepassen
Exact wat ik dus zei... Het werkt alleen bij grote of potentieel gevaarlijke commando's...

[Reactie gewijzigd door Alpha89 op 3 maart 2017 08:25]

Ik werk voor een grote ISP en kan in mijn eentje ook alles platgooien, al dan niet met kwade bedoelingen, (al ben ik in China bij wijze van, lang leve VPN).

Het 4 ogen principe wordt door ons enkel toegepast bij lastige changes die veel impact kunnen hebben als er iets misgaat. Of bijvoorbeeld als er na uitvoerig testen een nieuw type router of zelfs software op de router voor het eerst live op de productieomgeving wordt gezet.

Meeste changes doe ik vanuit huis maar soms ook weleens gezamelijk vanuit kantoor in de nacht.

Wel hulde voor de transparantie van Amazon. Respect voor de mede-beheerder die de fout heeft begaan, been there done that :X
Ik werk voor een grote ISP en kan in mijn eentje ook alles platgooien, al dan niet met kwade bedoelingen, (al ben ik in China bij wijze van, lang leve VPN).
Als jij in je eentje alles plat kan gooien is dat eigenlijk heel eng.

Ik denk dat het helaas bij veel bedrijven zo is en tot op heden nog niet echt voor hele grote problemen gezorgd heeft.

Neemt niet weg dat als jij in je eentje alles plat kan gooien dat eigenlijk dus heel gevaarlijk is. Mocht jij nu bijv een ict medewerker van een bank zijn die dat soort toegang heeft dan zou je een mooi doelwit kunnen zijn voor criminelen.
We staan bij dit soort dreigingen nog niet stil maar zouden dat meer moeten doen.
De rechten die ik heb op de omgeving zijn inherent aan mijn functie als beheerder van het geheel..

Dat het ook gevaren met zich meebrengt ben ik ook met je eens. Gelukkig bestaat er ook nog iets als het moreel / de moraal.

Dit risico kun je m.i. niet voorkomen. Je kunt de rechten wel inperken maar en moeten toch individuen zijn die de core moeten kunnen beheren...
Respect voor de mede-beheerder die de fout heeft begaan, been there done that :X
Als je niet werkt maak je geen fouten. :)

En geen beheerder niet eens een keer iets onderuit getrokken heeft, om binnen 5 minuten met een rood hoofd een "Oeps" momentje te hebben... lastige herinneringen komen terug... :X

Natuurlijk voorkomt het 4 ogen principe een hoop shit, maar er moet ook zoiets zijn als vertrouwen: als management moet je er op kunnen vertrouwen dat je medewerkers weten waar ze mee bezig zijn. En de echt professionele beheerders geven zelf wel aan als ze iets lastig vinden: dan kan het management altijd besluiten om er nog iemand naast te zetten.
Zelfs bij een 4-eyes check moet uiteindelijk het werk toch worden uitgevoerd, Ok neem typos nooit kwalijk en de SLA zal dit ook wel hebben afgedekt. Niet leuk, maar de afnemers willen voor paar nootjes de diensten afnemen. Zou mij niet verbazen wanneer een samenhang is van werkdruk (eigenlijk denk ik dat dit de reden is).
Zelfs met een 4-eyes check (of meer) worden fouten gemaakt. Sommige oorzaken van fouten zijn extreem lullig. Denk bijvoorbeeld aan stomme dingen als een spatie te veel, CR, 0 i.p.v O.
Ik kan me niet voorstellen dat dit een typefout is geweest. Dit is een blunder van de eerste orde.

Nu moet ik wel toegeven dat ik in mijn systeembeheer dagen ook wel eens de verkeerde server uitgeschakeld heb :+
Ik vind het juist bewonderingwaardig dat ze juist zo eerlijk en transparant zijn. Meestal zie je dat bedrijven met vage statements komen waarin ze de schuld afschuiven op een samenloop van omstandigheden of geen details geven. De meeste bedrijven denken dat ze gezichtsverlies leiden als ze eerlijk zijn.

Iedereen die in de IT werkt weet echer dat zoiets kan gebeuren, hoeveel zaken je ook automatiseert (want dan zit daar tenslotte wel weer een fout die handmatig gecorrigeerd moet worden). Als programmeur heb ik ook regelmatig iets getypt wat daarna niet voor het gewenste resultaat zorgde :+ . Zeker als de vermoeidheid en druk toenemen. Eerlijkheid duurt het langst.
Ik weet nog hoe ik tijdens mijn afstuderen regelmatig alle kate-backups wilde verwijderen (rm *~) en soms eerst de tilde en daarna pas de asterisk typte uit angst dat ik te vroeg op enter zou drukken (rm *) en alles kwijt zou zijn (natuurlijk, er waren back-ups, maar minstens een paar uur werk was ik dan wel kwijt).
Ach zo heb ik ooit eens alle .tmp files van een Linux server weg willen halen...

rm -rf / *.tmp ... weet niet meer precies wát er mis ging, maar ineens kon ik geen shell commando's meer uitvoeren, bestonden mappen niet meer, en stond de telefoon roodgloeiend :|
Daarmee heb je gewoon alle mappen bestanden van het systeem weggegooid. Op zich best logisch dat je geen shell commando's meer kon uitvoeren, want die bestonden gewoon niet meer.
Ja dat snapte ik daarna ook, maar in m'n onschuld meende ik dus gewoon alle .tmp files ( immers, *.tmp !!) weg te gooien.

Dat wil zeggen, ik ken de gevaren van rm -rf wel, maar ja het was vrijdagmiddag, je komt om in het werk en wil nog snel even wat ruimte vrij maken op die ene server. Goddank was het geen belangrijke machine verder ;) (dwz. was nog in aanbouw/post install configuratie bezig) maar toch wordt je dan op een lullige manier met je neus op de feiten gedrukt.

[Reactie gewijzigd door DigitalExcorcist op 3 maart 2017 09:35]

Je had je doel wel bereikt. Er was meer als genoeg ruimte erna :)
Ja dat wel :) maar lullig blijft 't.
Voor als 't nog een keer moet:

find / -name '*.tmp' -print # check output...
find / -name '*.tmp' -print0 | xargs rm -f #uitvoering.
sja, zo heb ik een keer een site gewist. er was een script dat xml bestanden moest downloaden, maar die files kwamen in de root folder vd site vanwege een pad dat nog niet goed stond ingesteld .

rm -rf rf * .xml

met mn worstevingertjess even een spatie tussen de * en de .xml tjoeps!

gelukkig wel een backup en de dbase was onaangetast, maar toch...
Da's ook lullig inderdaad! En rm beschermt je op geen enkele wijze tegen jezelf..

[Reactie gewijzigd door DigitalExcorcist op 3 maart 2017 14:51]

Da's ook lullig inderdaad! En rm beschermt je op geen enkele wijze tegen jezelf..
het is meer de -rf (recursive + force) die t nogal jammer maakt ;-)

zo heb ik ook echt af moeten leren om altijd maar shift + delete te doen in windows (handig: want niet in de trashcan, alleen wel jammer als je per ongeluk een verkeerde folder of e-mail weggooit...)
De spatie tussen / en *.tmp ;)
Yep :) inmiddels weet ik 't wel maar de eerste keer dat het je overkomt sta je toch mooi even te kijken.
Dat is zeker waar!
Of als je een ander pakket installeert, gewoon op Y drukt en niet ziet dat je mailserver verwijdert word :+
Ahh, een klassieker. Daarom log je ook niet niet onder root aan op je systeem. Kijk, zo'n fout maak je gewoon 1 maal en daarna nooit meer ;)
tja als je websservers beheerd werkt je PHP vaak op suphp/FPM/Fcgi basis, en dan heb je alsnog sudo nodig om het spul te verwijderen gezien elke site als eigen user draait/de groep geen rechten heeft.
Daarom gebruik ik voor dat soort operaties eigenlijk altijd mc (norton commander kloon). Eerst altijd even kijken wat ik selecteer en dan de echte verwijder actie.
Yup, nog ff snel iets doen wat je normaal gesproken met je ogen dicht doet en... Bam, alles plat.

|:(
Dat is het ergste. Ooowh ik heb dit al zo vaak gedaan, wacht maar ik doe dit wel even. Ondertussen toch stiekem ook met iets anders bezig zijn en Bam daar ga je. Helaas zel ook wel eens de live database eruit gedonderd ipv de DEV db.... ;(
Of de vrijdag voordat je op vakantie gaat. Even snel eind van de middag dan 'ene kleine dingetje' nog even er doordrukken.
De hele dag in de terminal met auto completion.. een foutje is snel gemaakt hoor. Meestal onschuldig maar zoals je zelf al zegt, het gebeurt iedereen wel eens. Ik kan me het eigenlijk best wel goed voorstellen dat dit het geweest zou kunnen zijn.
Die autocomplete zal hier ook aan bijgedragen hebben. Waarschijnlijk ook de naamgeving van de servers en services die teveel overeenkomsten hebben.

Alles heel herkenbaar maar daarom niet minder stom.
Exact dat: Eastnode-00001 tm 13450. Zo een groot datacenter heet elke server niet meer Optimusprime en Ogreslayer. Dan heb je het zo gedaan als je even je koffie niet had gedronken.

[Reactie gewijzigd door ro8in op 3 maart 2017 09:00]

Hmm, ik was van plan om namen uit Game Of Thrones voor onze nieuwe serverfarm te gaan gebruiken, dan heb ik ook meer dan voldoende.

Maar inderdaad, Amazon zal de servers gewoon genummerd hebben en dan is een dergelijke fout wat sneller gemaakt. Per ongeluk een * achter de hostnaam van USA-EC-NOD10 (terwijl er 1000 servers zijn geeft al een problem lijkt me)
Ik heb mijn kleine serverpack gewoon conventioneel genaamd
FM-RSD-xxx-BM voor de fileservers
ML-RSD-001-V ( er is maar één (virtuele mailserver ;) )
WB-RSD-0xx-D voor de webserver

kenmerk-plaats-nummer-tag
Zo kan ik uitbreiden, Baremetel, Virtual of Docker
En je hebt nooit last van versprekingen, verkeerd verstaan of gelezen. Ik ben echt heel erg groot voorstander van gewone namen, duidelijk makkelijk te onthouden en in het alledaagse gesprek weinig kans op misverstanden. En voor functionaliteit gebruik je gewoon bepaalde series namen.
Met de juiste documentatie valt dat wel mee.
Overal kunnen fouten gemaakt worden natuurlijk, ik zal zeker niet uitsluiten dat hier iets kan misgaan, alleen is een 'park' hier een persoonlijke kast, ipv 100'en machines :+

Maar de bedrijven waar ik gewerkt heb / rondgelopen gebruiken allemaal zo'n setup, dus er zal ergens iets goed gaan
Dat bedoel ik dus, maar gemakkelijk is het niet. En ik weet dat het in veel bedrijven zo gebeurt maar creatief en gemakkelijk of duidelijk is het niet. En als je kijkt in het een standaard namen boek heb je keuze genoeg en kan je er ook nog logica in zetten.
Wat is er dan niet logisch aan mijn benamingen ?
eerste 2 leters - type
dan de 3 letters zoals NS en KPN ze gebruiken voor locaties, en nummering + soort install
Totdat je gaat verhuizen en er dan achter komt dat je niet alle servers een andere naam wilt geven.
Zo blijf je in een cirkeltje wandelen, want als Game stopt, komt er een nieuwe serie ( verhuizing )
Blijft het probleem aanwezig.
Zelf voorstander van de elementen voor scheiding op basis van verschillende klassen namen;

Webservers > Griekse goden
Database servers > Elementen uit het periodiek systeem (hierachie master/slave per groep naar beneden)
Fileservers > planeten uit het zonnestelsel

zo kun je geen verwarring krijgen, stukje documentatie, en met name bij de DB's is het erg handig dat je een mooi geprint overzicht hebt wat zo als "geek" poster aan de muur kan
Fileservers > planeten uit het zonnestelsel
Ik zie je al bij je baas staan om uit te leggen waarom alle fileservers een upgrade moeten krijgen: "nou ja, op zich werkt de huidige configuratie prima, maar dan hebben we wel negen machines nodig en ik hoor net van de IAU dat we het voortaan met acht machines moeten doen". :+
Totdat je een duizendtal databases hebt...
Altijd rekening houden met extreme groei, neem ipv4 of de epochtime. Nee, schaalbaarheid gaat voor nerdiness
ik denk dat ik in mijn privé situatie geen "duizenden" database servers zal halen, tegen die tijd zal ik de expertise wel extern inschakelen, ben als chemicus opgeleid, niet als ITér :+
Ik hoop niet dat die servers dan het zelfde lot ondergaan als de karakters uit de serie, want ook dan zal de main-server er gewoon kunnen uitklappen.

Oh, en ook niet Eddard Stark noemen, want dan weet je zeker dat je aan de beurt bent :+
Eddard wordt het front/head-end
Cercei als firewall (iedereen gaat er overheen)
Jaime gaat in de DMZ met een pootje
Varys als mailserver
Ach, zo kun je nog wel even doorgaan met wat flauwe en melige benamingen.
Ik kan het me net heel goed voorstellen. Custom made tooling met relatief weinig checks onder het motto van: niemand maakt die fout ooit. Totdat de fout eens gemaakt wordt en je heel je infrastructuur in de soep doet draaien.
Inderdaad, ik zou het gezicht van die medewerker willen zien nadat hij er achter kwam dat er iets niet helemaal goed gegaan was.

Wel een goed plan vans Amazon om te kijken of ze de opstarttijd van dat indexcluster kunnen verbeteren.
Mwah, het kan zo simpel zijn als het vergeten van het gebruik van quotes, of een spatie te veel in een script.

"reboot klant-xyz- *" in plaats van "reboot klant-xyz-*" (bij wijze van spreken) en je hebt meteen downtime op onverwachte machines.
Daarom had ik op servers zoals dns/dhcp altijd duidelijke benamingen die tegen de gestelde conventie in gingen.

Srvabc1 = dns -> srvabc1-dns
Srvabc2 = dhcp -> srvabc2-dhcp

Iets meer tikwerk maar wel duidelijk met welke server en service je bezig bent.
Ik kan me niet voorstellen dat dit een typefout is geweest.
Ja, wat is een typefout? Als ik "formqt" ipv "format" intyp, dan noem ik dat een typefout. Het voordeel daarvan is dat het commando niet herkent wordt, waardoor er niets gebeurt. Als ik "format c:\" ipv "format d:\" intyp, dan geef ik gewoon een fout commando.
op windows is dat een typefoutje die verder weinig invloed heeft,

op linux kan een spatie op de verkeerde plek je complete systeem verneuken ;)
" Are you sure, <Y/N>"
" Y"
" Shutting down xyz system"
" Oke"
" Huh wait what! No! Abort! Abort!"

Het kan de beste overkomen en ze hebben de management tool al aangepast dat het niet in 1 keer alles kan uitschakelen.
Precies dat dus. En dan kan je zeggen vraag twee kom om bevestiging. Maarja uit eindelijkt komt routine om de hoek kijken en weetje dat je twee keer enter moet gebruiken ipv 1 keer, en gaat het alsnog fout
Een timer van 10 seconden inbouwen na de vraag Y/N zodat je gedwongen wordt even 10 seconden na te denken alvorens te kiezen.

Maar ja, dan ga je in die 10 seconden natuurlijk nog ff snel iets anders doen op een ander scherm :)
In een onderzoek wat ik ooit gelezen heb, kan even geen link achterhalen, was het percentage door mensen veroorzaakte downtime iets van boven de 80%, daarna pas software en hardware.
Dat geloof ik best hard en software kun je redundant draaien, als er dan een failure is betekend dat geen downtime. Zet iemand een cluster perogelijk uit, dan heb je een probleem :+
Wel, de drama heeft positieve en negatieve kanten.
Negatief is natuurlijk typo dat teveel servers uitzet als gevolg van kleine kettingreactie.
Ook geen goed tijdstip, het is overdag in Amerika.

Positief is dat het ook zwakte systeem blootmaakt. Dus voor de volgende keer weten ze ook meer wat er moet veranderen om herhaling te voorkomen.
Zoiets kan alleen als er fout ontstaat, anders komt men bijna niet achter.

Volgende keer dus beter. :)
Zeker, neem maar van mij aan dat er een uitgebeide RCA (Root Cause Analysis) wordt gedaan en vervolgens een 'lessons learned' document wordt opgeleverd om herhaling in de toekomst te voorkomen.
Wellicht bij hele belangrijke acties iemand mee laten kijken, netzo als een co-piloot.
Goed om te zien dat zulke dingen ook bij bedrijven als Amazon kunnen gebeuren.
Hopelijk dat ze niet een volgende keer alle schijven formatteren :)
Ik heb plaatsvervangend medelijden met de medewerker in kwestie. Not his finest hour.

Ik kan me uit mijn eigen 'professioneel' verleden nog goed de dag herinneren dat ik bij een klant per abuis een script uitvoerde waarmee de productiedatabase gedropt werd en een kopie van de replicatie database werd teruggezet. Dat script dat bedoeld was voor het herstel van calamiteit situaties stelde verder ook geen vragen...

Pak 'm beet vijf seconden nadat ik dat script per ongeluk afvuurde begonnen om mij heen alle telefoons te rinkelen. Auw, dat werd een hele lange dag...

Uiteindelijk heeft e.e.a. zowel mij, als de klant en de fabrikant een aantal wijze lessen geleerd. Pijnlijke, maar wijze lessen.
En wederom zijn het mensen die de fout maken... logisch: want waar gehakt wordt vallen spaanders...

Zijn er geen standaarden voor zulke procedures? Moet zoiets niet automatisch gaan voor het verminderen van risico's?
Vanaf nu wel denk ik zo :D
Hahaha dat mag je hopen ;) maar de reden waarom ik het me afvraag is dat aws altijd ermee coketteert dat ze zo compliant zijn enzo :) maar dan kan dit toch eigenlijk niet meer gebeuren?
Zo is dat en meestal in de haast even snel regelen en dan gaat het wel eens mis :) alles waar mensen aan werken worden fouten gemaakt, ik heb zelf ook wel eens wat fout gedaan hoor, bijvoorbeeld een delete from en dan een stukje in de where clause vergeten. Het was geen database met ondersteuning voor transacties dus alles was weg :) gelukkig hadden we een backup lol
Die heb ik ook maar soms moet je ook iets updaten of wijzigen in een productie database.
dan is het een kwestie van de query op je dev maken, en daarna pas live gebruiken :) ik zou nooit van me leven op een productie database een query gaan zitten typen.

Dat ligt dan misschien ook aan de grootte van de site en de impact bij downtime, een blog is een ander verhaal dan een grote webshop bijvoorbeeld.
Script maken en testen in dev/acceptatie omgeving...

Script uitvoeren in productie...
Mooi verhaal in de praktijk gaat het soms anders. Maar waarschijnlijk ben je superieur en maak jij nooit fouten in tegenstelling tot andere.

[Reactie gewijzigd door 291692 op 3 maart 2017 12:05]

Zeg ik niet, maar jij neemt hier wel mooi even de moral high ground met bad practices. En dan haal je nog de popular karma vote ook.


Prachtwereld.

Op dit item kan niet meer gereageerd worden.


Apple iPhone X Google Pixel 2 XL LG W7 Samsung Galaxy S8 Google Pixel 2 Sony Bravia A1 OLED Microsoft Xbox One X Apple iPhone 8

© 1998 - 2017 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Hardware.Info de Persgroep Online Services B.V. Hosting door True

*