Interrupción del servicio Amazon S3

LEÉ ESTO PRIMERO:

Necesitamos divulgar que este EJEMPLO de ACR se basa en información disponible públicamente publicada en un único informe de Amazon y no en una investigación independiente realizada por Sologic. Sologic no ha investigado este incidente en ninguna capacidad oficial, y no queremos dar a entender que estuviéramos asociados de algún modo con este evento. El único propósito de este informe de análisis de causa raíz es que se use como ejemplo para nuestros estudiantes y otras partes interesadas.

Un análisis de causa raíz tiene dos objetivos principales: 1) Organizar una amplia gama de información de fuentes dispares de manera que sea más fácil de entender, y 2) Identificar un conjunto de soluciones basadas en evidencia para presentarlas a los responsables de la toma de decisiones. Los informes de interrupción de TI a menudo son imprecisos y están salpicados de términos técnicos intensos. Este estilo los hace un poco opacos para quienes están fuera de la industria. Pero no tiene por qué ser así: un gráfico de causa y efecto proporciona una buena referencia visual para acompañar el informe. El gráfico pone las interacciones causales en contexto con respecto al tiempo, lo que permite al lector ver cómo se desarrolló el evento.

Algunas reflexiones sobre TI y análisis de causa raíz en general, no necesariamente asociadas a este evento en particular. Según nuestra experiencia, los profesionales de TI a menudo son extremadamente inteligentes. Pero a nivel macro, las TI son relativamente nuevas en el mundo de la solución de problemas estandarizada. Muchos esfuerzos de ITSM se centran primero en la gestión de incidentes, con la intención de mejorar la gestión de problemas en algún momento posterior. Cuando se produce un gran problema como el detallado en este ejemplo, los profesionales de TI se encuentran bajo una presión extrema para completar la investigación lo más rápido posible. A menudo, han surgido nuevos problemas que requieren su atención. Y sus clientes están exigiendo respuestas. Combine este entorno con el hecho de que estos sistemas son complejos y el equipo de investigación a menudo no tiene experiencia con el análisis de causa raíz y usted obtiene las condiciones adecuadas para una investigación subóptima. Este no es siempre el caso, solo una observación basada en nuestra experiencia.

El problema con esto es la continua exposición al riesgo, incluso cuando se toman medidas para resolver formalmente el problema. Se supone que una inversión en una investigación formal de causa raíz financiará una reducción en el riesgo. El riesgo de recurrencia del problema está directamente relacionado con la calidad de las soluciones implementadas por el equipo, y la calidad de la solución depende de un análisis de causa raíz lógico, exhaustivo y basado en la evidencia. Cuando las consecuencias de la falla son altas, una inversión en la capacidad ACR vale la pena en gran medida. Esta inversión incluye capacitación, software y consultoría (todo lo que Sologic brinda). Pero igualmente importante es la inversión que hace el liderazgo en la gestión del cambio. La capacidad de construcción requiere la estructura de un Programa de ACR y esto requiere el reconocimiento por parte del liderazgo de que su éxito incumbe a la capacidad colectiva de resolución de problemas de la organización. Esto es particularmente cierto en TI.

De ser posible, considere imprimir el siguiente informe de resumen y siga junto con el gráfico de causa y efecto al leer el informe. Observe las soluciones que Amazon ha implementado, junto con las causas que controlan. ¿Qué piensas?
 

Enlace a: Informe Orignal de Amazon

El 28 de febrero de 2017, Amazon Web Services (AWS) experimentó una interrupción en el servicio que afectó a la región EAST-1 de EE. UU. La interrupción comenzó a las 9:37 AM y duró hasta que se restauró el servicio a la 1:54 PM. El principal sistema afectado fue el Amazon Simple Storage Service (S3). Otros servicios, como Amazon Elastic Compute Cloud (EC2), Amazon Elastic Block Store (EBS) y AWS Lambda, todos los cuales dependen de S3, se vieron afectados durante varias horas más.

Tenga en cuenta que bien pudo haber habido impactos adicionales, pero no se informaron públicamente. A los fines de un ejemplo, está bien. En un ACR real, nos gustaría documentar los impactos a fondo.

Servicio S3 no disponible:

El servicio S3 se apagó cuando un técnico solucionó un problema con el sistema de facturación S3. El técnico intentaba eliminar una pequeña cantidad de servidores, lo que no habría afectado la disponibilidad del servicio. Pero, en cambio, eliminó un conjunto de servidores mucho más grande. Esto desestabilizó el servicio S3, derribando el sistema. El técnico estaba siguiendo un conjunto aprobado de procedimientos (lo que el informe de Amazon llama "libro de estrategias establecido"), sin embargo, el técnico ingresó un comando incorrectamente. No está claro si esto fue simplemente un error por parte del técnico o si hubo un problema con el libro de procedimientos. El sistema aparentemente no tiene protecciones secundarias para evitar que se ejecute dicho comando, sin embargo, no se informaron los parámetros específicos de diseño del sistema. Un ACR real viajaría más adelante en esta vía para identificar cómo se diseñan los sistemas, se identifican los riesgos y se implementan acciones preventivas.

4:17 Requerido para que S3 se recupere:

Se necesitó un reinicio completo del subsistema Index para volver a conectar el S3 (tiempo requerido = 3:41). Luego, el subsistema de colocación requirió tiempo para recuperarse (tiempo requerido = 0:36). El sistema S3 ha experimentado un crecimiento masivo en los últimos años, lo que ha aumentado su complejidad. Hay un historial de recuperación limitado para este sistema. Eso es porque este sistema generalmente es confiable y, por lo tanto, no ha experimentado un reinicio total en muchos años.
 

Conozca más sobre Sologic ACR