Principios de diseño de la confiabilidad

Las interrupciones y los errores de funcionamiento son problemas graves para todas las cargas de trabajo. Una carga de trabajo confiable debe sobrevivir a esos eventos y seguir proporcionando constantemente su funcionalidad prevista. Debe ser resistente para que pueda detectar, resistir y recuperarse de errores dentro de un período de tiempo aceptable. También debe estar disponible para que los usuarios puedan acceder a la carga de trabajo durante el período de tiempo prometido en el nivel de calidad prometido.

No es realista suponer que no se producirán errores, especialmente cuando la carga de trabajo se compila para ejecutarse en sistemas distribuidos. Es posible que se produzca un error en algunos componentes, mientras que otros siguen funcionando. En algún momento, la experiencia del usuario podría verse afectada, lo que pone en peligro los objetivos empresariales.

Las arquitecturas de carga de trabajo deben tener garantías de confiabilidad en el código de la aplicación, la infraestructura y las operaciones. Las opciones de diseño no deben cambiar la intención especificada por los requisitos empresariales. Estos cambios deben considerarse importantes inconvenientes.

Los principios de diseño están diseñados para proporcionar instrucciones para aspectos de confiabilidad que debe tener en cuenta a lo largo del ciclo de vida de desarrollo. Comience con los enfoques recomendados y justificar las ventajas de un conjunto de requisitos. Después de establecer la estrategia, impulse las acciones mediante la lista de comprobación de confiabilidad.

Si no aplica estos principios al diseño, es más probable que la carga de trabajo no esté preparada para prever ni controlar problemas en producción. El resultado puede ser interrupciones del servicio que conducen a una pérdida financiera. En el caso de cargas de trabajo críticas, si no se aplican estos principios, podría poner en peligro la seguridad.

Diseño de requisitos empresariales

Recopile los requisitos empresariales con un enfoque en la utilidad prevista de la carga de trabajo.

Los requisitos deben cubrir la experiencia del usuario, los datos, los flujos de trabajo y las características que son exclusivos de la carga de trabajo. El resultado del proceso de requisitos debe indicar claramente las expectativas. Los objetivos deben ser factibles y negociados con el equipo, dada una inversión especificada. Deben documentarse para impulsar opciones tecnológicas, implementaciones y operaciones.

Enfoque	Prestación
Cuantifique el éxito estableciendo objetivos en indicadores para componentes individuales, flujos del sistema y el sistema en su conjunto. ¿Esos destinos hacen que los flujos de usuario sean más confiables?	Las métricas cuantifican las expectativas. Permiten comprender las complejidades y determinar si los costos descendentes de esas complejidades están dentro del límite de inversión. Los valores de destino indican un estado ideal. Puede usar los valores como umbrales de prueba que le ayudarán a detectar desviaciones de ese estado y cuánto tiempo se tarda en volver al estado de destino. Los requisitos de cumplimiento también deben tener resultados predecibles para los flujos dentro del ámbito. Al priorizar estos flujos , se presta atención a las áreas más sensibles.
Comprender los compromisos de la plataforma. Tenga en cuenta los límites, cuotas, regiones y restricciones de capacidad para los servicios.	Los acuerdos de nivel de servicio (SLA) varían según el servicio. No todos los servicios y características están cubiertos por igual. No todos los servicios o características están disponibles en todas las regiones. La mayoría de los límites de recursos de suscripción son por región. Tener una buena comprensión de la cobertura y los límites puede ayudarle a detectar el desfase y crear mecanismos de resistencia y recuperación.
Determine las dependencias y su efecto en la resistencia.	Realizar un seguimiento de la infraestructura dependiente, los servicios, las API y las funciones desarrolladas por otros equipos o terceros le ayuda a determinar si la carga de trabajo puede funcionar en ausencia de esas dependencias. También le ayuda a comprender los errores en cascada y a mejorar las operaciones de bajada. Los desarrolladores pueden implementar patrones de diseño resistentes para controlar posibles errores cuando se usan servicios externos que podrían ser susceptibles a errores.

Diseño para resistencia

La carga de trabajo debe seguir funcionando con funcionalidad completa o reducida.

Debe esperar que se produzcan errores de funcionamiento del componente, interrupciones de la plataforma, degradaciones del rendimiento, disponibilidad limitada de recursos y otros errores. Cree resistencia en el sistema para que sea tolerante a errores y pueda degradarse correctamente.

