Una de las cosas que no se suelen probar en los proyectos de
desarrollo de software es cómo operan los desarrollos realizados antes
situaciones en las que la red falla (los famosos
micro-cortes de red tan utilizados para justificar el mal
funcionamiento de un software)
Hay proyectos, como el ejercito de monos de netflix
… que sirven para probar estas cosas (hay un mono que se dedica a
hacer putadas en la red para ver si los componentes son tolerantes a
fallos o no y sobre todo si tenemos efecto de bola de
nieve, que es el peor de los problemas cuando diseñas
sistemas complejos).
Teniendo claro que lo mejor sería integrar el ejército de
monos en los sistemas de calidad de zylk, vamos, de momento,
a ser un poco menos ambiciosos y vamos a usar únicamente un conjunto
de comandos de sistema operativo para simular problemas en la red.
Para ello haremos uso del comando netem
desde el que podemos simular caídas de red, latencia variable,
perdidas de paquetes etc… Los comandos base que podemos usar son
>sudo tc qdisc add dev eth0 root netem delay 900ms 10ms distribution normal
Que nos permite añadir un delay a las peticiones de red (eth0) que
corresponde a una distribución
gaussianacon un máximo de delay de 900ms y un mínimo de centrada en el 900 y con una campana de 10 de ancho.
10ms
>sudo tc qdisc add dev eth0 root netem loss 0.1%
Que nos permite simular una perdida de paquetes del 0.1%
Existen comandos equivalentes para forzar la corrupción de
paquetes, duplicidad de los mismos y un montón de cosas más…
La conclusión, una vez que usas este tipo de técnicas para realizar
las QA de los proyectos, es que … Ohhh dios mio!!! (que dirían en
friends) los patrones que usa la gente no suelen ser los correctos y
fallan estrepitosamente ante este tipo de problemas. Además ahora hay
que tener especial cuidado ya que todo se ve como un servicio y un
cliente que se conecta a dicho servicio…. Habrá que
repasar este patrón. Y estar más atento a lo que hace la gente
de netflix que de este tema parece saber mucho mucho mucho… En zylk
ya llevamos algún tiempo usando estas técnicas para probar, en
condiciones adveras, algunos de los proyectos que realizamos.
