DevOps практики оптимизируют разработку ПО: увеличивают скорость, производительность и качество рабочих процессов.
Как отметил Патрик Дебуа – пионер DevOps – успешный подход к DevOps определяет тактика. Но без помощи в анализе данных трудно получить стратегическое представление о том, как модернизировать повседневную работу команды разработчиков: например, как автоматизировать рутинные задачи DevOps или как разрабатывать надежное и отказоустойчивое ПО. Помощь приходит в лице искусственного интеллекта. AIOps, дисциплина применения ИИ и расширенной аналитики к ИТ-операциям, изменил способы управления сложными системами в организациях. Интеллектуальный подход в DevOps (AIOps к DevOps) означает использование ИИ на протяжении всего жизненного цикла разработки программного обеспечения (SDLC). А совмещение DevOps c SRE (проектирование надежности сайта) в буквально смысле преобразует бизнес.

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

DevOps — это гибкая структура методов разработки, которую организации используют для создания ПО, путем согласования и координации усилий по разработке программного обеспечения («Dev») с ИТ-операциями («Ops»).

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

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

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

В конечном итоге SRE помогает организациям достигать операционных целей: сокращать время простоя, быстро исправлять ошибки, определяя и автоматизируя цели уровня обслуживания (SLO).

SRE и DevOps, по сути, две стороны одной медали. В то время как среды DevOps ориентированы на совместную работу на протяжении всего жизненного цикла и устранение разрозненности, надежные SRE помогают внедрять и автоматизировать методы DevOps с использованием SLO: они обеспечивают отказоустойчивость систем и создаваемого DevOps программного обеспечения.

По словам Энди Грабнера, сотрудника DevOps в Dynatrace, «DevOps и SRE — это баланс между скоростью и безопасностью». В то время как DevOps помогает организациям двигаться слева направо по жизненному циклу разработки и эксплуатации, чтобы повысить общую скорость, SRE движется справа налево, чтобы помочь снизить частоту сбоев на ранних этапах цикла разработки.

Хотя DevOps возможен и без SRE, эти два процесса лучше всего работают в паре: вместе они создают непрерывный цикл, обеспечивающий постоянные улучшения в обоих направлениях конвейера CI/CD.

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

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

В то время как CI фокусируется на регулярных, независимых обновлениях кода в центральном репозитории, непрерывная доставка CD фокусируется на выпуске завершенных блоков кода в репозитории через регулярные промежутки времени. Эти блоки кода всегда должны быть в состоянии развертывания для тестирования или запущены в производство.

CD часто путают с непрерывным развертыванием — следующим процессом, — который выпускает окончательный код в производство. Развертывание — это действие по предоставлению конечным пользователям нового и обновленного программного обеспечения. Соответственно, CD в первую очередь означает «непрерывная доставка» или как «непрерывная доставка, так и развертывание», но редко просто непрерывное развертывание.

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

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

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

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

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

Еще одна фундаментальная практика DevOps — непрерывная безопасность, основанная на тестировании, мониторинге, авторизации и отслеживании запасов. Это эволюция в сторону DevSecOps. Проще говоря, непрерывная безопасность — это процесс превращения безопасности в часть процесса CI/CD, охватывающий весь SDLC. Безопасность становится дополнительным уровнем, располагающийся поверх процесса и конвейеров DevOps. Это гарантирует, что ваша инфраструктура и приложения будет работать без уязвимостей. Сегодня, когда мы видим, что среды становятся все более сложными, подход к безопасности «на болтах» не является масштабируемым или устойчивым.

Необходимо встраивать безопасность в автоматизированные процессы, чтобы обеспечить непрерывное и безопасное тестирование на протяжении всего жизненного цикла разработки. В том числе во время работы программного обеспечения в производственной среде. Кроме того, любые применяемые меры безопасности тоже должны быть автоматизированы, чтобы не снижать эффективность. С точки зрения культуры, сотрудники службы безопасности рассматриваются как полноправные партнеры в процессе DevOps: наравне с разработчиками и специалистами по эксплуатации — отсюда и сдвиг в сторону DevSecOps.

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

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

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

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

Традиционно такие процессы, как тестирование, мониторинг, обнаружение и исправление ошибок, включали небольшую автоматизацию и большое количество ручного труда. Это работало, когда небольшие группы трудились над монолитными приложениями. Но с современными микросервисными приложениями это невозможно. Цифровая трансформация оказывает еще большее давление на ИТ: удержаться в гонке помогает автоматизация, обеспечивая согласованные процессы на каждом этапе жизненного цикла DevOps. В результате вы можете чаще отправлять код в производство и создавать согласованное, надежное и безопасное программное обеспечение.

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

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

Использование ИИ как части процессов DevOps позволяет повысить функциональность и автоматизировать циклы разработки, тестирования, безопасности, поставки и выпуска, а также осуществлять постоянный мониторинг.

SRE всегда ориентируются на цели уровня обслуживания (SLO). Для обеспечения соответствующего уровней производственного обслуживания требуется непрерывная оценка индикаторов уровня обслуживания (SLI) в сравнении с SLO. Но возникает вопрос: почему бы разработчикам не убедиться, что код, который они создают, соответствует тем же производственным SLO? Эта концепция смещения влево улучшает качество программного обеспечения, помогает обнаруживать проблемы на более ранних этапах жизненного цикла и предотвращает выпуск кода, который не соответствует производственным SLO, на следующий этап.

Результатом является меньшее количество нарушений SLO в производстве, экономия времени и денег из-за меньшего количества или отсутствия летучек, но, что более важно, обеспечение 100% соблюдения соглашений об уровне обслуживания (SLA).

