Эта статья была спонсирована PagerDuty . Спасибо за поддержку спонсоров, которые делают возможным использование SitePoint.
Плановое обслуживание веб-сайта — это плановое обслуживание, обычно требующее значительного количества времени и рабочей силы, а также простоев вашего сервиса. Это интернет-эквивалент отправки вашего автомобиля для настройки. Проблема в том, что веб-приложения определенно не являются автомобилями.
Посмотрим правде в глаза: никто не любит плановое обслуживание — ни клиенты, ни разработчики. Это отнимает много времени, обычно приходит в выходные и может стоить компании, выполняющей техническое обслуживание. Даже если вы выполняете техническое обслуживание в воскресенье вечером в Соединенных Штатах, например, это рано утром на следующий день в Индии, так что эти пользователи будут затронуты вашим отключением.
Веб-мастера «планируют» такие задачи обслуживания, чтобы внести серьезные изменения в веб-сайты. Единственная причина, по которой они делают это, даже зная потенциальные последствия, состоит в том, чтобы избежать помех, с которыми они столкнутся, если их служба все еще будет работать. Представьте, что автомеханик пытается починить двигатель, когда он еще работает.
К счастью, современные методы разработки означают, что все изменилось. В этом посте мы расскажем о том, как отказаться от планового технического обслуживания и найти способ исправлять ошибки в реальном времени, не затрагивая ни одного пользователя! Изначально это было очень сложно при правильном планировании и выполнении стратегий.
Непрерывное развертывание — мир без планового обслуживания
Давайте начнем с самого начала и поговорим о цели планового технического обслуживания. Обычно это время, когда вы вносите значительные изменения в свой продукт — будь то устранение ошибок или добавление функций. Обычно вы вносите кучу изменений в течение одного сеанса обслуживания, чтобы максимально использовать время простоя.
Другой, лучший способ сделать эти изменения прост — в режиме реального времени. Это называется непрерывным развертыванием. Как только вы идентифицируете ошибку, вы назначаете ее разработчику, который необходимо устранить. Как только ошибка будет устранена, вы объедините ее с основной базой кода. Это звучит довольно просто, но есть еще несколько шагов.
Поддерживать промежуточный сервер
Многие организации поддерживают промежуточный сервер с фиктивной базой данных, которая служит связующим звеном между вашим локальным компьютером и основным сервером. Основным мотивом промежуточного сервера является проверка того, как изменения будут выглядеть для конечного пользователя. Сначала вы предварительно просмотрите изменения на промежуточном сервере, и если вы удовлетворены изменениями, вы заставите их появиться на главном сервере.
Доступ к промежуточному серверу должен быть ограничен, и этого можно достичь, разместив его на необычном поддомене (что-то кроме «staging.yoursite.com»).
Автоматизированное тестирование
Вы должны обеспечить надлежащую среду тестирования (которая включает в себя такие тесты, как модульные тесты и интеграционные тесты), через которую данное исправление должно пройти до объединения с основной базой кода. Это важно, потому что само исправление может привести к новой ошибке, которая может привести к простою. Во многих организациях это тестирование автоматизировано — ваш код объединяется на главном сервере только после того, как он прошел все указанные тесты.
Идея состоит в том, чтобы гарантировать, что любой добавляемый вами код не приведет к поломке.
Непрерывная интеграция
Где проходит это автоматическое тестирование? Нам нужен централизованный сервер, который выполняет тесты кода, прежде чем изменения вступят в силу. Существует много решений с открытым исходным кодом, таких как Buildbot, и облачных решений, таких как Travis CI или Jenkins CI, которые выполняют эту задачу автоматизации.
Я уверен, что вы используете какой-то контроль версий для управления своим исходным кодом. В популярной системе контроля версий Git вы можете написать сценарии, называемые «ловушками», для выполнения ряда задач в соответствии с вашими требованиями. Наиболее распространенной задачей было бы объединить код с основным хранилищем после прохождения тестов. Вот подробное руководство по использованию хитов Git для непрерывной интеграции .
Управление изменениями в схеме базы данных без простоев
Одной из проблем, которая может действительно вызвать соблазн запланированного обслуживания, является выпуск исправлений функций, которые требуют изменений в схеме базы данных. Как вы поступите с таким выпуском без каких-либо простоев?
Оказывается, есть и способ обойти это, хотя это требует некоторых осторожных шагов. Вам нужно будет примерно следовать следующим шагам:
- Измените схему, создав новую таблицу или добавив новый столбец (без удаления старой таблицы или столбца).
- Измените ваше приложение для чтения старых данных и записи как старых, так и новых данных.
- Перенесите данные, скопировав старые данные в новую схему
- Измените ваше приложение, чтобы читать и писать только новую схему
Вы должны действовать с осторожностью на каждом этапе. Вот более подробное руководство .
Оповещения в реальном времени и ситуационная осведомленность
Даже если ваша система развертывания идеальна, ошибки все еще могут появляться. Эти ошибки часто сначала встречаются конечными пользователями. Хорошие самаритяне сообщат об этом, но вы можете не знать об ошибке сразу.
Поэтому важно настроить систему оповещения, которая сообщит вам, как только конечный пользователь обнаружит ошибку. В идеале это можно сделать, отправив электронное письмо в список рассылки ваших разработчиков или назначив кого-то для разговора с помощью ChatOps.
Чрезвычайно полезно иметь систему для единого обзора вашей инфраструктуры, чтобы вы могли не отставать и реагировать на ошибки и простои. PagerDuty — это платформа, которая позволяет разработчикам по вызову отслеживать проблемы с помощью подробной аналитики и интеграции с такими приложениями, как New Relic, Crashalytics и AppDynamics. Во время инцидента оповещения будут поступать по электронной почте, по телефону, с помощью push-уведомлений или путем интеграции с этими другими службами. Служба имеет непрерывную маршрутизацию и автоматическую эскалацию, чтобы гарантировать, что каждому предупреждению уделяется внимание, которое оно требует.
Особенности развертывания на этапах
До сих пор мы говорили в основном об ошибках. Когда дело доходит до выпуска новых функций, такие компании, как Facebook, выпускают их партиями (например, новую временную шкалу или поиск по графику). Это помогает исправлять ошибки в более ранних версиях новой функции, не оказывая слишком большого влияния на обслуживание.
Помимо исправления ошибок, по мере увеличения трафика на новую функцию вы можете оценить ее производительность и внести необходимые изменения для ее оптимальной работы.
Использовать архитектуру высокой доступности
Ваши пользователи (мы надеемся) рассредоточены по всему миру, а ваше приложение получает трафик в течение дня. Это делает время работы очень важным. Разработчики рассчитывают до 99,999999% времени безотказной работы, что указывает на долю времени простоя менее чем на долю секунды в год.
При таких требованиях требуются подходы высокой доступности, такие как балансировка нагрузки и отказоустойчивые системы . Помимо применения этих принципов на уровне приложений, вам также может потребоваться выполнить репликацию или разделение базы данных в соответствии с вашими потребностями.
Последние мысли
Прежде чем мы закончим этот пост, позвольте мне привести несколько примеров компаний, которые не только осуществляют непрерывное развертывание, но и призывают других сделать это — Facebook , Google , LinkedIn и PagerDuty (вот пост о том, как последний управляет им ). Это просто показывает, что непрерывное развертывание — это путь вперед.
Как вы отошли от планового технического обслуживания? Есть ли у вас какие-либо советы по облегчению перехода?