NetOps necesita defensores, no adversarios

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Estás a punto de hincarle el diente a una comida que llevas todo el día esperando cuando te das cuenta de que está poco hecha. Frustrado, hablas con dureza al camarero y puede que incluso le dejes menos propina. Él lo acepta con una sonrisa, aunque no sea culpa suya. Al fin y al cabo, no ha preparado tu comida. Pero es tu enlace con la cocina y, en última instancia, es quien paga las consecuencias de los fallos que se producen fuera de tu vista.

Ya sea el camarero de un restaurante o un representante de atención al cliente de <inserte aquí el servicio>, por lo general es la persona que trata directamente con usted quien acaba soportando el peso de su angustia, frustración o enfado cuando algo sale mal.

Eso también ocurre en el centro de datos.

A medida que el departamento de TI avanza en su transformación digital con el objetivo de lograr una mayor optimización y rapidez, los equipos de NetOps son quienes tienen más probabilidades de interactuar con los «clientes» internos y, por tanto, quienes soportan el grueso de las quejas de los usuarios descontentos cuando los procesos no avanzan con la rapidez deseada.

Es importante reconocer que no siempre son las «NetOps» las que obstaculizan el despliegue de la última novedad, aplicación o servicio. Los impedimentos para avanzar con rapidez suelen deberse a que no se adoptan todas las premisas de DevOps cuando las organizaciones tratan de transformar las operaciones de TI.

¿Estás aplicando DevOps o simplemente automatizando?

CAMS es el método más utilizado para difundir los principios fundamentales de DevOps. CAMS corresponde a: cultura, automatización, medición y colaboración.

De estos cuatro aspectos, la automatización es el que más probablemente se adopte con entusiasmo. Son los otros tres los que suelen quedar relegados o ser directamente ignorados en el afán por agilizar la prestación de servicios de TI.

Cabe destacar especialmente que los tres conceptos que suelen ignorarse están interrelacionados. Es difícil cambiar la cultura cuando los equipos siguen aislados por funciones y centrados en métricas que no importan a otros equipos. Trabajamos para alcanzar aquello por lo que se nos evalúa. Si se nos evalúa por la disponibilidad de la red, eso es en lo que nos centraremos, aunque nuestros homólogos de operaciones estén intentando mejorar la disponibilidad de la aplicación.

A este respecto, quizá recuerde el estudio sobre el estado de la automatización de redes en el que unimos fuerzas con Red Hat para adentrarnos en el complejo mundo de DevOps, NetOps y la automatización. En él, constatamos una gran disparidad entre las métricas (mediciones) que buscaban los equipos de NetOps y las que interesaban a los equipos de desarrollo y operaciones.

Casi tres cuartas partes (el 73 %) de los profesionales de NetOps señalaron la «disponibilidad de la red» como su principal métrica. En cambio, el 59 % de los profesionales de desarrollo y operaciones indicaron que su principal métrica era la «disponibilidad de las aplicaciones». Por otro lado, el porcentaje de profesionales de desarrollo y operaciones evaluados según la frecuencia de los despliegues (30 %) es casi el doble que el de los profesionales de NetOps (16 %) y Seguridad (17 %).

¿Por qué es importante esta disparidad? Si mi principal objetivo es mantener la red disponible, dedicaré mi tiempo a centrarme en ella. La instrumentación y la monitorización —esta última, fundamental para el componente de intercambio de DevOps— se centrarán primero en la red y, quizá después, en la aplicación. Si queda tiempo. Nadie tiene tiempo para la seguridad y, de todos modos, a nadie se le evalúa por ella. De hecho, la principal métrica citada en materia de seguridad fue <redoble de tambores, por favor> la «disponibilidad de la red»: el 59 % de los profesionales de la seguridad son evaluados según esta métrica.

Las personas, que siguen siendo el eje central de TI y conforman los equipos que deben implementar la automatización y la orquestación, no siempre comparten los mismos objetivos. Uno de los factores que contribuyen a esta falta de alineación es el aislamiento persistente de los distintos ámbitos operativos. Los grupos de NetOps y Seguridad son más propensos a trabajar como equipos de «función única». NetOps se ocupa de la red. ¿Seguridad? De la seguridad. ¿Operaciones? De las operaciones de sistemas.