Один из способов автоматизировать этот процесс сдвига влево, использовать пороги качества, которые позволяют автоматически сравнивать SLI любого конвейерного инструмента (например, мониторинга и тестирования) с заранее определенными SLO. Если код не проходит порог качества на основе SLO, он не может перейти к следующему этапу, и система автоматически уведомляет группу разработчиков о необходимости устранения проблемы.

Прогрессивная доставка (также называемая сдвигом вправо) фокусируется на расширении общих методов CI/CD, чтобы усилить контроль доставки приложения и услуг. Это позволяет организациям управлять тем, как и когда поставляются новые функции, обновления и исправления, чтобы свести к минимуму негативное влияние на пользователей. Некоторые распространенные методы включают сине-зеленое развертывание, A/B-тестирование, канареечное развертывание и функциональные флаги.

Сине-зеленое развертывание

Эта модель выпуска приложений постепенно переводит пользователей с текущей версии приложения или службы («синяя» версия) на новую версию («зеленая» версия), в то время как и синяя, и зеленая версии работают в рабочей среде. Это изменение должно быть незаметным для пользователя, а синий может быть в резерве на случай, если непредвиденная проблема с зеленым потребует отката к более ранней, стабильной версии.

A/B-тестирование

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

Фиче-флаги

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

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

Канареечное развертывание

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

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

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

Как насчет безопасности сдвига вправо? Это тоже важно. После нескольких лет «сдвига влево» предприятия понимают, что им также необходимо поддерживать видимость в производственной среде. Мы видели много успешных атак на среды Kubernetes — от вредоносных вирусов, которые были вставлены в хаб Docker в 2020 году, до атак на Azure и Tesla со стороны «криптоджекеров». Вот почему 44 % предприятий планируют внедрить новые элементы управления безопасностью во время выполнения (Shift-Right) в течение следующих 12–24 месяцев.

Вот причины, по которым автоматизированная безопасность (DevSecOps) должна перейти прямо в производственную среду:

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

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

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

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

Надежные, измеримые данные необходимы для автоматизации тестирования, коммитов и выпусков. Чтобы внедрить передовой опыт, организации могут начать с проекта, созданного командой Google DevOps Research and Assessment (DORA), известного как «Четыре ключа», который определяет четыре основных показателя, отражающих производительность команды DevOps. Итак, каковы четыре ключа DORA и какие другие ключевые показатели могут отслеживать организации, чтобы улучшить свои методы DevOps и SRE?

Частота развертывания измеряет, как часто организация успешно выпускает продукт в производство. DevOps и непрерывная интеграция/непрерывная поставка (CI/CD) идут рука об руку. Команды теперь работают с меньшими блоками кода, а непрерывное тестирование и проверка позволяют быстрее выполнять коммиты. Такой темп разработки означает, что команды могут делать несколько выпусков в день.

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

Частота развертывания является как долгосрочной, так и краткосрочной метрикой. Например, в качестве показателя эффективности, вы можете измерить, сколько коммитов кода вы отправляете ежедневно или еженедельно в ответ на изменения процесса. В течение более длительных периодов времени команды могут отслеживать как увеличивается количество развертываний с течением времени. Графики медленного выпуска могут указывать на узкие места или задержки обслуживания.

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

Тем не менее, время выполнения заказа не является на 100% плохим или хорошим.

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

Два важных способа сократить время подготовки к внесению изменений — внедрить тестирование обеспечения качества в нескольких средах разработки и автоматизировать процессы тестирования и DevOps.

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

Высокий уровень неудачных изменений (более 40%) может указывать на неотлаженные процедуры тестирования и требует, чтобы команды часто вносили небольшие изменения, что снижает эффективность.

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

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

MTTR измеряет, как долго система восстанавливается после производственного сбоя. Пользователи зависят от доступности функций, а время безотказной работы 99,99+% является желанной целью.

Чтобы определить MTTR, вы можете оценить время между возникновением инцидента и время, когда это было решено. Какое развертывание разрешило этот инцидент? Наблюдаемость в данных развертывания и данных c взаимодействием с пользователем является ключом к пониманию того, было ли эффективно восстановлено обслуживание. Длительное время восстановления может указывать на плохой мониторинг и может привести к увеличению числа затронутых систем.

Лучшей практикой для достижения быстрого MTTR является развертывание программного обеспечения небольшими шагами, чтобы снизить риск, и развертывание автоматизированных решений для мониторинга, чтобы предотвратить сбой. MTTR — еще одна метрика, которая сильно различается между системами.

Хотя четыре ключа DORA являются важной основой, существует множество показателей, которые вы можете использовать для отслеживания эффективности ваших процессов DevOps и SRE. Вот еще шесть показателей, которые вы можете отслеживать для целостной оценки эффективности вашей воронки продаж.

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

Эффективность и действенность методов DevOps зависит от мониторинга ключевых показателей, таких как четыре ключа DORA, которые измеряют частоту развертывания, время выполнения изменений, частоту отказов изменений, доступность приложений и среднее время восстановления службы (MTTR) среди прочих.

Чтобы упростить практику DevOps, SRE и CI/CD, платформа Software Intelligence от Dynatrace на базе нейросети легко интегрируется с набором инструментов DevOps и автоматизирует задачи на протяжении всего жизненного цикла DevOps. Благодаря непрерывной автоматизации и точному определению первопричин, Dynatrace позволяет организациям улучшить работу DevOps, избавляя их от рутины и улучшая качество выпущенного кода.

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

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

Вам поможет безопасное развертывание с прогрессивной доставкой. За счет автоматизации канареечного и синего-зеленого развертывания, переключения фич-функций, включая запуск откатов и исправлений, вы держите под контролем качество новых релизов.

Повысьте качество, безопасность, сократите расходы за счет постоянной проверки ПО на препроде с выставленными заранее критериям качества и SLO.