No me gusta hacer análisis post mortem. El pasado domingo tuvimos una incidencia que afectó principalmente a los servicios de DNS, clientes tránsito IP, canal de soporte telefónico, registro de dominios y acceso a paneles.
Fundamentalmente lo más crítico fue (para los clientes) la indisponibilidad para ofrecer resolución DNS. Podréis pensar, ¿pero no está redundado o existe alta disponibilidad sobre estos servicios? La respuesta es sí. ¿Se puede mejorar? Sí. ¿Volverá a suceder? La respuesta es que posiblemente sí. Las causas serán diferentes, el problema será distinto, pero nada es a prueba de fallos, una de las pocas verdades de este mundo es la muerte. Eso sí, sino analizas, actualizas, y no tratas de mejorar el sistema, no minimizas las posibilidades de tener un incidente.
Estos servicios corren en un cluster (tres servidores físicos en este caso) que están conectados a dos conmutadores de red, doble acometida de electricidad, y cada una de las instancias o servicios está en servidores diferentes con un balanceador de tráfico que dirige las peticiones a la instancia correspondiente. En nuestra configuración usamos VPC o virtual port channel (podéis ver el blog de nuestro compañero Eduardo donde explica un poco esto) que nos permite hacer un enlace único de varios físicos en conmutadores diferentes y manejarlos como si fueran uno solo. Ya sabéis: redundancia.
Pues bien, una empresa como la nuestra, tiene que ‘mover’ servicios, máquinas de ubicación o realizar cambios en la red para ello (es algo habitual), y ayer, un error humano, ocasionó un efecto no deseado. Varios de los VPC de uno de nuestros switches quedaron inconsistentes, dejando sin servicio, entre ellos, al cluster que denominamos ‘INFRA’, donde hay servicios críticos como el DNS, entre otros. Cluster que es sólo para servicios «internos» con más de un centenar de instancias o servidores virtuales.
Dicho esto, la incidencia duro unas dos horas, el tiempo de un domingo en el que el equipo se desplazó al centro de datos, se revirtieron los cambios y se recuperaron todos los servicios del cluster afectado en cuestión.
¿Por qué tuvimos que ir al centro de datos?
Uno de los efectos no deseados fue que el ‘encaminamiento’ de varias redes internas que dependen de dos routers virtuales, también estaban en ese cluster, recordad… disponemos de redundancia para cubrir la contingencia de un fallo de hardware y están distribuidos en alta disponibilidad VRRP para no afectar con mantenimientos o actualizaciones en el servicio. Al igual que nuestro acceso VPN para administrar la red. Todo estaba en dicho cluster, por lo que fue de obligado cumplimiento ir al centro de datos, ya que estábamos fuera de toda gestión por esos dos motivos. ‘Encaminamiento’ de redes internas y acceso VPN.
Después de analizar la situación, vamos con los factores, humano y diseño.
Error Humano
El error humano es posible que pudiera haberse evitado con la simple política de un segundo validador o verificador. Oye, voy a aplicar este cambio:
- ¿Lo das o dais por bueno?
- ¿Significa esto que no sabemos hacer lo que estamos haciendo?
Miremos esto desde el punto de vista del ego técnico que todos podemos tener o el exceso de confianza, lo hemos hecho mil veces. Validar con otros un cambio en producción es un mecanismo que nos sirve para volver a repensar lo que estamos haciendo, compartir la responsabilidad, disminuir la posibilidad de fallo o error de lo que vamos a hacer, dado que otro puede ver el error que tu no has visto a la hora de introducir el cambio. Lo ideal sería un «comité de cambios», sé que se pierde agilidad en tener un comité de aprobación de cambios, hay que reunir a la gente para revisar y acordar que se realizará un cambio el día X. ¿Quiere decir que esto no pueda fallar o evitar el fallo? Sinceramente no, pero se reducen mucho las posibilidades a la hora de aplicarlos ya que hemos repasado la tarea con anterioridad con varias personas. Por muy pequeño e insípido que este parezca, puede generar un gran ‘KAOS’.
Estas prácticas, en ocasiones, generan una mella en nuestro ego. Tener que consultar cualquier cosa que queramos hacer no es fácil, incluso llegando a tener el ‘síndrome del impostor’, pero cuando entras en determinadas escalas, creedme que los egos de uno se deben guardar para otras ocasiones o situaciones. Además, sé que después de un error así, uno se siente mal, MUY mal, lo sé por experiencia propia. Aunque seamos una organización productiva y positiva que no castiga el error, muy transparente, y aprendamos de nuestros errores, el entorno que gestionamos es MUY complejo, cada vez se hace más grande y hay cientos de variables que se deben tener en cuenta. Apoyarnos en el equipo no es una debilidad, es una fortaleza. En esta ocasión no fue así, y os pedimos disculpas, ya que la presión que existe en determinadas ocasiones es mala compañera, y había presión en mover ciertos servicios y no es marca de nuestro ADN. Sí que lo son la humildad y valentía para reconocer los errores y la autoexigencia responsable (aunque tampoco se trata de llegar al punto de la frustración, pero creedme que cuando uno es exigente, se llega fácilmente a ella produciendo desmotivación).
Keep Calm, stay focused
El inconformismo y la mejora continua de cómo ofrecemos los servicios a nuestros clientes, el cuidado y detalle en muchas ocasiones, se pierden por las presiones. Son muchos factores que hacen que no tengas el foco adecuado en un momento dado. Y esto quiero que sirva también como ejercicio de reflexión interna, ya que la falta de cuidado al detalle genera errores que pueden ser críticos, trabajamos con información, con datos; uno de los materiales más replicables pero al mismo tiempo volátiles del mundo. Sino hacemos adecuadamente los procesos de calidad y validación del código, teniendo salvaguardas y verificando que los procesos son los adecuados, no hay éxito. Siempre he dicho que el éxito es la consecuencia de un trabajo bien hecho, de disfrutar el camino, de tener la tensión adecuada, que no estrés por sacar antes o más rápido una nueva mejora en el servicio. El éxito es equilibrio y esto también es complicado.
Algunas métricas
Para tener algo más de perspectiva, todos los cambios que hacemos son reflejados en los «commits» de las configuraciones de cada elemento de la red, por seguridad y trazabilidad, este año han sido más de 200. Nuestro indice de efectividad es alto, el equipo es confiable y para mi la operativa es buena. Algunos fueron muy complejos, eso sí, estudiados en equipo. Y mira por dónde, uno tonto te pega una buena bofetada de realidad. Esta vez no fue una actualización de seguridad, hemos sido nosotros y te lo contamos porque somos honestos, en operación hay que ser transparente.
Sí analizamos el servicio DNS los últimos 12 meses, mes a mes. Os comparto las estadísticas, y como veíamos, hemos realizado cientos de actualizaciones tanto en el servicio, como en la red, los cluster, etc… Nuestro entorno está en constante cambio; actualizaciones de seguridad, discos, memorias o renovación de servidores. Cosas que pasan inadvertidas para el cliente final porque está contratando un servicio para no tener que lidiar con ellas, pero al final alguien debe de ocuparse de esta parte física y lógica.
Como ejemplo de la operación y su complejidad es que hace ya un año migramos a NSD en nuestros DNS autoritativos, este proceso empezó a prepararse hace dos años y migramos de forma transparente ni incidentes el servicio, hemos pasado por PowerDNS, por Unbound, activado los servicios IPv6, etc… todo ello sin un estornudo, mucho más complejo sin duda que el cambio que provocó la incidencia.
Diseño, se puede mejorar
Reunión de análisis post mortem, flota en el aire… ¡pongamos un segundo cluster! y cada uno de los routers o instancias de DNS podrían caer en clusters diferentes… es tentador, la verdad. Pero para evitar un fallo como el de ayer, debería haber estado colgando de conmutadores diferentes, además en armarios diferentes, para que la caída del VTP que afectó a este cluster no se hubiera producido. Sin duda este escenario evitará algunos otros, un fallo en las dos acometidas eléctricas en el armario por ejemplo. El cambio que se aplicó en un conjunto de interfaces, si se hubiera aplicado de idéntica forma en VTP en conmutadores diferentes, se habría producido igualmente afectando ambos clusters… por tanto, no parece probable que para solucionar este problema pensemos que dos clusters nos habrían salvado, ya que es un error humano. Lo que sí nos habría dado un poco más de aire es disponer de un segundo acceso de VPN y unas rutas de último recurso para la gestión de ciertas redes internas que no teníamos. Esto habría minimizado el tiempo de recuperación al no tener que desplazarnos al centro de datos. Ya estamos en ello.
Otra cosa es el DNS, igualmente este puede verse afectado por otros elementos de indisponibilidad como pueda ser una caída de tránsito, no sólo un error en el cluster donde reside, hay muchos más factores que pueden afectar a este servicio. Los que estáis pensando: «pues poned un servidor de nombres en otra red». Esto lo trataremos en un futuro artículo aunque para eso DNS ANYCAST es la solución con un mayor nivel de disponibilidad. En otra entrada hablaremos sobre DNS ANYCAST cuando esté disponible, aunque nuestro compañero Eduardo Collado ya ‘plantó la hebra’ hace tiempo y Adrián Almenar está trabajando en esto, sabéis que nos gusta controlar toda la cadena, podríamos subcontratar y usar una marca blanca, no habría nada de malo en ello, pero… aquí quizás es donde si tenemos un poquito de ego, sobre todo porque nos gusta tener el dato bien aterrizado y controlado 😉
Me ha encantado, gracias por compartir.