Descripción de la ingeniería para la resistencia

Completado

Microsoft define la resistencia como "la capacidad de un proceso o servicio empresarial para satisfacer las expectativas de los clientes frente a errores y desafíos para las operaciones normales". A escala de Microsoft Online Services, la resistencia es fundamental para mantener la disponibilidad de nuestros servicios en línea. Creamos nuestros servicios para que sean resistentes porque sabemos que:

• Se producirá un error en el hardware. Supongamos un tiempo medio antes del error (MTFB) de 100 000 horas para un disco duro. Para un solo disco duro, esto parece un error administrable cada 11,5 años. Pero si tiene 10 000 000 unidades de disco duro, se produce un error aproximadamente cada 30 segundos. La resiliencia frente al error de los componentes de hardware comunes es una característica clave de cómo diseñamos y compilamos nuestros servicios en línea.
• Los seres humanos cometen errores. Supongamos que una persona en una implementación de TI típica realiza 100 operaciones al día en un sistema de 100 servidores. Con una precisión del 99%, eso sigue siendo un error al día. Escalado a 250 000 servidores, se convierte en 2500 errores al día.
• El software tendrá errores. Las actualizaciones de software deben implementarse continuamente para mantener los servicios actualizados. Los servicios resistentes deben protegerse de errores nuevos y previamente no detectados en el software.

Respondemos a estos desafíos usando la nube a gran escala de Microsoft y empleando la automatización de servicios para que nuestros servicios sean resistentes frente a varios modos de error.

Diseño de servicio activo/activo

Siempre que sea posible, nos aseguramos de que nuestros servicios estén diseñados e implementados con resiliencia activa/activa. Esto significa que si se produce un error en un componente crítico del servicio, hay un componente idéntico disponible para asumir el control sin pérdida de disponibilidad. Las implementaciones activas/activas reemplazan los modelos activos/pasivos más antiguos, en los que los componentes pasivos tardaron tiempo en asumir la carga de trabajo si se produce un error en los componentes activos, lo que interrumpe temporalmente la disponibilidad del servicio y la integridad de los datos. El diseño del servicio activo/activo representa una mejora significativa con respecto a otros modelos de implementación y proporciona resistencia frente a muchos tipos de errores de servicio.

Aislamiento de fallos

El aislamiento de errores aumenta la resistencia del servicio al impedir que los errores de un componente provoquen errores en otros componentes. El aislamiento de errores complementa el diseño del servicio activo/activo al reducir el ámbito necesario para la recuperación automatizada de errores de componentes. Microsoft trabaja continuamente para reducir el tamaño de las zonas de error en nuestros servicios en la nube para evitar que los errores se propaguen e afecten a otros componentes del sistema.

Algunas de las estrategias que usamos para el aislamiento de errores son:

• Control de errores específico dentro y entre componentes de servicio: Por ejemplo, los grupos de disponibilidad de base de datos de Exchange Online limitan el impacto de los errores dentro del servicio a grupos de disponibilidad específicos.
• Administración de varios protocolos para la disponibilidad del servicio: Por ejemplo, un incidente que afecte al acceso a los archivos de Teams se puede mitigar mediante la accesibilidad de archivos a través de SharePoint Online.
• Regionalización y diseño de sistema granular: nuestro diseño de servicio separa la infraestructura de servicio lógico y físico en unidades cada vez más pequeñas. Esto nos permite responder adecuadamente a los incidentes en función de su ámbito mediante la flexibilidad de la administración de servicios tanto a pequeña como a gran escala.
• Equilibrio de carga y limitación: Nuestros servicios ordenan de forma rutinaria el tráfico y los datos entre los componentes del sistema como parte del funcionamiento normal del servicio. El tráfico del lado del servicio no esencial se limita en favor del tráfico crítico, como la entrega de correo. Esto permite que nuestros sistemas prioricen automáticamente los servicios críticos en caso de un error de componente o incidente de servicio.

Radio de explosión reducido

Estrechamente relacionado con el aislamiento de errores es el concepto del "radio de explosión" de un incidente. Cuando se produce un incidente, el radio de explosión hace referencia a la amplitud del incidente que afecta a nuestros servicios en línea. Microsoft trabaja constantemente para reducir el radio de impacto de posibles incidentes. Cuando una respuesta a un incidente posterior al ataque descubre un tipo de incidente con un radio de explosión inaceptable, respondemos invirtiendo en actualizaciones de servicio diseñadas para reducir el impacto de incidentes similares en el futuro.

Mejora continua

Cuando se producen incidentes, nuestro proceso de respuesta a incidentes garantiza que cada incidente se administra para su resolución. Usamos métricas estandarizadas para realizar un seguimiento del impacto de los incidentes en la disponibilidad y el rendimiento del servicio. Los incidentes con un impacto significativo en los clientes están sujetos a una revisión posterior a los incidentes. Los resultados clave y las mitigaciones resultantes de la revisión posterior al incidente se publican en el panel de Service Health para que los clientes afectados los vean.

Las revisiones posteriores al incidente ayudan a identificar las mejoras de resistencia que podrían impedir o limitar el ámbito de problemas similares en el futuro. Las lecciones aprendidas de los incidentes se comparten entre los equipos de servicio, por lo que cada equipo puede implementar mejoras sin experimentar directamente un incidente similar.

Más información

• Resiliencia del servicio Microsoft 365 y orientación al cliente
• Resiliencia de datos en Microsoft 365