WebOps


Ayer asistí a otra clase de skillshare, Web Operations, ofrecida por Alexis Lê-Quôc cofundador de Datadog. Las operaciones Web son las que se aseguran que el acceso al producto sea permanente. Generalmente el ciclo de integración continua entrega pequeños releases en cada iteración pero una vez entregadas, ¿qué pasa si algo falla?

El ciclo propuesto por Alexis incluye nuevas fases complementarias que promueven la reacción rápida y la gestión sencilla de dichos incidentes:

Medir

Se almacenan los cuatro datos básicos: cpu, memoria, acceso a disco, tráfico de red. Herramientas:

  • Ganglia: Incluye interfaz web, gráficos que se pueden descomponer, integración con Nagios y soporte para Grid. También hay modulos específicos para el kernel de Linux.
  • Collectd: No genera gráficos pero tiene cerca de 90 plugins para diferentes operaciones esta escrito en C para reducir el consumo de recursos sobre la máquina monitoreada.

Log

Los eventos de log deben tener significado, es decir, deben poder ser analizables respecto al tiempo sin producir Terabytes de mensajes basura. Creo que es importante incluir el identificador del hilo dentro del formato de logging. También es una buena idea documentar un estándar de logging (tipo, forma, datos incluidos) para el equipo de desarrollo, eso hace que luego se pueda obtener información a partir de los archivos de log más fácilmente. Cada lenguaje tiene sus herramientas de logging, en java me gusta más logback en lugar de log4j.

Monitorear

Para monitorear los cambios en las medidas o los eventos que se registran en log existen alternativas como Graphite -En este post muestran como usarlo desde java- y ERMA. La idea es definir métricas que sean fáciles de comprender y que tengan en cuenta la forma general en la que se comporta la aplicación, por ejemplo no solo revisar los datos instantáneos sino usar derivadas o integrales para obtener información más cercana y menos alarmante.

Alertar

Estas herramientas deben notificar al equipo en caso de que las métricas muestren que hay cambios importantes -aka se esta incendiando el barco-. Una nota interesante es que si no se tiene planeado hacer algo en caso de que salte cierto tipo de alerta es mejor borrar la alerta porque de lo contrario el equipo deja de prestarle atención a TODAS las alertas, así que se pierde la idea de que el producto esta en riesgo y se asume que ese es el estado natural de las cosas.

El vetusto Nagios (estándar de la industria) tiene un fork interesante, Icinga que compite en todos los aspectos y parece estar más abierto a los aportes de la comunidad.

Corregir / Escalar

Siempre que una alerta se presenta un humano debe intervenir, la idea es tener un contacto primario 7*24 y uno secundario en caso de que no responda el primario (con una espera de unos 15-20 mins), Alexis sugiere rotar la responsabilidad del contacto entre los miembros del equipo. Otro consejo muy razonable es tratar de que los perfiles del equipo sean desarrollador / operador de sistema para que las personas vean como se “divierte” alguien cuando el sistema se derrumba a las 2 am además de generar conciencia respecto a la calidad de las entregas.

En caso de no poder solucionar el problema es necesario escalarlo, para ello es importante poder contactar al responsable (generalmente al desarrollador en cabeza del equipo) mediante el bug tracker o directamente.

Investigar

Una vez se pasa la emergencia debe venir una investigación (por lo general en los sistemas en los que he trabajado se termina con la corrección) para determinar no solo el origen del problema sino las condiciones que lo causaron y las implicaciones del arreglo que se hizo.

Para ello es importante revisar en la linea de tiempo antes de que el sistema se degradó por completo, hay que tener cuidado con la hora del sistema y empezar donde y cuando el problema se detectó inicialmente.

Lilith es una herramienta para revisar archivos de log generados por Commons Logging, Log4j y Logback. Tambien es útil documentar en la wiki del proyecto las evidencias encontradas.

Analizar

Con las evidencias recolectadas se hace un análisis iniciando con la técnica de los 5 ¿porqué?, empezando desde donde se detectó el problema sin detenerse demasiado en los detalles puntuales de % de cpu, memoria usada, etc. La idea es poder reconstruir de forma coherente la cadena de hechos que llevo al sistema a comportarse como lo hizo sin caer en un juego de acusaciones entre los miembros del equipo.

Cambiar

El resultado del análisis debe ser una serie de acciones de cambio (metodológicas, de configuración de herramientas, de afinamiento de métricas, etc) que permitan evitar incidentes similares o que arreglen de forma definitiva el problema, la idea es que no se hagan cambios en caliente sobre el sistema (Ad hoc changes) pero si son necesarios luego del análisis sean documentados e incorporados correctamente.

Finalmente, el consejo es montar las herramientas para hacer el seguimiento del ciclo completo (supongo que también enterar a los miembros del equipo) y lanzar unas pocas métricas básicas que se deben afinar, aumentar o corregir a medida que el producto esta en producción. La presentación de Alexis está disponible en prezi.

Acerca de Nickman

Aunque crítico e Ingeniero (especializado en software), piloto de aeroplano soy (seré).

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s