Habilidades IT Ops en un entorno de DevOps

Digamos que ha decidido, al menos en teoría, ayudar a llevar a su organización a una posición de DevOps. Ha leído acerca de algunas de las capacidades de alto nivel que usted, como Operador, debe proporcionar a la organización.

¿Cómo lo hace?

En una palabra, “pegamento”.

Lo diré de nuevo: DevOps es una filosofía. La contabilidad sigue siendo un buen ejemplo. La industria de la contabilidad está de acuerdo, más o menos, en lo que constituye una buena contabilidad, y de ahí es de donde provienen los PCGA. Del mismo modo, la industria de DevOps está definiendo lentamente de que se trata un “DevOps bueno”

Pero cada organización lo hace a su manera. Observe cómo cada organización maneja su contabilidad, en detalle, y encontrará un montón de diferencias con otras organizaciones. Tal vez los auditores trabajen de formas diferentes, o tal vez un rol de trabajo diferente es responsable de diferentes funciones de contabilidad. Algunas empresas necesitan una contabilidad bastante simple, mientras que otros necesitan una contabilidad increíblemente compleja que exige cientos de personas que trabajan las veinticuatro horas del día. Aunque todos ellos operan con los mismos principios, sus implementaciones varían ampliamente.

Así es con DevOps.

En una organización pequeña, la contabilidad puede ser lo suficientemente simple como para que las herramientas disponibles en el mercado, como Quickbooks, sean suficientes. En ese tamaño de una organización, DevOps ni siquiera podría existir, porque una empresa de ese tamaño simplemente podría no hacer ningún “dev” para empezar. En una empresa masiva y multidepartamental, la contabilidad podría incluir herramientas “disponibles” que requieren meses y meses de personalización y ajustes. Del mismo modo, DevOps en esa misma organización podría implicar herramientas personalizadas que utilizan bloques genéricos de construcción … y un montón de pegamento personalizado.

Proporcionar la infraestructura operacional para una organización de DevOps puede ser hacking en su mejor momento. Sí, usted encontrará un montón de productos y tecnologías disponibles en el mercado … pero muchos de ellos sólo le llevarán hasta cierto punto en las metas de su organización. Después de eso, tendrá que hacer mucho de personalización, y poco de “pegado” de herramientas diferentes clases, además de algo de “hacking” alrededor para juntar las piezas. Probablemente siempre será así, así como todavía es el caso de nuevos despliegues de herramientas de contabilidad que por lo general toman meses y meses. Nada fuera de una plataforma podrá cubrir todas las necesidades de cada organización, por lo que simplemente tendrá que estar preparado para hacer algo de personalización, algo de hacking y un poco de pegado.

Con eso en mente, ¿cuáles son las habilidades adecuadas que se deben tener?

• Capacidad de aprender rápidamente. Tendrá que dominar nuevos productos y tecnologías sobre la marcha.
• Creatividad. Tendrá que pensar en soluciones inteligentes para evitar obstáculos. No espere que todo “funcione” - no lo hará.
• Conocimiento profundo de su plataforma(s). Ya sea que esté trabajando en Microsoft Windows, una distribución de Linux o alguna otra plataforma, necesita conocer profundamente cómo funciona, porque va a interactuar con ella a muy bajo nivel.
• Scripting. Va a necesitar ser fluido en lenguajes de programación de sistemas (“scripting”) usados en su plataforma, porque ese es el “pegamento” que usará para adherir diferentes tecnologías en una solución coherente y personalizada.

Este material de DevOps no es para principiantes, ni para débiles de corazón. Es por esto que, en mi propia creencia personal, las empresas crean títulos de trabajo como “DevOps Engineer”. La mayoría de la comunidad de DevOps con bastante razón se asusta por títulos de trabajo como ese, porque a menudo son una demostración de que alguien en la organización no lo entiende. DevOps no es un rol de trabajo. Sin embargo, en una organización que practica DevOps, hay ciertamente algunas habilidades que será muy práctico contar con ellas, especialmente en el lado de Operaciones. Alguien que posea esas habilidades podría ser llamado “Ingeniero de DevOps”, que es quizás menos engorroso que “Una persona de TI que sabe lo suficiente para pegar todos esos bits de tal manera que podamos obtener las capacidades de DevOps que necesitamos”. Eso sería una gran tarjeta de presentación. “DevOps Engineer” es probablemente también un título menos vergonzoso para los compañeros de trabajo que “El Chico listo de IT que necesitamos”, que al final suele ser el caso.

