Confiabilidad del sitio

En este documento se describe el enfoque del equipo de Fabric para mantener un servicio confiable, eficaz y escalable para los clientes. Describe la supervisión del estado del servicio, la mitigación de incidentes y la acción sobre las mejoras necesarias. Otros aspectos operativos importantes, como la seguridad y la administración de versiones, están fuera del ámbito de este documento. Este documento se creó para compartir conocimientos con nuestros clientes, que a menudo plantean preguntas sobre las prácticas de ingeniería de confiabilidad del sitio. La intención es ofrecer transparencia en cómo Fabric minimiza la interrupción del servicio a través de la implementación segura, la supervisión continua y la respuesta rápida a incidentes. Las técnicas que se describen aquí también proporcionan un plan estratégico para los equipos que hospedan soluciones basadas en servicios para crear procesos fundamentales de sitios en tiempo real que sean eficientes y eficaces a gran escala.

¿Por qué se producen incidentes y cómo vivir con ellos?

El equipo de Fabric envía actualizaciones semanales de características al servicio y correcciones dirigidas a petición para solucionar problemas de calidad del servicio. El proceso de lanzamiento incluye un conjunto completo de puertas de calidad, incluidas revisiones de código completas, pruebas ad hoc, pruebas automatizadas basadas en componentes y pruebas basadas en escenarios, distribución de características y implementación segura regional. Sin embargo, incluso con estas medidas de seguridad, los incidentes en el sitio pueden ocurrir y suceden.

Los incidentes del sitio en vivo se pueden dividir en varias categorías:

• Problemas de servicio dependientes, como Azure AD, Azure SQL, Storage, conjunto de escalado de máquinas virtuales, Service Fabric.

• Interrupción de la infraestructura, como un error de hardware, un error del centro de datos.

• Problemas de configuración del entorno en Fabric, como una insuficiencia de capacidad.

• Regresiones de código de servicio de Fabric

• Configuración incorrecta del cliente, como recursos insuficientes y consultas incorrectas o informes.

Reducir el volumen de incidentes es una manera de reducir la carga del sitio activo y mejorar la satisfacción del cliente. Sin embargo, no siempre es posible hacerlo, dado que algunas de las categorías de incidentes están fuera del control directo del equipo. Además, a medida que la superficie del servicio se expande para admitir el crecimiento en el uso, la probabilidad de que se produzca un incidente debido a los factores externos aumenta. Los recuentos de incidentes elevados pueden producirse incluso en los casos en los que el servicio Fabric tiene regresiones mínimas de código de servicio y ha cumplido o superado su objetivo de nivel de servicio (SLO) para la confiabilidad general de 99,95%, que ha llevado al equipo de Fabric a dedicar recursos significativos a reducir el impacto en los incidentes.

Proceso de gestión de incidentes en sitio en vivo

Al investigar incidentes de sitios activos, el equipo de Fabric sigue un proceso operativo estándar que es común en Microsoft y el sector. En la imagen siguiente se resume el ciclo de vida estándar de control de incidentes del sitio activo.

• fase 1: supervisión de servicios El equipo de SRE trabaja con ingenieros, administradores de programas y el equipo de liderazgo sénior para definir indicadores de nivel de servicio (SLA) y objetivos de nivel de servicio (SLO) para escenarios principales y escenarios menores. Estos objetivos se aplican a diferentes métricas del servicio, incluidos escenarios y componentes de confiabilidad, escenarios y componentes de rendimiento (latencia) y consumo de recursos. A continuación, el equipo de sitio activo y el equipo de productos diseñan alertas que supervisan los indicadores de nivel de servicio (SLA) contra los objetivos acordados. Cuando se detectan infracciones, se desencadena una alerta para su investigación.

• fase 2: respuesta a incidentes: los procesos están estructurados para facilitar los siguientes resultados:

  • Notificaciones inmediatas y específicas a los clientes sobre cualquier impacto relevante

  • Análisis de los componentes y flujos de trabajo de servicio afectados

  • Mitigación dirigida del impacto en incidentes

• fase 3: mejora continua: finalización del análisis post mortem pertinente y resolución de cualquier proceso, supervisión o configuración o correcciones de código identificados. A continuación, las correcciones se priorizan contra el trabajo pendiente de ingeniería general del equipo en función de la gravedad general y el riesgo de repetición.

Nuestras prácticas para la supervisión del servicio

