Сколько DevOps нужно, чтобы всё было хорошо

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

Давайте разбираться, как, куда и зачем внедрять DevOps-практики в своем высокотехнологичном бизнесе/IT подразделении и какие выгоды это принесет.

Что такое DevOps? Я что-то подзабыл

DevOps — это методология, а вернее даже философия разработки веб-приложений, в основе которой лежит ряд принципов:

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

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

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

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

Так выглядят основные принципы DevOps. Теперь осталось определиться, на что лучше сделать упор в вашем случае и какие методики стоит выбрать — в зависимости от размера и стадии развития вашей компании.

1. Стартапы и мелкий бизнес (IT-команда в 1-5 человек)

Что полезно сделать?

Автоматизировать и максимально упростить деплой новых версий и багфиксов. Для этого идеально подходит контейнеризация приложений с помощью Docker и развёртывание контейнеров с новыми версиями кода в облаке с помощью Docker Swarm или Kubernetes. Команда сможет сфокусироваться на написании кода, а машины возьмут на себя всю работу по доставке кода конечному пользователю.

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

Делать бэкапы. Маленькие команды (особенно на ранних стадиях развития) часто забивают на этот пункт. Не забивайте — лучше 1 раз автоматизировать, чем хоть раз узнать, что такое восстанавливать с нуля все данные. Тем более, что сейчас существует огромное количество систем резервного копирования для любых целей — от примитивных самописных скриптов и простых решений для одного сервера до готовых облачных решений и огромных систем уровня предприятия.

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

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

— А как поведет себя приложение при запуске на тысяче серверов?

— Проверить легко, создаем скриптами 1 000 облачных серверов, раскатываем тестируемый софт и собираем результаты!

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

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

Кому это делать?

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

2. Компании в стадии активного роста и средний бизнес (ИТ команда в 5-20 человек)

Что полезно сделать?

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

Сделать полностью автоматическую выкатку новых версий сервиса. В идеале новые версии должны выкатываться по нажатию одной кнопки или вообще без нажатий — сразу после внесения правок в стабильную ветку кода. При этом должен происходить полный цикл сборки всех компонентов вашей системы, полный прогон всех возможных тестов и в случае успеха — выкатка нового функционала на сервер с рассылкой уведомлений всем сотрудникам компании. Этот подход еще называется CI/CD (Continuous Integration/Continuous delivery) – непрерывная доставка в автоматическом режиме новых функций от разработчика к пользователям.

Настроить глубокий мониторинг всех аспектов поведения железа, сервисов и вашего продукта. Серверы должны работать стабильно, везде должно хватать памяти, процессоров и дисков. Сервисы должны быть доступны и отвечать в заданное время. Например, время отклика веб-сервера не должно превышать какой-то разумный порог (допустим, для веб-страницы это 0.5 секунды). Само приложение должно подробно отчитываться о всех важных параметрах своей работы и о поведении пользователей в системе. Сюда уже стоит включать параметры вроде количества отправленных писем, запросов в БД, разбивки активности пользователей по минутам и многое другое. Надо как следует разобраться с системами хранения и обработки аналитики — Prometheus, Grafana, которые, опять-таки, можно развернуть в облаке. Метрики активности систем позволяют увидеть реальную картину использования вашей системы пользователями, а это куда информативней и правдивей, чем любые интервью и тесты с фокус-группами.

Автоматизировать и/или упростить восстановление после сбоев. Это касается развёртывания резервных копий, обработки случаев отказа сервера в кластере или падения каналов связи.

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

Автоматизировать управление конфигурациями серверов. Хранить конфигурации уже недостаточно — нужно уметь за минуты (а то и секунды) поднять новый сервер и включить его в кластер имеющихся машин. Здесь уже становятся обязательными Salt, Ansible, образы операционных систем и прочие способы автоматизации.

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

Кому это делать?

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

3. Компании с большой нагрузкой и крупный бизнес (ИТ команда в 20+ человек)

Что полезно сделать?

И опять — убедиться, что вы уже выполняете все советы для команд до двадцати человек. А потом приступать к улучшениям.

Автоматически развертывать всю инфраструктуру программными способами. Нужно иметь возможность в одно нажатие создать, например, 20 новых облачных серверов, ввести их в уже сформированный кластер, автоматически сконфигурировать все сервисы и направить на них трафик.

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

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

Мониторить и реагировать на все инциденты в системах безопасности. Например, попытки взломов или странные активности в системе (многочисленные вводы неправильных паролей, странные списания денег со счета, странный заказ на 100 000 холодильников на один адрес или возросшее количество логинов из Центральной Африки ровно в 3 часа ночи).

Делать много тестов. Тесты и еще больше тестов. Нагрузочные тесты. Тесты скорости работы. Смоук-тесты для проверки работоспособности новых версий на боевых серверах. Тесты взаимодействия подсистем.

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

Кому это делать?

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