Cómo mejorar tu flujo de trabajo de soporte de TI
Cómo aplicar los principios de DevOps al soporte de TI
Está demostrado que incorporar los principios de DevOps a los equipos de ingeniería y servicios de TI mejora considerablemente la calidad del servicio, el estado de ánimo del equipo, la resolución de problemas y la productividad de la empresa. De hecho, las empresas que adoptan los principios de DevOps indican de media un aumento del 45 % en la satisfacción del cliente y del 43 % en la productividad de los empleados, una mejora del 41 % en el índice de defectos y una reducción del 38 % en los costes relacionados con TI.
Con estas cifras, no cabe duda de que integrar los principios de DevOps en la gestión de servicios de TI puede ser muy beneficioso para las empresas. Sin embargo, este cambio puede parecer complicado para los equipos, aunque por suerte no lo es tanto. De hecho, las claves de los servicios con mejores resultados son tan sencillas que puede que te sorprendan.
¿Qué es DevOps?
DevOps es un concepto que reúne un conjunto de prácticas pensadas para cohesionar a dos equipos que suelen trabajar de forma aislada y que tienen un largo historial de fricciones: el de desarrollo y el de operaciones. El objetivo es que colaboren, que tengan una comunicación abierta y que encuentren la manera de que los dos departamentos alcancen sus respectivos objetivos.
En palabras de nuestros expertos, "DevOps es un conjunto de prácticas que automatizan los procesos entre los equipos de desarrollo de software y TI para que puedan compilar, probar y publicar software con mayor rapidez y fiabilidad. El concepto de DevOps se basa en establecer una cultura de colaboración entre equipos que, tradicionalmente, trabajaban en grupos aislados. Entre las ventajas que promete, se incluyen el aumento de la confianza y de la velocidad de publicación de software, la capacidad de solucionar incidencias críticas rápidamente y una mejor gestión del trabajo imprevisto".
Motivos para aplicar los principios de DevOps al soporte de TI
Desde una perspectiva empresarial, las cifras hablan por sí solas: la satisfacción del cliente aumenta un 45 %, la productividad de los empleados crece un 43 % y los costes relacionados con TI se reducen un 38 %. El movimiento DevOps ha contribuido significativamente a mejorar los resultados de las empresas, y quizá es por eso por lo que cuatro de cada cinco declaran que están aplicando algunos de sus principios.
También hay motivos de peso para los equipos, ya que, si se aplican bien, los principios de DevOps mejoran la satisfacción, la colaboración y el reconocimiento de los empleados y del equipo. Además, simplifican los procesos más difíciles, aceleran las tareas y eliminan una capa de burocracia que durante mucho tiempo ha causado tensiones entre el equipo de TI, el equipo de desarrollo y otros equipos interrelacionados.
En lugar de la frustración que supone para los equipos de operaciones que salgan publicaciones nuevas de las que no sabían nada y para las que no pueden dar soporte (lo que, según Gartner, genera entre el 85 y el 87 % de los incidentes), DevOps ofrece vías de comunicación y preparación de cara al futuro. En cuanto a los equipos de desarrollo, la frustración que sienten cuando el equipo de operaciones les obliga a dar pasos atrás y las publicaciones se retrasan se transforma en colaboración para acelerar los lanzamientos y no poner en riesgo los compromisos de SLA y los objetivos de SLO.
Prácticas recomendadas de DevOps para el servicio de TI
El cambio de mentalidad es lo primero
El mayor desafío de la integración de DevOps es el cambio de mentalidad.
Las organizaciones de TI tradicionales suelen tener grupos de trabajo aislados, con el equipo de desarrollo en su propia burbuja y el equipo de operaciones tomando el relevo cuando se produce un cambio en los sistemas, a menudo con poca o ninguna información previa.
Las organizaciones que aplican los principios de DevOps, en cambio, priorizan la colaboración y la comunicación entre los equipos con prácticas y herramientas como los hackatones, las reuniones rápidas y las salas de chat.
Adoptar este cambio supone incorporar herramientas, procesos y una perspectiva cultural totalmente nuevos que den prioridad a la comunicación entre equipos y al éxito compartido.
Automatiza todo lo que puedas
El aumento de la productividad que aporta DevOps se debe, al menos en parte, a una filosofía que prioriza la automatización. Adoptar DevOps significa animar a los equipos a que se pregunten constantemente qué pueden automatizar.
¿Podemos automatizar las revisiones del código para detectar errores comunes? ¿Es posible automatizar los sistemas para vincular problemas, incidentes y solicitudes a los cambios o publicaciones que puedan haberlos desencadenado? ¿Podemos automatizar los controles y balances que nos impiden publicar código que no cumpla con los requisitos legales o de seguridad? ¿Es posible automatizar los sistemas para que congelen las publicaciones nuevas si nos acercamos demasiado a nuestros compromisos de SLO?
Hay muchas formas de automatizar y mejorar las métricas de DevOps. Estas son tres de las más habituales:
- Flujo de trabajo (por ejemplo: mover los tickets de soporte a través del centro de asistencia más rápido)
- Conocimientos (cuando se presenta un incidente, la herramienta de gestión de servicios debe mostrar automáticamente los conocimientos y la documentación relevantes)
- Escalación (si en la organización solo hay dos personas que puedan resolver un problema, se les debería escalar directamente con un sistema inteligente en lugar de seguir rutas de escalado rígidas y lineales)
Haz un seguimiento de las métricas importantes
En lo que respecta a la colaboración entre el equipo de desarrollo y el de operaciones de TI, una práctica recomendada es que también se encarguen de supervisar cómo van la cosas.
Los indicadores clave de rendimiento (KPI) más comunes de DevOps incluyen MTBF (tiempo medio entre fallos), MTTR (tiempo medio de recuperación, reparación, respuesta o resolución), MTTF (tiempo medio sin averías) y MTTA (tiempo medio de confirmación de recepción). Muchas empresas también se fijan en cifras como el número de alertas o solicitudes generadas en un determinado período de tiempo, el coste del tiempo de inactividad por minuto o el coste del soporte por llamada o solicitud.
Las métricas que tendrán que supervisar tus equipos dependerán del equipo en cuestión, de los compromisos que se hayan adquirido con los clientes en los SLA, de los objetivos de SLO acordados con la organización y de los problemas específicos que quieras abordar. También es importante ser consciente de que las métricas no son estáticas: si algo cambia dentro de la empresa, como los productos a los que TI presta soporte, las necesidades de las partes interesadas o las obligaciones legales o de seguridad externas, es posible que también haya que cambiar las métricas que se supervisan y cómo se supervisan.
Da prioridad a la comunicación
DevOps trata de tender puentes entre la creación y el mantenimiento, o lo que es lo mismo, entre las personas que crean y las que dan soporte. Consiste en compartir puntos de vista, objetivos, procesos, terminología, conocimientos, comunicaciones, herramientas, recursos y bases de código. Pero quizás lo más importante es que se basa en la propiedad compartida, lo que significa compartir la responsabilidad y también los éxitos.
Para muchas organizaciones tradicionales, cambiar a DevOps implicaría replantearse cómo definen, recompensan y supervisan las responsabilidades y los éxitos compartidos. ¿Los objetivos del equipo de desarrollo son opuestos a los del equipo de operaciones? ¿El éxito de un equipo dificulta el triunfo del otro?
Por ejemplo, si el equipo de desarrollo tiene que lanzar nuevas funciones cuanto antes y el equipo de operaciones de TI tiene que mantener el tiempo de actividad, es posible que un objetivo afecte negativamente al otro. Puede que el equipo de operaciones quiera ralentizar a los desarrolladores con el fin de superar sus objetivos de tiempo de actividad, y que al equipo de desarrollo le moleste que el equipo de operaciones le impida alcanzar sus objetivos con los lanzamientos.
La solución para muchos equipos de DevOps es aplicar un enfoque SRE. En este ejemplo, eso significaría dejar que el equipo de desarrollo haga todos los lanzamientos que quiera mientras el tiempo de actividad esté dentro de los objetivos de SLO, y paralizarlos si el tiempo de actividad baja a niveles inaceptables para que los dos equipos colaboren y recuperen el nivel adecuado de tiempo de actividad.
¿ITIL o DevOps?
Si conoces ITIL, puede que te estés preguntando qué papel desempeña DevOps. Hay un gran número de empresas para las que las prácticas de ITIL y DevOps son totalmente compatibles y, de hecho, en Atlassian vemos como muchas de ellas adoptan ventajas y puntos fuertes de los dos modelos.
Esto es lo que se explica en este fragmento sobre DevOps o ITIL: "Necesitamos los dos modelos porque son complementarios, no opuestos. Tenemos que conseguir trabajar de forma más rápida e inteligente, pero también necesitamos procesos y control. Los equipos y las organizaciones más modernos y con mejores resultados cada vez son más conscientes de ello, y por eso aplican elementos de los dos enfoques en lugar de considerarlos excluyentes".
ITIL tiende a abordar las prácticas recomendadas para operaciones, soporte, control y otras funciones empresariales básicas. DevOps, por su parte, se centra en aspectos como la entrega continua, la cultura sin acusaciones, las herramientas de colaboración y las prácticas de la metodología ágil que puedan mejorar y desarrollar las prácticas incorporadas desde hace tiempo en las pautas de ITIL.
Herramientas para organizaciones que aplican los principios de DevOps
Adoptar el enfoque de DevOps también puede suponer empezar a usar herramientas nuevas para la comunicación, la automatización y la colaboración entre equipos.
A la hora de evaluar herramientas nuevas, es importante hacerse preguntas como estas:
- ¿Esta herramienta funciona en nuestro entorno y se integra con las herramientas existentes?
- ¿Cubre nuestras necesidades?
- ¿Todas las herramientas nuevas funcionan juntas y forman un conjunto completo e integrado?
Puede que estemos barriendo para casa, pero en Atlassian utilizamos Jira Service Management para la gestión de servicios de TI, Jira Software para el desarrollo de software y Bitbucket para nuestro repositorio de código.
Si estas herramientas funcionan tan bien es en parte porque funcionan bien juntas. Y es que si estás intentando dejar atrás los grupos aislados en la estructura del equipo, lo último que quieres es que cada herramienta funcione al margen de las demás.
The Total Economic Impact™ Of Atlassian For ITSM
The Total Economic Impact™ of Atlassian Jira Service Management. The report includes cost savings and business benefits enabled by Jira Service Management.
Lee el artículo técnicoAtlassian's guide to agile ways of working with ITIL 4
ITIL 4 is here—and it’s more agile than ever. Learn tips to bring agility and collaboration into ITSM with Atlassian.
Lee el artículo técnico