Resistencia gracias al diseño para servicios de nube · 2017-01-30 · Informática de confianza |...

Resistencia gracias al diseño para servicios de nube Una metodología estructurada para priorizar las inversiones de ingenieríaMayo de 2013

Índice Descripción 2

Antecedentes 2

Beneficios 4

Maneras en que funciona el análisis y modelado de

resistencia 5

Consideraciones de implementación 17

Llamado a la acción 19

Conclusión 19

Recursos adicionales 21

Autores y colaboradores 21

Informática de confianza | Resistencia gracias al diseño para servicios de nube 2

Descripción Microsoft Trustworthy Computing (TwC) ha colaborado con diversos equipos de servicios de nube en todo Microsoft para desarrollar un enfoque cuyo fin es aumentar la resistencia de los servicios de nube al identificar y analizar las fallas potenciales. Este documento describe brevemente la motivación y los beneficios de incorporar un diseño sólido y resistente al ciclo de desarrollo. Además, describe el Análisis y el modelado de resistencia (RMA), una metodología para mejorar la resistencia adaptada a partir de la técnica estándar de la industria conocida como Modo de fallo y análisis de efectos (FMEA)1 y ofrece una guía para la implementación. El principal objetivo de este documento es permitir a los ingenieros de servicios de nube comprender en forma detallada el RMA, incluidos los pasos y las plantillas utilizados para realizar el proceso, a fin de facilitar una adopción sencilla y consistente.

Antecedentes Tradicionalmente, el desarrollo de software ha puesto énfasis en la prevención de fallas y, dado que los clientes operaban el software, cualquier falla se aislaba en las implementaciones in situ de los clientes. En la actualidad, los servicios de nube generalmente ejecutan sistemas altamente complejos, distribuidos y “siempre disponibles” que prestan servicio a numerosos clientes. Los sistemas de nube están distribuidos globalmente, a menudo se construyen utilizando hardware genérico y tienen dependencias inherentes de servicios de terceros y asociados. La naturaleza de la Internet y las redes globales permite que fallas transitorias, e incluso prolongadas, sean bastante comunes. Por ello, los ingenieros deben cambiar su manera de pensar a fin de adoptar prácticas de Informática orientada a la recuperación (ROC),2 asimilar totalmente la idea de que las fallas se producirán y, por consiguiente, incorporar estrategias de copiado en su diseño de servicios y software a fin de reducir al mínimo los efectos perjudiciales de dichas fallas. La ilustración siguiente muestra un espectro de fallas, que van desde fallas poco frecuentes (desastres naturales ambientales o desastres ocasionados por el hombre) a fallas comunes (imperfecciones del software, fallas de hardware o errores humanos). Debido a que las fallas comunes son inevitables, su incidencia y efecto deben considerarse en el servicio durante la fase de diseño, de manera que el software se pueda diseñar y crear de manera más resistente y así minimizar el impacto para los usuarios. 1 El Modo de fallo y análisis de efectos también se conoce como Modo de fallo y análisis de efectos y gravedad (FMECA). 2 “Recovery Oriented Computing (ROC): Motivation, Definition, Techniques, and Case Studies” (Informática orientada a la

recuperación (ROC): motivación, definición, técnicas y casos prácticos) http://roc.cs.berkeley.edu/papers/ROC_TR02-1175.pdf


Ilustración 1. El espectro de fallas contempla fallas comunes y fallas poco frecuentes. Una falla es inevitable, de manera que se deben incorporar técnicas de tolerancia a fallas en el diseño de servicios para reducir el impacto cuando estas se producen.

Si asimilamos la idea de que las fallas son esperables en el mundo de los servicios de nube, los ingenieros deben modificar su enfoque en el diseño para prolongar el tiempo entre fallas (TBF) y concentrarse en el diseño para reducir el tiempo de recuperación (TTR) de fallas. Si la fallas son comunes, el objetivo más importante es detectarlas con rapidez y desarrollar estrategias de copiado que minimicen sus efectos en los clientes. Adaptamos los conceptos del proceso estándar de la industria conocido como FMEA a fin de crear una metodología de Análisis y modelado de resistencia (RMA) para los equipos de servicios de nube en Microsoft. El propósito de esta metodología es priorizar en forma más eficaz el trabajo en las áreas de detección, mitigación y recuperación de fallas, los cuales son factores muy importantes para la reducción del TTR. Al realizar el RMA, un equipo de ingeniería podrá comprender en detalle muchos de los problemas de confiabilidad y estar mejor capacitado para garantizar que, cuando se produzcan fallas, se minimicen los impactos en los clientes. El FMEA es un marco flexible que permite efectuar un análisis cualitativo de fallas en sistemas industriales e informáticos. Las posibles fallas se identifican y sus consecuencias se analizan a fin de evaluar el riesgo.

Software Hardware Error humano

Desastre natural Actividad criminal

Técnicas de tolerancia a fallas

Técnicas de recuperación ante

desastres

Interrupción de los datos


Beneficios El beneficio de la adopción del RMA para los equipos de ingeniería de servicios de nube es que los insta a utilizar mejores prácticas que, en conjunto, pueden mejorar la confiabilidad de los servicios.

Solución de problemas de confiabilidad en las primeras etapas de diseño

