Falla mayor en Amazon Web Service
En la tarde del día 28 de febrero de 2017 nuestros sistemas comenzaron a comportarse de forma no habitual. Para nuestra sorpresa, al revisar, descubrimos que la causa de todo venía desde uno de los servicios más estables dentro del Cloud de Amazon.
Amazon Simple Storage Service o Amazon S3.
Amazon Simple Storage Service (Amazon S3) es un almacenamiento de objetos con una sencilla interfaz de servicios web para almacenar y recuperar la cantidad de datos que desee desde cualquier ubicación de la web. Se ha diseñado para ofrecer una durabilidad de 99,999999999% y escalar más allá de billones de objetos en todo el mundo. https://aws.amazon.com/es/s3/
Lo impensable pasó y vivimos durante unas hora ese 0,000000001% de probabilidades de falla. Durante ese tiempo fue imposible obtener, crear o modificar los objetos que usamos en las operaciones habituales de Autofact.
Plan de contingencia
Siempre hemos operado sabiendo que la infraestructura de Amazon puede fallar, a pesar de que tienen los mejores estándares de calidad.
Estábamos preparados para que fallaran los servidores, las bases de datos o se cortara la comunicación de red. Irónicamente nuestra web de respaldo para el peor de los casos (quedar totalmente fuera de línea) se basa en un site estático en S3. Evidentemente nos quedamos sin ese backup ayer.
Necesitábamos sacar nuestros sistemas de línea y mostrar información del problema a los usuarios para evitar que siguieran entrando solicitudes y quedaran corruptas o incompletas.
Pánico total
Cuando intentamos levantar la web de emergencias en una nueva instancia descubrimos la alta dependencia que tienen el resto de los servicios de Amazon con S3. Era imposible levantar instancias nuevas y crear balanceadores de carga. DynamoDB y Lambda también quedaron fuera del juego. La página de status de Amazon no reportaba problemas porque ellos mismos no podían modificarla.
Tuvimos que trabajar con lo poco que seguía en pie y logramos sacar los sistemas hasta que se resolvió todo.
Consecuencias
Estuvimos sin operar de cara a los clientes durante varias horas. No fuimos los únicos:
The issues appear to be affecting Adobe’s services, Amazon’s Twitch, Atlassian’s Bitbucket and HipChat, Autodesk Live and Cloud Rendering, Buffer, Business Insider, Carto, Chef, Citrix, Clarifai, Codecademy, Coindesk, Convo, Coursera, Cracked, Docker, Elastic, Expedia, Expensify, FanDuel, FiftyThree, Flipboard, Flippa, Giphy, GitHub, GitLab, Google-owned Fabric, Greenhouse, Heroku, Home Chef, iFixit, IFTTT, Imgur, Ionic, isitdownrightnow.com, Jamf, JSTOR, Kickstarter, Lonely Planet, Mailchimp, Mapbox, Medium, Microsoft’s HockeyApp, the MIT Technology Review, MuckRock, New Relic, News Corp, OrderAhead, PagerDuty, Pantheon, Quora, Razer, Signal, Slack, Sprout Social, StatusPage (which Atlassian recently acquired), Travis CI, Trello, Twilio, Unbounce, the U.S. Securities and Exchange Commission (SEC), The Verge, Vermont Public Radio, VSCO, Wix, Xero, and Zendesk, among other things. Airbnb, Down Detector, Freshdesk, Pinterest, SendGrid, Snapchat’s Bitmoji, and Time Inc. are currently working slowly. -Fuente
No hubo ninguna pérdida de información, y pudimos recuperar las solicitudes que quedaron a medias durante el evento fatal y, aunque un poco demorados, todos los clientes recibieron sus informes.
Estuvimos pendientes todo el tiempo de la evolución del problema y nuestros servicios volvieron a la vida en cuanto Amazon se declaró en funcionamiento correcto nuevamente.
¿Y en el futuro?
Realmente no hay mucho que podamos hacer. Podemos tomar todas las medidas posibles para casi todos los escenarios pero siempre tendremos que vivir con un margen de riesgo, por pequeño e improbale que este sea. En estos casos no queda más que estar atentos, mantener a los clientes informados, minimizar el impacto y recuperarse tan pronto como sea posible sin importar la hora o el día de la semana.
Es la dosis de adrenalina que implica un trabajo como el nuestro.
