Es importante definir el proceso de gestión de incidencias que se tendrá cuando la solución teconlógica se encuentre operativa.

En este sentido se podrán definir diferentes niveles de atención así como los procesos a seguir en cada nivel.

A continuación se presenta un proceso genérico para la gestión de incidentes:

Y en la siguiente imagen cómo se podrían dividir las responsabilidades los diferentes niveles de atención:

Es necesario revisar los niveles de servicio establecidos tanto en los Términos de Referencia, en la Especificación de Requerimientos y en el Alcance. Estos pueden requerir alguna actualización o que sean llevados a más detalle para poder definir correctamente cuáles serán las medidas que se realizarán para monitorear el software en producción y asegurar los niveles de servicio establecidos.

A su vez, sugerimos revisar los Indicadores sugeridos para el MCS, ya que alguno de ellos puede resultar adecuado para medir la calidad de la solución que estará operativa. Algunos que pueden resultar útiles para este paso pueden ser:

• Cantidad de defectos
• Disponibilidad
• Grado de uso/adopción

Se debe hacer uso de herramientas para el monitoreo de los sistemas y bases de datos. Dependiendo de lo que se desee monitorear, existen diversas herramientas que podrían utilizarse. A continuación algunos ejemplos:

Software as a Service (SaaS)

• Acronis Monitoring Service
• New Relic
• LogicMonitor

Código abierto

• Nagios
• Icinga
• Sensu
• Zabbix

Propietarias

• Paessler
• SolarWinds
• ManageEngine

Cuando el software se coloca en operación en el ambiente de producción, defectos no detectados durante el desarrollo y testing del sistema pueden surgir y requerirán ser tratados de forma rápida.

Es posible que para la propia comunicación dentro del equipo de desarrollo ya existan herramientas instaladas para la gestión y seguimiento de los defectos. Algunas opciones gratuitas pueden ser: Bugzilla, Mantis, Request Tracker (RT), o similares. Si ya se cuenta con una herramienta, una opción puede ser utilizar la misma herramienta para la gestión de las incidencias en producción. Otra opción puede ser utilizar otra herramienta para el soporte a producción que de cierta forma relacione las incidencias de producción con las de desarrollo.

En general, para las incidencias en producción se siguen ciertos niveles de gestión de las incidencias. La persona que recibe la incidencia directamente de producción le realiza un tratamiento de primer nivel:

• Se chequea que no sea un problema en el uso/operación del sistema, que no haya problemas de infraestructura (conexión a internet, dispositivos, etc).
• Se chequea que no sea un error de configuración.
• Se chequea que no sea un error conocido con un workaround (procedimiento alternativo) a realizar para poder realizar la operación deseada. Para esto es deseable tener un
• Otros...

Este primer nivel de atención evita que se reporten incidencias a desarrollo que no refieren a un potencial defecto, dando una respuesta rápida al usuario y maximizando los esfuerzos tanto del equipo de soporte como del equipo de desarrollo.

Si ese primer nivel falla, generalmente se revisa si ese problema no fue reportado a desarrollo con anterioridad, en caso de que sí, se relaciona el incidente de producción con aquel ya reportado, se deja una nota o similar.

Si el problema no fue reportado aún, es necesario crear un registro de incidente nuevo, en donde la calidad de la información allí reportada resulta vital para la resolución rápida del problema. Un ejemplo de información útil para el reporte de los incidentes puede ser:

• Criticidad del problema
• Prioridad de resolución
• Impacto potencial del problema en el cliente
• Tipo de problema reportado
• Versión del sistema en el que el problema fue evidenciado
• Datos e información de la configuración en producción relevante
• Datos de la infraestructura en producción relacionada al problema (bases de datos, servidores, etc)
• Descripción del problema
• Evidencia del problema
• Pasos para reproducir el problema (si se pudo reproducir)
• Datos de producción para reproducir el problema
• Trazabilidad al reporte de defecto en desarrollo (opcional)

Luego de la instalación de las herramientas de monitoreo y gestión de incidentes en producción, es necesario monitorear los indicadores definidos para asegurar que niveles aceptables de operación y servicio del sistema están siendo brindados.

Políticas de acción/contingencia ante problemas en los servicios y en la operación de los sistemas tienen que ser establecidas para que todos los involucrados sepan cómo accionar rápidamente ante un problema en producción. Esto puede involucrar:

• Volver a una versión estable del sistema (o un antiguo sistema que está siendo suplantado).
• Levantar servidores de contingencia.
• Intervención manual en el tratamiento de los datos para evitar problemas críticos.
• Rápida orientación en caminos alternativos (workarounds) a la resolución temporal del problema para no afectar la operativa, mientras el problema de fondo está siendo analizado o su resolución lleva un tiempo que afecta negativamente los niveles de servicio.