La meta y el beneficio principales del RMA es descubrir las brechas de resistencia y diseñar de manera explícita para su detección y mitigación antes de que el código se ponga en producción (donde resulta más costoso modificarlo y actualizarlo). El RMA se puede codificar en el ciclo de vida de desarrollo y ser utilizado por las organizaciones de ingeniería de servicios de nube para que se convierta en una competencia principal importante que infundirá los principios de la ROC en los equipos de ingeniería a fin de que ellos se concentren de manera continua en reducir el tiempo para detectar, mitigar y recuperarse de fallas. Después de poner el servicio en producción, se puede seguir aplicando la metodología de RMA para permitir que la organización de ingeniería utilice todos los conocimientos obtenidos en el ciclo de ingeniería siguiente.

Priorización de las iniciativas de trabajo relacionadas con la confiabilidad

El objetivo clave del RMA es identificar y generar una lista (por prioridad) de fallas de confiabilidad comunes pertinentes para un servicio específico. Los participantes logran comprender que la recuperación de fallas se debe enfatizar por sobre la prevención de las mismas. A menudo, los servicios de nube complejos se someten a un sinnúmero de condiciones de falla y, generalmente, resulta difícil para los equipos saber dónde focalizar sus esfuerzos para reducir el impacto de dichas fallas. Este planteamiento es especialmente complicado para equipos cuyos servicios consumen componentes o servicios de diversos propietarios o proveedores de servicios titulares o de terceros. El RMA ayuda a definir las prioridades y tomar decisiones de inversión informadas en las áreas de detección, mitigación y recuperación.

Proporcione resultados tangibles para otras iniciativas de confiabilidad

El proceso de RMA genera resultados tangibles que se pueden aprovechar en otras iniciativas de confiabilidad. Los equipos de asociados, operaciones de servicio y personal de soporte pueden comprender mejor cómo el software de producción se pone en funcionamiento al aprovechar el diagrama de interacción de componentes (CID), creado durante la fase inicial del proceso de RMA. Este permite un giro distinto del de los diagramas de diseño o arquitectura estándar, que a menudo se encuentran en especificaciones de desarrollo tradicionales.


Las lista de fallas por prioridad se asigna en forma concreta a elementos de trabajo y errores de código. Además, constituye un recurso excelente para que la organización de prueba pueda desarrollar casos de prueba. Estas asignaciones ofrecen información de los lugares en el sistema donde las prácticas de inserción3 de errores se pueden aplicar mejor para validar la eficacia de las mitigaciones de fallas.

Maneras en que funciona el análisis y modelado de resistencia El proceso de análisis y el modelado de resistencia (RMA) se ejecuta en cuatro fases, que se muestran y describen en la ilustración siguiente y en los puntos de viñeta:

Ilustración 2. Fases del proceso de RMA

• Trabajo previo. Crea un diagrama para capturar los recursos, dependencias e interacciones entre componentes.

• Descubrimiento. Identifica las fallas y las brechas de resistencia. • Clasificación. Realiza un análisis de los impactos. • Actuación. Genera elementos de trabajo para mejorar la resistencia.

Trabajo previo

Durante esta fase del análisis, se realizan dos tareas. La primera tarea es crear un diagrama de interacción de componentes (CID); la segunda tarea es transferir todas las interacciones desde el diagrama a la plantilla del libro de RMA. El objetivo principal de esta fase es capturar todos los recursos y las interacciones entre ellos. Estas interacciones se utilizarán para focalizar la enumeración de fallas en la fase de Descubrimiento. Se deben realizar las dos tareas de esta fase antes de proseguir a la fase de Descubrimiento.

3 El ejemplo canónico de pruebas de inserción de errores es la herramienta de resistencia Netflix, conocida como Chaos Monkey.

Clasificación

Actuación

Descubrimiento Trabajo previo


Tarea1:CrearelCID

Esto es de importancia fundamental para que el proceso de RMA permita generar un diagrama integral de alta calidad en esta tarea. Si faltan recursos o interacciones en el diagrama, es posible que no se identifiquen fallas y el valor del ejercicio se vea mermado. Los desarrolladores de los recursos de componentes modelados en el diagrama son los miembros principales del personal que se necesitan para esta tarea. Es posible que los ingenieros cuestionen el nivel de detalle necesario para el diagrama, pero no existe una regla tajante al respecto. La respuesta dependerá de si el equipo desea que el ejercicio contemple una situación de extremo a extremo, límites acotados a los servicios de nube o componentes.4 Sin embargo, se aplica una cierta guía general: • No incluya el hardware físico. Por lo general, los servicios de nube constan de roles de

servidor, de los cuales normalmente existen múltiples instancias. En la mayoría de los casos, no resulta productivo ilustrar componentes del servidor, como discos, tarjetas de red, procesadores, etc. Si bien se producen fallas con estos componentes, tanto el impacto como la frecuencia de las mismas se comprenden bien. Si una falla de este tipo afecta la capacidad de funcionamiento de un recurso, los efectos se observarán en la interacción del llamante de este recurso en la forma de un error o la ausencia de respuesta. De manera similar, los componentes de red, como enrutadores, conmutadores y equilibradores de carga son todos fuentes de falla, pero no es necesario que se ilustren en el diagrama. Puede encontrar más detalles en el texto siguiente sobre cómo capturar la información relevante de la falla para estos tipos de dispositivos y componentes.

