Исправление простоя путем обновления версий службы

Исторически администраторы должны были выводить сервер в оффлайн режим для обновления и модернизации локального программного обеспечения. Однако простой совершенно недопустим для глобальных служб, работающих 24×7. Многие современные облачные службы являются критически важной зависимостью для пользователей для запуска своих предприятий. Как найти подходящее время для остановки системы, если команда должна обеспечить непрерывную работу, устанавливая важные обновления безопасности и новые функции?

Используя обновления версий, эти критически важные службы можно легко перенести с одной версии на другую , пока клиенты активно используют их. Не все обновления являются трудными. Обновление интерфейсных макетов или стилей легко. Изменения функций могут быть сложными, но существуют известные методики для устранения рисков миграции. Однако изменения, исходящие от уровня данных, представляют новый класс проблем, требующих особого рассмотрения.

Обновите слои по отдельности

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

Часто управление версиями проще обрабатывать в коде приложения. Более крупные системы обычно имеют довольно много устаревшего кода, например SQL, который находится в своих базах данных. Вместо дальнейшего усложнения этого SQL код приложения должен справиться с сложностью. В частности, можно создать набор классов фабрики, способных обрабатывать версионирование SQL.

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

Так как это на самом деле работает? Например, предположим, что ваша команда в настоящее время развертывает Sprint 123. Двоичные файлы понимают схему базы данных Sprint 123 и схему базы данных Sprint 122. Общий подход — работать с обеими версиями/спринтами N и N-1 схемы SQL. Бинарные файлы запрашивают базу данных, определяют версию схемы, с которой они взаимодействуют, а затем загружают соответствующую связь. Затем код приложения обрабатывает ситуацию, когда новая схема данных пока недоступна. После того как новая версия будет доступна, код приложения может начать использовать новые функции, включенные последней версией базы данных.

Выполняйте переход только на уровне данных

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

Последовательность развертывания

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

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

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

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

Обновления базы данных выполняются с помощью шаблона миграции. Набор кода и скриптов смотрит на версию базы данных, а затем вносит добавочные изменения, чтобы перенести схему из старой в новую версию. Все миграции автоматизированы и выводятся через сервис управления релизами.

Веб-интерфейс также должен обновляться без нарушения пользователей. При обновлении файлов JavaScript, таблиц стилей или изображений избегайте смешивания старых и новых версий, загруженных клиентом. Это может привести к ошибкам, которые приведут к потере незавершенной работы, например, если пользователь редактирует поле. Поэтому вам следует версионировать все файлы JavaScript, CSS и изображения, помещая все файлы, связанные с развертыванием, в отдельную папку, выделенную для управления версиями. Когда веб-интерфейс выполняет вызовы к уровню приложения, ресурсы с указанной версией загружаются. Только если действие пользователя приведет к полному обновлению страницы, новый веб-интерфейс загружается в браузер. Обновление не нарушает взаимодействие пользователя.

Дальнейшие шаги

Корпорация Майкрософт является одной из крупнейших в мире компаний по разработке программного обеспечения на протяжении десятилетий. Узнайте, как корпорация Майкрософт управляет надежными системами с DevOps.