La gente de IT Ops que trabaja para proporcionar las capacidades compatibles con DevOps es a menudo la gente más experimentada y más inteligente del equipo. Tienen más experiencia y conocimiento, y son a menudo los más ansiosos de hacer frente a este desafío.

Por cierto, fíjese cómo lo expresé. “… trabajar para proporcionar las capacidades compatibles con DevOps …” fue una frase deliberada. Una organización que practica DevOps necesita capacidades específicas, y la parte de Operaciones proporciona algunas de ellas, en estrecha colaboración con el lado Dev. Pero esto no significa que usted vaya a tener un “Departamento de DevOps”, eso no tiene sentido. “DevOps Engineer” como un título de trabajo es sólo legítimo si significa “Ingeniero que ayuda a proporcionar nuestras capacidades relacionadas con DevOps”. DevOps no es algo que simplemente se haga. Es algo en lo que usted cree y que a su vez le impulsa a hacer las cosas. Si usted cree en DevOps, su organización necesitara comportarse de cierta manera, y necesitara ciertas herramientas para apoyar esos comportamientos.

También hay un conjunto de nuevas habilidades de desarrollo que necesitan ser introducidas en un entorno DevOps. Los desarrolladores tienen que centrarse más en que el código se pueda ser desplegado, supervisado y administrado de una manera centrada en DevOps. Por ejemplo, en la mayoría de los entornos basados en Windows, los desarrolladores suelen utilizar herramientas incluidas en Visual Studio para crear paquetes de Windows Installer. Esos paquetes no siempre han sido fáciles de desplegar de forma automatizada, porque pueden haber requerido (o se creían necesarios) privilegios de administrador u otros elementos que simplemente hicieron que el despliegue del código fuera difícil e incluso peligroso. Para “hacer” DevOps eso tiene que cambiar. Operaciones debe proporcionar a desarrollo la capacidad de desplegar el código de forma transparente en ambientes de producción, pero desarrollo necesita escribir código que admita ese modelo. La carga recae en ambos grupos, como un equipo combinado, no sólo en Operaciones.

Planificar para el fracaso

“Espera un minuto,” puedo oírte diciendo, “!desplegar el nuevo código directo en producción es lo que causa todos los problemas!”

De acuerdo. Cualquier tipo de cambio tiene el potencial de crear problemas. El punto de DevOps - y más particularmente el papel de Operaciones en DevOps - es crear un entorno donde se puede fallar rápidamente, y arreglar con la misma rapidez (gracias a Chris Hunt por eso). Si DevOps significa desplegar constantemente pequeños pedacitos de código, entonces debe estar preparado para - en el lenguaje de Facebook - “moverse rápido y romper las cosas”. Con el tiempo algún despliegue va a ser problemático, por lo tanto el papel de Operaciones no es ralentizar las cosas para evitar el problema, sino más bien golpear el problema duro y rápido. La virtualización, como un ejemplo, nos da la capacidad de “revertir” rápidamente entornos operativos enteros a un “buen estado conocido”, haciendo que la perspectiva del fracaso sea un poco menos aterradora. Planificar para el fracaso, en lugar de tratar de evitar el fracaso por completo.

Pregúntese si usted es el tipo de persona que rutinariamente planea fracasar. Por ejemplo, en cada vuelo de avión que tomo, tengo un juego de ropa de repuesto en mi equipaje de mano, aunque sea sólo mi bolsa para la computadora. Tengo un pequeño desodorante, porque es un artículo no incluido en los paquetes de amenidades de las aerolíneas. Supongo que habrá un fracaso en el viaje, y tengo planes sencillos para mitigar ese fracaso. Sin embargo, pocas personas toman estos sencillos pasos, y cuando el fracaso ocurre, se enojan, estresan, se sienten incómodos, incluso cuando las causas del fracaso están completamente fuera su control, como el clima por ejemplo. Planeo esperas más largas que la mayoría de la gente - normalmente 2 horas en cada aeropuerto de cada país - y con frecuencia soy capaz de evitar un fallo en mi viaje debido a ese margen adicional.

En un entorno DevOps, tiene que aceptar que se producirá un error. Su esfuerzo debe ir menos en la prevención de ese fracaso - especialmente poniendo “puertas” que consumen tiempo como una pared entre los codificadores y los usuarios - y en su lugar poner el esfuerzo en poder iterar y recuperarse rápidamente en caso de ser necesario. En un verdadero equipo de DevOps, cuando en una liberación se encuentra un bug no significa volver a la última copia estable conocida. El verdadero significado debe ser poder hacer una nueva liberación con las correcciones mucho más rápido. Eso es avanzar en lugar de retroceder, y tener la capacidad de hacerlo es el sello principal de una organización preparada para DevOps.