• La enumeración de los casos es importante. El número de unidades funcionales es de extrema importancia para el modelado de confiabilidad. La redundancia es una de las principales técnicas de resistencia que se aplica a todas las capas de un servicio de nube. El número de regiones geográficas donde existe su servicio, el número de centros de datos dentro de una región y el número de roles e instancias del servidor son atributos importantes que debe capturar. Esta información se usa para determinar la probabilidad de que la falla en una interacción específica afecte a los clientes.

4 Consulte la subsección “Enfoque” más adelante en este documento para obtener más información sobre el alcance del ejercicio.


• Incluya todas las dependencias. Los servicios de nube tienen numerosas dependencias, desde la resolución de nombre hasta la autenticación, el procesamiento de datos y el almacenamiento. Con frecuencia, estos servicios son proporcionados por sistemas que no son de propiedad del equipo de servicios de nube, pero son fundamentales para el funcionamiento correcto del servicio. En el diagrama, es necesario representar cada uno de estos sistemas de dependencia, junto con las interacciones correspondientes entre ellos y sus componentes de servicio de nube ilustrados con claridad. Sin embargo, la composición de los sistemas de dependencia puede quedar oculta al dibujarlos en el diagrama como una sola forma fuera del centro de datos (si el servicio está disponible por Internet) o como una sola forma dentro de cada centro de datos (si el servicio se proporciona localmente en el centro de datos). Si el acuerdo de nivel de servicio (SLA) del sistema de dependencia se conoce, también se debe señalar en el diagrama.

La mayoría de los equipos tienen un diagrama de servicio que se basa en los documentos de diseño o arquitectura. Además, lo equipos que ya aplican el modelado de amenazas de seguridad, como se describe en el Ciclo de vida de desarrollo de seguridad (SDL, por sus siglas en inglés) de Microsoft,5 deben tener diagramas de flujo de datos Nivel 0 para consultar. Ambos tipos de diagramas constituyen buenos puntos de partida; sin embargo, a menudo carecen de algunas (o todas) las interacciones necesarias para realizar un CID. Informática de confianza creó ejemplos de documentos de CID6 para ayudar a los equipos a elaborar sus propios CID. Estos ejemplos de documentos incluyen muchas formas y conexiones que ofrecen pistas visuales para ayudar a los equipos a analizar las fallas más adelante en el proceso. La ilustración siguiente es un ejemplo de CID para un servicio de nube simple denominado Contoso,7 un servicio de nube que recopila información de clientes en Internet, la transforma utilizando un servicio de terceros y almacena los datos finales en la nube.

5 Ciclo de vida de desarrollo de seguridad (SDL) de Microsoft www.microsoft.com/sdl 6 Consulte la sección “Recursos adicionales” al término de este documento para conocer los enlaces a los ejemplos de documentos. 7 Este diagrama no utiliza todas las formas disponibles en la galería Visio de CID; sin embargo, la galería Visio completa contiene una

leyenda integral con una descripción de cada forma.


Ilustración 3. Ejemplo de diagrama de interacción de componentes (CID)

Las ilustraciones siguientes ofrecen un mayor detalle de las formas que proporcionan pistas visuales para identificar fallas durante la fase de Descubrimiento:


• Flechas y números de interacción. Los datos más importantes corresponden a las interacciones entre componentes, que se analizan en la fase de Descubrimiento con el fin de explorar todas las distintas fallas que se pueden producir. Todas las interacciones están etiquetadas con un número que se transfiere al libro de RMA.

• Certificados. La forma certificado se utiliza para resaltar casos en que son necesarios los certificados. Las fallas relacionadas con los certificados son fuentes frecuentes de errores. Observe cómo los certificados en el diagrama están codificados por color para asociarlos a la interacción correspondiente.

• Señal de ceda el paso. La señal de ceda el

paso indica que este recurso usa limitación, lo que a su vez indica que un llamante puede encontrar fallas en interacciones con este recurso cuando se produce un desaceleramiento intencional del servicio.


• Caché. Observe la forma de caché local en verde, que se incluye dentro de las instancias del receptor. El almacenamiento en caché es una medida de mitigación común contra fallas y, en este caso, si el Servicio receptor no puede (a través de la interacción Nº7) almacenar resultados en la base de datos, almacenará en la caché los datos de manera local hasta que se restablezca la conexión a la base de datos.

• Dominios de falla. El ejemplo de diagrama siguiente ilustra diversos tipos de roles de

servidor. Cada tipo de rol utiliza un etiquetado especial para capturar información sobre distintos dominios de falla. El concepto de dominios de falla resultará conocido para todos quienes hayan desarrollado servicios de nube en Windows Azure. Un usuario elige el número de dominios de falla para sus casos de rol y la infraestructura Windows Azure subyacente se asegura de que los casos de rol se marquen con rayas en gabinetes de servidores, conmutadores y enrutadores, de manera que una falla en una capa de nivel inferior de la infraestructura no afecte a más de un dominio de falla. Al analizar las fallas para casos de rol, esta información es importante porque influye directamente en la amplitud del impacto que una falla de este tipo tendrá en un tipo de rol Azure. Para servicios de nube creados en un modelo de alojamiento en centro de datos tradicional, es posible aplicar este mismo concepto de dominios de falla a la infraestructura subyacente para evaluar los impactos en el rol de servidor. Además, es posible estimar el nivel de impacto de las fallas en estos componentes de manera sencilla al observar el número de dominios de falla para cada tipo. En este diagrama, observe que todos los casos de rol de servidor del receptor están conectados a un par de enrutadores, un par de equilibradores de carga y se marcan con rayas sobre cinco conmutadores de gabinete. Esta información ayuda a transmitir el impacto para el rol del receptor si se produce una falla en cualquiera de estas capas de la infraestructura.


