Close

Cómo mejorar tu flujo de trabajo de soporte de TI

DevOps o ITIL: ¿Qué es mejor para tu equipo?

En el sector de TI hay muchas opiniones sobre DevOps e ITIL. Estas opiniones tienden a contraponer los dos enfoques. Para mucha gente es: ITIL o DevOps. Blanco o negro. Uno u otro. Hay que escoger.

Este debate es interesante en el marco del ciclo de noticias sobre tecnología, pero aplicar este enfoque de todo o nada puede ser costoso, confuso y poco útil para los profesionales y sus negocios, porque no es cierto que tenga que ser todo o nada. No hay por qué escoger.

DevOps e ITIL no son prácticas excluyentes. Pueden complementarse y cada una puede aportar sus propias ventajas. Agilidad y colaboración. Proceso y control. Con un enfoque mixto, pueden aprovecharse los puntos fuertes de ambas.

¿Qué es DevOps?

DevOps acorta la distancia entre el desarrollo y las operaciones. Sus principios básicos son la comunicación abierta, la colaboración y los objetivos compartidos.

En palabras de nuestros expertos:

"A diferencia de marcos como ITIL, no hay un documento 'oficial' de prácticas recomendadas para los equipos que utilizan DevOps. Sin embargo, en términos generales podemos estar de acuerdo en que DevOps consiste esencialmente en ofrecer valor empresarial a una organización al eliminar los grupos aislados, aumentar la transparencia y fomentar la comunicación abierta entre los desarrolladores y los equipos de operaciones de TI".

¿Qué es ITIL?

ITIL (Biblioteca de infraestructuras de tecnologías de la información) es un conjunto de pautas para la gestión de servicios de TI. Estas pautas incluyen las prácticas recomendadas y los procesos de eficacia demostrada para áreas como la gestión de incidentes, la gestión de problemas y la gestión de cambios.

Conceptos erróneos sobre DevOps e ITIL

1. DevOps puede sustituir a ITIL

"Ya no usamos ITIL, nos hemos pasado a DevOps". Si llevas mucho tiempo en el sector de la tecnología, seguramente habrás escuchado esta frase.

El problema es que esta afirmación no es cierta porque, aunque los departamentos de TI puedan dejar de lado la formación y los procesos aislados de ITIL, deben mantener algunos aspectos de la gestión de servicios. Hay funciones empresariales básicas, como las operaciones, el soporte, el control y los costes, para las que DevOps no ofrece pautas, pero ITIL, sí. Por lo tanto, es probable que las empresas que gritan a los cuatro vientos que ahora solo usan DevOps sigan con algunos procesos o principios de ITIL.

2. DevOps equivale a desarrollo continuo, integración y entrega automatizada

DevOps incluye desarrollo continuo, integración y entrega automatizada, pero eso no es todo lo que ofrece ni es necesariamente el centro de la práctica. El contexto y las motivaciones de DevOps consisten, sobre todo, en alejarse de las antiguas divisiones y colaborar desde el respeto mutuo y sin buscar culpables.

Eso es todo. Colaboración, objetivos compartidos, respeto mutuo y nada de acusaciones.

Este enfoque colaborativo puede mejorar todo tipo de métricas empresariales, aunque el equipo aún no haya adoptado por completo la entrega automatizada o el desarrollo continuo.

3. ITIL/ITSM implica mucha documentación con procesos complejos que ralentizan a los equipos

Muy a menudo se considera erróneamente que ITIL es un conjunto de reglas inamovibles en lugar de pautas abiertas a la interpretación.

ITIL es lo que tu equipo quiera que sea. Si parece rígido, es porque en algún momento se decidió que fuera así. Pero eso puede cambiar.

ITIL no es más que el punto de partida para comprender los complejos procesos de TI que deben gestionar la mayoría de las empresas. Es una hoja de ruta, una guía, no el único camino posible. Sirve para darnos el contexto necesario para tomar decisiones y dirigir a los equipos de TI de la manera más eficaz y eficiente posible.

Cuando ITIL se interpreta como un reglamento, lo que suele pasar es que la documentación y la burocracia se multiplican, pero, si se toma como una pauta, puede simplificar las operaciones en lugar de bloquearlas.

