Archivo para la categoría 'Web Operations'

Ganado en lugar de mascotas

25/4/2013 5:36 am

Influenciado por la lectura del libro del proyecto Phoenix, que os recomiendo a todos, creo que voy a escribir este articulillo en versión novelada sobre el tema de tratar servidores como ganado en lugar de como mascotas (cattle no pets), a ver qué tal se da.

5532770373_3811034fd7

“Son las 3 de la mañana y el maldito “busca” vuelve a sonar. Puff, ¡menuda semanita llevo!, pienso mientras a tientas busco el maldito cacharro en la mesita de noche para poner fin a sus convulsiones y chillidos. “Webserver15.httpfarm load average ALERT”. Por un instante pienso en volverme a dormir. Un solo nodo cargado y ninguna otra alerta, como por ejemplo retardos en la carga de la página no debería ser un problema, pero… algo en mi interior me lo impide y ¿si es importante?. A mi lado mi mujer murmura algo acerca del maldito zumbido mientras me voy incorporando para llegar a la mesa del despacho donde presiono el botón de inicio del portatil, que tampoco parece feliz de ser despertado en medio de la noche.

Al parecer, un par de procesos se han quedado bloqueados esperando a un recurso compartido que estaba tardando demasiado en responder y eso ha elevado la carga en ese nodo, mientras en todos los demás todo sigue bien. Mando al nodo sospechoso al banquillo modificando la configuración del balanceador para ser examinado mañana más a fondo, y decido terminar la noche durmiendo en el sofá para no molestar en caso de que la rebelión continue. Solucionar el problema me llevó 15 minutos pero ya no puedo dormir en las siguientes horas así que dejo entrar a Oscar, nuestro gato, para que me haga compañía. Mientras acaricio su panza pienso que algunos de nuestros servidores requieren más cuidados que una mascota.

A la mañana siguiente, despues de la reunión de arranque del equipo, me dedico a investigar que le pasó al nodo molesto. Al parecer, una de las modificaciones que hicimos hace varios meses a la granja de servidores web había sido aplicada, pero el recurso no había sido remontado, con lo cuál no había tenido efecto.

¡Maldita sea!, otro copo de nieve (aka snowflake), parece que nuestro proceso de homogeneización no está tan refinado como creíamos. Reinstalar el servidor es un proceso completamente automatizado que tan sólo lleva unos minutos. Una vez que ha vuelto a la vida verifico que el nuevo nodo es exactamente igual que sus compañeros del corral, para a continuación abrir el grifo en el balanceador para que comience a llegarle tráfico de nuevo. Todo funciona a la perfección.

En la mayoría de los casos y con el nivel de redundancia que tenemos es obvio que es un error tratar a cada servidor como una mascota. Debemos de empezar a pensar en ellos más como ganado, y especialmente en diseñar nuestros sistemas para que en caso de error, el procedimiento sea sustituir al enfermo por uno exactamente igual y ya en caso de requerir una intervención especial entonces alertar a uno de los doctores. Una de las ventajas es que todas las gráficas de rendimiento y los logs de los servidores se mantienen en servicios separados, con lo que no estaremos borrando pistas para el analisis post-mortem. Incluso podríamos ponerlo simplemente en cuarentena.

Paso el resto del día poniendo en práctica esta idea de “ganado en lugar de mascotas” en nuestra granja de servidores web reconfigurando el sistema de monitorización para, en caso de detectar un nodo enfermo jugar el combo de cartas: “tiro en la cabeza” y “resurreción de entre los muertos”. En aquellos casos en los que la alerta se repita en breve en el mismo nodo, alertaremos al vaquero de turno. Ahora, para asegurar que el sistema funciona y que lo seguirá haciendo, es hora de soltar al “mono del caos” que introducirá errores en los servidores cada cierto tiempo de forma que el procedimiento se esté verificando constamente.

Los resultados en la granja web han sido muy satisfactorios y hemos decidido empezar a extender el proceso a todos los servidores. De hecho, este evento nos ha hecho replantearnos cómo vamos a hacer el proceso de alerta fuera del horario de oficina, sustituyendo cientos de alertas individuales (cpu alta, sistemas de ficheros lleno, etc) por otras que eliminen la individualidad del asunto (el portal está caido, la búsqueda media es demasiado lenta, etc).

Espero que mi gato Oscar no esté preocupado porque lo sustituya por un corralito lleno de cerdos.”

Cultura devops en REA

5/8/2012 11:41 am

Como muchos sabéis ya, hace algo más de 4 meses que inicié mi aventura en tierras Australianas y comencé a trabajar para REA, grupo que se dedica a la gestión de publicidad online para el mercado inmobiliario, principalmente en Australia, pero con presencia internacional en Italia, Luxemburgo, HongKong, etc…

Deajando aparte el factor aventura, y las ganas de conocer esta parte del mundo, cuando me ofrecieron este trabajo se unieron la oportunidad de trabajar en una compañía que maneja algunos de los portales con más tráfico de Australia con mi interás por dedicarme a las operaciones web a gran escala. Uno de los elementos que más me atrajo fue la cultura de la compañía, que por lo que pude adivinar en las entrevistas, y he verificado postriormente, destaca por una implantación muy alta de metodologías ágiles, equipos de alto rendimiento y gran nivel técnico, mentalidad hacker, mimo por los empleados y una cultura devops muy evolucionada.

