En mi carrera, he sido desarrollador de software y practicante de ITIL en un rol de operaciones. Por lo tanto, DevOps fue una progresión natural para mí.
Sin embargo, siempre he tenido problemas con el lenguaje altamente especializado que presenta ITIL y por hacer que sea "amigable para el desarrollador" lo suficiente como para no ser un completo desaire para los desarrolladores.
ITIL es un marco de gestión de servicios de TI reconocido internacionalmente que se ha desarrollado durante 30 años como un conjunto de prácticas que tienen un beneficio comprobado para la estabilidad operativa y la madurez de una organización.
¿DevOps es realmente compatible con ITIL, o en esencia necesitamos tomar el espíritu de ITIL y "traducirlo" a un lenguaje que los equipos de desarrollo entiendan mejor:
- Gestión de incidentes y problemas → Defectos, errores o problemas de producción
- Gestión de cambios y versiones → Entrega continua
- Gestión de eventos → Registro, telemetría, instrumentación y alertas
fuente
Respuestas:
En mi opinión, la cultura DevOps viene junto con un cambio de metodología hacia la gestión de procesos ágiles .
ITIL está fuertemente dirigido a un formalismo claro del proceso y los resultados y, por lo tanto, más adaptado a un modelo de cascada .
Esto no significa que ITIL sea incompatible con Devops, pero generalmente serán dos procesos separados con diferentes líneas de tiempo. Quiero decir que la inclusión de un nuevo producto dentro del referencial de ITIL generalmente se retrasará hasta que el producto / aplicación haya sido lanzado en producción por un tiempo, donde se hayan realizado y adaptado los primeros inconvenientes y alguna documentación necesaria para integrar ITIL después de que el producto esté " vivir".
Una de las cosas en ITIL es el diseño del servicio, que se supone que se define antes de cualquier tarea de desarrollo, un proceso ágil revisará / puede revisar el diseño en cada iteración, rompiendo el formalismo necesario en un proceso de ITIL.
El objetivo principal de ITIL es, como usted dijo, proporcionar un marco para garantizar que no se omita nada entre la fase de diseño / concepción y mantenimiento (Build / Run). En una cultura devops, todo el equipo es responsable de todas las fases a largo plazo, de ahí que se reduzca el formalismo.
Eso no significa que tengamos que olvidar a ITIL, los principios básicos son absolutamente buenos y, en mi opinión, deben usarse como una lista de verificación para construir la cartera de pedidos inicial de un producto. Es solo que seguir el principio de ITIL con todo su formalismo va en contra de la meta de reducción de tiempo de un desarrollo de software iterativo rápido y, a veces, ni siquiera es aplicable, ya que hay menos transmisión de información necesaria entre los equipos, ya que las tareas son realizadas por el mismo equipo .
fuente
Estoy certificado por ITIL (aunque ha pasado un tiempo). Estoy de acuerdo con Tensibai: ITIL y DevOps no son incompatibles , pero eso no necesariamente los hace grandes amigos.
Se puede argumentar que los procesos en ITIL deben suceder de alguna manera, especialmente para organizaciones más grandes. La integración exitosa de las prácticas DevOps, donde ITIL ya se practica, requiere una planificación cuidadosa, comunicación y ejecución. Por otra parte, eso es cierto para cualquier transformación DevOps.
Para una transformación "greenfield" en la que ni ITIL ni DevOps estén en su lugar, crearía una combinación de ambos utilizando terminología "mapeada" como usted ha descrito. Mientras todos en la organización estén en la misma página, usando el mismo idioma, ITIL y DevOps pueden agregar valor cuando se combinan.
fuente
Me gustaron las respuestas proporcionadas por el escéptico de TI en un episodio de DevOpsCafe.org. Si lo recuerdo correctamente, su línea de pensamiento es que si realmente entiendes ITIL, hay muy poco conflicto. Que la mayoría de las pautas de ITIL son muy generales y que los conflictos son en gran medida entre algunas implementaciones de ITIL, no detrás de la especificación real.
fuente