El equipo de Fabric hace hincapié en un enfoque coherente, controlado por datos y centrado en el cliente en sus operaciones de sitio activo. Definir indicadores de nivel de servicio (SLA) e implementar las alertas de supervisión del sitio activo correspondientes forma parte de los criterios de aprobación para habilitar cualquier nueva característica de Fabric en producción. Los ingenieros de grupo de productos también incluyen pasos para investigar y mitigar alertas cuando se producen mediante una guía de solución de problemas de plantilla (TSG). Esas entregas se presentan al equipo de Ingeniería de confiabilidad del sitio (SRE).

Una manera en la que el equipo de Fabric permite el crecimiento exponencial del servicio es mediante un equipo de SRE. Estas personas están especializadas en la arquitectura del servicio, la automatización y las prácticas de administración de incidentes, y se insertan dentro de incidentes para impulsar la resolución de un extremo a otro. El enfoque contrasta con el modelo rotacional en el que los líderes de ingeniería del grupo de productos toman un rol de administrador de incidentes durante solo unas pocas semanas al año. El equipo de SRE asegura que un grupo coherente de personas sea responsable de impulsar las mejoras en el sitio en vivo y de que las lecciones aprendidas de incidentes anteriores se incorporen en futuras escalaciones. El equipo de SRE también ayuda con simulacros a gran escala que prueban las funcionalidades de continuidad empresarial y recuperación ante desastres (BCDR) del servicio.

Los miembros del equipo de SRE utilizan su conjunto de aptitudes único y una considerable experiencia en el sitio en vivo, y también se asocian con los equipos de funcionalidades para mejorar los SLI y las alertas proporcionadas por el equipo del producto de diversas maneras. Algunas de las formas en que mejoran los SLI incluyen:

• alertas de anomalías: los SRE desarrollan monitores que consideran el uso típico y los patrones operativos dentro de un entorno de producción determinado y alertan cuando se producen desviaciones significativas. ejemplo: la latencia de actualización de conjuntos de datos aumenta en 50% en relación con períodos de uso similares.

• Customer/Environment-Specific Alerts : los SRE desarrollan monitores que detectan cuándo determinados clientes, las capacidades aprovisionadas o los clústeres implementados se desvían del comportamiento esperado. Ejemplo: una capacidad única propiedad de un cliente está fallando al cargar conjuntos de datos para la consulta.

• Fine-Grained Alertas: los SRE consideran subconjuntos de la población que pueden experimentar problemas independientemente de la población más amplia. En estos casos, se diseñan alertas específicas para asegurarse de que las alertas se desencadenarán de hecho si se producen errores en esos escenarios menos comunes a pesar de un volumen inferior. ejemplo: se producen errores al actualizar conjuntos de datos que usan el conector de GitHub

• Alertas de confiabilidad percibida:los ingenieros de confiabilidad del sitio (SRE) también crean alertas que detectan casos en los que los clientes no tienen éxito debido a cualquier tipo de error. Esto puede incluir errores de usuario e indicar la necesidad de mejorar la documentación o modificar la experiencia del usuario. Estas alertas también pueden notificar a los ingenieros errores inesperados del sistema que, de lo contrario, podrían clasificarse erróneamente como un error de usuario. ejemplo: se produce un error en la actualización del conjunto de datos debido a credenciales incorrectas

Otro rol fundamental del equipo de SRE es automatizar las acciones de TSG en la medida de lo posible a través de Azure Automation. En los casos en los que la automatización completa no es posible, el equipo de SRE define acciones para enriquecer una alerta con información de diagnóstico útil y específica de incidentes para acelerar la investigación posterior. Este enriquecimiento se empareja con instrucciones prescriptivas en un TSG correspondiente para que los ingenieros de sitio activo puedan realizar una acción específica para mitigar el incidente o escalar rápidamente a los SME para una investigación adicional.

Como resultado directo de estos esfuerzos, se mitigan más de 82 % de incidentes sin ninguna interacción humana. Los incidentes restantes tienen suficientes datos de enriquecimiento y documentación complementaria que se van a controlar sin la participación de SME en el 99,7 % de casos.

Los SRE del sitio en vivo también aseguran la calidad de las alertas de varias maneras, entre las que se incluyen las siguientes:

• Asegurarse de que los TSG incluyen el análisis de impacto y la política de escalación

• Asegurarse de que las alertas se ejecuten para la ventana de tiempo más pequeña absoluta posible para una detección más rápida

• Asegurarse de que las alertas usan umbrales de confiabilidad en lugar de límites absolutos para escalar clústeres de tamaño diferente

