google mail damage control
вчера (первого сентября) моя работавшая из дому flatmate ничего не могла сделать -- у гугла лежала почта (гаечные ключи) - точнее, веб-интерфейс к ней.
там же опубликован отчет о поломке (общая ее длительность 6 часов) -- гугл отключил часть серверов, занимающихся распределением входящих запросов, на профилактику, а остальные не справились и отражали все запросы вообще.
вспоминая свою работу в одной интернет-компании в долине, я помню, как часто все сводилось к scalability. Как-то раз одна неработающая часть системы с распределением нагрузки привела к отказу всей сети сервис-центров -- понимаю, насколько важно держать резерв серверов и его испытывать; а еще важнее -- честная коммуникация с клиентом (как во время аварии, так и после).
Actions and Root Cause Analysis
On Tuesday, September 1, a small portion of Gmail's web capacity was taken offline during a routine
upgrade and service update. This is normal operating procedure as the Gmail web interface runs in
multiple locations, and Gmail's request routing automatically directs users' requests to available servers.
However, we underestimated the increased load that some of the new updates placed on request
routing.
As a result, at approximately 12:30 PDT, a few request routers became overloaded and responded by
refusing all incoming requests. This response transferred the load to the other request routers, and as the
effect rippled through the system, almost all of the request routers became overloaded. As a result, users
could not access Gmail through the web interface since their requests could not be routed to a Gmail
server. Gmail processing and access through the IMAP/POP interfaces continued as usual because
these processes use different request systems.
там же опубликован отчет о поломке (общая ее длительность 6 часов) -- гугл отключил часть серверов, занимающихся распределением входящих запросов, на профилактику, а остальные не справились и отражали все запросы вообще.
вспоминая свою работу в одной интернет-компании в долине, я помню, как часто все сводилось к scalability. Как-то раз одна неработающая часть системы с распределением нагрузки привела к отказу всей сети сервис-центров -- понимаю, насколько важно держать резерв серверов и его испытывать; а еще важнее -- честная коммуникация с клиентом (как во время аварии, так и после).
Actions and Root Cause Analysis
On Tuesday, September 1, a small portion of Gmail's web capacity was taken offline during a routine
upgrade and service update. This is normal operating procedure as the Gmail web interface runs in
multiple locations, and Gmail's request routing automatically directs users' requests to available servers.
However, we underestimated the increased load that some of the new updates placed on request
routing.
As a result, at approximately 12:30 PDT, a few request routers became overloaded and responded by
refusing all incoming requests. This response transferred the load to the other request routers, and as the
effect rippled through the system, almost all of the request routers became overloaded. As a result, users
could not access Gmail through the web interface since their requests could not be routed to a Gmail
server. Gmail processing and access through the IMAP/POP interfaces continued as usual because
these processes use different request systems.