En una semana y media hay 3 ejemplos de desastres en empresas de tecnología y me pareció oportuno ver como los comunicaban; Sony comunicó en su blog que pasó con el hack al Playstation Network; mientras Apple lanzó un press release explicando porque hay un archivo con datos de ubicación en cada iPhone y, finalmente, Amazon que tuvo problemas gigantes en AWS simplemente no tiene un registro de nada.
Y lo más interesante sea ver como Sony tiene fuera de línea a todo Playstation Network hasta asegurar seguridad y confiabilidad para sus usuarios, ver tambien como Apple anuncia cambios en la forma en la que se guardan datos y hasta el borrado cuando no hay geolocalización elegida y como Amazon hace... ¿nada? Lo que implica ver como cada empresa reconoce sus errores/problemas y se hace cargo de ellos
Pero quizás si uno mira los 3 problemas que existieron puede ver como la respuesta es más eficiente de acuerdo a la severidad del problema (y esto, antes que me quieran linchar, siempre es subjetivo) porque me parece que en un caso es una falla técnica, en otro es una falla de privacidad/confianza y finalmente hay una violación a la seguridad de una red gigantesca con datos no sólo personales sino financieros de los que usan el servicio... entonces me genera como una sensación de correlación entre severidad del problema y calidad de la respuesta que no esperaba ver en empresas de este calibre.
De hecho estoy bastante decepcionado con que Amazon no haya siquiera dejado un post en el blog oficial de Amazon Web Services diciendo algo simple como "Hey, pasó esto y si tus servicios estuvieron caídos podrías haberlo solucionado así" porque hay empresas afectadas que perdieron mucha plata... en el caso de Apple su comunicado es tan aséptico como un puede esperar de un demiurgo al aceptar un error pero me parece genial que hayan tomado el toro por las astas y lo hayan comunicado y, finalmente, lo de Sony Playstation Network me parece genial comunicacionalmente porque el comunicado y el Q&A es claro y efectivo pero además no dudaron en cerrar el servicio aún perdiendo plata para frenar todo tipo de pérdida de confianza o de problemas para sus clientes.
Es raro... en menos de una semana tuvimos la posibilidad de ver como 3 gigantes "¿amados/odiados?" tenían problemas gigantescos y como respondían ante ellos, a más gravedad mejor fué la respuesta e, irónicamente, a mayores expectativas mayor fue el fiasco a verlos responder.
Mariano, un par de detalles, amazon si comunico y lo ha echo como siempre y es en el status, y ojo amazon informa a los Server Administrator no a los usuarios finales, por ende su forma de comunicar son lógicamente diferentes. Por ende les faltó tacto para las masas pero no para las personas que debían ser informadas.
Y si mal no recuero, me parece leí que también Android lo hace y no vi que hablaras de ellos :).
Pd: pichon de demanda se va a comer Sony :D:D:D y ademas no valla a ser que le pidan libertad de servidores para que no estén obligados a jugar en su red y así no tener que tener esos riesgos :D
Francisco,
Amazon dejó sin servicio a dos de sus centros y para vos que en el blog de desarrolladores, que en el blog oficial y que en el centro de prensa de Amazon no haya ni una mención es ¿aceptable? Vos me decís que “amazon informa a los Server Administrator” cuando solo te muestra un semáforo en vez de soluciones para un administrador ¿y eso te parece aceptable? Definitivamente vos no perdiste un sitio dos días, no perdiste servicios como Grippo ni fuiste afectado… y si lo fuiste, me encantaría tenerte como cliente asi se que no te jode nada.
El blog oficial no es para “masas” es para administradores, es para developers, es para empresas que confían en una plataforma (PaaS) y por eso está lleno de tutoriales y comunicados pero ni una mención a la caída más grande que tuvieron en su historia…. y más alla de eso ¿Android lo hace? No entiendo ni siquiera de que estás hablando, pero como asumo que estás hablando del problema de la privacidad.. te aclaro dos detalles: a) Me pareció un problema más de prensa que otra cosa, b) En Android esos datos están encriptados.
Mariano… Es el servicio que tiene menos soporte y más barato del mercado (en grandes empresas)… Esto dice mucho de la empresa y quienes lo contratan.
2)Te recomiendan que siempre tengas replica en 2 lugares para que no tengas estas caídas… pero california es un poco más caro por los impuestos :D y replicar tus centros es muy caro y esto nunca había pasado. Todos asumieron el riesgo, si hubieran tenido la replicación adecuada, solo tenían una caída de performance (por unos 30 minutos) y no mucho más.
3) Si no sabes administrar servidores, no te metas en amazon… esto es sabido, porque no te ayudan mucho mas que unos tutoriales que dejan mucho que desear. Por ende si sos developer o alguien sin muchos conocimientos usa otro proveedor y paga un poco más.
4) Usan tecnología Xen que es sabido de este posible inconveniente, que los administradores o los inversores se quieran desligar de este desastre no quiere decir que amazon actuó en forma incoherente ya que siempre actuó de la misma forma y uno contrata esto por sus costos y calidad del servicio, no por su soporte. Si queres soporte y prensa paga por ejemplo Rackspace que si te lo ofrece. y cuesta un 10% más.
5) si tengo servidores y en N. Virginia. ;)
6) No quiero defender a amazon, pero da lo que ofrece y más que lo que cuesta.
7) Nunca negué que les falto tacto con esto, sobre todo para consumidores finales y medios. Pero no son su público objetivo.
8) Si era por la privacidad (perdón) y lo vi como un análisis de prensa, pero lo dije porque google siempre tiene buen manejo de prensa. y creo que valía colocarlo en este ejemplo que diste y que es un grande también y con un problema similar.
Saludos y este año entro en el ranking de los que comentan ;)
Francisco, debo aclarar un par de puntos porque lo que decís de Amazon se presta a confusión.
Primeramente, Amazon comunicó INCORRECTAMENTE en la descripción del su servicio EBS que nunca habría un único punto de fallo dentro de una región, siendo que se dispone de múltiples Availability Zones. Eso es exactamente lo que comunicó y es exactamente lo que falló. Absolutamente las 4 AZ de la región en cuestión fallaron todas a un mismo tiempo.
Segundo Amazon se comunica con clientes, no necesariamente con sysadmins.
Tercero, decir que postear en status.aws.amazon.com y comunicar son lo mismo es quizás lo que más confusión crea y se desvía completamente del sentido de esta nota. Si Amazon hubiera sido honesto y hubiera comunicado desde el primer momento la verdadera situación, en vez de dilatar diciendo “no tenemos mucho para decir, lo diremos dentro de una hora” una y otra vez, muchos sitios hubiéramos agarrado backups antes de esperar que “en unas horas” Amazon recuperara la plataforma. Ponete en el lugar que tiene el sitio caído, recién como a las 8 horas de iniciado el evento te dicen que los APIs no se ejecutarán hasta nuevo aviso. Luego, a las 24 horas, mientras vos ya no podés creer que tu sitio haya cumplido un día entero fuera de línea te dicen que están listos para recuperar backups desde S3 y eso tarda unas 24 horas mas, y en cada una de las 24 horas mas postean que “están trabajando”. ¿Te parece bien comunicado?
NO. Y entiendo lo problemático que fue para muchos (soy sysamin), pero no es mucho más que eso Amazon, un servicio que no tenes en ningún lugar donde contactarte con soporte o tirar un ticket (al menos que pagues U$S 400 por mes, para que nadie lo contrate), me parece que la “Seriedad” de amazon siempre fue esta. El problema es que a amazon se la tiene relacionada con una calidad que no tiene y eso es lo que planteo.
No está bien comunicado pero no es otra cosa Amazon y fue coherente con todo esto, para bien o para mal.
Espero con esto no ofender, ni justificar, pero es como veo yo a amazon.
Si fueras sysadmin de Reddit por ejemplo o de Foursquare, sería interesante saber si pensarías lo mismo acerca de lo que es Amazon y lo que no es. Esos ingenieros siguieron documentación de Amazon, no fueron irresponsables. Y a todo el que diga ahora que habia que tener un setup multiregion le pregunto, por qué Amazon hizo tan complicado hacer un setup multiregión, por qué Amazon documentó que un setup Multizona tenía 4 niveles de redundancia sin un único punto de fallo y por qué m…. no lo dijeron antes del outage y esperaron el outage para salir a decirlo.
Si soy sysadmin de esas empresas no hubiera dormido aún, gracias a dios no estoy hoy en sus pantalones.
Pero si tenes un producto de ese calibre, hay una gran responsabilidad de los sysadmin por el proveedor que eligieron y por lo menos deberían haber pagado soporte por unos meses para implementar multizone o migrar a otro proveedor que les brinde un soporte que esté a la altura de tu empresa.
Soy una persona que siempre piensa que la culpa es de uno, no puedo pensar de otra forma, pero si te recomiendan más de una región y te lo hacen difícil y poca documentación sobre el tema y no tenes donde consultar o generar ticket salvo un blog que no da garantías de nada, que haces teniendo Reddit y Foursquare (que reciben rondas de inversión millonarias) sin un plan de fallos o porque están contratando un proveedor que te recomienda hacer algo que no te lo permite hacerlo fácilmente.
Repito no quiero estar en sus pantalones, pero es la plataforma que eligieron y si es la base de tu negocio o sea, me supera pensar que gente que recibe millones de dolares no planifique estados de crisis o elija un proveedor que claramente no está a la altura de tus recursos.
Es como recibir millones de dolares para abrir una cadena y compras los materiales más baratos (hay algo que alguien está haciendo mal) es la base de tu negocio. Por mucho marketing y nombre es responsabilidad es de los que eligieron la plataforma, porque la eligieron por nombre y costo, y no por la calidad, ya que sin soporte y documentación clara, es obvio que por lo menos “Serios No Son”.
No quiero generar polémica con esto y cada uno tiene sus recursos y estrategias y apuesta donde cree mejor y realmente nadie espera una cosa tan grave de “Amazon”, pero explicarle a los inversionistas que contrataste para la base de tu negocio un proveedor que no da soporte ni documentación clara, espero que haya sido una decisión consensuada porque sino, no hay forma hoy de justificarla.
Nos hemos ido del objetivo de la publicación y entiendo lo mal que la pasaron, como sysadmin tuve estas experiencias y no se las deseo a nadie.
Con respecto a Amazon, cuando comentas “[..]y finalmente hay una violación a la seguridad de una red gigantesca con datos no sólo personales sino financieros de los que usan el servicio[..]”, queda la sensación de que el problema que tuvieron esta a la altura del de Sony o Apple. El caso de Amazon en realidad fue una muy grave disrupción de servicio (con perdida de datos de clientes en algunos casos, como se anuncio hoy), pero de acuerdo a la información de que se ha hecho disponible no se obtenido un acceso no autorizado a la misma.
Por otra parte, el caso de Apple es para seguir de cerca … ahora parece que no guardamos ningún tipo de información, pero si la información quedaba por mas tiempo del estipulado en el equipo ‘todo fue por un simple bug’ …
Nosotros tuvimos problemas con todas nuestas aplicaciones y las de nuestros clientes. Sin embargo, la gente de Amazon fue dando un status detallado de lo que estaba ocurriendo en todo momento (http://status.aws.amazon.com/). Lo que todos estamos esperando aún es el análisis post-mortem que prometieron.
Perdón Matu, (repito) no es lo mismo postear en status.aws.amazon.com que comunicar. Comunicar es otra cosa muy diferente, y no han tenido los huevos de hacerlo en beneficio de los clientes, sino que fueron simplemente cuidando su culo.
Hoy salio la publicacion del analisis detallado del caso de AWS:
http://aws.amazon.com/message/65648/
“… we also identified improvements that need to be made in our customer communications. We would like our communications to be more frequent and contain more information.”
http://aws.amazon.com/message/65648/