¿Qué técnicas de programación utilizas para hacer que los programas C ++ estén altamente disponibles?

Me siento extraño respondiendo a mi propia pregunta, pero este es el tipo de cosas que estoy buscando. Estoy considerando escribir un libro sobre este tema, y ​​quiero ver cuánto conocimiento hay por ahí.

  • No hay ningún tipo de redundancia. Esta no es una técnica de programación. Quiero saber qué haces para evitar que tu programa se detenga o se cuelgue.
  • Manejo de llamadas a abort (), manejo de errores de verificación de tiempo de ejecución, manejo de señales como para control-c.
  • Manejo de todas las excepciones, proporcionando un indicador de salida para todos los monitores para que se pueda controlar el apagado
  • No arrojar destructores, no arrojar funciones no arrojar, no usar en exceso las especificaciones de excepción, por lo que no se llama inesperado ().
  • Monitorear la ejecución del programa desde otro proceso y reiniciar el programa si falla.
  • La industria integrada tiene temporizadores de vigilancia y subprocesos de vigilancia.
  • Por supuesto, todos los métodos de desarrollo que ayudan a eliminar defectos de los programas; prueba, registro, etc.

No estoy seguro de considerarlo una “técnica de programación” tanto como un enfoque de configuración, pero siempre configuro servidores en hardware replicado, con almacenamiento de datos replicados, todo configurado para la conmutación por error de repuesto dinámico. “Ningún punto único de falla” contribuye en gran medida al tiempo de actividad del 100%. Diseñar para el intercambio en caliente de componentes fallidos (ya sea una sola unidad de disco o un servidor completo) lo acerca aún más.

Escalado horizontal con múltiples copias de la aplicación.

Infraestructura duplicada para garantizar que la aplicación tenga más de una ruta.

La apatridia para permitir que las copias no dependan de configuraciones complejas para mantener la aplicación activa.

Código bien depurado que tiene en cuenta lo imposible que ocurre.

Diseñado tanto para operación como para mantenimiento para permitir que se realicen cambios de configuración y redistribución sin quitar la aplicación.

Diseños de subprocesos múltiples y seguros para subprocesos para permitir un gran número de solicitudes concurrentes.

Replicación de estado en otros nodos. Configuraciones ligeramente variables como umbrales de descarga de diario para que el mismo error de software no se manifieste al mismo tiempo en copias redundantes. Actualización en línea para que eso no reduzca la disponibilidad. Degradación en línea porque a veces una nueva versión no funciona bien. La verificación de modelos en un entorno simulado con pruebas deterministas y búsqueda de estado pseudoaleatoria para asegurar que las rutas de código raramente utilizadas como el cambio y la actualización / degradación realmente funcionen.

Independientemente del uso de una sola máquina o soluciones de sistemas distribuidos, pruebo las rutas de error con inyección de fallas para asegurarme de que funcionen.

Desde que David Patterson me presentó a la Computación Orientada a la Recuperación, he aceptado que las fallas son inevitables y he tomado medidas para eliminar o limitar la visibilidad de sus usuarios. Diseño para un reinicio rápido. Reinicio los procesos que se bloquean o dejan de responder (Dave sugiere un reinicio recursivo: operación, proceso, sistema hasta que se resuelvan los problemas). Busco problemas latentes y los corrijo antes de terminar en una situación de doble falla irrecuperable.