Уже достаточно давно в наши основные навигационные продукты включена возможность "бесшовного" апргрейда на новые версии.
Также у нас есть развитая система по выпуску мелких патчей для уже установленных систем - сейчас без этого никуда не денешься, хотя еще пару лет назад все пользователи могли получать обновления только раз в полгода (длина типичного цикла разработки).
И вот под Новый год приключилась занимательная история...
Началось все достаточно невинно - в последнюю опубликованную версию продукта для одного из потребителей нужно было сделать некую работу, фактически, это было даже не исправление ошибки, а небольшая новая дополнительная возможность (связана она была с устранением необходимости рестарта базовых сервисов после реконфигурации системы).
Сделали исправления, проверили на системе, создали патч, проверили, выложили клиенту - все как всегда... Клиент был доволен...
Потом делали следующий кумулятивный патч, предыдущий туда вошел, отгрузили...
После Нового года начали очередной цикл тестирования систем по апгрейду с предыдущих версий на новые (мы, кстати, обеспечиваем проверку только для двух предыдущих версий продуктов + комбинации из установленных патчей - иначе никаких тестовых ресурсов не хватает. Интересно, как выкручиваются остальные?).
И тут началось - часть тестов upgrade не проходит...
Выяснилось, что сбои происходят на тех системах, на которые был установлен последний кумулятивный патч.
Надо сказать, что обновление продуктов у нас делается за счет major update в терминологии Windows Installer. Предыдущая версия при этом деинсталлируется в ходе инсталляции новой версии, потом устанавливается новая версия и конвертируется сохраненная конфигурация.
И вот в момент деинсталляции предыдущей версии и происходила ошибка - попытка остановить базовые сервисы Windows оканчивалась "зависанием" последних.
Выяснилось, что уже довольно давно в системе была ошибка, заключающаяся в том, что два сервиса, которые были на деле зависимы друг от друга, для Windows такими не являлись. Это не проявлялось никогда и ни при каких тестах, даже у клиентов...
Но тут "выстрелило" внесенное патчем исправление - теперь один из сервисов начал изредка при своем завершении использовать ресурсы другого сервиса... И на части систем получалось так, что к этому моменту он уже был остановлен!
Почему только на части систем - меня лучше не спрашивать, тут нужен астролог, но результат был интересным - апгрейд иногда ломался на попытке снести предыдущую версию.
Проблема была обнаружена достаточно банальным способом - включением протоколирования работы Windows Installer cо всеми доступными опциями. Ну и последующим разглядыванием лога объемом в 15 МБайт.
По итогу нам очень повезло - из-за рождественских каникул патч-вредитель успели скачать только те, кто запрашивал исходную модификацию, их обслужили индивидуально, остальные системы не пострадали и мы сумели этот патч отозвать.
Орг. выводы:
1) При проверке патчей нужно проверять не только то, что он вносит в систему требуемые изменения, но и не оказывает влияния на ее дальнейшее развитие. Как минимум, обязательно нужно проверять, как после этого работет модификация инсталляции, ее repair и деинсталляция.
2) С учетом стохастической природы проявления части ошибок нужно выполнять эти операции неоднократно.
Нас спасло то, что пользователи в уязвимый период времени были неактивны, а операции обновления программного обеспечения согласно методике тестирования выполнялись сразу на большом наборе станций, поскольку система сетевая.
Ну и то, что все патчи у нас учитываются и снабжаются комментариями по производимым модификациям - это позволяет быстро установить изменения, которые проводились в исходных текстах...
Комментариев нет:
Отправить комментарий