MERLION: как снизить риски при обновлении системного ПО

Эксперты MERLION Engineering дали рекомендации, как снизить риски при обновлении системного ПО, на примере перехода на новую версию СУБД Microsoft. Смена версии программного обеспечения несёт в себе как потенциальные выгоды, так и определённые риски.

Если на конкретном предприятии СУБД решает все возлагаемые на неё задачи достаточно хорошо, то ценность потенциальных выгод снижается, а риски всё ещё остаются актуальными. В этом случае обновление СУБД может откладываться до поры. Однако, неизбежно наступает момент, когда используемая версия достигает конца жизненного цикла и снимается с поддержки производителя. В этом случае переход на новую версию становится обязательным для предприятия, ценящего стабильность и безопасность своей информационной инфраструктуры. Тем не менее, за время, пока обновление откладывалось, расхождение в особенностях эксплуатации между устаревшей и текущей версией увеличило вероятность реализации рисков. Поэтому важно понимать, какие именно это риски, и какие есть средства для их смягчения.

Главная ценность любого продукта заключается в его основной функциональности. В случае с СУБД речь идёт о надёжном хранении структурированных данных, достаточно быстром доступе к ним и оперативном внесении изменений. Функциональность, связанная с защитой данных, мониторингом нагруженности и шибок, также является важной, но не первостепенной. В первую очередь необходимо, чтобы СУБД хранила наши данные, позволяла их быстро извлечь и модифицировать. В случае если данных много, задача быстрого исполнения запросов встаёт с особенной остротой. Причем за оперативность реализации отвечает не только аппаратное и программное обеспечение, но и автор запроса. Известно, что язык извлечения и манипулирования данными — SQL — является языком запросным, т.е. описывающим в своих конструкциях, какой именно результат хочет получить отправитель задания. Конкретный алгоритм построения результата при этом в большинстве случаев никак не фиксируется. Однако, такой алгоритм всё равно нужен. Он называется «план исполнения запроса», и генерируется внутренним компонентом СУБД — оптимизатором запроса. Естественно, что при смене версии СУБД поменяется и версия оптимизатора, а значит — велика вероятность того, что на те же запросы будут построены другие планы. Более того, меняются компоненты СУБД, отвечающие за исполнение элементов плана, а также становятся доступны новые элементы для планов исполнения запросов. Впрочем, пугает не столько новизна движка базы данных с оптимизатором, сколько риск того, что на наших данных и нашем потоке запросов планы окажутся менее производительными. Выражаясь проще: есть риск того, что при обновлении версии СУБД важные запросы станут исполняться медленнее настолько, что это вызовет недовольство пользователей.

Любая СУБД является не самостоятельным приложением, а лишь слоем хранения данных для бизнес-приложений. Предприятию важно, чтобы именно эти приложения работали исправно и быстро, а это обеспечивается в том числе и совместимостью между бизнес-приложением и связанной с ним СУБД. Самый первый уровень совместимости — возможность подключения к СУБД. В этой части опасаться особенно нечего, поскольку мы обсуждаем переход между версиями одной и той же СУБД — обеспечить в этом месте обратную совместимость достаточно просто, и производитель это делает. Гораздо серьёзней риск несовместимости диалекта SQL. В самом деле, реализация SQL в конкретной СУБД меняется от версии к версии — появляются новые возможности и устаревают имевшиеся ранее. Конечно, из соображений обратной совместимости устаревший синтаксис некоторое время принимается СУБД, но производитель оставляет за собой право в конце концов исключить его из языка. Если это произойдёт, то запросы с устаревшими элементами синтаксиса перестанут работать, и приложения, их отправляющие, потеряют, по меньшей мере, часть своей функциональности. И ещё одна точка несовместимости — изменение в структурах хранения данных. Может изменяться толкование стандартных типов данных или условия хранения ёмких типов. Конечно, как и в случае устаревшего синтаксиса, устаревшие структуры данных тоже поддерживаются некоторое время из соображений обратной совместимости, но рано или поздно они могут быть исключены из СУБД и тогда наступает несовместимость. Пути устранения синтаксической и структурной несовместимости очевидны — переписать часть кода бизнес-приложений так, чтобы появилась совместимость с новой версией СУБД. Даже в случае наличия поддержки бизнес-приложения, это может занять значительное время. Правда, производители бизнес-приложений для крупных предприятий, как правило, отслеживают выход новых версий, и у них имеются готовые варианты, совместимые с актуальными версиями смежного ПО. Тем не менее, обновление бизнес-приложения — это отдельный ёмкий процесс. Как временное решение могут помочь режимы совместимости в СУБД.