Después de finalizar el diagrama de interacción de componentes, el equipo de ingeniería puede pasar a la tarea siguiente en la fase de Trabajo previo.

Tarea2:TransferirlasinteraccionesdesdeeldiagramaallibrodeRMA

La segunda tarea en la fase de Trabajo previo consiste en transferir los números de interacciones desde el CID al libro de RMA con el fin de crear la lista maestra de interacciones, que se utiliza durante la fase de Descubrimiento para enumerar diversos tipos de falla que se pueden producir durante cada interacción. Las interacciones con número se ingresan en el libro de RMA. La información requerida incluye la Id, un nombre corto (que normalmente especifica al llamante y a quien responde) y una descripción de la interacción misma. El ejemplo siguiente de libro incluye información del diagrama correspondiente al servicio Contoso, que analizamos antes en la Tarea 1. ID Interacción entre

componentes/dependencias Descripción de la interacción

1 Cliente de Internet -> Ingestion Service

Los clientes usuarios finales se conectan a través del extremo de Internet de los roles web de Contoso Azure Service Ingestion y cargan datos.

2 Roles de Ingestion -> Azure Storage Table

Ingestion Instances almacena los datos cargados del cliente en Azure Storage Table.

3 Roles de Ingestion -> Azure Storage Queue

Las instancias de Ingestion envían un mensaje a Azure Storage Queue con un puntero hacia los datos del cliente almacenados en Azure Storage Table.

4 Roles del receptor -> Azure Storage Queue

Las instancias del receptor extraen el mensaje de Azure Storage Queue que contiene un puntero hacia los datos del cliente almacenados en Azure Storage Table.

5 Roles del receptor -> Azure Storage Table

Las instancias del receptor extraen los datos cargados del cliente de Azure Storage Table.

6 Roles del receptor -> Procesamiento externo

Las instancias del receptor incorporan los datos cargados del cliente en el Servicio de procesamiento externo para su transformación.

7 Roles del receptor -> Azure SQL Database

Las instancias del receptor incorporan los datos del cliente transformados en Azure SQL Database.

Ilustración 4. Columnas de interacciones del libro de RMA (ejemplo)

Después de finalizar el CID y registrar toda su información de interacción entre componentes en el libro de RMA, el equipo de ingeniería está listo para pasar a la fase siguiente del proceso de RMA, Descubrimiento.

Descubrimiento

El objetivo de la fase de Descubrimiento es enumerar y registrar las posibles fallas de cada interacción entre componentes. Esta fase es una sesión de tormenta de ideas facilitada que, por lo general, resulta más eficaz cuando todas las disciplinas de ingeniería participan activamente. Los desarrolladores son participantes fundamentales de este ejercicio debido a su conocimiento cabal del comportamiento del sistema cuando se producen fallas.


La información que se debe registrar en el libro de RMA durante este ejercicio incluye: • Id de la interacción. Se determina en la fase de Trabajo previo. • Nombre de la interacción. Se determina en la fase de Trabajo previo. • Nombre corto de la falla. Un nombre corto para el tipo de falla. • Descripción de la falla. Una descripción más larga de la falla. • Respuesta. Información sobre la gestión, las alertas y las medidas de

mitigación/restablecimiento de errores asociadas a esta falla. La información en la columna Respuesta se utilizará para analizar los efectos de cada falla en la fase Clasificación, de manera que es muy importante capturar toda la información descrita en la lista anterior. El ejemplo siguiente corresponde al servicio Contoso, un servicio al que hacemos referencia en todo el documento. Id Interacción

entre componentes/dependencias

Nombre corto de la falla

Descripción de la falla

Respuesta


Existencia:Resolución de nombre

Es posible que Azure Storage Table no pueda resolver en DNS por períodos prolongados.

Las instancias de Ingestion almacenarán en caché los datos del cliente de manera local en un disco virtual hasta que la resolución de nombre se restablezca para Azure Storage Table. La caché local se mantendrá durante el reinicio de la VM, pero se perderá después de la destrucción de la VM. El sistema de alerta ContosoMon activará una alerta SEV1 en caso de errores de resolución de nombre para Azure Storage Table. Si la condición persiste más allá de las longitudes de cola local, se requerirá intervención humana.


Latencia:Sin respuesta

Es posible que Azure Storage Table no responda por períodos prolongados a todos los casos de roles de Ingestion.

Las instancias de Ingestion almacenarán en caché los datos del cliente en forma local en un disco virtual hasta que Azure Storage Table vuelva a responder. La caché local se mantendrá durante el reinicio de la VM, pero se perderá después de la destrucción de la VM. El sistema de alerta ContosoMon activará una alerta SEV1 en caso de errores de resolución de nombre para Azure Storage Table. Si la condición persiste más allá de las longitudes de cola local, se requerirá intervención humana.

Ilustración 5. Columnas del libro de RMA utilizadas durante el ejercicio de tormenta de ideas sobre fallas.

