Cómo hace el equipo de Operaciones para detener los problemas en sus vías

Traducción del original:
How the Technical Operations team stops problems in their tracks


Cómo hace el equipo de Operaciones para detener los problemas en sus vías

La semana pasada leías sobre como el equipo de operaciones técnicas de la Fundación Wikimedia ("Ops"), gastó centenares o miles de horas de trabajo para refactorizar y automatizar todos los servicios que provee, para prepararse para la migración de datacenter de Enero. Una recompensa de ese trabajo: nuestros sitios no estuvieron caídos tan a menudo, y cuando lo estuvieron, el downtime fue por buenos motivos.

"Otra cosa que ilustra nuestro crecimiento y madurez es nuestro downtime" dice el ingeniero de Operaciones Peter Youngmeister.

"Algo que es menos visible para la gente fuera de Ops es la clase de downtime que tenemos. Por ejemplo, ya no tenemos más el tipo "Oops, solté un cable" o "Ese server la palmó", porque las cosas son mucho más robustas ahora, mucho más redundantes. Un montón de eso es producto del masivo impulso a la automatización por el que pasamos, el cual nos permite crear redudancia mucho más fácilmente, y nos deja ocupar nuestro tiempo, en vez de estar "apagando incendios".

El ingeniero de la Fundación Wikimedia Roan Kattouw añade "o 'el server DB maestro tiene el disco lleno' - esa ocurrió unas pocas veces años atrás, y ya no ocurre más ahora."

Para arreglar las crisis rápidamente, necesitamos monitoreo: herramientas que automáticamente chequeen por problemas y alerten a nuestros ingenieros cuando algo está roto. En los primeros días de nuestros sitios, simplemente confiabamos en que habría algun sysadmin online y disponible en caso de que alguien notara algun problema y se quejara en IRC. Varios años atrás, comenzamos a usar Nagios para monitoreo y asignamos una rotación de "pagers", para decidir a quien despertar primero en caso de crisis.

Nagios corre test automatizados chequeando el comportamiento de nuestro sitio (como "¿Devuelve el puerto 80 un HTTP 301?"), y chequea ciertos números clave para asegurarse que los valores encontrados están dentro de un rango aceptable (por ejemplo, para testear y ver si nos estamos quedando sin memoria). Si un test falla, Nagios envía alarmas vía emails, IRC y SMS.

El monitoreo nos ayuda a manejar la crisis rápido, pero a menudo no ayuda a resolver el problema en sí.

"Nagios es grandioso para decirte cuando las cosas están rotas, y es basura para decirte por qué", explica Peter. "El trabajo que Asher Feldman ha realizado creando perfilado de datos (data profiling), es más útil".

Como lo explica Roan "Perfilado de datos es el acto de generar datos sobre 'Cuanto tiempo ha gastado la gran tarea X en realizar la subtarea Y' La razón para ello es que:

1) Uno de esos pequeños Ys podría en realidad no ser tan pequeño y ser un problema
2) Por la regla de 80-20, para algunos Ys, la optimización tendrá un impacto mayor, así que hace falta encontrarlos.

El perfilado de datos genera conocimiento acerca del comportamiento de nuestros sistemas, así los ingenieros pueden entender mejor como debería estar funcionando el cluster, y ofrece tips para resolver problemas.

Nosotros usamos dos sistemas de perfilado para obtener datos en tiempo-serie: Ganglia a nivel de host, y Graphite a nivel de aplicación. (conseguíte un login al Labs para ver Graphite). En los pasados dos años, configuramos Ganglia para cubrir muchos más datos, y en 2012 empezamos a usar Graphite. A mejores datos, se vuelve más útil para la resolución de problemas, y el Director de Operaciones CT Wook regularmente revisa el dashboard para ir viendo problemas por venir y alertar a su equipo. Esto reduce los downtimes.

Por ejemplo, en una página de Ganglia, previamente solo teníamos acceso a datos de host: espacio libre en disco, carga, etc. Recientemente añadimos datos específicos de Apache, como request por segundo y número de threads idle. Esta información adicional ayuda a los sysadmins en la resolución de problemas. "Uno puede verlo y hacer mejore deducciones que solo 'Oops, el server tiene mucha carga'," explica Peter.

Como la "puppetización", las mejoras en perfilado fueron una inversión del equipo de Operaciones. "Hay un plugin para Ganglia que arma estadísticas de performance de Apache. Me costó horas configurarlo totalmente, Pero, de vuelta, es pensar hacia adelante, una deuda que debemos honrar, en vez de insultarnos a nosotros mismos cuando no esté allí - esa información - cuando la necesitemos. Es un emprendimiento masivo decidir hacer las cosas del Modo Correcto, configurar una plataforma, en vez de hacer millones de cosas de 'una-sola-vez'."

Mientras que la "puppetización", mejora del monitoreo y perfilado, preparaban para la migración de datacenter, el equipo de Operaciones tuvo que diferir otros trabajos no urgentes. "Ops era menos capaz de dar soporte a muchos equipos", dice Peter, "por ejemplo, Recolección de Fondos solo tenía unos cuantos servers y podían hacer con ellos lo que quisieran, a diferencia de cómo es ahora donde Jeff Green (un ing. de operaciones), está trabajando en armar un asombroso sistema, PCI-compliant a tiempo completo. O Análisis era muy independiente/sin respaldo, porque había tan pocas horas/hombre para darles soporte que no estaban siquiera manteniendo el sitio activo..creo que el ensamble del EQIAD (el datacenter de Virginia), es muy demostrativo de la deuda técnica que tenía Ops."

Ahora Peter mira hacia adelante viendo a Wikimedia "instalar más datacenter, dramáticamente más rápido". El equipo de Operaciones está en preparativos para adicionar un datacenter en la costa oeste de Norteamérica. El Site Architech Asher Feldman ve un "arco continuado de refinamiento" en el futuro del equipo, en vez de "desafíos que terminan para ser reemplazados por nuevos desafíos". "Los desafíos en hacer escalar MediaWiki no van a dejar de existir a corto plazo, tampoco la necesidad de modernización incremental de la arquitectura en múltiples niveles". Por ejemplo, Ops necesita continuamente "puppetizar" ciertos servicios; algunos módulos también necesitan manifiestos Puppet tuneados para funcionar, no solo en el site principal, sino también en los Wikimedia Labs.

Podés chequear los objetivos del equipo de Operaciones para 2012-2013 y leer sobre lo que viene a continuación (incluyendo mejoras en búsquedas y seguridad).

Sumana Harihareswara, Engineering Community Manager

Copyright notes: NOLA Hackathon 20 by Ben Hartshorne, under CC-BY-SA 3.0 Unported, from Wikimedia Commons, Eqiadwmf 9045 by Rob Halsell, under CC-BY-SA 3.0 Unported, from Wikimedia Commons