Любой программный продукт имеет ошибки и уязвимости, которые обнаруживаются только в процессе эксплуатации. Кроме этого, новая функциональность и связанные с ней риски в области защиты данных на этапе запуска ПО ещё плохо известны техническому персоналу, поэтому возможны ошибки администрирования, также приводящие к ослаблению безопасности. В старом продукте есть известное количество уже обнаруженных уязвимостей, исправленных обновлениями от производителя. Поэтому кажется, что более ранняя версия более защищена. Однако, это чувство защищенности мнимое — действительно, много заплаток уже поставлено, но никто не знает, сколько дыр ещё осталось. А с учётом того, что старая версия продукта снимается с поддержки, риск злонамеренной эксплуатации открытой уязвимости резко возрастает. Поэтому специалисты как правило придерживаются мнения, что с новой версией ПО не связывается повышение риска — любая поддерживаемая версия, любого ПО имеет примерно одинаковую вероятность попасть под «атаку нулевого дня». И для любой версии методы смягчения этого риска одни и те же: сужение поверхности атаки, настройка безопасности внутри приложения, аудит нетипичной активности и своевременное применение обновлений безопасности.

Методика смягчения рисков снижения производительности и потери совместимости заключается в предварительном тестировании. Необходимо настроить временный экземпляр СУБД и создать в нём полную или частичную копию производственной БД. На продуктивной базе записать типичную активность пользователей за длительный период. Если типичная активность меняется от периода к периоду (например, активность в часы пиковой нагрузки, в отчётный период, в выходные дни и нерабочее время), то можно или записать активность одной сессией, охватывающей все такие периоды, или сделать несколько коротких сессий записи активности в периодах разного типа. Потом записанная активность запускается на копии базы данных — с целью убедиться в отсутсвии сбоев и снижения производительности. Более изящный способ требует хорошего знания характера запросов, приходящих в БД. Впрочем, если администратор БД озабочен её производительностью, он обычно знает все «тяжёлые запросы» и может проконтролировать их производительность, не прибегая к записи текущей активности пользователей. Проверку совместимости можно переложить на производителя бизнес-приложения, просто убедившись, что в списке совместимых СУБД присутствует та версия, на которую необходимо перейти.

Только в том случае, если в тестовой среде было обнаружено, что реализуются риски снижения производительности или потери совместимости, необходимо проводить работы по ликвидации последствий. Эти работы совпадают с рутинными задачами поддержания производительности на должном уровне при эксплуатации систем — обнаружение тяжёлых запросов, построение полезных и удаление вредных индексов, установка полезных и снятие вредных «намёков» оптимизатору и т.п. Хорошая практика — удалять периодически старые средства оптимизации и создавать новые «с нуля». В плане обеспечения совместимости СУБД и бизнес-приложений необходимо вести работу с производителями последних, добиваясь версий, совместимых с актуальной версией системы управления базами данных. В любом случае — подобные операции проводятся на тестовой копии БД и не влияют на работу пользователей. Только когда на тестовой среде достигается приемлемая работоспособность на новой версии СУБД, может быть принято решение о миграции на нее.

Прежде, чем приступать к миграции, необходимо убедиться, что доступна актуальная резервная копия переносимой БД, и имеется проверенная процедура восстановления из резервной копии. Если чего-то из перечисленного нет, это необходимо создать и иметь в оперативном доступе в процессе миграции.

Существуют два принципиально разных подходах к миграции — in-place и out-of-place. В первом случае обновление накатывается прямо на старую версию ПО, в надежде на то, что удастся корректно перенести все настройки. Однако, помимо риска некорректной работы мастера обновления на продуктивной среде, есть ещё и недоступность БД в процессе такой миграции, и невозможность быстро отскочить на исходную позицию (к старой версии). Поэтому наилучшей практикой является второй вариант — в инфраструктуре заказчика настраивается новая версия СУБД, в которую переносится продуктивная БД и применяются средства устранения проблем с производительностью и совместимостью. Затем в эту БД переводится работа пользователей. В случае неожиданных особенностей эксплуатации новой версии СУБД работа пользователей переводится обратно в старую версию СУБД, а исполнители миграции возвращаются к устранению обнаруженных проблем.