Se requiere un facilitador para que se asegure de que la reunión de tormenta de ideas sobre fallas sea productiva y capture el nivel correcto de detalles. El CID se utilizará y referenciará durante toda la reunión y, por lo general, será lo único que se muestre a los participantes durante esta fase. El facilitador registrará las diversas fallas identificadas durante la reunión en el libro de RMA. Una buena práctica para la reunión de tormenta de ideas es limitar el tiempo a no más de 90 minutos para evitar el cansancio y la reducción de calidad resultante. Si, después de 90 minutos, no se examinaron todas las interacciones para identificar fallas, la experiencia ha demostrado que es mejor detenerse y programar una segunda sesión para completar esta fase.


Si bien la tormenta de ideas se puede iniciar con cualquier interacción (como una en que todos estén de acuerdo que presenta problemas de confiabilidad en forma regular), es mejor comenzar por el punto de partida lógico de un escenario y luego, seguir el orden natural de las interacciones a partir de allí. El facilitador orientará a los participantes durante la actividad de tormenta de ideas que consiste en identificar la gran mayoría de fallas posibles. Estructurar un poco esta fase permitirá garantizar en gran medida que el ejercicio sea eficaz y, a la vez, integral. Para ayudar al facilitador, Informática de confianza elaboró una lista (que se muestra en la ilustración siguiente) de fallas comunes que se puede usar para guiar la conversación de una manera repetible para cada interacción.

Ilustración 6. Tabla de categorías de fallas que se pueden utilizar durante la fase de Descubrimiento


Las categorías se enumeran en una secuencia lógica de posibles interacciones entre componentes. Por ejemplo, cuando el componente A realiza una solicitud al Recurso B, pueden producirse problemas en la siguiente secuencia lógica: 1. Es posible que el Recurso B no exista o no se pueda encontrar. Si se encuentra, 2. Es posible que el Componente A no se autentique correctamente con B. Si no se autentica, 3. Es posible que el Recurso B ande lento o no responda la solicitud que emitió el Componente

A y así sucesivamente. La lista anterior no pretende ser un catálogo exhaustivo de todas las fallas posibles. Sin embargo, si los participantes consideran estas fallas para cada interacción y revisan cada categoría de esta manera estructurada, el registro de los resultados es más fácil y es menor probable que se omitan clases completas de fallas. Un punto muy importante que debe tener en cuenta durante este ejercicio es que las fallas en el RMA no son lo mismo que causa raíz. Puede haber múltiples causas raíz que lleven a que se produzca una falla de un recurso y haga que aparezca como sin conexión. Sin embargo, en todos esos casos, el comportamiento que observa el llamante es el mismo: el recurso no tiene conexión. La causa raíz subyacente no incide en cómo responderá el llamante. No obstante, puede ser conveniente registrar varias causas raíz de un tipo de falla en la columna Descripción de la falla para utilizarlas más tarde cuando se determine la probabilidad del tipo de falla. Después de enumerar la totalidad de las fallas para todas las interacciones entre componentes, el equipo de ingeniería está listo para pasar a la fase de Clasificación.

Clasificación

El objetivo de la fase de Clasificación es analizar y registrar los efectos que pueden resultar de cada una de las fallas enumeradas en la fase de Descubrimiento. Los detalles que se registraron para cada tipo de falla en la columna Respuesta proporcionarán la mayor parte del contexto necesario para realizar esta tarea. Este ejercicio permitirá generar una lista de valores de riesgo calculados para cada tipo de falla, la que a su vez se utilizará como información para la fase de Actuación. Nuevamente, al igual que en la fase de Descubrimiento, el facilitador dirigirá una reunión que incluya a las mismas personas que participaron en la enumeración de las fallas. Al igual que antes, recomendamos que esta reunión no se extienda por más de 90 minutos. Generalmente, el facilitador mostrará el libro en una pantalla de proyección a medida que todos proporcionan los datos restantes de cada falla utilizando la información recabada en esta reunión. El libro de RMA tiene varias columnas de selección desplegables que se llenarán durante esta fase. La ilustración siguiente ofrece más detalles de cada una de estas columnas.


Ilustración 7. Columnas del libro de RMA utilizadas durante el ejercicio de análisis de efectos de las fallas

La columna Riesgo es un valor calculado que se deriva de las otras cinco columnas. El objetivo detrás de este cálculo es evaluar el riesgo como resultado del impacto y la probabilidad de la falla. Probabilidad es un concepto claro que es representado por un solo valor en el libro (seleccionado de la lista desplegable Probabilidad). Sin embargo, el impacto de una falla se puede desglosar en varios elementos. El proceso de RMA se utiliza para evaluar el impacto de posibles fallas durante el diseño del producto de manera muy similar al método que usa un equipo de administración de problemas para evaluar el impacto de una interrupción de un servicio de nube ya en producción. Las siguientes preguntas clave se plantean en forma habitual en lo que se refiere al impacto de una interrupción: ¿Cuáles fueron los efectos perceptibles para el usuario o el proceso crítico para el negocio?

¿Esta interrupción constituyó una molestia o impacto menor en el rendimiento o fue algo que impidió interacciones clave de usuarios finales? ¿Cuál fue la profundidad del impacto?

¿Qué tan amplio fue el alcance del impacto? ¿Solo se vieron afectados algunos clientes o transacciones o el alcance del impacto fue más amplio? ¿Cuál fue la amplitud del impacto?

¿Cuánto tiempo demoró una persona o sistema automatizado en detectar la falla? ¿Cuál fue el tiempo de detección (TTD)?

