Часто слышу вопросы о том, что такое DevOps. Чем отличается это от привычных ролей в ИТ. Может это всего лишь модный термин, свистелка в виде модной профессии.

Что такое DevOps? Это скорость. Это интердисциплинарность. Это синергия. Это новая элита ИТ.

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

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

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

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

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

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

Представим систему из более чем 200 сервисов, которые обьединены в высокоскоростную динамическую среду, обслуживающую тысячи запросов в секунду, где каждое действие отображается цепочкой асинхронных запросов. Система, где на первое место поставленна надежность и скорость. Где широко применяются системы кэширования, со своими проблемами, где сервера обьединены в кластеры, и где асинхронность поставлена во главу угла. И существует несколько копий таких систем. Я говорю об окружениях. Как правило их 4-5, DEV, TEST, UAT, DEMO, PROD. Как в системе такого порядка наладить процессы развертывания приложений, циклы разработки различных команд должны быть синхронизированны между собой. Как управлять этим всем, и как решать проблемы возникающие в процессе работы? Поиск ошибок, устранение и развертывание фиксов на всех окружениях становятсй сложными и затратными.

С применением Test-Driven-Development, Continuous Integration and Delivery, систем контроля и мониторинга, Agile подхода можно довести скорость релизов до невообразимых порядков. К примеру Google в неделю имеет более 2х миллиардов builds. Правда, они считают по instance, умножают по количеству серверов в кластерах, а масштабировать эти парни умеют очень хорошо, но тем не менее, 2 миллиарда в неделю! Другие интернет гиганты имеют не менее потрясающие цифры. Грубо говоря DevOps это ответ на вызовы стоящие перед компаниями, такими как Facebook, Yahoo, Yammer, Amazon, Google, VMware и многими другими.

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

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

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

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

В своей работе половину времени я занимаюсь разработкой. В основном это инфраструктурные проекты в рамках Continuous Integration and Delivery. Другая половина — это траблшутинг и это наиболее интересная часть. Наш отдел это Special Forces, который решает ключевые проблемы, занимается performance-engineering, анализирует результативность команд разработчиков и делится знанием, как и что можно улучшить.

У нас сумасшедший темп, баги и проблемы не стоят в очереди, и все направлено на повышения качества. Сегодня я могу решать проблемы с ростом количества потоков в приложении, и обнаружить, что они не закрываются при сборке мусора. Я дорабатываю код, и провожу по цепочке окружений. Вчера я мог столкнуться с проблемой конфигурации load-balancer HAProxy в системе аутентификации. Завтра я столкнусь с таймаутами при вызове сервисами друг-друга из-за сборки мусора и буду решать ее. С каждым днем наращивается опыт и обьем знаний в самой широкой сфере, и ни одна роль в ИТ не дает такого. Это похоже на работу детектива или врача диагноста. Среднее между Шерлоком Холмсом и доктором Хаусом. Симптомы не похожи на причины. Aнализ логов, построение цепочек запросов, мультипоточное окружение, все это то, что не встретится в работе разработчика. И этот путь альтернатива тому, что стоит в «конце карьеры» программиста. Идти по бизнес линии в проект менеджеры, или по технической части в архитекторы. Это иной путь. И DevOps это в некотором смысле дзен ИТ. Снятие шаблонов мышления, выход за рамки, глубокое понимание и легкость движений.

Добро пожаловать в DevOps.