Зачем вам DevOps?

Что в сущности представляет из себя DevOps?

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

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

В DevOps выделяются три ключевые практики:

• инфраструктура как код
• непрерывная интеграция\непрерывная поставка (CI/CD)
• непрерывный мониторинг (Observability)

Инфраструктура как код - это подход, направленный на то, чтобы вся ваша инфраструктура от самого нижнего уровня (сети, оборудования, количество ресурсов, базы данных, очередь сообщений, кэширующие сервера и т.д.) была описана в виде кода. И не только они, а и все, что выше - application level, то, как разворачиваться ваше приложение, какая у него конфигурация, web-сервера. Это позволяет, во-первых, увеличить скорость: если вам надо, допустим, развернуть еще один сервер, и если уже есть такой же настроенный, с помощью этого подхода вы сможете получить новый, такой же сервер, изменив одну переменную или нажав всего одну кнопку. Во-вторых - контроль изменения. То есть вы знаете, кто, когда и что поменял. Если у вас происходит какой-то инцидент, вы сразу сужаете область поиска до того места, где вы что-то поменяли. Это дает идентичность сред разработки и продакшена, то есть у вас одинаковые версии библиотек, различных сервисов, баз данных, языков программирования, фреймворков. Когда у вас есть полный контроль над вашей конфигурацией, это позволяет уменьшить количество ошибок, которые происходят при внесении изменений в этот процесс.

Непрерывная поставка (CI/CD)

DevOps, в первую очередь, про скорость, про time-to-market, то есть про то, насколько быстро мы можем выводить изменения в наших продуктах на рынок без потери функциональных требований, таких как производительность, отказоустойчивость, безопасность.

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

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

Непрерывный мониторинг

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

Мониторинг - это тот подход, при котором то, что вы выкатываете в продакшен, сразу же обвешано метриками. Эти метрики создаются на этапе создания нового функционала. Помимо того, что вы пишете код, который делает новую функцию, вы пишете код, который тестирует новую функцию, и также вы пишете код, который мониторит эту функцию.
Второй “кусок”, который входит в эту практику - непрерывное логирование, как мы его называем, или Observability.

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

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

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

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

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

• Инфраструктура как код: типичные инструменты, которые используются, это системы управления конфигурации - Ansible, Puppet, Chef, SaltStack, для управления инфраструктурой используется Terraform. Нельзя также не упомянуть про kubernetes, внутри него вы используете Helm для управления инфраструктурой, и Docker-контейнеры для упаковки ваших образов.
• Непрерывная поставка: здесь самые популярные инструменты - Jenkins, Gitlab и Bamboo из бесплатных, и стоит упомянуть Teamcity из платных систем. Они похожи по функционалу, и основная их задача - нарисовать красивый пайплайн, автоматизировать и визуализировать все этапы, чтобы понять, как ваш конвейер поставки ПО движется по всем этапам.
• Мониторинг: здесь безусловная победа ELK-стека, то есть это Elastic, Logstash, Libana для систем централизованного логирования и поддержки observability, и Prometheus как система мониторинга.

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