Detección de errores en producción: de la anomalía a la corrección verificada
Celenisia es una solución de IA como servicio (AIaaS) concebida por Aezan, consultora de transformación digital. Industrializa un método que hasta ahora aplicábamos en nuestros proyectos: observar el comportamiento real de las aplicaciones, remontarse a la causa y asegurarse de que la corrección se mantiene en el tiempo. Celenisia se apoya en modelos de IA de código abierto, y ninguno de sus datos se utiliza para entrenar modelos.
1. Detectar lo que nadie ha visto todavía
Una parte de los fallos en producción no proviene del código: corte de red, base de datos saturada, pico de actividad, flujo insuficiente, error o incumplimiento en los datos, API de un socio o de un proveedor no disponible. La aplicación responde, pero no siempre, o no bien. Estas situaciones ni las anticipan las pruebas ni se señalan mientras un usuario no se queja.
Celenisia analiza de forma permanente el comportamiento de sus aplicaciones a partir de sus logs. Hace aflorar estas anomalías, incluidas las intermitentes, antes de que pasen por soporte y luego por operaciones.
2. Relacionar con los avisos de los usuarios
Cada anomalía detectada se contrasta con los tickets de su gestor (Jira, Azure DevOps…). Un “no funciona” se convierte en un hecho caracterizado: cuándo, dónde, con qué frecuencia.
3. Priorizar según el impacto
Sus Product Owners disponen de los elementos para decidir con datos objetivos de producción, y no con percepciones: frecuencia, alcance afectado, impacto en los usuarios. Los equipos saben dónde concentrar primero sus esfuerzos.
4. Remontarse hasta el código
Celenisia audita el código fuente afectado para identificar lo que provoca el error, o lo que habría que mejorar para tratarlo mejor, y propone una corrección.
Operaciones entiende lo que ocurre sin esperar el análisis de los desarrolladores; los desarrolladores dejan de ser interrumpidos para analizar una incidencia.
5. Seguir cada corrección
Desde el aviso hasta la puesta en producción de la corrección, cada corrección tiene su seguimiento. La dirección, soporte y los equipos técnicos comparten la misma observación, basada en hechos, de la situación en producción y del proceso de resolución.
| Aplicación | Anomalía | Frecuencia | Estado |
|---|---|---|---|
| Nómina | Diferencia de cálculo en horas extra | 12 esta semana | Corrección en pruebas |
| Facturación de proveedores | Tiempo de espera superado en la API bancaria | 4 esta semana | Causa identificada |
| Directorio | Fallo de sincronización con Active Directory | 2 esta semana | Corregida, no regresión verificada |
| Portal RR. HH. | Ninguna anomalía abierta | — | Estable |
6. Garantizar la no regresión
Una vez desplegada la corrección, Celenisia verifica que cada error tratado ha desaparecido de verdad, señala si quedan casos residuales o si aparecen casos nuevos. Se le avisa en cuanto un problema reaparece.
El resultado: la tranquilidad
El CIO puede rendir cuentas a las áreas de negocio con hechos: o bien la aplicación no presenta errores, o bien los errores están identificados y en curso de resolución. Y una vez corregidos, la aplicación vuelve a comportarse con normalidad.
Lo que utiliza Celenisia
| Fuente | Acceso solicitado | Qué aporta |
|---|---|---|
| Los logs de sus aplicaciones | Solo lectura, mediante Azure, AWS, SFTP o base de datos | El comportamiento real de la producción |
| Su código fuente (GitHub, GitLab, Azure Repos) | Solo lectura | La causa de origen de los errores y una propuesta de corrección, sometida a sus desarrolladores |
| Su gestor de tickets (Jira, Azure DevOps…) | Lectura | La creación de tickets estructurados y completos a partir de lo observado en producción, y el seguimiento de las correcciones |