Downtime. El cancer de un ISP

    Muchos son los aspectos que me preocupan a la hora de gestionar la red. Tal vez, uno de los que mas pánico me produce es el Downtime. Cuando digo downtime me refiero a la caida de algún tramo de la red, sobre todo de la capa de agregación o de la de core. Caida que produce la falta de servicio a mas de un cliente, por lo tanto, responsabilidad directa del operador.
¿Y como puedes evitar el downtime?
    Pues no se si me atrevo a contestar a esta pregunta, casi diría que directamente no puedes evitarlo. Pero una serie de medidas te pueden ayudar a minimizar el tiempo de corte, evitarlo, o en cualquier caso, disminuir su impacto sobre el servicio. Enumeraría estas medidas, de mayor a menor importancia, según mi criterio, de la siguiente manera:

1.- Redundancia.
    Como bien indica el amigo Felipe ( @cuubic)   en la publicación de su blog, la redundáncia es un aspecto imprescindible. Es la primera medida inmediata. Gracias a la redundancia podemos hacer que el fallo sea inapreciable para el cliente final. La redundancia es seguramente el aspecto que mas caro parezca de todos lo que enumeraremos, aunque una caida de varias horas es seguro mas cara que todo el material redundante. Redundar significa tener por duplicado todo. Routers, switches, AP's, técnicos (si, humanos), proveedores, baterías, etc, etc, y un largo etc. TODO.

2.- herramientas de monitorización y solución de fallos.
    Tan importante como la redundancia es la monitorización en tiempo (casi) real. Si detectamos el fallo antes que nadie, lo mas probable es que no afecte a mucha gente, y si somos rápidos, no afectará a nadie.  En cualquier caso, el downtime siempre será menor.  A continuación detallo algunas de las herramientas que utilizo a diario para la detección y solución a fallos.

• SNMP (dude)
• tr069
• Smokeping 
• Ospf, BGP, (R)STP,Stacking, Bonding.
• Scripting

Seguro que hay muchas mas y mejores.

3.-memoria.

    Para mi, tener memoria significa no cometer el mismo fallo mas de una vez (a lo sumo dos). Cada vez que uno de mis técnicos vuelve de una incidencia en el servicio le pregunto por que ha sido provocada. La mayoría de las veces son problemas del cliente (cables mal conectados, ordenadores infectados con multitud de virus, problemas de cobertura con el wifi interno, etc.), pero aun así, siempre intentamos buscar alguna forma de que ese mismo problema no nos vuelva a afectar. En este aspecto, es fundamental el Scripting y el TR-069. Casi siempre son las mejores herramientas. 

4.- información al cliente.

    Aún teniendo todo el cuidado del mundo, y las mejores herramientas, todavía cabe la posibilidad de una caida. Ante esta situación, no hay que esconder la realidad. Mas bién todo lo contrario. Desde mi punto de vista es fundamental mantener informado periodicamente a los usuarios de la caida, y que vean que estamos trabajando en ella. Uno de mis proveedores, ante una caida del servicio, me avisa por SMS cada 30 minutos, y me indica que siguen trabajando en encontrar una solución. Me gusta que me aporten nueva información en cada SMS, como el tiempo estimado de resolución, o la ubicación de la avería. Sobre todo para que no parezca que es un robot quien envia los SMS. Yo no tengo nada similar en mi red, pero reconozco que me gustaría aplicarlo. Todo llegará.