4. ITIL/ITSM solo es para grandes empresas

Es cierto que las grandes empresas han liderado el paso a ITIL, pero eso no significa que las pequeñas empresas no puedan beneficiarse de estas pautas. Las empresas de todos los tamaños tienen que saber cómo gestionar los cambios, los incidentes graves y los conocimientos, entre otras tareas empresariales básicas para las que ITIL puede servir de base.

Las empresas emergentes tienen que organizar sus equipos de TI en algún momento para poder escalar. Lo mismo pasa con las medianas empresas. Incluso un proyecto de desarrollo de una aplicación autofinanciado por dos personas necesita un plan de guardia y una estrategia de gestión de incidentes. De lo contrario, un solo fallo podría suponer su final.

Casos de uso de DevOps e ITIL

Aunque los casos de uso de DevOps e ITIL son prácticamente infinitos, a continuación encontrarás algunos ejemplos de las incidencias que pueden resolver y de cómo, en algunos casos, se necesitan los dos enfoques para encontrar la mejor solución.

Agiliza las nuevas publicaciones con DevOps

La metodología ágil de DevOps ofrece ventajas tanto a nivel de velocidad como de gestión de riesgos, ya que las publicaciones periódicas más reducidas y regulares pasan más rápido por la fase de desarrollo y son más fáciles de revertir o corregir si se produce algún incidente.

Reduce las llamadas al centro de asistencia de TI con ITSM

La práctica recomendada de ITSM sobre gestionar el conocimiento consiste en que el equipo de TI cree documentación mientras resuelve problemas. Esto puede reducir considerablemente la carga de trabajo del centro de asistencia, ya que ofrece opciones de autoservicio tanto a los clientes internos como a los externos.

Evita incidentes con ITIL y DevOps

Combina los procesos probados y demostrados de gestión de incidentes de ITIL con la automatización de los procesos de revisión y los análisis retrospectivos sin acusaciones de DevOps, añádele el enfoque “you built it, you run it” y tendrás la fórmula para que haya menos incidentes y que sean más cortos.

Llega a la raíz de los incidentes con DevOps

Uno de los aspectos más positivos de DevOps es la cultura de no buscar culpables. Esto no significa que los ingenieros no se responsabilicen de los errores, sino que pueden hablar honestamente de ellos, tener conversaciones más transparentes sobre lo que ha ido mal y hacerlo sin miedo al despido.

Este cambio de cultura ayuda a los equipos a llegar a la raíz de los incidentes más rápido y a centrarse en soluciones reales en lugar de apuntar a alguien como el problema en una cadena de eventos que han llevado a un incidente.

Reduce la confusión de los clientes con ITIL

Los acuerdos de nivel de servicio (SLA) son una práctica recomendada de ITIL, ya que recogen las promesas hechas a un cliente o con respecto a un producto. Esto puede ayudar a reducir la confusión y las quejas recibidas.

Optimiza los procesos con DevOps e ITIL

ITIL es la biblia de los procesos de TI. Surgió hace mucho tiempo y ha ido evolucionando para adaptarse a las necesidades cambiantes del sector.

Cuando te plantees tus propios procesos, piensa que no es necesario que reinventes la rueda, y que con ITIL tienes un punto de partida de eficacia demostrada.

Y si puedes añadir mejoras de DevOps, como los análisis retrospectivos sin acusaciones, la automatización o los enfoques más colaborativos, podrás perfeccionar los procesos de ITIL aún más.

Casos de uso de DevOps e ITIL

Como saben bien los mejores equipos, TI necesita elementos tanto de ITIL como de DevOps.

DevOps es mucho más que un desarrollo automatizado: es la cultura de la colaboración y de no buscar culpables, y una práctica que ofrece a los equipos el espacio necesario para que puedan dar lo mejor de sí en colaboración con los demás, en lugar de trabajar en grupos aislados y objetivos contrapuestos.

Del mismo modo, ITIL es mucho más que documentación: no tiene que ralentizar a los equipos ni crear problemas burocráticos innecesarios, y cuenta con prácticas básicas sólidas y probadas que, si se aplican de forma ágil, pueden simplificar la canalización de TI en lugar de obstruirla.