Una vez detectada la falla, ¿cuánto tiempo tomó restablecer el servicio y la funcionalidad? ¿Cuál fue el tiempo de recuperación (TTR)8?

Estas preguntas se aplican a fallas potenciales en el libro de RMA y se asignan de manera respectiva a las columnas Efectos, Parte afectada, Detección y Solución.

8 TTR es el tiempo que toma restablecer la funcionalidad para el cliente, no necesariamente el tiempo que demora la corrección

completa de la falla.


Es importante que el equipo de ingeniería recuerde que todas las columnas son completamente independientes entre sí. El facilitador debe asegurarse de que las evaluaciones de las columnas Efectos y Parte afectada en especial no se fusionen durante el ejercicio. Por ejemplo, es perfectamente razonable esperar que un equipo analice una falla que puede dar como resultado solo una leve degradación en la calidad del servicio a la vez que afecta prácticamente a todos los usuarios del sistema. Por el contrario, el equipo puede estar analizando una falla que afecta a solo un usuario (o una mínima parte del total de las transacciones que se están procesando) en el servicio, pero dicha falla puede tener consecuencias muy graves en términos de integridad de los datos, incluida la pérdida de datos. El cálculo numérico de las columnas Impacto y Probabilidad es fijo en el modelo; los valores desplegables están fijos en tres opciones9 (cuatro en el caso de Efectos). Sin embargo, los equipos pueden modificar el texto asociado de las selecciones desplegables para que reflejen mejor las características de su servicio de nube. Por ejemplo, un equipo con un tiempo de detección de fallas en el servicio casi instantáneo puede modificar el valor predeterminado Menos de 5 min, Entre 5 min y 15 min y Más de 15 min de la columna Detección para que sea Menos de 50 milisegundos, Entre 50 milisegundos y 500 milisegundos y Más de 500 milisegundos, respectivamente. Al comienzo de la fase de Clasificación, se deben revisar las selecciones desplegables de todas estas columnas. Cuando se realiza el análisis de efectos, la fase de Clasificación finaliza. El equipo ahora posee una lista de fallas por prioridad que puede usar como referencia para la fase de Actuación.

Actuación

El objetivo de esta fase final es tomar medidas en cuanto a los elementos descubiertos durante la parte de modelado de resistencia del proceso de RMA y realizar inversiones tangibles para mejorar la confiabilidad del servicio de nube. La categorización de riesgos de las fallas identificadas en el libro de RMA durante la fase de Clasificación ofrece orientación sobre la prioridad de las posibles inversiones de ingeniería. Usted puede crear elementos de seguimiento al evaluar todas las fallas de riesgo alto y medio y luego, generar elementos de trabajo para los recursos de ingeniería. A veces, es posible transformar fallas de riesgo alto en fallas de riesgo medio al reducir los valores de tiempo de detección (TTD) o de tiempo de recuperación (TTR). Es posible implementar muchas mejoras en estas dos áreas al invertir o efectuar cambios en los sistemas de supervisión. Los elementos de trabajo también pueden utilizarse para instrumentación y telemetría, detección y supervisión, y mitigaciones para resolver causas raíz específicas o acelerar la recuperación. Además, los elementos de trabajo pueden introducir nuevos casos de prueba que se deberán considerar en los bancos de pruebas para el servicio. Los elementos de trabajo también pueden dar como resultado solicitudes de cambios en la arquitectura si el RMA se realiza con suficiente anticipación en la etapa de diseño. 9 Las opciones desplegables se expresan como bajas, medias y altas para permitir a los equipos realizar la selección con rapidez sin entramparse en cálculos de precisión.


Como mencionamos antes, uno de los beneficios secundarios del RMA es que genera artefactos que pueden ser beneficiosos para otras personas fuera del equipo principal, como el personal de soporte telefónico o el personal de operaciones. Al exigir al equipo de ingeniería revalidar la arquitectura y el diseño durante la fase de Trabajo previo, el CID a menudo ofrece información adicional que trasciende al diseño y la arquitectura actuales o a los diagramas conforme al trabajo que normalmente se usan hoy en día. La organización de prueba puede usar el libro de RMA para realizar pruebas de inserción de errores gracias a que captura metadatos sobre la calidad de la respuesta de la interacción de un componente a una falla en el servicio de nube. Cualquier componente que incorpore medidas de mitigación de fallas puede utilizarse para inserción de errores a fin de verificar la calidad y la eficacia de tales medidas de mitigación.

Consideraciones de implementación RMA es un enfoque optimizado y sencillo que los equipos pueden utilizar para incrementar la resistencia de su servicio de nube al identificar y analizar las fallas potenciales. Si bien la implementación del proceso es flexible en varias áreas, los equipos deben considerar cuidadosamente los temas de tiempos, enfoque, roles y responsabilidades antes de comenzar.

Tiempos