Pero la cosa va aún más allá de eso. Porque dentro de los GRANDES silos hay otros aún más pequeños. Como una matrioshka —una muñeca rusa—, dentro de NetOps hay muchos equipos diferentes por los que debe pasar esa petición aparentemente sencilla de «nuevo sitio» antes de completarse. Para poder atenderla, es necesario aprovisionar e incorporar numerosos servicios de infraestructura y aplicaciones. Un nuevo sitio no solo requiere los recursos informáticos y de red necesarios para alojarlo, sino también muchos otros elementos: un servidor web y su almacenamiento, control de acceso, certificados y gestión de claves, balanceo de carga, reglas de cortafuegos... La lista de silos internos de TI que debe atravesar esta petición «sencilla» es interminable.

Y si uno de esos silos dentro del silo de NetOps no está automatizado, el proceso se detiene en seco. El tiempo necesario para atender una solicitud de este tipo puede prolongarse días, si no semanas.

Desde fuera —para quien realiza la solicitud—, parece que NetOps simplemente no está haciendo bien su trabajo. Es la «contraparte», el «enlace», el «socio de TI» quien soporta la frustración de quienes exigen saber por qué se tarda tanto en atender lo que parece una solicitud sencilla. Culpamos a NetOps del mismo modo que los neófitos en tecnología culpan al proveedor local por los fallos de Internet, cuando el problema es en realidad un router situado en lo más profundo de la red troncal y gestionado por otro proveedor.

Sé un defensor, no un adversario

El cambio hacia unas TI más colaborativas y transparentes sigue siendo apenas un punto en el horizonte para muchas organizaciones. Aunque algunos grupos de TI reconocen esta necesidad y adoptan los cambios necesarios, no todos lo hacen. En los cinco años que llevamos investigando los servicios de aplicaciones, no hemos visto que «DevOps» alcance el nivel de importancia estratégica necesario para impulsar realmente los cambios culturales y organizativos que permitan lograr la velocidad que la empresa desea y necesita. En su lugar, las organizaciones han adoptado la automatización y se han olvidado de los otros tres componentes fundamentales de DevOps.

Resulta preocupante que no se reconozca que la incorporación del movimiento DevOps a TI va mucho más allá de la mera automatización. Supone no entender que, para ganar velocidad, hay que automatizar el flujo de trabajo, y que este atraviesa prácticamente todos los ámbitos operativos y silos de TI. Esto significa que todas las partes implicadas deben avanzar hacia la automatización; de lo contrario, no se alcanzarán la velocidad y la frecuencia de despliegue deseadas. No basta con adoptar la automatización y esperar que funcione. Cuando la automatización debe traspasar las fronteras entre grupos aislados, no se tendrá éxito sin un cambio cultural significativo.

El cambio necesario tiene que venir desde arriba, especialmente el cambio organizativo. No podemos reorganizarnos por nuestra cuenta, ¿verdad? Tampoco podemos cambiar la prioridad de nuestros objetivos y utilizar un conjunto de métricas completamente distinto, ¿no?

No podemos hacerlo y, a menos que informemos y convenzamos a quienes sí pueden realizar los cambios necesarios, nos veremos atrapados en procesos manuales en medio de un flujo de trabajo que, por lo demás, está automatizado.

Así que dejemos de utilizar a NetOps como chivo expiatorio y reconozcamos que sus integrantes también pueden sentirse frustrados. En su lugar, recordemos a quienes toman las decisiones la necesidad de reevaluar las estructuras organizativas y cambiar las prioridades de las métricas para lograr una mejor alineación con el negocio y con el resto del proceso continuo.

Gritar al personal de NetOps que está en primera línea puede parecer satisfactorio, pero en realidad no cambia la situación que provocó el enfado en primer lugar. Y, si nada cambia, el pipeline no va a ir más rápido.

Sé el defensor de NetOps, no su adversario. Necesitan toda la ayuda posible.

Sobre el autor

Lori Mac VittieIngeniero distinguido y evangelista jefe | F5

Lori MacVittie es ingeniera distinguida y evangelista jefe en la Oficina del CTO de F5, y cuenta con una amplia experiencia en entrega de aplicaciones, estrategia de automatización e infraestructura. Es conocida por convertir la complejidad en claridad, ya sea definiendo mecanismos de protección para agentes de IA, analizando arquitecturas multinube frágiles o explorando los límites de los sistemas escalables. Aporta más de treinta años de experiencia en el sector en desarrollo de aplicaciones, arquitectura de TI y operaciones de redes y sistemas. Antes de incorporarse a F5, fue una galardonada editora de tecnología. MacVittie posee un máster en Informática y es una autora prolífica cuyas publicaciones abarcan la seguridad, la nube y la arquitectura empresarial. También es una apasionada de los juegos de mesa y los videojuegos, y expresa sin complejos sus firmes opiniones sobre el queso.

Más artículos de Lori Mac Vittie