Een update die de prestaties van verschillende diensten op het Microsoft Azure-platform moest verbeteren, heeft er juist voor gezorgd dat de diensten uitvielen of trager werden. Dat concludeert Microsoft nadat het woensdag elf uur lang kampte met storingen op het Azure-platform.
Gebruikers klaagden over vertraging in de dienstverlening voor storage, virtuele machines, Visual Studio Online, websites, zoekmachines en andere diensten van de softwaregigant.
Microsoft benadrukt dat bij eerdere tests van de updates onder kleine gebruikersgroepen zich geen incidenten voordeden. ‘Bij het beschikbaar stellen van de update voor een grote groep gebruikers ontstonden problemen met de koppelingen in de front-end’, schrijft Jason Zander, hoofd van het Microsoft Azure-team in een blog over de storingen.
De storingen troffen klanten in Europa, de Verenigde Staten en een deel van Azië. Microsoft laat weten dat het updates voor Azure voortaan in kleinere stappen gaat uitvoeren. De leverancier belooft recovery-procedures te verbeteren om de duur van onverhoopte storingen te verkorten.
Zonder me een expliciet standpunt aan te willen matigen vraag ik me af of er hier niet sprake is van een klassiek fout. Namelijk het testen en piloten op clean builds/omgevingen waardoor er geen represnetatief pilot werd gedraaid om goed te kunnen testen op een ‘gemiddelde’ operationele omgeving.
Ik vraag me dit af omdat het probleem vrij synoniem is aan hetgeen hier beschreven. Ik kom in de praktijk steeds vaker van dit soort dingen tegen namelijk.
@Numo,
je hebt een punt ….
Nou vindt ik Microsoft Azure toch een geweldig platform hoor, maar heeft het weer aan de manier van omgaan met de klant gelegen!
Getuige de uitlatingen van enkele Azure klanten die behoorlijke “pittige” uitingen doen op bovengenoemde update.
Wat me opvalt is dat , en nu moet ik misschien een eerder gestelde aanname van mijzelf terugnemen, is er géén gebruik gemaakt van zogenaamde “spin doctors” oftewel “goedweer mensjes” bij Microsoft Azure Services die de klant adequaat op de hoogte brachten!
De (ver)storingen werden natuurlijk opgemerkt door klanten , waaronder zelfs enkele die “oost en west” [lees kostbaar] datacenter connecties draaien ivm mission critical data!
Let wel , waar men over valt is dat er niet adequaat en op de juiste toon met de klant werd gecommuniceerd, en het “Azure service dashboard” stond op groen notabene, hè waar hebben we dat eerder gezien!
“Incident Start Date and Time 11/19/2014 00:51:00 AM (UTC)”
“Date and Time Service was Restored 11/19/2014 11:45:00 AM (UTC)”
En er werd niet adequaat gecommuniceerd met de klant, met andere woorden als jouw klant veel betaald voor jouw dienst, behandel hem/haar dan ook zo wanneer jouw dienst niet naar behoren presteert.
OVERIGENS, andere dienstverleners doen dat geen haar beter, hoor….!!!
Het verdiend zeker geen schoonheidsprijs en bepaalde tegenstanders zullen weer vooraan staan om te zeggen hoe onbetrouwbaar de “cloud” is.
Het goede nieuws is dat dit soort ernstige incidenten leermomenten zijn waardoor het uiteindelijk allemaal beter wordt.
Dat het service dashboard “groen” was is ook niet goed te praten, maar ondanks dat ik ook hinder ondervonden heb was het vooral traag en was de dienst dus wel bereikbaar, maar dan nog zou het in ieder geval oranje moeten kleuren met een melding “some customers…”
@Henri
Als je al begint met het wegzetten van reacties die terecht opmerken dat het niet allemaal perfect is dan zegt dat wat over je objectiviteit, zeker als ik overweeg dat je erna komt met de melding dat het service dashboard even betrouwbaar is als rijks ICT-dashboard. En stellen dat de dienst wel bereikbaar was maar alleen ontzettend traag is trouwens evengoed bagatalliseren. Mooie – maar niet limitatieve – definitie van betrouwbaarheid is het voldoen aan vastgestelde prestatie-eisen onder afgesproken condities gedurende een bepaalde tijdsduur.
Vul zelf maar in hoe betrouwbaar de cloud is als je als klant weinig invloed hebt op de veranderingen die leverancier aanbrengt, de gegeven definitie gaat verder dan beschikbaarheid als ik kijk naar de oorzaak van verstoring. Probleem lijkt me meer te zitten in ketenafhankelijkheden waarover ik in 2012 al eens wat schreef in opinie: ‘De cloud beheersbaar maar niet beheerbaar’ waarin ik inging op het verschil in definities.
Zo betekent beheerbaarheid volgens het computerwoordenboek de mate van een systeem om deze in operationele staat te brengen en te houden. Beheersbaarheid betekent daarentegen het in toom houden van een systeem, de mogelijkheid om het geheel te kunnen overzien. Laten we het erop houden dat de cloud nog verre van volwassen is als we nog moeten leren van fouten uit het verleden door de koppelvlakken te vergeten.