Блоги Блоги 02.03.2011 в 18:42 comment

Что это было?

author avatar
https://secure.gravatar.com/avatar/540826395fce3a1344dcf85beaaee1cb?s=96&r=g&d=https://itc.ua/wp-content/uploads/2023/06/no-avatar.png *** https://secure.gravatar.com/avatar/540826395fce3a1344dcf85beaaee1cb?s=96&r=g&d=https://itc.ua/wp-content/uploads/2023/06/no-avatar.png *** https://itc.ua/wp-content/themes/ITC_6.0/images/no-avatar.svg

Наконец появились развернутые комментарии по поводу давешнего инцидента с Gmail.

Оказывается, причина заключалась в обновлении ПО для системы хранения. Причем, как можно понять из текста сообщения, невысокий процент (сейчас он уже оценивается всего в 0,02%) пострадавших объясняется именно тем, что процесс вовремя остановили. А если бы не это?

Т.е. такие объяснения скорее ставят новые вопросы, чем отвечают на прежние. Есть же более-менее очевидные подходы к столь важным процедурам, как обновление действующих и, особенно, критических систем. К примеру, та же Microsoft выпускает специальные инструменты, позволяющие отсрочивать установку сервис-пакетов через Windows Update. В WSUS можно "придерживать" любые заплатки — с целью их предварительного тестирования на каком-то специальном "полигоне" на предмет несовместимостей с используемым ПО и пр.

Но в случае облачных систем срабатывает тот самый пресловутый эффект масштаба, только наоборот. Речь ведь идет не об отдельных компьютерах, а об огромных высокоинтегрированных системах, довольно сложно устроенных и взаимосвязанных. Можно ли здесь адекватно протестировать обновление? С более-менее реальными объемами и нагрузками? Есть сомнения.


Loading comments...

Сообщить об опечатке

Текст, который будет отправлен нашим редакторам: