Una vez desplegados los componentes de software es importante validar su correcta operación. Para ello, se deben considerar de manera exhaustiva sus flujos y posibles puntos de fallo.
Los flujos deben tener la capacidad de observarse en tiempo de ejecución con herramientas externas, entendiendo sus inputs, outputs y en caso de que ocurran errores, detectar lo más posible toda la información del error.
Esto permite poder tomar acciones lo más rápidamente cuando se despliegan componentes nuevos o, de manera post mortem, detectar anomalías en flujos ya existentes.
Como regla, se deben seguir además delas buenas prácticas de logs de eventos dentro del código, los siguientes puntos de control:
Es uso obligatorio de bibliotecas de logging que permitan:
Para el stack tecnológico actual, los sistemas de logger a utilizar son:
Al enviar los logs a través de la salida estándar, se puede utilizar AWS Cloudwatch como gestor y procesamiento de logs. AWS Cloudwatch entrega una poderosa herramienta de búsqueda query language llamada Logs Insights.
En general, la organización y gestión de los logs groups, permisos IAM asociados, y demás labores sobre la infraestructura AWS es parte de las actividad propias del área de Infraestructura de Elun, pero la construcción del software para hacer que toda esta cadena de eventos tenga valor es de responsabilidad del constructor y/o proveedor.
AWS Cloudwatch también permite la generación de alarmas y dashboards en base a eventos.
Ambas características son posibles gracias a que Cloudwatch puede generar métricas agregadas en base a atributos específicos, y en base a tolerancias perfilables, gatillar alarmas o presentar gráficos a través de sus componentes de dashboard.
AWS X-ray es un componente de AWS Cloudwatch que permite presentar de una manera visual la comunicación entre los distintos componentes de software. Su elemento atómico es llamado traces (trazas), y a través de su plataforma UI, se puede hacer seguimiento desde una perspectiva de modelo de nodos.
El constructor de Software debe implementar de manara obligatoria los SDKs correspondientes y realizar todas las configuraciones necesarias para poder hacer seguimiento de las trazas una vez el componente de software se encuentra operativo.
En el caso de las aplicaciones móviles, el componente de monitoreo que se debe implementar es Crashlytics el cual el provisto por Google a través de su suite Firebase.
Dado que por la naturaleza de funcionamiento de las Apps móviles (código compilado) no permite realizar seguimiento de eventos y caídas en tiempo real, se implementa Crashlytics para recopilar información valiosa de las caídas de la App (tanto las recuperables como las no recuperables) y dar seguimiento al cierre de estas incidencias.
Crashlytics permite dimensionar desde una perspectiva cuantitativa el tamaño y recurrencia de las caídas. De esta forma el constructor o proveedor puede generara un pipeline de resolución de incidencias.
La métrica de calidad asociada a la resolución de incidencias es de 93% de las sesiones totales sin incidencias para nuevos releases (nuevos features) y 97% como métrica de operación normal.