Фреймворк CALMS

Проблемы и экстренные ситуации как нельзя лучше проверяют культуру DevOps. Способны ли разработчики, инженеры по эксплуатации и специалисты по работе с клиентами вместе штурмовать проблему и решать ее, как одна команда? Ищет ли команда способ улучшить результаты при устранении будущих проблем во время разбора инцидента (вместо поиска виноватых)? Если ответ на эти вопросы «Да», значит, в вашей организации существует культура DevOps.

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

Автоматизация позволяет устранить монотонную ручную работу, сформировать воспроизводимые процессы и создать надежные системы.

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

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

«Почему?», — спросите вы. Компьютеры выполняют тестирование строже и добросовестнее, чем люди. Благодаря этим тестам можно раньше выявить баги и уязвимости. Наконец, при автоматизированных развертываниях специалисты по ИТ/эксплуатации получают оповещения об отклонениях среды, что позволяет минимизировать неожиданности в момент выпуска релиза.

Еще одно важное преимущество DevOps — использование принципа «конфигурация как код». Разработчики стремятся создать модульные, компонуемые приложения: такие приложения более надежны и удобны в обслуживании. Этот принцип применим и к инфраструктурам, в которых размещаются приложения, — как к облачным, так и к локальным сетевым ресурсам компании.

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

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

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

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

Кстати, вы знаете, что неудачи неизбежны? Поэтому стоит учить свою команду принимать поражения, восстанавливаться после них и делать соответствующие выводы (некоторые называют этот процесс «антихрупкостью»). Мы в Atlassian считаем, что если вы периодически не сталкиваетесь с неудачами, значит, вы работаете не в полную силу.

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

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

Измерить можно практически все. Но это не значит, что вам обязательно нужно измерять все показатели. Давайте обратимся к agile-разработке и начнем с основ.

Сколько времени проходит от разработки до развертывания?

Как часто ошибки или сбои возникают повторно?

Как долго выполняется восстановление после системного сбоя?

Сколько человек использует ваш продукт в настоящее время?

Каким был приток/отток пользователей на этой неделе?

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

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

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

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

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

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

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

С помощью Open DevOps от Atlassian команды могут создать желаемый пакет инструментов благодаря интеграциям с ведущими поставщиками и приложениями из Marketplace. Попробуйте прямо сейчас.