La caída de gmail, lecciones aprendidas

Ayer, martes 1 de septiembre, se cayó el servicio web de gmail, por un tiempo (no tengo el dato exacto de falla, pero fueron por lo menos dos horas). Yo uso el servicio via web, y tengo varias cuentas, alguna personal y otras por empresa cliente. Y me parece que el servicio de gmail es muy bueno, y la interface de manejo web me resulta útil: el tener “labels” por ejemplo, para manejar los temas, es algo que deberían tener todos los programas de correo desde hace años: basta eso de que un email va en una carpeta. Es como el delicious: cada item interesante, puede clasificar en más de un tag (es idea a explorar, que tengo pendiente desde hace unos años, desde que armé mi sitio, vi delicious, y estudié topic maps y temas relacionados).

Es interesante leer en el blog de gmail, las causas y medidas que se tomaron para subsanar la falla en el servicio, por ejemplo, leo en:

http://gmailblog.blogspot.com/2009/09/more-on-todays-gmail-issue.html

Here’s what happened: This morning (Pacific Time) we took a small fraction of Gmail’s servers offline to perform routine upgrades. This isn’t in itself a problem — we do this all the time, and Gmail’s web interface runs in many locations and just sends traffic to other locations when one is offline

Bien, la “redundancia es la mejor estrategia”, una frase de “Sadrac en el horno” de Silverberg, es una frase que parece que Google sigue siempre.

However, as we now know, we had slightly underestimated the load which some recent changes (ironically, some designed to improve service availability) placed on the request routers — servers which direct web queries to the appropriate Gmail server for response. At about 12:30 pm Pacific a few of the request routers became overloaded and in effect told the rest of the system "stop sending us traffic, we’re too slow!". This transferred the load onto the remaining request routers, causing a few more of them to also become overloaded, and within minutes nearly all of the request routers were overloaded. As a result, people couldn’t access Gmail via the web interface because their requests couldn’t be routed to a Gmail server. IMAP/POP access and mail processing continued to work normally because these requests don’t use the same routers.

Vean cómo la liebre salta cuando menos se lo espera. “Esperar lo inesperado” sería algo que resume la lección aprendida. Si tenemos un sistema andando, sea software, hardware, y demás, habrá que estar preparados para cuando pase lo que no debería pasar.

The Gmail engineering team was alerted to the failures within seconds (we take monitoring very seriously). After establishing that the core problem was insufficient available capacity, the team brought a LOT of additional request routers online (flexible capacity is one of the advantages of Google’s architecture), distributed the traffic across the request routers, and the Gmail web interface came back online.

Ciertamente, cuánto de nosotros planeamos las aplicaciones para que sean monitoreables? ¿o tenemos preparados los recursos para que sea tan flexible la arquitectura que permite un reemplazo rápido de los mismos? Yo debería aprender más sobre las técnicas de monitoreo, protocoles, estándares, que existen en la industria.

Vean igual que el problema se circunscribió a la interfaz web: el acceso IMAP/POP siguó funcionando.

Algunos usuarios en Twitter, empezaron a desgañitar pestes sobre google y gmail. Pero me parece la gente de Google hizo un excelente trabajo. Tengo menos caídas en Gmail, que en servidores locales de empresas cliente, que atienden a apenas decenas de usuarios.

Pienso entonces: si bien esto se puede ver como una señal de fragilidad de un servicio en línea (y de lo que pronto va a ser llamado algo difusamente “la nube”), veo que es una señal más de lo bueno que es delegar la solución de problemas a gente que está preparada para eso. ¿cuántos de nuestros servicios IT que consumimos en empresas a las que vamos todos los días, podrían reaccionar tan rápido? Yo he visto sistemas miles de veces más chicos, caídos por horas (o días), acá en estos lares.

Una opinión en contrario:

http://www.nevillehobson.com/2009/09/02/the-cloud-is-still-not-reliable-enough/

donde leo:

I still have more faith in local content and offline backups.

¿Opiniones?

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 2889, 3463, 9345. Bookmark the permalink.

4 Responses to La caída de gmail, lecciones aprendidas

  1. En Outlook/OWA tenes labels pero se llaman flags

  2. BlogueroConnor says:

    Ja, yo confio mas en Google que en mi mismo para los backups. En donde vivo (Quilmes) se corta mas la luz que el gmail, y la luz es mas importante sin dudas.

  3. Cesar Reyes says:

    Si, cuestiones como performance, monitoreo, logs, seguridad, redundancia, etc… siempre se dejan al final, mala practica, porque muchas veces tan pronto como quede la funcionalidad necesaria se liberan los productos y pues no debería de ser así. Entonces, debemos de ser conscientes de este tipo de cosas y ejemplos para estar preparados.

    Saludos..

  4. jose luis says:

    Muy cierto a veces nuestro proveedor de correo empresa local que atiende hasta apenas unos 60-80 usuarios no pueden resolver los problemas similares a los que le paso gmail. La verdad a veces confio mas en estos servicios que el de nuestro proveedor ya que las caidad son frecuentes -al menos me ha tocado- y los servicios como gmail, live, yahoo, muy raras ocaciones . Saludos

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>