Enfoque	Prestación
Distinguir los componentes que se encuentran en la ruta crítica de los que pueden funcionar en un estado degradado.	No todos los componentes de la carga de trabajo deben ser igualmente confiables. Determinar la importancia le ayuda a diseñar según la importancia de cada componente. No superará la resistencia del motor para los componentes que podrían deteriorar ligeramente la experiencia del usuario, en lugar de los componentes que pueden causar problemas de un extremo a otro si fallan. El diseño puede ser eficaz para asignar recursos a componentes críticos. También puede implementar estrategias de aislamiento de errores para que si se produce un error en un componente no crítico o entra en un estado degradado, se puede aislar para evitar errores en cascada.
Identifique posibles puntos de error en el sistema, especialmente para los componentes críticos, y determine el efecto en los flujos de usuario.	Puede analizar los casos de error, el radio de explosión y la intensidad del error: interrupción total o parcial. Este análisis influye en el diseño de las funcionalidades de control de errores en el nivel de componente.
Cree funcionalidades de autoconservación mediante patrones de diseño correctamente y modularización del diseño para aislar los errores.	El sistema podrá evitar que un problema afecte a los componentes de bajada. El sistema podrá mitigar errores transitorios y permanentes, cuellos de botella de rendimiento y otros problemas que podrían afectar a la confiabilidad. También podrás minimizar el radio de explosión.
Agregue la funcionalidad para escalar horizontalmente los componentes críticos (aplicación e infraestructura) teniendo en cuenta las restricciones de capacidad de los servicios en las regiones admitidas.	La carga de trabajo podrá controlar los picos de capacidad variable y las fluctuaciones. Esta funcionalidad es fundamental cuando hay una carga inesperada en el sistema, como un aumento en el uso válido. Si la carga de trabajo está diseñada para escalar horizontalmente en varias regiones, incluso puede superar posibles restricciones de capacidad de recursos temporales u otros problemas que afectan a una sola región.
Cree redundancia en capas y resistencia en varios niveles de aplicación. Apunte a la redundancia en las utilidades físicas y la replicación inmediata de datos. También tiene como objetivo la redundancia en el nivel funcional que abarca servicios, operaciones y personal.	La redundancia ayuda a minimizar los puntos únicos de error. Por ejemplo, si hay un componente, una interrupción zonal o regional, la implementación redundante (en activo-activo o activo-pasivo) le permite cumplir los objetivos de tiempo de actividad. La adición de intermediarios impide la dependencia directa entre los componentes y mejora el almacenamiento en búfer. Ambas ventajas protegen la resistencia del sistema.
Sobreaprovisionar para mitigar inmediatamente el error individual de las instancias redundantes y almacenar en búfer el consumo de recursos descontrolado.	Una mayor inversión en sobreaprovisionamiento aumenta la resistencia. El sistema seguirá funcionando en la utilidad completa durante un error activo incluso antes de que las operaciones de escalado puedan empezar a corregir el error. Del mismo modo, puede reducir el riesgo de un consumo inesperado de recursos descontrolado que reclama el búfer planeado, obteniendo un tiempo de evaluación de prioridades crítico antes de que se produzcan errores del sistema o un escalado agresivo.

Diseño para la recuperación

La carga de trabajo debe ser capaz de prever y recuperarse de la mayoría de los errores, de todas las magnituds, con una interrupción mínima en la experiencia del usuario y los objetivos empresariales.

Incluso los sistemas altamente resistentes necesitan enfoques de preparación ante desastres, tanto en el diseño de la arquitectura como en las operaciones de carga de trabajo. En la capa de datos, debe tener estrategias que puedan reparar el estado de la carga de trabajo en caso de daños.

Enfoque	Prestación
Tener planes de recuperación estructurados, probados y documentados alineados con los objetivos de recuperación negociados. Los planes deben cubrir todos los componentes además del sistema en su conjunto.	Un proceso bien definido conduce a una recuperación rápida que puede evitar un impacto negativo en las finanzas y la reputación de su negocio. La realización de simulacros de recuperación regulares prueba el proceso de recuperación de componentes del sistema, datos, y pasos de conmutación por error y conmutación por recuperación para evitar confusiones cuando el tiempo y la integridad de los datos son medidas clave de éxito.
Asegúrese de que puede reparar los datos de todos los componentes con estado dentro de los destinos de recuperación.	Las copias de seguridad son esenciales para volver al sistema a un estado de trabajo mediante un punto de recuperación de confianza, como el último estado correcto conocido. Las copias de seguridad inmutables y coherentes con las transacciones garantizan que los datos no se pueden modificar y que los datos restaurados no están dañados.
Implemente funcionalidades automatizadas de recuperación automática en el diseño.	Esta automatización reduce los riesgos de factores externos, como la intervención humana, y acorta el ciclo de corrección de interrupción.
Reemplace los componentes sin estado por unidades efímeras inmutables.	La creación de unidades efímeras que puede poner en marcha y destruir a petición proporciona repetibilidad y coherencia. Use modelos de implementación en paralelo para realizar la transición a las nuevas unidades incrementales, lo que minimiza las interrupciones.

Diseño para operaciones