Un ejemplo del arraigo de la cultura devops en la empresa es que los dos grupos que celebran reuiones en la zona sobre el tema: “Melbourne devops” e “Infrastructure coders” están siempre sobre poblados de gente de REA, ya sea en el público, como colaboradores o como organizadores. Fuera de Australia, cuando uno de mis compañeros recientemente asistió a Velocity y Devopsdays en Estados Unidos recibió comentarios de admiración sobre el grado de implantación de la cultura devops en la compañía.

Pero después de tanto rollo, ¿cómo es la cultura devops en REA? Podría decirse que en una compañía como esta, en la que los conceptos de agilismo y lean están tan marcados en todos sus estratos, la búsqueda de la eficacia y las mejores prácticas es una evolución constante. Si aplicamos estos elementos al concepto de cómo operamos nuestros servicios nos damos cuenta de que se trata de un viaje que implica un cambio constante. Podemos marcar el comienzo de este viaje hace ya algún tiempo, cuando las operaciones eran ejecutadas de forma centralizada por el equipo de Operaciones Web (dentro del área de IT). Los ya consabidos problemas consecuencia de la separación de Operaciones y Desarrollo, sumados a la desalineación de ambos con los intereses del área de negocio, llevaban a un funcionamiento ineficiente. Operaciones estaba descontento porque no podía solucionar los problemas endémicos, ya que no estaba presente en el proceso de creación y/o mejora de los productos. El equipo de Desarrollo por su parte veía en Operaciones un elemento bloqueante, que no le permitía alcanzar la velocidad demandada por el entorno del negocio, en aras de mantener la estabilidad del entorno. Y todo acaba con las consabidas peleas de perros y gatos, tan ilustradas en cualquier presentación sobre devops.

Los primeros refinamientos del proceso se basaron en empezar a “infiltrar” miembros del equipo de Operaciones en los distintos equipos de Desarrollo, para intentar mejorar la comunicación, y para conseguir que el elemento de operaciones estuviera presente en el día a día del desarrollo y mejora de los servicios. Al parecer el comienzo no fue muy fácil ni agradable y en algunos casos los equipos rechazaban al nuevo miembro, como cuando un cuerpo rechaza un transplante, y también había choques culturales, siendo los “infiltrados” los que no se sentían cómodos en este nuevo ambiente. Su trabajo consistía casi únicamente en realizar pasos a producción de forma manual una y otra vez. Por aquel entonces, había un segundo equipo denominado SPA (Site performance and availability) que se encarga del soporte global de las operaciones, es decir del cuidado de las infraestructuras y gestión de incidencias relacionadas con producción.

Transcurrido algún tiempo comenzaron a hacerse evidentes las ventajas del modelo, gracias al éxito de los equipos que lo habían implementado. Esto dió paso a prácticas que mejoraron el proceso de despliegue y gestión de los servicios mediante la automatización de los mismos y al comienzo de la adopción de un modelo PaaS (Plataforma cómo servicio) cuyo objetivo era la estandarización de los entornos y la simplificación en las operación de los mismos.

Los siguientes pasos en este proceso son la incorporación de la obre la gestión de las operaciones en estos equipos que ahora serán responsables del servicio de forma global incluyendo la creación, mejora y operación del mismo. Este proceso incluye la gestión y resolución de incidencias, ahora los miembros de SPA se han enbebido completamente en los equipos, y el siguiente paso es conseguir que la responsabilidad de solucionar los problemas recaiga en todo el equipo: desarrolladores, calidad, operaciones e incluso los productores y responsables de negocio que poco a poco se han ido incorporando al equipo en su día a día, formando algo parecido a mini startups dentro de la empresa. Por lo que ahora todo el equipo se sienta en la misma zona de la oficina, atiende a las reuniones diarias (standups) y participa en el trabajo cómo uno más. Se acabó esto no lo podemos resolver esto porque X o G no colaboran. Los problemas se priorizan dentro del equipo y se decide que demandas se deben atajar primero y el diseño de nuevas funcionalidades siempre cuenta con la idea de cómo vamos a operar el servicio cuando este esté en producción.

Respecto a la tecnología usada dentro de los equpos relacionada con devops podríamos describirlo cómo que cada equipo tiene libertad para utilizar los elementos que le sean más productivos para conseguir sus objetivos, es la ventaja de tener el control y la responsabilidad de extremo a extremo de los elementos, y en muchos casos esta apoyada en la estandarización que provee el uso de una plataforma común, de la que ya hablaré en un articulo posterior. Por tanto nos encontramos elementos muy distintos cómo puppet o chef para la gestión de configuración, el uso de rpms para la distribución de nuestras aplicaciones, nagios, newrelic, gomez y graphite para monitorización y métricas entre otros muchos.

La implantación de la cultura devops en una compañía no puede medirse cómo blanco o negro, más bien se trata de un gris que va cambiando de tono ya que está en constante evolución persiguiendo el fin último de mejorar la forma en que ofrecemos nuestros servicios y aumentamos el valor para nuestros clientes, así que os mantendré informador de futuras mejoras y la implantación de los planes actuales.