Nuestras prácticas para la respuesta a incidentes

Cuando se crea un incidente de sitio activo automatizado para el servicio Fabric, una de las primeras prioridades es notificar a los clientes el posible impacto. Azure tiene un tiempo de notificación de destino de 15 minutos, lo que es difícil de lograr cuando los administradores de incidentes publican manualmente las notificaciones después de unirse a una llamada. Las comunicaciones en tales casos corren el riesgo de ser tardías o inexactas debido al análisis manual necesario. Azure Monitoring ofrece soluciones de supervisión y alertas centralizadas que se basan en determinadas métricas dentro de este período de tiempo, pueden detectar posibles impactos. Sin embargo, Fabric es una oferta de SaaS con escenarios complejos e interacciones de usuario que no se pueden modelar y realizar un seguimiento fácilmente mediante estos sistemas de alertas. En respuesta, el equipo de Fabric desarrolló el servicio de notificaciones Time To Notify Zero (TTN0).

La filosofía del sitio activo de Fabric destaca la resolución automatizada de incidentes para mejorar la escalabilidad general y la sostenibilidad del equipo de SRE. El énfasis en la automatización permite la mitigación a escala y puede evitar costosas reversiones o correcciones aceleradas de riesgo en los sistemas de producción. Cuando se requiere una investigación manual, Fabric adopta un enfoque por niveles con la investigación inicial realizada por un equipo de SRE dedicado. Los miembros del equipo de SRE tienen experiencia en la gestión de incidentes en el sitio en vivo, facilitando la comunicación entre equipos y promoviendo la mitigación. En los casos en los que el miembro del equipo de SRE que actúa requiere más contexto en un escenario o componente afectado, podrían involucrar al experto en la materia (SME) de esa área para obtener instrucciones. Por último, el equipo de SME realiza simulaciones de fallos en los componentes del sistema a fin de comprender y mitigar problemas antes de un incidente en un sitio activo.

Una vez determinado el componente afectado o el escenario del servicio, el equipo de Fabric tiene varias técnicas para mitigar rápidamente el impacto. Algunos de ellos son:

• activar la infraestructura de implementación en paralelo: Fabric admite la ejecución de diferentes cargas de trabajo con versiones en el mismo clúster, lo que permite al equipo ejecutar una versión nueva (o anterior) de una carga de trabajo específica para determinados clientes sin desencadenar una implementación a escala completa (o reversión). El enfoque puede reducir el tiempo de mitigación a 15 minutos y reducir el riesgo general de implementación.

• Ejecutar el Proceso de Continuidad Empresarial y Recuperación ante Desastres (BCDR): permite al equipo transferir las cargas de trabajo críticas a este entorno alternativo en tres minutos si se encuentra un problema grave en una nueva versión de servicio. BCDR también se puede usar cuando los factores ambientales o los servicios dependientes impiden que el clúster o la región principal funcionen normalmente.

• Aprovechar la resistencia de los servicios dependientes: Fabric evalúa e invierte proactivamente en esfuerzos de resistencia y redundancia para todos los servicios dependientes (como SQL, Redis Cache, Key Vault). La resistencia incluye una supervisión de componentes suficiente para detectar regresiones ascendentes y descendentes, así como redundancia local, zonal y regional (si procede). Invertir en estas funcionalidades garantiza que existen herramientas para la activación automática o manual de operaciones de recuperación para mitigar el impacto de una dependencia afectada.

Es hora de notificar que se ha llegado a cero

Time To Notify Zero, también conocido como TTN0, es un servicio de notificación de incidentes totalmente automatizado que usa nuestra infraestructura de alertas interna para identificar escenarios específicos y clientes afectados por un incidente recién creado. También se integra con agentes de supervisión externos fuera de Azure para detectar problemas de conectividad que podrían pasar desapercibidos. TTN0 permite a los clientes recibir un correo electrónico cuando TTN0 detecta una interrupción o degradación del servicio. Con TTN0, el equipo de Fabric puede enviar notificaciones confiables y dirigidas en un plazo de 10 minutos desde el inicio del impacto (lo cual es un 33% más rápido que el objetivo de Azure). Dado que la solución está totalmente automatizada, hay un riesgo mínimo de errores humanos o retrasos.

Nuestras prácticas para la mejora continua