Desplaze a la izquierda en las operaciones para anticipar las condiciones de error.

Los errores de prueba a principios y a menudo en el ciclo de vida de desarrollo y determinan el impacto del rendimiento en la confiabilidad. Por motivos de análisis de causa principal y postmortems, debe tener visibilidad compartida, entre equipos, de estado de dependencia y errores continuos. La información, el diagnóstico y las alertas de los sistemas observables son fundamentales para la administración eficaz de incidentes y la mejora continua.

Enfoque	Prestación
Cree sistemas observables que puedan correlacionar la telemetría.	La supervisión y el diagnóstico son operaciones cruciales. Si se produce un error en algo, debe saber que se produjo un error, cuando se produjo un error y por qué se produjo un error. La observabilidad en el nivel de componente es fundamental, pero la observabilidad agregada de los componentes y los flujos de usuario correlacionados proporciona una visión holística del estado de mantenimiento. Estos datos son necesarios para permitir a los ingenieros de confiabilidad del sitio priorizar sus esfuerzos de corrección.
Predecir posibles errores de funcionamiento y comportamiento anómalo. Haga que los errores de confiabilidad activos sean visibles mediante alertas prioritarias y accionables. Invertir en procesos confiables e infraestructura que conduce a una evaluación de prioridades más rápida.	Los ingenieros de confiabilidad del sitio se pueden notificar inmediatamente para que puedan mitigar los incidentes de sitios activos en curso y mitigar proactivamente posibles errores identificados por alertas predictivas antes de convertirse en incidentes activos.
Simulación de errores y ejecución de pruebas en entornos de producción y preproducción.	Resulta beneficioso experimentar errores en producción para que pueda establecer expectativas realistas para la recuperación. Esto le permite tomar decisiones de diseño que respondan correctamente a errores. Además, le permite probar los umbrales establecidos para las métricas empresariales.
Cree componentes teniendo en cuenta la automatización y automatice tanto como pueda.	La automatización minimiza el potencial de error humano, lo que aporta coherencia a las pruebas, la implementación y las operaciones.
Tenga en cuenta las operaciones rutinarias y su impacto en la estabilidad del sistema.	La carga de trabajo puede estar sujeta a operaciones en curso, como revisiones de aplicaciones, auditorías de seguridad y cumplimiento, actualizaciones de componentes y procesos de copia de seguridad. Examinar esos cambios garantiza la estabilidad del sistema.
Aprenda continuamente de incidentes en producción.	En función de los incidentes, puede determinar el impacto y las descuidos en el diseño y las operaciones que podrían pasar desapercibidos en la preproducción. En última instancia, podrá impulsar mejoras en función de los incidentes de la vida real.

Sencillo ante todo

Evite sobreengineering el diseño de la arquitectura, el código de aplicación y las operaciones.

A menudo es lo que quita en lugar de lo que agrega que conduce a las soluciones más confiables. La simplicidad reduce el área expuesta para el control, minimizando las ineficiencias y posibles configuraciones incorrectas o interacciones inesperadas. Por otro lado, la sobresmplificación puede introducir puntos únicos de error. Mantener un enfoque equilibrado.

Enfoque	Prestación
Agregue componentes a la arquitectura solo si le ayudan a lograr valores empresariales de destino. Mantenga la ruta crítica magra.	El diseño de los requisitos empresariales puede dar lugar a una solución sencilla que sea fácil de implementar y administrar. Evite tener demasiados componentes críticos, ya que cada uno es un punto significativo de error.
Establezca estándares en la implementación, implementación y procesos de código y documentelos. Identificar oportunidades para aplicar esos estándares mediante validaciones automatizadas.	Los estándares proporcionan coherencia y minimizan los errores humanos. Los enfoques como las convenciones de nomenclatura estándar y las guías de estilo de código pueden ayudarle a mantener la calidad y facilitar la identificación de los recursos durante la solución de problemas.
Evalúe si los enfoques teóricos se traducen en un diseño pragmático que se aplica a los casos de uso.	El código de aplicación demasiado granular puede provocar interdependencia innecesaria, operaciones adicionales y un mantenimiento difícil.
Desarrolle código suficiente.	Podrá evitar problemas que son el resultado de implementaciones ineficaces, como el consumo inesperado de recursos, errores de usuario o flujo de datos y errores de código. Por el contrario, los problemas de confiabilidad deben provocar revisiones de código para asegurarse de que el código sea lo suficientemente resistente como para controlar los problemas.
Aproveche las características proporcionadas por la plataforma y los recursos creados previamente que pueden ayudarle a cumplir de forma eficaz los objetivos empresariales.	Este enfoque minimiza el tiempo de desarrollo. También le permite confiar en prácticas probadas y probadas que se han usado con cargas de trabajo similares.

Pasos siguientes

Lista de comprobación de confiabilidad