Si su equipo está acostumbrado a realizar modelado de amenazas de seguridad como se describe en el Ciclo de vida de desarrollo de seguridad de Microsoft, usted ya tiene una idea cabal de la cadencia de RMA. De manera similar a las recomendaciones para modelado de amenazas de seguridad, Informática de confianza le recomienda revisar su modelo de resistencia cada seis meses (no menos de seis meses y definitivamente una vez al año por lo menos) cada vez que realice cambios importantes en la arquitectura o la funcionalidad o cuando experimente problemas en el sitio activo que le impidan cumplir de manera consistente con los objetivos de disponibilidad de sus clientes. Para servicios nuevos o servicios que se están sometiendo a una modificación importante, los equipos deben considerar la implementación de RMA después de que la arquitectura se haya planificado y el diseño inicial se haya propuesto, pero antes de finalizar la mayor parte del código. Resulta más rentable diseñar la resistencia en el servicio en lugar que reaccionar ante fallas después de que el servicio ya se puso en funcionamiento. Los equipos de servicios de nube que ya están en producción deben considerar la implementación inmediata de RMA; no es necesario esperar hasta la próxima modificación importante del servicio para comenzar a aplicar la metodología de RMA. La lista de fallas por prioridad que genera el proceso de RMA ofrece una amplia variedad de oportunidades para realizar inversiones focalizadas en instrumentación, detección, mitigación y recuperación, muchas de las cuales se pueden implementar con rapidez. Además, los conocimientos obtenidos del análisis sobre un producto actualmente en producción serán de enorme valor para los ciclos de planificación y desarrollo futuros. Muchos equipos con


servicios ya en producción también están interesados en la inserción de errores. Los resultados del proceso de RMA proporcionan información muy valiosa para las pruebas de inserción de errores cuyo fin es validar la eficacia de las técnicas de mitigación de fallas actuales.

Enfoque

La metodología de RMA es tan flexible que la puede aplicar a cualquier aspecto de un servicio de nube. Considere cada una de las siguientes variaciones dentro del alcance al momento de determinar la inversión de tiempo que desea realizar en RMA: • Escenario de extremo a extremo. La confiabilidad del servicio se debe evaluar desde la

perspectiva de los clientes. Por consiguiente, los equipos a menudo desean concentrarse en fallas que afectan flujo de trabajo de usuarios clave o fallas debido a las cuales la organización será la más afectada por incidentes de confiabilidad. Si aplica este enfoque, usted priorizará las inversiones de ingeniería asociadas a la confiabilidad, lo que se considera un aspecto importante para los consumidores del servicio. No obstante, los escenarios de extremo a extremo a menudo abarcan muchos componentes y límites de servicio. Para reducir la necesidad de requerir la participación de tantas personas pertenecientes a muchos equipos distintos, el escenario se puede dividir en subescenarios para obtener el nivel deseado de eficiencia.

• Límites de los servicios de nube. Con frecuencia, lo que más preocupa a los equipos son los problemas de confiabilidad en los límites de su servicio de nube. Estos límites constituyen los puntos de intersección entre los componentes de su servicio de nube y los servicios de terceros o suministrados por asociados. El alcance del ejercicio de RMA se puede configurar para modelar todos los puntos de integración de servicios a fin de identificar fallas. El beneficio de este enfoque es que estos puntos de integración generalmente se encuentran donde los servicios suelen ser más susceptibles a fallas. Además, este enfoque normalmente requiere menos participantes para realizar el ejercicio. La desventaja de este enfoque es que es posible que ciertos componentes que abarcan escenarios de usuario claves o flujos de trabajo críticos para el negocio no se modelen de manera suficiente.

• Componente por componente. Una tercera opción es que los equipos puede elegir focalizar el RMA en un pequeño número de componentes del servicio de nube por vez. Por lo general, los equipos comienzan con componentes que experimentan la mayoría de los problemas de confiabilidad (si el servicio ya está en producción) o con un componente para el que desean obtener un nivel de confiabilidad en las primeras etapas de diseño. La definición del alcance del ejercicio de RMA para abarcar un solo componente del servicio de nube ofrece el beneficio de requerir menos participantes y se puede realizar a un costo menor. Este enfoque es similar al modelado de límites de servicios de nube, pero a nivel de componente. Los flujos de trabajo clave que abarcan múltiples componentes obtienen una cobertura completa cuando cada equipo de componentes realiza el RMA en el transcurso del tiempo. Sin embargo, es necesario efectuar un análisis adicional de cómo los componentes interactúan para garantizar que las iniciativas de detección, mitigación y recuperación se complementen en cada punto de integración.


Roles y responsabilidades

El ejercicio de RMA es más eficaz cuando se incluye a representantes de todas las disciplinas de ingeniería en el proceso, lo que permite expresar perspectivas variadas de cada rol durante las diversas fases de RMA. La inclusión de todas las disciplinas de ingeniería ayudará a garantizar un resultado más integral. Existe una disciplina que debe participar de todas maneras en el proceso de RMA: la disciplina de desarrollo. Generalmente, los desarrolladores (o propietarios de componentes) están mejor facultados para explicar detalladamente cómo se comportará un sistema cuando se produzca una falla. Un facilitador debe impulsar el proceso de inicio a fin y asignar elementos de trabajo a otros al término del proceso. Esta persona puede pertenecer a cualquier disciplina, pero debe ser capaz de orientar cuidadosamente las conversaciones entre las diversas disciplinas de ingeniería de manera que los elementos de trabajo asignados al término del ejercicio generen los mejores resultados de confiabilidad a la vez que consuman la menor cantidad de recursos para ello.

