¿Qué comandos utilizaron los técnicos que accidentalmente fallaron en AWS S3 en la región del norte de Virginia?

Los servicios críticos de Amazon Cloud cayeron a principios de esta semana, causando interrupciones en los servicios de varios sitios web, incluidos Quora, Spotify, Netflix, Slack, Pinterest, Buzzfeed, Trello e IFTTT. El sitio web para verificar si otros sitios web están caídos, ahora está abajo También cayó debido a la interrupción en los servicios en la nube de Amazon. El sitio de comercio electrónico de Amazon no se vio afectado por la interrupción.

Una autopsia realizada por Amazon reveló la causa raíz del problema. Un solo comando incorrecto ejecutado por un empleado causó un efecto en cascada que eliminó una serie de otros servicios. Un empleado del equipo de Amazon Simple Storage Service (S3) estaba llevando a cabo una operación de depuración de rutina, investigando un problema en el que los servicios de facturación de S3 progresaban a paso de tortuga. El empleado tenía la intención de ejecutar un comando que eliminaría una pequeña cantidad de servidores que manejaban el proceso de facturación S3.

Una de las entradas en el comando tenía un error tipográfico, como resultado se eliminó un mayor número de servidores. Un subsistema de índice que contenía los metadatos y rastreaba todos los objetos en el S3 se cayó. El subsistema de ubicación que dependía del subsistema de índice para funcionar correctamente también se cayó. En conjunto, las interrupciones significaron que Amazon ya no podía atender solicitudes API de clientes en la región del norte de Virginia, designado como US-EAST-1.

Después de la interrupción inicial, Amazon tardó cuatro horas en volver a poner en funcionamiento todos los sistemas. Los subsistemas E3 no se habían reiniciado en años y se habían expandido considerablemente desde la última vez que se reiniciaron. Las comprobaciones para asegurarse de que todo funcionaba correctamente, así como para ponerse al día con la acumulación de solicitudes recibidas durante el corte significaron que los sistemas tardaron más en recuperarse de lo previsto. Amazon ha anunciado que está tomando medidas para asegurarse de que tal interrupción no vuelva a ocurrir.

Ahora hay controles automáticos en el lugar, donde la capacidad se elimina lentamente y no se puede eliminar por debajo de un umbral mínimo. Un comando incorrecto ingresado en el futuro no podrá interrumpir los servicios de Amazon de la misma manera. Amazon está realizando una auditoría de un sistema para garantizar que se realicen verificaciones similares para todos los servicios. Amazon tiene en cuenta los servicios en pequeñas células para disminuir la cantidad de impacto que pueden tener los eventos disruptivos. Amazon tiene la intención de descomponer estas células en piezas más pequeñas a finales de este año.

Después de explicar el evento, Amazon ha publicado: “Finalmente, queremos disculparnos por el impacto que este evento causó a nuestros clientes. Si bien estamos orgullosos de nuestro largo historial de disponibilidad con Amazon S3, sabemos cuán crítico es este servicio para nuestros clientes, sus aplicaciones y usuarios finales, y sus negocios. Haremos todo lo posible para aprender de este evento y utilizarlo para mejorar aún más nuestra disponibilidad “.

AWS no reveló el comando exacto, pero estaban tratando de resolver un problema de s3 más lento y las combinaciones de teclas eliminaron casi todos los servicios. Otras partes de AWS comenzaron a fallar, incluida la consola Amazon S3, Elastic Compute Cloud (EC2), No se pudo acceder a Elastic Block Stores (EBS), AWS Lambda y las API S3. Básicamente, un colapso completo del sistema tarda varias horas en solucionar todo debido a un comando mal escrito.

Entonces, la conclusión es que no importa cuán grande y robusto se vuelva un servicio, solo se necesita un humano con privilegios de administrador para que todo se bloquee \ U0001f60f

Salud,

Kapil