En TI, la capacidad de actuar en tiempo real se ha convertido en un referente. Los equipos detectan un problema, lo diagnostican rápidamente y, en el mejor de los casos, lo resuelven antes de que la persona afectada tenga que abrir una solicitud al servicio de asistencia.

Es preferible a esperar a que alguien informe de una incidencia. Pero actuar en tiempo real no equivale necesariamente a prevenir. Si surge un problema y respondemos en milisegundos, seguimos reaccionando ante algo que ya ha ocurrido.

¿Y si vuelve a suceder mañana? Una solución automatizada puede hacer que el empleado apenas lo note y que ningún ingeniero tenga que intervenir. Es un avance valioso, pero seguimos reparando algo que ya habíamos reparado.

Los problemas recurrentes tienen un coste, incluso cuando TI se vuelve muy eficiente al resolverlos. Los empleados pierden tiempo cuando la tecnología no funciona como esperan y los equipos de TI dedican recursos a investigar y remediar situaciones conocidas. La ingeniería de fiabilidad de sitios (SRE, por sus siglas en inglés) ofrece una manera de romper ese ciclo.

## Aplicar SRE a los dispositivos de los empleados

SRE surgió del enfoque de Google para operar sistemas de producción a gran escala y aplicar principios de ingeniería de software a los retos operativos. En esencia, consiste en definir qué nivel de fiabilidad necesita un servicio, medirlo y reducir el trabajo repetitivo necesario para mantenerlo.

Un objetivo de nivel de servicio (SLO) establece una meta medible de fiabilidad. Los presupuestos de error, por su parte, reconocen que ningún servicio puede ser perfecto en todo momento. Son conceptos consolidados en el desarrollo de software y la infraestructura, y cada vez tienen mayor relevancia para la experiencia digital del empleado.

Los dispositivos, las aplicaciones y los servicios que utiliza cada persona forman parte de la operación diaria de una organización. Su fiabilidad influye directamente en la capacidad de los empleados para realizar su trabajo.

En una conversación reciente, un socio resumió el reto de esta manera: «Avísame de los riesgos emergentes cuando todavía estén en un 0–2 % y dame pruebas para priorizarlos. Cuando superen entre un 5 y un 10 % de la línea base, el servicio de asistencia ya estará desbordado».

Se refería a la desviación respecto de la línea base habitual, no al porcentaje de empleados afectados. Necesitaba indicios suficientes para detectar un deterioro y decidir si debía intervenir antes de que aumentara la demanda de soporte. Reaccionar en milisegundos es positivo, pero prevenir es mejor.

Para ello, hay que detectar los problemas antes de que sean evidentes. Los datos sobre la experiencia digital del empleado pueden revelar incidencias que las métricas operativas tradicionales no muestran y ofrecer a TI señales tempranas, antes de que el servicio de asistencia se convierta en el principal indicador.

Por ejemplo, en una gran aseguradora de la lista Fortune 100, el equipo descubrió que cerca del 25 % del tiempo de inactividad de los centros de llamadas pasaba prácticamente inadvertido para TI. Al combinar la telemetría de los dispositivos con la automatización proactiva, la organización redujo el volumen de solicitudes en un 35 % en un año y evitó más de 45.000 tickets gracias a una única automatización de autoservicio.

## Aprender de los problemas que se repiten

Quienes trabajan en operaciones de TI saben cuánto tiempo pueden consumir las incidencias conocidas. En una gran red hospitalaria, un número reducido de problemas recurrentes generaba una parte desproporcionada de la actividad del servicio de asistencia. Entre ellos había dificultades con la sincronización de archivos, los servicios de seguridad, el uso de la CPU, la red y las herramientas de colaboración.

Al utilizar datos de los dispositivos para identificar y abordar las causas recurrentes, la organización redujo en aproximadamente 50.000 el número anual de incidencias y calculó un ahorro cercano a los 1,6 millones de dólares.

Aquí es donde el concepto de toil de SRE —el trabajo operativo repetitivo necesario para mantener un servicio en funcionamiento— encaja especialmente bien con la TI del entorno laboral. La automatización puede liberar a los ingenieros de muchas tareas rutinarias. Pero si una misma corrección vuelve a ser necesaria, ese patrón merece atención.

En ocasiones, la automatización seguirá siendo la respuesta más sensata. No todas las condiciones repetidas justifican un proyecto de ingeniería. En otros casos, los datos pueden apuntar a una aplicación, una configuración, una actualización u otra causa subyacente que convenga corregir de manera permanente.

PIMCO, una firma global de gestión de inversiones, ofrece otro ejemplo de lo que ocurre cuando los equipos disponen de mejores pruebas. Su equipo de infraestructura combinó datos de los dispositivos con la correlación de cambios y redujo de días a minutos investigaciones que antes requerían mucho tiempo para identificar la causa raíz.

La rapidez importa, pero también lo que el equipo puede hacer con esa información: entender qué cambió, aislar la causa y acercarse a eliminar el problema recurrente en lugar de tratar sus síntomas una y otra vez.

## Comprobar qué ocurrió después de la intervención

A menudo contamos con pruebas de que una acción de TI se llevó a cabo: un script terminó, se instaló una actualización, se reinició un dispositivo o un flujo de trabajo alcanzó su último paso. Pero la siguiente pregunta es la que importa: ¿funcionó? ¿Desapareció el problema? ¿Volvió la experiencia afectada a su nivel esperado? ¿Se mantuvo la mejora un día o una semana después?

La telemetría posterior a la intervención puede responder a estas preguntas. Sin ella, TI sabe que se ejecutó una acción, pero tiene menos información sobre el resultado y sobre cuánto duró la mejora. Los SLO ayudan a definir el nivel de fiabilidad esperado y permiten evaluar la recuperación. La ejecución de una acción es un dato; el estado posterior del servicio es otro.

Esta retroalimentación será cada vez más importante a medida que la inteligencia artificial asuma más tareas de diagnóstico y resolución sin que un ingeniero tenga que revisar cada señal o acción. Si la IA identifica un problema e inicia una respuesta, TI todavía necesita pruebas de que la intervención dio resultado.

Por eso importa el flujo completo, desde la detección hasta el resultado. A medida que más etapas se automatizan, la validación y la rendición de cuentas deben seguir formando parte del proceso. De lo contrario, TI podría automatizar cada vez más actividades sin lograr que el entorno sea realmente más fiable.

Nada de esto resta valor a la observabilidad en tiempo real, la automatización o la eficiencia del servicio de asistencia. Todas son necesarias. La velocidad de respuesta importa, al igual que reducir el trabajo manual.

Para los CIO, el mayor beneficio llega cuando esas capacidades permiten que menos problemas requieran atención desde el principio. Eso implica detectar antes el deterioro, aprender de las incidencias recurrentes y comprobar que las intervenciones funcionan y se mantienen. TI ya ha aprendido a resolver los problemas con rapidez. SRE ofrece ahora la oportunidad de dedicar menos tiempo a resolver los mismos problemas una y otra vez.

from Latest from TechRadar https://ift.tt/HutmbAV
via IFTTT IA