Escalado horizontal de personas.

Muchas veces, en las grandes empresas, vemos cómo tenemos que esperar horas, o incluso días, para hacer operaciones que en empresas pequeñas se hacen realmente rápido. Por poner un ejemplo, agregar un acceso a un servicio en una empresa mediana supone esperar a que alguien compile las reglas del firewall una vez al día.

Pero en empresas muy grandes podemos encontrarnos con que esa misma operación solo se realiza un par de veces a la semana. Lo que significa que si necesitamos agregar una regla un jueves por la tarde no vamos a poder tenerla hasta el lunes de la semana siguiente, ¡cuatro días más tarde! Y si hay algún problema puede suponer un retraso de otros tres días. ¡Una semana para habilitar un acceso!

¿Qué es lo que ha pasado para que esa empresa, que al principio funcionaba a una velocidad muy alta, llegue a ese nivel de lentitud?

Nueve mujeres no hacen un bebé en un mes

En un trabajo anterior, yo gestionaba el firewall de una empresa de desarrollo. Su tamaño era de unas 60 personas repartidas en tres sedes en Madrid, Panamá y País Vasco. Tenía relaciones con otras empresas y otros clientes.

El nivel de seguridad se podría considerar medio-bajo porque se permitían accesos inseguros para no penalizar desarrollos y demos de un día. No quiero que te mires las reglas, sino que hagas scroll para que veas la magnitud de la información de la que estamos hablando, así que pincha aquí para ver las reglas.

Agregar una regla ahí podía llegar a ser un problema por varios motivos:

• Lleva un tiempo asegurarse de que los cambios solo afectan a un proyecto.
• Si te equivocas dejas sin red a toda la empresa. Doy fe de ello... varias veces ;-)
• Llega un momento en el que toda la información no te cabe en la cabeza y tienes que elegir entre gastar mucho tiempo en procesarla o ser poco fiable.

El problema es que esto no puede ser hecho por varias personas. Si contratas a 9 personas para revisar unas reglas de firewall, se revisarán 9 veces y, en el mejor de los casos, tardarás exactamente lo mismo, pero multiplicarás tu coste por 9. ¡Nueve técnicos de redes gestionados así rinden lo mismo que uno solo!

En grandes empresas optan por la solución menos mala, que es gastar mucho tiempo para intentar hacer el cambio sin errores y buscar ventanas de tiempo para hacer cambios por si los cometen.

¿Cómo hemos llegado hasta aquí?

Este planteamiento era válido cuando la empresa empezó a crecer y tenía solo uno o dos proyectos. Tener en la cabeza las reglas que necesita un solo proyecto si es viable e incluso sano.

Nos da una visión general de ese proyecto y nos hace sentir parte del mismo. Nos hace más proactivos ante los problemas que vayan surgiendo en nuestro proyecto. El problema ocurre cuando la empresa crece en proyectos y sigue gestionándose como si solo tuviera un solo proyecto. Se trata de un problema un 50% gestión y un 50% de técnico.

Un problema de gestión

Hola, jefe. Tú, como buen gestor que eres, usarás algún sistema de gestión de incidencias que te dará los datos para generar una gráfica como ésta en la que la Y es el tiempo de resolución de una incidencia de red y la X es la fecha del dato:

Al fin y al cabo, cualquier sistema de gestión elegido al azar, por malo que sea, te proporciona una gráfica con esta información o bien los datos para hacerla.

Seguramente también tendrás esas mismas gráficas con un techo que marcará tu SLA, porque si no tienes unos objetivos... ¿para qué te sirve hacer las gráficas?

Un problema técnico

Hola, técnico. Tú, como buen profesional que eres, habrás visto que el tiempo que tardas en agregar una regla es el tiempo que cualquier proveedor de IAAS, elegido al azar, tarda en agregar una regla en miles de clientes de forma simultánea.

Seguro que, o bien lo estás investigando o bien ya sabes cómo lo hacen y lo estás implementando en tu empresa. O si la empresa tiene unos procedimientos muy rígidos, te has ido a otra empresa donde sí tengas el estímulo de que te dejen solucionar los problemas.

Un problema empresarial

Si te digo que en un proyecto necesitamos crear un cluster de ElasticSearch compuesto por:

• Una red independiente.
• Tres servidores en tres zonas de disponibilidad diferentes.
• Una regla de balanceo para todos los servidores en el puerto 9200.
• Agregar los nombres en el dns.
• Reglas de seguridad para permitir el tráfico desde las máquinas que lo necesitan.

¿De cuánto tiempo podríamos estar hablando? ¿Entre una semana y un mes?

Esto es lo que se tarda en el mundo real:

La URL es openstack-beta, porque si Google puede estar durante años en Beta y nadie les dice nada, ¿por qué nosotros no? ;-)

¿Herramientas gráficas para solucionar el problema?

Utilizar una herramienta gráfica no ayuda a solucionar el problema real, solo lo retrasa un poco.

Cuando tienes que hacer un scroll de 50 pantallas para aplicar una regla acabas echando de menos el archivo de texto del que guardabas una copia, sobre el que podías hacer cambios, cagarla, deshacer los cambios y volver a dejar las cosas como estaban.

Pensar a nivel de proyecto nos ayuda a escalar

Si pensamos en varios proyectos que gestionan sus reglas de forma autónoma y asignamos personas a proyectos ¡podremos escalar horizontalmente en personas asignando una o varias personas a cada proyecto!

Ahora, si podemos poner 9 personas a trabajar en paralelo sobre una sola empresa que lleva 9 proyectos, iremos 9 veces más rápido.

Si el proyecto se vuelve demasiado grande se puede partir en varios proyectos. En el fondo se trata de aplicar el paradigma de los microservicios a la gestión de sistemas y redes. Nada nuevo bajo el sol.

Conclusión

La escalabilidad horizontal en los equipos de sistemas y redes es necesaria para que la empresa sea capaz de gestionar más proyectos de una forma efectiva. Pero supone un gran reto técnico y de gestión.