Entornos de prueba: preparar una preproducción para validar cambios en plataformas críticas

Qué vas a conseguir

Un entorno donde probar una actualización de la historia clínica, un parche del servidor o un cambio de integración antes de que llegue a la planta. En una plataforma que no puede pararse, el entorno de pruebas es lo único que separa un cambio de una incidencia a las tres de la mañana. Solo sirve si se parece a producción en lo que importa y si no contiene datos reales de pacientes.

Antes de empezar

• El inventario de la plataforma en producción: servidores, versiones, base de datos, integraciones (laboratorio, imagen, farmacia) y certificados.
• El responsable funcional de la aplicación y el proveedor: son quienes saben qué hay que probar y quienes firman.
• La política de protección de datos del centro y al delegado de protección de datos (DPD): los datos de salud son categoría especial en el RGPD.
• Capacidad en la plataforma virtual para un entorno más pequeño, pero con la misma arquitectura.

1. Lo que tiene que ser igual que producción

Si el clúster o el balanceador forman parte del cambio, el entorno de pruebas los necesita también. Probar una conmutación en un solo nodo no prueba nada.

2. Los datos: nunca pacientes reales

• Datos ficticios generados por el proveedor o por un script para pruebas funcionales normales.
• Copia de producción enmascarada cuando hace falta volumen o casos reales (rendimiento, migraciones): se restaura en una red aislada, se enmascara y solo entonces se abre a los probadores.
• El enmascaramiento es estático: se cambian los datos en la base. El enmascaramiento dinámico de SQL Server solo oculta al consultar; el dato sigue ahí y no vale para un entorno de pruebas.
• Se enmascara todo lo identificativo: nombre, apellidos, DNI, número de historia, tarjeta sanitaria, teléfono, dirección y textos libres de notas clínicas (o se vacían).

›Invoke-Sqlcmd -ServerInstance srv-sql-pre01 -Database HCE_PRE -Query "SELECT TOP 3 NHC, Apellido1, DNI, Telefono FROM Pacientes"NHC       Apellido1   DNI        Telefono---       ---------   ---        --------PRE000101 APELLIDO101 00000101T  600000101PRE000102 APELLIDO102 00000102R  600000102PRE000103 APELLIDO103 00000103W  600000103

Si la comprobación muestra un solo nombre real, el entorno se cierra y se avisa al DPD. No se "arregla después".

3. Red aislada y accesos

• VLAN propia para el entorno de pruebas, sin rutas hacia los servidores de producción. Una prueba que escribe en el laboratorio real es una incidencia de seguridad del paciente.
• Las integraciones apuntan a los entornos de pruebas de los otros sistemas, o a simuladores.
• Acceso nominal y temporal para probadores y proveedor; cuentas de servicio distintas de las de producción.
• Copias de seguridad propias: un refresco fallido no debe obligar a pedir otra copia de producción.

4. El plan de pruebas y el visto bueno

El plan se escribe con el responsable de la aplicación, no lo escribe IT solo:

1. Qué cambia y qué partes de la aplicación toca.
2. Casos de prueba de los circuitos críticos: ingreso, prescripción, petición al laboratorio, alta.
3. Pruebas técnicas: instalación, tiempo del cambio, reversión y rendimiento básico.
4. Resultado de cada caso con quién lo probó y cuándo.
5. Visto bueno firmado por el responsable funcional, que se adjunta a la petición de cambio antes de ir al CAB.

5. El ticket: "funcionó en pruebas y falló en producción"

Jueves, 06:10, tras la ventana de cambio. La actualización se aplicó y el módulo de farmacia da error en producción; en preproducción funcionó.

1. Se aplica el plan de reversión si el error afecta a la atención y no hay solución en el tiempo acordado. Primero la plataforma, después la investigación.
2. Se busca la deriva: qué es distinto entre los dos entornos. Lo habitual: un parche del sistema, un certificado, un cambio manual que nunca se documentó.

›Compare-Object (Get-HotFix -ComputerName srv-hce-app01) (Get-HotFix -ComputerName srv-hce-pre01) -Property HotFixIDHotFixID   SideIndicator--------   -------------KB5066835  <=

Producción tiene un parche que preproducción no tiene. Se aplica en preproducción, se repite la prueba y se reproduce el error: ya hay causa para el proveedor.

1. Se corrige el proceso: el entorno de pruebas entra en el mismo ciclo de parches que producción, una semana antes.

6. Lo que revisas cada mes

• Versiones y parches de producción y preproducción comparados, con las diferencias justificadas.
• Fecha del último refresco y resultado de la comprobación de enmascaramiento.
• Accesos al entorno: los temporales caducados, retirados.
• Cambios aprobados en el mes que se aplicaron sin pasar por pruebas, y por qué.

Siguientes pasos

• La guía de ISO 27001/NIS2/RGPD en IT explica el tratamiento de datos de salud y la gestión de cambios que pide la auditoría.
• La guía de PostgreSQL/MySQL/SQL Server cubre la restauración de bases de datos para el refresco.
• La guía de Backup y DR/BCP sitúa el entorno de pruebas en el plan de recuperación.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.