Для того чтобы эффективно осуществлять разработку и поддержку IT продуктов и сохранять прозрачность и гибкость процессов бизнесам требуется интеграция современных технологий деплоя, разработки и других эффективных решений, которые предлагает сфера DevOps.
В нашей работе мы акцентируем внимание на реальные вызовы, с которыми сталкиваются наши клиенты и предлагаем решения исходя из них.
Итак, какие основные точки роста мы выделяем?
Поскольку мы всегда ставим на первое место бизнес интересы наших клиентов, мы должны иметь возможно объективно оценивать нашу работу. Для этого мы можем выделить следующие показатели:
● Частота развертывания — как часто код доставляется в продуктивные среде, или как часто конечные пользователи получают новые версии продукта.
● Время выполнения изменений — сколько времени проходит от загрузки кода в репозиторий до его развертывания в производственной среде.
● Время восстановления сервиса — сколько времени требуется для восстановления службы после ошибки или падения.
● Частота сбоев обновлений — какой процент развертываний приводит к ухудшению User Experience и требует устранения новых проблем, например путем выполнения откатов.
Эти показатели помогут вам оценить, насколько эффективна ваша компания DevOps и в каком направлении наша команда может Вам помочь.
Итак. Давайте по пунктам.
Частота развертывания
Проблема №1:. Мы задеплоили код, который не был протестирован, в результате чего наш сервис упал.
Задача инженера DevOps: Предоставить простой способ отката и помочь автоматизировать тестирование в инфраструктуре.
Проблема № 2: Мы развернули новую фичу с ошибками, и ее реализация изменила структуру базы данных и откат стал невозможным.
Работа DevOps-инженера: Помогать разработчикам создавать архитектурные решения, предлагать эффективные методы переноса данных.
Проблема № 3: развертывание сложное и занимает много времени. (Мы часто встречали образы Docker, создание которых занимает 20 минут. Это довольно распространенное явление у клиентов которые обращаются к нам.)
Задача DevOps-инженера: найти способ ускорить развертывание и откат, а также ускорить процесс сборки. (После оптимизации, мы доводили развёртывание до 5 минут и меньше)
Время выполнения изменений
Эта метрика полезна и для менеджеров. В конце концов работа менеджера — организовать рабочий процесс в котором код, написанный разработчиками, фиксируется и развертывается как можно быстрее. Но DevOps инженеры могут помочь с решением задач по организации такого рабочего процесса.
Проблема № 1: Между созданием и слиянием пулл реквестов в git проходит слишком много времени. Например, потому что по несколько раз делают ревью уже ранее проверенного кода. Корень проблемы здесь, опять же, в автоматизации процессов разработки программного обеспечения.
Работа DevOps-инженера: Вместе с менеджером по разработке автоматизировать слияние веток в git
Проблема №2: Ручное тестирование занимает слишком много времени.
Работа инженера DevOps: Помощь в автоматизации тестирования.
Проблема №3: Процесс сборки занимает слишком много времени.
Работа DevOps-инженера: Следить за тем, сколько времени занимает процесс сборки, и пытаться сократить его.
Для этого DevOps-инженер должен прежде всего понимать как работает ПО, как его автоматизировать и как интегрировать автоматизированное тестирование в процесс сборки. Кроме этого инженер DevOps должен разложить процесс развертывания ПО на отдельные компоненты и попытаться выяснить какие части можно оптимизировать с точки зрения скорости.
Вы можете отслеживать весь процесс от коммита кода до его развертывания в продакшене, узнавать сколько времени занимает процесс сборки и сколько времени требуется на одобрение пулл-реквеста, а потом вместе с менеджером и разработчиками выяснять где можно сэкономить время.
Время восстановления службы
Проблема № 1: Очень сложно выявить причины падений.
Работа DevOps-инженера: Обеспечить наблюдаемость и вместе с разработчиками настроить инфраструктуру мониторинга чтобы эффективно информировать Вас о производительности вашего сервиса.
Проблема № 2: В настоящее время инфраструктура не позволяет легко выполнять откаты.
Работа DevOps-инженера: Обеспечить своевременные откаты на стабильные сборки.
Проблема №3: Миграция сделала невозможным выполнение откатов.
Задача инженера DevOps: обучать разработчиков передовым методам обеспечения отказоустойчивости, а также миграции данных, обеспечивающей легкий откат.
Частота сбоев изменений
Этот показатель также относится к сфере менеджмента. Однако есть забавный факт которые многие упускают из вида: сбои случаются чаще, если развертывания происходят нечасто.
К сожалению, мы часто видим, как компании решают начать DevOps-трансформацию и внедряют Kubernetes и GitOps, но все это никак не влияет на частоту их релизов. Их подход остается прежним. Если до внедрения этих технологий разработка новой версии продукта занимала шесть месяцев, то и сейчас она занимает всё те же шесть месяцев. А когда вы пишете код, для запуска которого в производственной среде требуются месяцы, такой код с гораздо большей вероятностью даст сбой, чем код, развертываемый еженедельно. Этот менталитет подрывает всю трансформацию DevOps — если компания хочет внедрить DevOps, но их цикл разработки занимает шесть месяцев, это большая проблема.
В этой ситуации DevOps-инженер должен бить тревогу и пытаться еще раз достучаться до бизнеса, объяснив какую ценность приносит DevOps инфраструктура и как нужно изменить подход к разработке программного обеспечения с учетом новых возможностей.
Business First подход
DevOps инженеры должны иметь четкое представление о том, что нужно бизнесу, и работать над удовлетворением этих потребностей.
Вот основные принципы которыми мы руководствуемся в нашей работе:
● Стабильность текущей версии не так важна, как, во-первых, стабильность инфраструктуры в целом и, во-вторых, возможность в случае сбоя откатиться на предыдущую версию, изолировать проблему и быстро устранить ее.
● Стабильность среды разработки критически важна, особенно если в команда разработчиков большого размера. Когда всему отделу разработки приходится прекращать работу из-за проблем со средой разработки, это так же плохо, как простои на заводе.
● Мониторинг процесса доставки программного обеспечения теперь является частью мониторинга всей инфраструктуры. Если на развертывание чего-то уходит 20 минут нужно работать над его ускорением.
● Скорость доставки программного обеспечения стала одной из ключевых областей для улучшения. В идеале у вас должен быть высокоэффективный конвейер работающий без сбоев.
● Удобная среда разработки — еще одна ключевая задача. Если разработчики могут использовать среду без каких-либо проблем, они пишут код быстрее, чаще его развертывают, а качество кода в целом выше.
Ставя на первое место задачи бизнеса и понимая все современные тренды сопровождения разработки, мы успешно помогаем таким компаниям как Билайн налаживать непрерывную поставку приложений.