МойСклад начал проводить обновления без остановки

15 Июля 2020

Почти каждый будний день наш сервис обновляется: 5-10 минут раз в сутки — и в МоемСкладе появляется новая функция или сразу несколько, исправляются ошибки. В это время пользователи сталкиваются с небольшими перебоями в работе, и приходится немного подождать. На днях мы сделали так, что обновления в сервисе больше никак не сказываются на работе пользователей. Про обновления без остановки обслуживания клиентов и о том, как мы поддерживаем производительность сервиса и сохранность данных — в интервью с сооснователем и техническим директором МоегоСклада Олегом Алексеевым.

—  Олег, когда у нас вышло первое обновление без остановки обслуживания и в чем его суть?

—  В конце июня мы сделали первое обновление в новом формате. Это был выпуск интеграции МоегоСклада с платформой для ecommerce Shopify, и он не повлиял на работу пользователей нашего сервиса.

—  Какие ИТ-средства обеспечивают эту новую функцию в МоемСкладе?

—  Мы выбрали технологию — средство для управления инфраструктурой — которая позволяет нам достаточно просто проводить обновления без остановки сервиса. Это Kubernetes, точнее, его реализация от Red Hat — OpenShift. Сначала мы переводили на него компоненты нашего сервиса. Затем работали над тем, чтобы можно было обновлять сервис без остановки обслуживания. Это очень большая работа команды МоегоСклада, она заняла около двух лет.

—  Почему обновления без остановки обслуживания мы сделали только сейчас?

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

Тем не менее, наша клиентская база растет, в том числе и на Дальнем Востоке, где в 00:00 по Москве уже начинается деловая активность, и сейчас настал момент, когда мы просто обязаны перейти на обновления без остановки обслуживания и не отвлекать пользователей от работы.

—  Нельзя ли было запрограммировать так, чтобы все, что делал пользователь во время обновления, «запоминалось» бы сервисом?

—  Можно, но в довольно ограниченном объеме. Это реализовано в одном из наших приложений — Касса МойСклад. Оно умеет работать автономно и на разных платформах: от Windows до iOS.

Однако для «большого» МоегоСклада организовать полноценное хранение данных на стороне клиента затруднительно из-за большого объема и ресурсов, которые нужны для их обработки в компьютере клиента.

Хранение данных МоегоСклада у клиента полностью поменяло бы и сам сервис, и его стоимость. МойСклад — это довольно большое веб-приложение, по сути, онлайн-ERP. Онлайн предполагает, что для работы не требуется ничего, кроме подключения к интернету и браузера на любом устройстве: смартфоне, планшете, ноутбуке или стационарном компьютере.

—  Как работа в Kubernetes повлияла на возможность делать обновления в МоемСкладе чаще?

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

Помимо этого существуют слабо зависимые от переезда в Kubernetes особенности работы с обновлениями. Они связаны с тем, что основная часть МоегоСклада — это монолит, над кодом которого работают одновременно восемь команд. Все изменения, разработанные для МоегоСклада, нужно уметь собрать вместе и сделать доступными для пользователей.

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

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

—  Давай поподробнее про планирование обновлений.

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

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

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

Другой пример: в разделе Показатели есть несколько графиков, и каждый из них строится определенным образом. Одновременно делать два обновления, которые меняют способ подсчета, рискованно, и их желательно выкатить друг за другом. Если обновление было неудачным, мы сразу понимаем, в чем причина, и откатываем его. Когда в обновлении сразу несколько новых возможностей или исправлений, трудно быстро сориентироваться, где именно сломалось.

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

—  Обновления с остановкой обслуживания и технический сбой — это для пользователя одно и то же: недоступен МойСклад. С выпуском обновлений теперь понятно. А как мы работаем, если сервис сломался?

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

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

После сигнала от системы мониторинга мы можем быстро переключить неработающие мощности на резервное оборудование. У нас есть трехкратный резерв «железа», и если компонент выйдет из строя, мы переключаем нагрузку на другой сервер. Как я уже говорил, часто пользователи вообще не ощущают сбой, иногда может случиться небольшой простой. Он может сказаться на работе только части пользователей, реже — на всех, если какой-то компонент трудно резервируется.

—  Расскажи, из чего складывается доступность сервиса?

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

—  Пользователи часто просят нас об услуге резервного копирования. Почему мы ее еще не ввели?

—  Теоретически это возможно, но требует больших технических изменений в нашем приложении.

—  Тогда важный вопрос: мои данные лежат в МоемСкладе. Если вдруг случится самая страшная авария, сохранится ли все, что есть в моем аккаунте?

—  Конечно. Данные пользователей хранятся одновременно в двух дата-центрах. Каждую ночь с них автоматически снимается копия.

Если утрировать: представим, что бомба попадает в дата-центр. Что будет? Данные сохранены в разных местах, и для развертывания в новом центре нужны примерно сутки. За это время можно начать полноценную работу с сохраненным массивом информации. Так что гарантии есть, и не стоит переживать за свои данные.

—  Количество пользователей МоегоСклада постоянно растет. В связи с этим как мы планируем нагрузку на инфраструктуру?

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

Сегодня мы узнали больше про невидимую часть МоегоСклада и о том, как относиться к техническим особенностям облачных сервисов.

Вкратце: наши пользователи больше не пережидают остановку сервиса из-за обновлений, так как теперь это делается в фоновом режиме.

За свои данные, размещенные в МоемСкладе, переживать не стоит: их копируют раз в сутки автоматически и хранят в нескольких местах. Не переживайте и работайте в МоемСкладе продуктивно!

Читайте также:
Новости МоегоСклада: интеграция с Shopify
Новости МоегоСклада: предварительный чек в Кассе

МойСклад — торговля, склад и CRM в облаке Всё, что нужно, в одной системе: продажи, закупки, склад, финансы,
клиенты и поставщики
Начать использовать