Llamado a la acción Adopte los principios de ingeniería asociados a la informática orientada a la recuperación. Incorpore el RMA en su ciclo de vida de desarrollo de software: modele las fallas y los efectos de las mismas, decida qué fallas se deben solucionar al seguir el proceso descrito aquí y realice las inversiones de ingeniería necesarias para mitigar riesgos de alta prioridad. Demuestre el valor de aplicar el RMA en su entorno al tomar los recursos de ingeniería que se utilizan por no poseer la capacidad de responder en forma continua a las fallas y reasignarlos al diseño y la posterior entrega de innovación orientada al cliente a un ritmo aun más rápido que antes. Comparta la experiencia de RMA con otros equipos de ingeniería que aún no han adoptado esta iniciativa y ayúdeles a comprender cómo aplicar la metodología y beneficiarse del incremento en la productividad igual que usted.

Conclusión La computación en nube se puede definir como un ecosistema complejo que consta de infraestructura compartida y dependencias ligeramente complementadas pero estrechamente integradas entre aplicaciones, muchas de las cuales estarán fuera del control directo del proveedor. A medida que sigue aumentando la adopción de servicios basados en la nube, las expectativas de los clientes en cuanto a disponibilidad de servicios a nivel de utilidad se mantienen altas, a pesar de los desafíos evidentes asociados a la entrega de una experiencia confiable 24 horas al día, los siete días de la semana y los 365 días del año.


No obstante la aplicación rigurosa de prácticas de diseño de software empresarial conocidas, los componentes de prueba durante el desarrollo y la implementación de infraestructura redundante y copias replicadas de los datos, es inevitable que se produzcan interrupciones. Existe evidencia creciente de que ser capaz de evitar completamente la falla es una suposición que tiene sus puntos débiles; en los medios de comunicación, siguen apareciendo artículos que describen fallas de servicios de nube populares y los proveedores de servicios de nube normalmente explican lo que salió mal, por qué salió mal y cómo tienen planificado evitar incidencias futuras. Aun así, las fallas se siguen produciendo. Los arquitectos de software deben hacerse a la idea de que los recursos computacionales subyacentes pueden simplemente desaparecer inesperadamente (y lo más probable es que lo hagan) y, quizás, por períodos prolongados. En términos simples, los arquitectos de software deben aceptar esta nueva era de incertidumbre y diseñar conforme con ello. Se ha comprobado que la metodología descrita en este documento es altamente eficaz en ayudar a los equipos de servicios de nube a comprender cómo enfrentar las amenazas de confiabilidad persistentes de hoy en día. Además, le puede ayudar a priorizar las inversiones de ingeniería necesarias con el fin de reducir (o incluso eliminar) el impacto de tales amenazas desde la perspectiva de los clientes. El principal beneficio de la adopción del RMA versus un enfoque más focalizado que consista solo en el modelado de fallas y el análisis de causas raíz es que el equipo de diseño de servicios puede, gracias al ejercicio, obtener un análisis más integral basado en la exploración detallada de cada aspecto del servicio que se está creando. Los resultados del proceso de RMA ofrecen al equipo una comprensión más profunda de dónde se encuentran los puntos de falla conocidos, cuál es el impacto probable de los modos de falla conocidos y, lo más importante, el orden en que deben superar estos riesgos potenciales para obtener el resultado más confiable en el período más breve. Sabemos que las interrupciones del servicio son inevitables. Estamos diseñando y creando nuestros servicios mediante metodologías como RMA para minimizar el impacto de estas interrupciones para los clientes.


Recursos adicionales Guía para una arquitectura de nube resistente en Azure

- Guía de arquitectura de Windows Azure:

www.windowsazure.com/en‐us/develop/net/architecture/

- FailSafe (en canal 9): channel9.msdn.com/series/failsafe

Informática orientada a la recuperación: roc.cs.berkeley.edu/ Plantillas

- Diagrama de interacción de componentes (CID): aka.ms/CID

- Ejemplo de libro de RMA: aka.ms/RMAworkbook

Confiabilidad de Informática confiable: www.microsoft.com/reliability

Autores y colaboradores DAVID BILLS, Microsoft Trustworthy Computing

SEAN FOY, Microsoft Trustworthy Computing

MARGARET LI, Microsoft Trustworthy Computing

MARC MERCURI, Microsoft Consulting Services

JASON WESCOTT, Microsoft Trustworthy Computing

© 2013 Microsoft Corp. Todos los derechos reservados. Este documento se entrega "tal y como se encuentra". La información y los puntos de vista expresados en este documento, incluidas URL y otras referencias a sitios web de Internet, podrían cambiar sin aviso previo. Usted asume el riesgo de utilizarlo. Este documento no le otorga derecho legal alguno sobre cualquier propiedad intelectual de cualquier producto Microsoft. Puede copiar y utilizar este documento para fines de referencia interna. Otorgado con licencia en virtud de licencia Creative Commons Reconocimiento-No comercial-Compartir bajo la misma licencia 3.0 Unported.

http://www.windowsazure.com/en-us/develop/net/architecture/�

http://channel9.msdn.com/series/failsafe�

http://roc.cs.berkeley.edu/�

http://aka.ms/CID�

http://aka.ms/RMAworkbook�

http://www.microsoft.com/reliability�

http://creativecommons.org/licenses/by-nc-sa/3.0/�

http://creativecommons.org/licenses/by-nc-sa/3.0/�

Resistencia gracias al diseño para servicios de nube · 2017-01-30 · Informática de confianza |...

Documents

Transcript of Resistencia gracias al diseño para servicios de nube · 2017-01-30 · Informática de confianza |...