NetOps necesita defensores y no adversarios
Estás listo para disfrutar de una comida que has esperado todo el día cuando notas que está poco cocida. Frustrado, le hablas con dureza al camarero y quizás incluso le reduces la propina. Lo toman con una sonrisa aunque no sea su culpa. Después de todo, ellos no prepararon tu comida. Pero ellos son su interfaz con la cocina y, en última instancia, son ellos quienes pagan el precio de los fallos que ocurren fuera de la vista.
Ya sea el camarero de un restaurante o un representante de atención al cliente de <insertar servicio aquí>, generalmente es la persona que interactúa con usted la que termina soportando el peso de su angustia, frustración o enojo cuando algo sale mal.
Esto también es cierto en el centro de datos.
A medida que la TI se transforma digitalmente con el objetivo de lograr una mayor optimización y velocidad, son los equipos de NetOps los que tienen más probabilidades de interactuar con "clientes" internos y, por lo tanto, soportar el peso de los usuarios descontentos cuando los procesos no avanzan tan rápido como se desea.
Es importante reconocer que no siempre es "NetOps" el que impide la implementación de la última aplicación/servicio. Los impedimentos para la velocidad a menudo se deben a la falta de adopción de todas las premisas de DevOps a medida que las organizaciones buscan transformar las operaciones de TI.
¿Estás haciendo DevOps o simplemente automatizando?
CAMS es el medio más utilizado para difundir los principios básicos de DevOps. CAMS significa: cultura , automatización , medición y compartición .
De estos cuatro, es más probable que la automatización sea adoptada con entusiasmo. Son los otros tres los que tienden a quedar rezagados o directamente ignorados en la búsqueda por mejorar la velocidad del servicio dentro de TI.
Es de particular interés que los tres conceptos comúnmente ignorados estén entrelazados. Es difícil cambiar la cultura cuando los equipos todavía están aislados por función y enfocados en métricas que no importan a otros equipos. Trabajamos hacia aquello por lo cual somos evaluados. Si nos medimos por el tiempo de actividad de la red, en eso es en lo que nos centraremos, incluso si nuestros homólogos en operaciones están intentando mejorar el tiempo de actividad de las aplicação .
Es decir, quizás recuerdes la investigación sobre el estado de la automatización de la red en la que unimos fuerzas con Red Hat para sumergirnos en el turbio mundo de DevOps, NetOps y la automatización. En él, encontramos una amplia disparidad entre las métricas (mediciones) buscadas por NetOps y aquellas involucradas en el desarrollo y las operaciones.
Casi tres cuartas partes (73%) de NetOps citaron el "tiempo de actividad de la red" como su métrica principal. Del otro lado, el 59% de los desarrolladores y operadores nos dijeron que el "tiempo de actividad de la aplicação " era su métrica principal. Por el contrario, casi el doble de desarrolladores y operaciones (30%) se miden en función de la frecuencia de implementaciones que NetOps (16%) y Seguridad (17%).
¿Por qué es importante esta disparidad? Si mi objetivo principal es mantener la red disponible, voy a dedicar mi tiempo a concentrarme en la red. La instrumentación y el monitoreo (este último es fundamental para el componente compartido de DevOps) se centrarán primero en la red y luego, quizás, en la aplicação. Si hay tiempo. Nadie tiene tiempo para la seguridad y, de todas formas, nadie se fija en ella. De hecho, la medición número uno citada para la seguridad fue "tiempo de actividad de la red" con un 59 % de profesionales de seguridad evaluados según esta métrica.
Las personas, que todavía están en el corazón de TI y componen los equipos que deben implementar la automatización y la orquestación, no están necesariamente alineadas con los mismos objetivos. Un factor de esta desalineación es el continuo aislamiento de los dominios operativos. Es más probable que los grupos de NetOps y Seguridad trabajen en la estructura de un equipo de "función única". NetOps se preocupa por la red. ¿Seguridad? Seguridad. ¿Operaciones? Operaciones del sistema.
Pero esto va incluso más allá de eso . Porque dentro de los GRANDES silos hay silos aún más pequeños. Al igual que la matrioska (una muñeca rusa), hay muchos equipos diferentes dentro de NetOps sobre los cuales debe fluir esa solicitud aparentemente simple de "nuevo sitio" antes de que se complete. Es necesario aprovisionar e incorporar una gran cantidad de servicios de infraestructura y aplicação antes de que se pueda cumplir con dicha solicitud. Un nuevo sitio implica no sólo los recursos computacionales y de red para alojarlo, sino también un conjunto de otros requisitos. Un servidor web y su almacenamiento. Control de acceso. Certificados y gestión de claves. Equilibrio de carga. Reglas del firewall. La lista de silos internos de TI por los que debe pasar esta solicitud "simple" es interminable.
Y si uno de esos silos dentro del silo NetOps no está automatizado, el proceso se detiene abruptamente. Se pueden agregar días o incluso semanas al tiempo que lleva entregar dicha solicitud.
Desde afuera, al solicitante, le parece que NetOps simplemente no está cumpliendo con su tarea. Es la “contraparte”, el “enlace”, el “socio informático” que soporta la angustia de aquellos que exigen saber por qué se tarda tanto en cumplir una petición aparentemente sencilla. Echamos la culpa a NetOps de la misma manera que los neófitos técnicos culpan al proveedor local por los fallos en Internet cuando el problema es en realidad un enrutador en lo profundo de la red troncal gestionado por algún otro proveedor.
Sea un defensor, no un adversario
El cambio hacia una TI más colaborativa y transparente todavía es apenas un punto en el horizonte para muchas organizaciones. Si bien algunos grupos de TI ven la necesidad y aceptan los cambios necesarios, no todos lo hacen. En los cinco años que llevamos investigando los servicios de aplicação , no hemos visto que "DevOps" alcance el nivel de importancia estratégica necesario para iniciar realmente los cambios culturales y organizacionales necesarios para lograr el tipo de velocidad que la empresa desea (y necesita). En cambio, las organizaciones han adoptado la automatización y se han olvidado de los otros tres componentes críticos para DevOps.
Es preocupante que no se reconozca que el movimiento DevOps en TI implica algo más que mera automatización. Es no reconocer que, para ganar velocidad, es necesario automatizar el proceso, y ese proceso atraviesa prácticamente todos los dominios y silos operativos dentro de TI. Eso significa que todos los afectados tienen que avanzar hacia la automatización, o no podrán lograr la velocidad y la frecuencia de implementaciones que buscan. No se puede simplemente adoptar la automatización y esperar tener éxito. Cuando la automatización debe cruzar líneas entre grupos aislados, fracasará si no se produce un cambio cultural significativo.
El cambio necesario tiene que venir desde arriba. En particular, el cambio organizacional. No podemos reorganizarnos muy bien, ¿verdad? No podemos reordenar nuestras prioridades y utilizar un conjunto de métricas totalmente diferente, ¿verdad?
No podemos, y a menos que eduquemos y convenzamos a quienes pueden hacer los cambios necesarios, nos encontraremos estancados con procesos manuales en medio de un proceso que de otro modo estaría automatizado.
Dejemos entonces de usar a NetOps como chivo expiatorio y reconozcamos que ellos también pueden estar frustrados. En lugar de eso, recuerde a los tomadores de decisiones la necesidad de reevaluar las estructuras organizacionales y reordenar las mediciones para lograr una mejor alineación con el negocio y el resto del flujo de trabajo continuo.
Gritarle a la gente de NetOps que está en primera línea puede resultar satisfactorio, pero en realidad no cambia la situación que generó el enojo en primer lugar. Y sin cambios, el oleoducto no va a avanzar más rápido.
Sea su defensor de NetOps en lugar de su adversario. Necesitan toda la ayuda que puedan conseguir.