El equipo de Fabric revisa todos los incidentes que afectan al cliente durante una revisión semanal del servicio con representación de todos los grupos de ingeniería que contribuyen al servicio Fabric. La revisión divulga los aprendizajes clave del incidente a los líderes de toda la organización y ofrece la oportunidad de adaptar nuestros procesos para cerrar las brechas y abordar las ineficiencias.

Antes de revisarlo, el equipo de SRE prepara el contenido post-mortem e identifica los elementos de reparación preliminar para el equipo de sitio activo y el equipo de desarrollo de productos. Los elementos pueden incluir correcciones de código, telemetría aumentada, alertas actualizadas u hojas de resolución de problemas. Los SRE de tejido están familiarizados con muchas de estas áreas y, a menudo, realizan de forma proactiva los ajustes en tiempo real mientras responden a un incidente activo. Esto ayuda a garantizar que los cambios se incorporen al sistema en el tiempo para detectar la repetición de un problema similar. En los casos en los que un incidente era el resultado de una escalación de clientes, el equipo de SRE ajusta las alertas automatizadas y los SLA existentes para reflejar las expectativas del cliente. En el caso del pequeño número de incidentes que requieren una escalación a un experto en la materia (SME) del escenario o componente afectado, el equipo de Fabric SRE revisará las formas en que se podría controlar el mismo incidente (o incidentes similares) sin escalarse en el futuro. El análisis detallado del equipo de SRE ayuda al equipo de desarrollo de productos a diseñar un producto más resistente, escalable y compatible.

Más allá de la revisión de postmortems específicos, el equipo de SRE también genera informes sobre los datos de incidentes agregados para identificar oportunidades de mejora del servicio, como la automatización futura de la mitigación de incidentes o correcciones de productos. Los informes combinan datos de varios orígenes, incluidos el equipo de soporte técnico al cliente, las alertas automatizadas y la telemetría del servicio. La vista consolidada proporciona visibilidad de los problemas que afectan negativamente al servicio y al estado del equipo y, a continuación, el equipo de SRE da prioridad a las posibles mejoras en función de la ventaja general para la confiabilidad del servicio. Por ejemplo, si una alerta determinada se activa con demasiada frecuencia o genera un impacto desproporcionada en la confiabilidad del servicio, el equipo de SRE puede asociarse con el equipo de desarrollo de productos para invertir en mejoras de calidad pertinentes. Completar estos elementos de trabajo impulsa la mejora de las métricas del sitio activo y del servicio y contribuye directamente a los resultados clave objetivo de la organización (OKR). En los casos en los que se ha cumplido un Índice de Nivel de Servicio (SLI) de manera constante durante un largo período de tiempo, el equipo de SRE puede sugerir aumentos en el Objetivo de Nivel de Servicio (SLO) para mejorar la experiencia de nuestros clientes.

Medición del éxito a través de resultados clave objetivo (OKR)

El equipo de Fabric tiene un conjunto completo de resultados clave objetivo (OKR) que se usan para garantizar el estado general del servicio y la satisfacción del cliente. Los OKR se pueden dividir en dos categorías:

• OKR de la salud del servicio: estos OKR miden directa o indirectamente la salud de los escenarios o componentes del servicio y, a menudo, se realiza un seguimiento mediante la supervisión o alertas. Ejemplo: Una sola capacidad propiedad de un cliente no puede cargar conjuntos de datos para la consulta.

• OKR de salud del sitio en vivo: estos OKR miden directa o indirectamente lo eficiente y eficazmente que las operaciones del sitio en vivo están abordando incidentes e interrupciones del servicio. Ejemplo: tiempo para notificar a los clientes (TTN) un incidente que les afecta.

El tiempo necesario para que el equipo de Fabric reaccione a los incidentes medidos por TTN, TTA y TTM supera significativamente los objetivos. La automatización de alertas se correlaciona directamente con la capacidad del equipo de mantener el crecimiento exponencial del servicio, al tiempo que sigue cumpliendo o superando los tiempos de respuesta de destino para las alertas, notificaciones y mitigación de incidentes.

El equipo de sitio en vivo de Fabric, así como el equipo de liderazgo sénior, realizan un seguimiento activo de los OKR mencionados anteriormente para asegurarse de que el equipo sigue cumpliendo o supera la línea de base necesaria para apoyar un crecimiento sustancial del servicio, mantener una carga de trabajo de sitio en vivo sostenible y garantizar una alta satisfacción del cliente.

Contenido relacionado

• conceptos y licencias de Microsoft Fabric
• Paridad de características de Microsoft Fabric