Formación escrita en DevOps
¿Qué problemas tiene en TI sin DevOps?
En un entorno de TI sin DevOps, suele haber conflictos entre los equipos de desarrollo y operaciones. El aseguramiento de la calidad de principio a fin de las funcionalidades y ventajas que pide el cliente empieza cuando desarrollo ya trabaja en un proyecto totalmente distinto. Las auditorías de seguridad de la información y preparación para producción se hacen el día anterior al despliegue previsto. Resolver problemas de software en esa etapa crítica, sobre todo fallos de diseño y seguridad que se deberían haber detectado y corregido hace 8 meses, pone en riesgo tanto la continuidad de TI como la del negocio. Un equipo de desarrollo agotado, uno de operaciones poco colaborativo, áreas aisladas de pruebas y seguridad, responsables de proyecto y producto exigentes y desesperados, directivos enfadados y clientes y partes interesadas de TI frustrados aportan poco valor.
Demasiados traspasos de actividades y dependencias en todas las direcciones, junto con innumerables tareas manuales, descoordinadas y poco transparentes, son parte de un día cualquiera en el departamento de TI.
Aunque se tarda mucho en sacar adelante cualquier tarea, no hay una opción mejor, al menos por ahora, y sabe que todavía necesita este trabajo para ganarse la vida.
Por fin llega el gran día. Tras un despliegue caótico y problemático que ha provocado un tiempo de inactividad considerable en el negocio, se pregunta si ha dejado de funcionar algo que ya estaba en producción. Le preocupa la falta de claridad y de pruebas concretas sobre lo que ocurrió y qué partes de sus sistemas de producción se vieron afectadas.
Aun así, ya empiezan a celebrar la puesta en producción en los pasillos de la gran sala de TI. También es hora de tomar algo y recuperarse mentalmente de la dura noche en vela. De todos modos, lo que estropeó anoche en producción será problema de otra persona. No es para tanto…
Quizá se pregunte cómo es posible que estos proyectos tan difíciles se terminen de algún modo pese a haber estado en una situación desesperada. La respuesta está en el teorema del mono infinito. En pocas palabras, el teorema dice que un mono que pulse al azar las teclas de una máquina de escribir durante un tiempo infinito acabará escribiendo un texto determinado, como las obras completas de William Shakespeare. No es broma.
Del mismo modo, aunque sea imposible prever cuándo se acabará el trabajo, si su equipo de TI retrasa lo suficiente un proyecto para ganar tiempo, seguro que acaba entregándolo.
Conflicto crónico entre desarrollo y operaciones
Entre las muchas responsabilidades clave de su organización de TI destacan dos misiones:
- Su equipo de desarrollo debe entregar con rapidez para responder a las demandas cambiantes de sus clientes y del mercado al que atiende su empresa.
- Su equipo de operaciones debe garantizar un servicio estable, predecible, seguro y continuo para atender a sus clientes y al mercado.
Con esta estructura, los equipos de desarrollo y operaciones tienen misiones y motivaciones contrapuestas. El conflicto reduce la productividad, la calidad del servicio, la satisfacción de los clientes y los resultados de TI y, en última instancia, el rendimiento de todo el negocio.
Ahora tiene deuda técnica
Apagar incendios constantemente, aplicar soluciones provisionales y realizar tareas imprevistas para salvar el día solo acumula más deuda técnica. Esto afecta tanto al rendimiento de desarrollo y operaciones como al de arquitectura, seguridad de la información, pruebas, gestión de productos, gestión de versiones y las partes interesadas del negocio.
La deuda técnica se parece a la financiera. Cuanta más deuda financiera tenga, menos opciones tendrá para alcanzar sus objetivos. Al final, se vuelve casi imposible tomar la decisión correcta para conseguir los resultados deseados y es más probable que se endeude aún más.
Con la deuda técnica ocurre lo mismo. Cuanta más tenga, menos opciones tendrá de crear y entregar soluciones adecuadas. Acabará acumulando soluciones provisionales sobre otras, como castillos de naipes unos encima de otros. Ya sabe que es cuestión de tiempo que se derrumben.
Su negocio depende de los ingresos de sus sistemas más frágiles
Un hecho poco sorprendente pero preocupante es que los sistemas más críticos y que generan ingresos son también los más propensos a errores, fallos e interrupciones.
Estos sistemas suelen estar en el centro del negocio y difícilmente asistirá a una reunión en la que no salgan a relucir. Son los sistemas críticos a los que afectan casi todos los proyectos. Por su importancia, exigen trabajo continuo, cambios urgentes y correcciones no previstas. Aun así, siguen generando incidentes de prioridad 1.
Si estropea algo, hace promesas aún mayores
Como su organización de TI incumple promesas y frustra a las partes interesadas continuamente, estas se vuelven más exigentes para compensar lo ocurrido. Usted y sus responsables a menudo solo pueden decir «¿por qué no?», salvo que tengan una oferta de trabajo mejor a la vista.
Entonces se encarga a desarrollo y entrega un reto mayor de lo habitual. Como sus sistemas críticos y la arquitectura de TI ni siquiera se acercan a cubrir los requisitos en los plazos «urgentes» fijados, empieza a diseñar soluciones provisionales nuevas sobre las que ya tenía.
El trabajo deja de ser divertido
Al final todo el mundo está un poco más ocupado. No le queda ni una hora libre en el calendario para trabajar sin interrupciones en las tareas para las que le contrataron y le pagan. Le llueven correos, así que aprovecha los ratos poco productivos de las reuniones para revisar y limpiar una bandeja llena de mensajes, en su mayoría confusos e inútiles. Se pregunta por qué su organización no ofrece formación obligatoria sobre cómo usar el correo y redactar mensajes.
Para seguir trabajando, suele depender de otros equipos. Sin embargo, el otro equipo ni siquiera ha considerado lo que pidió hace un par de semanas porque acaba de empezar su proyecto «Horizon 2400» mientras resolvía 9 incidentes de prioridad 1 causados por la fragilidad de sus aplicaciones.
Empieza a impacientarse porque necesita que la persona que actúa como único contacto en el otro equipo le responda para poder seguir trabajando.
No pudo contenerse y envió otro correo para recordar la solicitud. Esta vez puso en copia a la jefa de su contacto y pensó que debería haberlo hecho desde el principio.
En cuestión de segundos aparecieron dos respuestas automáticas en la pantalla. Su contacto estará en los talleres de «Horizon 2400» hasta finales de semana. Su jefa está hoy enferma en casa.
CONCLUSIÓN
En este capítulo hemos explicado los retos a los que se enfrentan la mayoría de las empresas y profesionales de TI, así como las espirales descendentes y los círculos viciosos que viven casi todas las empresas y profesionales.
Gartner estima que las empresas de todo el mundo malgastan unos 600 mil millones de USD al año en mantenimiento de TI no presupuestado ni programado para mantener operativos los sistemas que generan ingresos. Para hacerse una idea, escrito en cifras: $600,000,000,000.-
Como habrá visto, cuesta entender tal nivel de desperdicio en una profesión tan exigente intelectualmente como TI.
Es un reto que merece la pena abordar. DevOps tiene algunas respuestas para algunas empresas y quizá también para la suya, siempre que esté dispuesta a experimentar, aprender y adaptarse.
