Форму обновили, тесты прошли, разработчик написал в чат: «Выложил». А заявки перестали приходить. В такой ситуации важно не только исправить код. Нужно понять, какая версия работает, кто проверяет весь путь заявки и кто принимает решение о восстановлении.
В Гуси-Лебеди мы предлагаем разбирать DevOps именно через работу продукта. Это подход к совместной разработке и эксплуатации: команда договаривается о выпуске изменений, автоматизирует повторяемые действия и получает обратную связь после запуска. Название образовано от development и operations, разработки и эксплуатации. В объяснении AWS к DevOps отнесены культура сотрудничества, практики и инструменты. Покупка одной системы или найм специалиста сами по себе ещё не создают этот порядок.
Ниже рассмотрим условный пример обновления формы. Он поможет обсудить процесс с подрядчиком или своей командой без обещаний, что выбранная технология автоматически устранит все сбои.
Когда бизнесу нужен DevOps и с чего начать
Сначала посмотрите, как изменение доходит до пользователя. Не как этот путь описан в презентации, а как проходил последний выпуск. Где лежит код? Что собирали? Где проверяли? Кто разрешил установку? Что посмотрели после неё? Ответы покажут, какую проблему действительно нужно решать.
Если выпуск зависит от человека, который помнит команды и настройки, у компании появляется задача передачи знаний. Если тестовое окружение сильно отличается от рабочего, нужно разобраться с этими различиями. Если ошибка становится заметна только после звонка клиента, стоит обсудить проверку пользовательских действий и уведомления. Это разные задачи, поэтому начинать с одинакового набора инструментов для всех проектов неудобно.
Мы советуем выбрать один понятный участок. В нашем примере это изменение формы и передача заявки в систему обработки. У него можно определить начало, результат и участников. Не нужно одновременно перестраивать весь сайт, переносить инфраструктуру и менять порядок работы команды, чтобы проверить первый шаг.
| Что мешает работе | Что выяснить до выбора инструмента |
|---|---|
| Новую версию трудно выпустить | Какие ручные действия нужны, кто их выполняет и где появляется задержка |
| На стенде работает, на сайте нет | Какие настройки, данные и внешние подключения различаются |
| Пользователь сообщает об отказе раньше команды | Как проверяется нужное действие и кому приходит сигнал |
| Задача застревает между участниками | Кто принимает решение, кому передают результат и что считается завершением |
Назначение DevOps-инженера зависит от устройства проекта. В работе могут быть сборка, доставка приложения, инфраструктура, наблюдение за сервисом и помощь разработчикам. Но обязанности нужно согласовать явно. Общая ответственность за продукт не означает, что один человек должен отвечать за код, бизнес-требования, оплату облака и все обращения клиентов.
Для маленького сайта может быть достаточно воспроизводимого выпуска, предусмотренного резервирования и понятного сопровождения. Для регулярно меняющегося веб-сервиса потребуется подробнее организовать доставку изменений и эксплуатацию. Решение выбирают по фактической работе, частоте изменений и требованиям к доступности, а не по модности названия.
Проверьте и причину задержки. Если готовое изменение ждёт согласования содержания, новая система сборки может не помочь. Если заявка теряется в стороннем подключении, сначала нужно проследить этот участок. Автоматизировать имеет смысл процесс, который команда понимает.
Как устроить выпуск: от кода до работающей формы
В разговоре о DevOps часто появляется сокращение CI/CD. CI, непрерывная интеграция, связывает внесение изменений в общий репозиторий с автоматическими сборками и проверками. Непрерывная доставка подготавливает проверенное изменение к выпуску. Разрешение установить его в рабочую среду может оставаться за человеком. Не путайте готовность к выпуску с автоматическим применением каждого изменения к работающему сайту.
Удобно пройти весь путь на одной задаче. Допустим, в форме добавляется поле с выбором услуги. Для пользователя изменение небольшое, но проверить нужно не только появление поля на экране. Значение должно попасть туда, где сотрудник принимает заявку. Это условный сценарий, а не описание выполненного нами проекта.
- Определить результат. Команда согласует, какие варианты видит посетитель, какое значение передаётся и как оно отображается получателю. Без этого автоматические проверки будут проверять неполное требование.
- Подготовить изменение. Код и необходимые настройки фиксируются предусмотренным порядком. Связь версии с исходниками позволяет позже понять, что именно установлено. Основы этого подхода разобраны в статье о работе с версиями проекта в Git.
- Собрать и проверить. Запускаются согласованные проверки. Если обязательная проверка не прошла, у процесса должен быть понятный результат: выпуск останавливается, ответственному доступно объяснение. Успешная сборка сама по себе не подтверждает доставку заявки.
- Пройти сценарий в тестовой среде. Посетитель выбирает услугу, отправляет форму, получатель проверяет запись. Нужно учитывать тестовый адрес назначения, ограничения внешней системы и отличия конфигурации. Рабочие персональные данные не следует переносить на стенд без предусмотренного компанией основания и порядка.
- Выпустить согласованную версию. Ответственный применяет изменение по принятому процессу. Фиксируются версия, время и результат установки. Далее команда проверяет пользовательский сценарий уже в предусмотренных условиях рабочей среды.
Инструменты помогают выполнять этот путь, но не заменяют его. Система CI/CD запускает заданные действия, а не угадывает требования заказчика. Контейнеры позволяют упаковать приложение и зависимости; вопросы данных и настроек всё равно нужно решать отдельно. Об этом есть материал про Docker в веб-проекте.
Различия окружений лучше записать заранее. В тестовом режиме письмо может уходить на другой адрес, платежи могут быть отключены, а интеграция работать с отдельным аккаунтом. Проверка должна учитывать, что именно нужно подтвердить в каждой среде. Иначе команда получит зелёный отчёт, который ничего не говорит о рабочем сценарии.
Отдельный вопрос: что делать с изменениями данных. Если вместе с кодом меняются поля или структура базы, нельзя заранее считать возврат старой версии безопасным решением. Попросите описать совместимость версий и порядок восстановления. Он должен учитывать уже появившиеся записи и действия пользователей, а не только файлы приложения.
При организации DevOps для проекта мы предлагаем принимать автоматизацию по выполненному сценарию: что запустилось, что проверилось, где сохранился результат и кто может повторить выпуск. Если часть работы остаётся ручной, её лучше назвать прямо.
Что проверять после запуска и как принимать работу
После установки процесс не заканчивается. В нашем примере главная страница открывается, форма выглядит правильно, но запись с выбранной услугой может не дойти до получателя. Поэтому наблюдение стоит строить вокруг нужного действия, дополняя его техническими сигналами.
Для формы полезно различать несколько событий: пользователь отправил данные, сервер принял запрос, подключение передало запись, получатель её увидел. Конкретные сигналы зависят от системы. Не все они доступны из коробки, и не каждый из них означает, что вся цепочка завершилась.
В руководстве Google SRE по мониторингу отдельно рассматриваются внешнее поведение сервиса и его внутренние показатели. Там же объясняется, почему статус HTTP 200 не всегда означает правильный результат. Для заказчика это практический вопрос: какую проверку команда выбрала и какую проблему она сможет заметить?
Сигнал должен вести к действию. Кому приходит уведомление? Кто смотрит подробности? Какой результат требует немедленной реакции, а какой можно разобрать в рабочем порядке? Условия дежурства и время реакции согласуются отдельно. Наличие графика или чата не подтверждает круглосуточную поддержку.
Не стоит выдавать симптом за причину. «Заявка не появилась» означает, что нужно проследить путь. Оно ещё не доказывает отказ сервера, ошибку кода или проблему внешнего сервиса. Сохраните доступные сведения и проверяйте предположения, прежде чем менять настройки.
Разбор инцидента полезно заканчивать конкретным решением. Если команда обнаружила непроверяемый участок, добавьте проверку. Если инструкция восстановления оказалась устаревшей, исправьте её и проверьте в согласованной среде. Если повторялись лишние уведомления, пересмотрите условия сигнала. Цель такого разбора: улучшить следующий выпуск, а не подобрать виноватого.
Как принять результат у подрядчика. Попросите показать один контрольный выпуск от выбора версии до проверки работы. Затем разберите предусмотренную ситуацию отказа в безопасных для проекта условиях. Не нужно специально ломать рабочий сервис: порядок и действия можно проверить на согласованном стенде.
На приёмке полезны три самостоятельных доказательства. Первое: команда может повторить выпуск по инструкции и показать его результат. Второе: выбранные проверки замечают предусмотренную проблему и передают сигнал ответственному. Третье: порядок восстановления учитывает приложение, настройки и данные, а после него проверяется нужное действие пользователя. Если какой-то пункт ещё не проверен, его нужно оставить открытым в акте или рабочем протоколе.
Передача доступа и знаний входит в эксплуатацию. У компании должны быть назначены владельцы репозиториев, инфраструктуры и необходимых аккаунтов. Другому ответственному нужна понятная инструкция, а секреты должны храниться предусмотренным компанией способом. Публичная документация не должна превращаться в список паролей.
Дальше сравнивайте фактическую работу с исходной проблемой. Стало ли меньше ручных шагов? Исчезла ли зависимость от одной инструкции в голове? Можно ли связать установленную версию с исходниками? Какие ошибки обнаруживаются до выпуска, а какие после? Для ответа нужны наблюдения и результаты, не число установленных программ.
В Гуси-Лебеди мы считаем полезным обсуждать DevOps через эти проверяемые действия. Работающий порядок помогает команде понимать, что она выпускает, как узнаёт о проблеме и как возвращает сервис к нужному результату. Именно это стоит согласовать до выбора инструментов и закрепить после внедрения.