Кто такой DevOps и почему это не то, что нам обещали
Меня зовут Денис Наумов, я спикер курса «Python для инженеров». Курс создан для того, чтобы инженеры могли прикоснуться к программированию. Есть и вторая цель — развеять мифы о параллельности DevOps и разработки.
В этой статье я хочу поделиться своим пониманием DevOps с двумя примерами из практики: собственной и моих коллег. Как говорится, «добро пожаловать под кат».
Кто такой DevOps-эксперт и почему это не то, что нам обещали
Если перечитать вакансии на позиции DevOps-инженеров и выделить нечто общее, то образуется суперкластер требований и звучат они так:
настраивать и поддерживать инфраструктуру на Kubernetes;
настраивать пайплайны валидации кода, сборки, тестирования и деплоя;
обеспечивать CI/CD-процессы.
Складывается стойкое ощущение, что DevOps-эксперт это человек, который:
вместо виртуализации использует контейнеризацию;
знает синтаксис и возможности инструментов CI/CD;
знает, как подготовить машину к «приему» контейнеров;
умеет совмещать три предыдущих пункта.
Звучит уже не так весело, как обещали. А на заре становления DevOps обещали, что это не методология, а целая культура. Идеальный мир, где тесное сотрудничество разных команд воплощается через общую цель: сделать хорошо себе и клиенту. И самое важное: DevOps не был культурой написания over 9000 пайплайнов.
Свобода творчества должна была проявляться буквально во всем. Начиная от выбора стека, технологий и инструментов, проходя выбор самих задач и заканчивая прямым влиянием на процессы внутри компании. Все это вместе делало из DevOps-сферы работу мечты.
Время шло, культура внедрялась, что-то действительно стало так, а что-то стагнировало и выродилось в рутину. Все свелось к администрированию, но с использованием технологий, обеспечивающих идемпотентность и какую-никакую стабильность. Со всем приданным, включая нюансы отношений между разработчиками и инженерами.
Ходят легенды о том, что первые администраторы были превосходными программистами, а первые программисты — администраторами. Затем специальности разделились на множество разных видов администрирования и программирования, а сейчас цикл замыкается.
Сегодняшние инженеры не понимают, почему разработчики мешают им строить архитектуры не по принципу «сделайте хоть как-то, красиво будем делать после». Разработчики все так же не понимают почему, пользуясь инструментами для придания идемпотентности и отказоустойчивости, нельзя сделать механизм, который всегда срабатывает одинаково успешно.
В сухом остатке две стороны: разработчики — генератор on-call задач в самое неподходящее время, инженеры — герои мемов наподобие тех, что о дата-саентистах, кроссвалидации и 300к/сек. Только вместо дата-саентистов там DevOps-инженеры.
В результате труъ-инженеры должны смотреть косо на все, что связано с разработкой, умышленно отрезая себе путь в тот самый «истинный» DevOps. Замкнутый круг.
Мне повезло чуть больше: в компаниях, где я работал, DevOps зарождался самостоятельно, и мы не знали о рамках и ярлыках. Мы вообще узнали о том, что это DevOps гораздо позже создания инструментов. Пару историй об этом я хочу рассказать.
Выстраивая мосты
Когда я начал свою карьеру, IT-мир переживал потрясение за потрясением: монолитные приложения стремительно распадались сначала на бэкенды и фронтенды, а затем и бэкенды продолжили распадаться на микросервисы.
Разработчикам открывались новые возможности выносить в отдельные единицы не только части кода в виде библиотек, но и доменов бизнес-логики в виде микросервисов. CI процессы были настроены и картина ничем не отличалась от других компаний.
Я работал в команде обработки данных. Наши сервисы находились в ядре всей системы. Писали мы , как и все, не без багов и логических ошибок. Другие команды этим охотно пользовались. Кто-то минимизировал риски, перенося часть логики на сторону своих сервисов, чтобы не ждать нас. Кто-то использовал наши сервисы нецелевым путем.
Любое исправление или реорганизация кода было потенциально опасно. Конечно же инструментов вроде аппрувов в merge request«ах тогда не существовало. И меня, как джуна, временем которого пожертвовать не страшно, перевели на эту задачу. Если говорить совсем честно, то бросили этой задачей в меня с формулировкой: «Хочешь, чтобы команда действительно приняла тебя? Попытайся сделать так, чтобы от вашей дискоммуникации ничего не ломалось».
Какой стек, какие возможности, какая архитектура решения никого не волновало и это пугало больше всего. Я слышал столько жалоб на легаси-технологии, что было действительно страшно сделать нерасширяемый проект. В какой-то момент я почти согласился признать свое бессилие, но азарт взял свое, я начал пробовать и втянулся в структурирование хаоса.
Сначала ввели то, что сейчас называется commit conventions: некоторые теги в commit message, для того, чтобы отличать характер изменения и генерацию changelog«a по ним. Используя changelog QA могли ретроспективно отслеживать важные изменения и проверять регрессию.
Потом научили программу строить деревья зависимостей в проектах и звать в корпоративном мессенджере на ревью всех заинтересованных. Дали обновлению имя «активные деплои». Этого хватило, чтобы установить шаткие, но все же мостики коммуникации между командами.
Техлиды начали договариваться, иногда даже шли на уступки друг другу в ущерб показателям эффективности своих команд, чтобы не сломать ничего другим. Задача была выполнена, думал я. Но так заставляло меня думать мое нежелание просматривать оповещения системы контроля версий.
Периодически поглядывая на проект, я все чаще ловил себя на мысли, что уже не узнаю его. Мой код подвергли рефакторингу, на добровольных началах добавлялась новая функциональность. Например, система не только отправляла уведомления, но и следила за тем, чтобы кто-то из ведущих разработчиков зависимых проектов написал сообщение о готовности к изменениям. Только тогда система позволяла отправить новую версию в релиз.
Постепенно логики становилось больше, опасные для каждого из проектов изменения определялись на основе разных правил. Логику адаптировали и для отслеживания миграций в схемах БД. И удивляло то, что разработчики с разными представлениями об идеальном коде не мешали друг-другу в рамках одного проекта. По их словам, такой валидатор помог им не только уберечь свои проекты от поломок, сделать архитектуру чище, но и научиться взаимодействовать так, чтобы все оставались в выигрыше.
Важная оговорка: не все моментально стало радужно. Сначала все происходило через принуждение: автоматику ведь не обманешь. Но постепенно люди начали понимать как извлекать пользу и те, кто выступал против строгости бизнес-процессов, начинали призывать пользоваться новым инструментом и активно его развивать. Кажется, что максимальное соответствие идеям DevOps было достигнуто: хорошо всем.
Делая прозрачнее
Эта история, в отличие от первой, произошла недавно. Я отвечал за техническую сторону направления аналитики в ISPsystem. Само направление аналитики для компании было новым и при создании мы выбрали путь культуры данных и удобных инструментов вместо работы по заявкам и готовых ответов.
Требовалось покрыть инструментами много различных бизнес-доменов в максимально сжатые сроки. Мы довольно быстро начали сталкиваться с тем, что тратили большую часть времени на реализацию каких-то чрезмерно сложных алгоритмов, которые решали узкий спектр задач.
В принципы прототипирования и экстремальной разработки это вписывалось чуть менее, чем «никак». Планирование и обсуждение задач до начала работы над ними дало краткосрочный эффект. В основном в задачах, где ход реализации был более-менее предсказуем. В остальных задачах планирование хода решения порождало еще больше подзадач «для полноты картины»: сделать вроде надо, но зачем — непонятно.
Пятиминутная ретроспектива у кофемашины привела к выводу, что проблема в нас. Мы привыкли генерировать ход решения задачи прямо в момент её решения и совершенно не готовы инвестировать в изменение своего восприятия. Сказано — сделано.
Так появилась первая и последняя внутренняя задача, созданная руками: «Научить GitLab управлять задачами на основе TODO в коде». Идея была такова, что любая задача выполняется частями, на каждую задачу дается фиксированный интервал времени. По окончании времени должен быть создан полезный артефакт: рабочий код, документация, эскиз и новые TODO-комментарии. Либо задача закрывается как несвоевременная и больше не открывается никогда. Если она действительно нужна, рано или поздно наработки позволят вернуться к ней другим путем и выполнить по этой схеме.
В таком подходе нет ничего нового, нужно только вовремя понять свой стиль работы и позволить себе использовать его максимально эффективно. Так появился модуль, который обнаруживает различные виды комментариев в языках. GitLab любезно дедуцирует используемый язык, что позволило сделать проект не только универсальным, но и автоконфигурируемым.
Другой модуль интегрировался с трекером задач и создавал или закрывал задачи с проставленным пользователем, временем и прочими атрибутами на основе содержимого merge request«а.
Третий модуль управлял содержанием TODO-комментариев проставляя ссылки на созданные задачи и внося новые commit«ы. Некоторые сложности возникли с deadline-таймером выполнения задачи. Хотелось оставить себе возможность управлять им, бывают ведь разные ситуации. Но механизм обратных вызовов на действия в трекере эту проблему полностью решил. Имея под рукой текстовый редактор и git можно разрабатывать не вспоминая о том, что такое учет рабочего времени и ведение задач. А сынтегрировавшись с мессенджером, можно про это забыть, управляя через репозиторий не только кодом, но и всеми аспектами рабочего процесса.
Чем мы в итоге довольны:
тем, что не пришлось ничего менять;
тем, что съедающие время задачи отсеиваются автоматически и не могут быть созданы снова;
тем, что в процессе дали бизнесу инструмент, показывающий как и куда тратится время;
тем, что так происходит не только с кодом, но и с прочими артефактами, включая знания, которые еще и версионируются;
тем, что немного отвлеклись и решили совсем внешнюю по отношению к команде задачу.
Предвидя критику, могу сказать, что такой вариант действительно подходит не всем. Хороший работодатель всегда «за» определение комфортного стиля работы своих сотрудников. Как правило, они подчиняются психологическим паттернам, и вы рискуете сделать хорошо не только себе, но и вашим коллегам. Более того, инструмент никак не связан с контролем каждой минуты рабочего времени сотрудника. Случались и переработки из-за того, что коллеги описывали внезапные идеи через эту систему, пока, к примеру, шли в магазин. При этом доля программирования в рабочем дне бывала всего час или два.
При чем здесь программирование?
Возможно ли делать подобные инструменты не умея программировать? Да. Проще ли их делать, если все же уметь? Да, гораздо.
Программирование это давно не про разработчиков, иначе IT-мир бы коллапсировал в технологической сингулярности еще несколько десятков лет назад. Навыки в одной предметной области являются уже не достаточным, а только необходимым условием успеха.
Так от разработчиков требуют познаний в сфере бизнеса, для которого они создают решение. От системных администраторов требуют познаний в том же программировании. От DevOps-инженеров требуют еще и познаний в природе самих людей: только так можно организовать эффективную автоматизированную среду взаимодействия команд, а не еще один пайплайн.
Дальше больше: SRE стоит на стыке разработки, администрирования, навыков управления людьми в ходе решения инцидентов, а также аналитики, чтобы докопаться до истины. На эту позицию можно попасть из разных доменов, что вдохновляет, а среди работодателей она востребована, потому что миру снова нужны универсальные бойцы.
Вывод
Чем больше стыков различных областей находится под специальностью, тем более специалист уникален и желанен для бизнеса.
Специалисты теперь будут уметь не одно и то же, а каждый будет являться носителем уникальной специальности. Но нам только предстоит стать свидетелями этих изменений.
Пока они не наступили, есть время стать их частью, а не наблюдателем, осваивая базовые специальности и получая новые компетенции. Именно этого мы вместе с командой Слёрм и хотим добиться, в том числе и внутри курса «Python для инженеров». В нем весь наш позитивный и негативный опыт в DevOps: понятная теория и непонятные задания, польза которых раскрывается не только от результата, но и от процесса автоматизации коммуникаций.