Итак, эксперты рассмотрели обстоятельства, которые могут привести к решению отложить обновление версии СУБД, и увидели, что это лишь усугубляет возможные проблемы, поскольку чем старше используемая версия, тем выше вероятность возникновения негативных последствий и серьезных нестыковок. Поэтому переход на новую версию СУБД следует планировать заранее — по мере выпуска новых версий, с учётом ранее озвученных рисков и механизмов их смягчения.

Однако, стоит вспомнить ещё одно средство, позволяющее нам оптимизировать управление обновлениями. Речь идёт о переносе баз данных в «облако». Если говорить о конкретной ситуации с окончательным устареванием MS SQL Server 2008, то такой перенос сегодня позволит ещё на некоторое время оттянуть наступление неизбежного. Дело в том, что эта версия SQL Server в Azure получит три года бесплатного продления обновлений безопасности (Extended Security Updates), и проблемы, с которыми столкнутся пользователи «наземных» MS SQL Server 2008 сегодня, для пользователей «облачных» продуктов наступят значительно позже. При этом и пользователи «наземных» SQL Server тоже смогут воспользоваться продлением обновлений безопасности, но при соблюдении определённых условий и за отдельные деньги.

Перенос сервисов в «облако» позволяет снизить нагрузку на технический персонал пользователя системы, в том числе и по применению обновлений. Это можно считать ещё одним доводом в пользу миграции баз данных в Azure.

Эксплуатация снятой с поддержки СУБД существенно увеличивает риски в области безопасности и стабильности работы бизнеса. При переходе на новую версию СУБД существует вероятность снижения производительности, потери совместимости и снижения безопасности. При этом риск снижения безопасности является мнимым. В свою очередь риски снижения производительности и потери совместимости смягчаются опытной эксплуатацией в изолированной среде. При выявлении проблем их устраняют, пользуясь стандартными процедурами, аналогичными тем, что используются при оптимизации работы действующей системы. Перед миграцией на новую версию СУБД должна быть обеспечена резервная копия и процедура восстановления. Наилучшим способом миграции является out-of-place — с сохранением старой версии сервиса для быстрого отскока назад при обнаружении неожиданных проблем.

Помимо технических нюансов миграции на новую версию SQL Server, так же существуют и лицензионные вопросы, которые при неправильном подходе несут в себе серьёзные риски частичного покрытия серверов лицензиями и, соответственно, нарушение лицензионной политики вендора.

При переходе на новую версию рекомендуется провести аудит установленных копий SQL Server и количество подключений к ним. Изучить текущие схемы лицензирования и выбрать для себя оптимальный вариант.

На данный момент существует две основные редакции SQL Server 2017 — Standard и Enterprise. Редакция Standard сохранила «классическую» схему лицензирования — «server + CAL», которая подразумевает, что каждая серверная лицензия дает право запускать программное обеспечение только в одной физической или виртуальной операционной среде одновременно, однако клиент может использовать любое количество запущенных экземпляров SQL Server в этой операционной среде. И не стоит забывать про клиентские лицензии, которые нужны для всех пользователей или устройств, которые подключаются к SQL Server в сети организации. Вторая модель лицензирования изменилась по сравнению с SQL 2008. И заключается в подсчёте всех ядер, которые физически присутствуют на данном сервере. При лицензировании «по ядрам» клиентские лицензии SQL CAL покупать для этого сервера не надо. При лицензировании виртуальных машин, считаем только ядра, которые были выделены для этой ВМ. Вне зависимости от среды развёртывания, необходимо лицензировать минимум 4 ядра.

Схема лицензирования редакции Enterprise изменилась, и теперь необходимо считать количество ядер, которые в физической среде присутствуют на сервере, либо — в ВМ выделены для этого экземпляра SQL Server. И так же, как и у редакции Standard, — минимальное количество ядер для лицензирования составляет 4 шт. А если полностью лицензировать сервер путем покупки лицензий SQL Server 2017 Enterprise с подпиской Software Assurance с учетом общего числа физических ядер в серверах, клиенты получают возможность развертывать неограниченное число виртуальных машин.