DevOps простыми словами: как IT-команде делать важное и зарабатывать больше
Статья написана в соавторстве с Андреем Баулиным, Head of DevOps продуктовой IT-компании Megogo.
Разбираемся, почему попытки «внедрения DevOps» не имеют смысла без конкретной цели и как оптимизировать работу IT-компании, когда цель есть.
В разных технических коллективах можно встретить различные формулировки DevOps и их навыков. Большинство сводится к тому, что это некий человек, который находится «в одной комнате» с development и IT operations (иногда еще QA) и согласовывает их работу. Конечно, такое определение очень и очень условно.
В технологических стартапах с малым количеством людей не программирующий девопс — нонсенс. Зачем он там? По сути, в таких командах ops — маленькие буквы в конце, а DEV — большие в начале. В устойчивых командах среднего размера OPS набирают обороты, а девов и так много, поэтому «удельный вес» букв заметно меняется.
Мы никогда не ставили перед собой цель «внедрить DevOps» или «нанять девопсов». Потому что — ну кто это? Почему они должны сделать нас лучше всех? Чем они отличаются от тех людей-оркестров, которые в компании и так были всегда? Мы создавали команду мотивированных операционистов, знающих и углубляющихся в логику продукта, работающих бок о бок с девелоперами и тестировщиками. И потом констатировали, что многие в глобальном IT-сообществе называют таких людей девопсами.
Зачем нам DevOps
DevOps — это набор практик и инструментов, они должны решать реальные задачи. Молоток нужен, чтобы забить гвоздь. Сначала вы определяете цель, а потом уже ищете инструменты.
Наша цель — максимально эффективный бизнес. Поэтому мы гибкие и не стесняемся выбирать простые решения. Там, где другие делают по устоявшимся шаблонам, мы делаем в первую очередь оптимально, но все равно хорошо. Такой подход требует постоянной культивации все новых лайфхаков и на техническом поле. Мы должны разрабатывать и администрировать среды так, чтобы они предоставляли максимально возможную гибкость для бизнеса. Если при этом они просты, порой даже примитивны в своей реализации — ну и что?
Нам не нужны люди с титулом DevOps и умением рассуждать о Kubernetes 20 минут подряд, если они не умеют объяснить, как TCP-пакет попадает из одной OS в другую.
Мы продуктовая компания, и всё у нас крутится вокруг продукта. У нас никогда не было «системных администраторов», потому что не было таких систем, которые имели бы смысл и ценность без продукта. В начале
Мы не ставили перед собой цель «внедрить DevOps». Вместо этого задали себе вопрос: что нам нужно в operations и кто это может реализовать. Ответ получился из трёх частей: люди (команда), подход к работе IT operations и среда.
Что (и кто) делает команду эффективной
Для начала мы описали людей, которых хотим видеть в коллективе: их hard и soft skills, майндсет и работу всей команды целиком. Вот признаки, которые получилось выделить:
- Структура должна быть как можно более плоской, никаких начальников. Операционистов не должна волновать политика. Они не должны думать о том, «кто попросил это сделать», и оценивать задачи, основываясь на иерархии. Законно то, что логично. «Более прав» тот, кто лучше обосновывает.
- Люди должны быть самостоятельными. Соотношение goal driven против process oriented среди сотрудников должно быть максимально в пользу первых, но для баланса нужны и вторые.
- Они должны уметь костылять как боги! Но и вести счет «костылям», и правильно писать их в технический долг.
- Cloud-навыки для нас менее важны, чем on-premise. Человек, умеющий превратить on-premise DC в приличный private IAAS, в наших глазах ценнее ловкача в AWS-среде, к примеру.
- Важны хорошие навыки в темплейтизации, тяга к ней. Вот чтобы хлебом не корми, а дай увидеть темплейт в разрозненных сущностях и процессах.
- «Автоматизация» и «аксиома» не должны быть синонимами в голове операциониста. Собственно, возвращаемся к третьему пункту: они должны уметь костылять как боги!
- Логика важнее преемственности. На интервью в игровых технических заданиях мы стараемся поставить человека в ситуацию, в которой он не может выехать за счёт энциклопедических знаний. И смотрим, как он думает в этих условиях, умеет ли объяснить ход своих мыслей. Кстати, разрешаем брать на интервью телефон с интернетом и гуглить.
Какими характеристиками должен обладать IT operations
- Продукт использует пользователь. И он должен быть доволен. У нас не в ходу фраза «ну пускай кто делал, тот и разбёрется». Наш operantions — «затычка» в любой боли, которой ещё не найден конкретный хозяин.
- Удобно — это прозрачно и интуитивно. Чем меньше надо помнить и знать о сервисах и системах, тем лучше. В идеале — ничего не надо помнить и знать о сервисах. Но прозрачно и интуитивно — не равно небезопасно (об этом ниже).
- Мы не планируем на годы вперед, но все-таки планируем. И мы не тратим на планирование существенные ресурсы, экономим время.
- Если кто-то хочет попробовать новый продукт — он просто ставит себе задачу и устанавливает PoC. Потом рассказывает другим.
- Новые сущности в продакшене появляются по двум причинам:
а) это можно нарисовать и уложить в описанную схему: всё должно отвечать на вопрос, «как создать ещё сто таких, чтобы было одинаковое и удобное»;
б) потому что надо «вот прям щас», нужно ловить момент. - Меньше совещаний, больше ad hoc (то есть меньше групповых совещаний, больше конкретных технических диалогов и споров).
- По возможности, отсутствие неинтерактивных коммуникаций (вроде имейлов).
- По возможности, присутствие тикетной системы.
- Чем раньше ops появится среди dev во время реализации чего-то нового, тем лучше. В идеале — успеть с самого начала. Поэтому, вместо работы над единым пулом задач, наши ребята работают каждый в своих девелоперских командах.
- В клиент-саппорте эджайлу — нет. Если оставить телефонный саппорт с клиентами наедине, то никакого улучшения качества не будет. В этой области ITSM-подход — наше всё: разделение на уровни L1-L2-L3, по возможности — независимый инцидент и проблем-менеджмент, работа со статистикой инцидентов... Мы вкладываем ресурсы в это и всё сильнее «закручиваем гайки». Кстати, в Megogo с клиент-саппортом тесно связан мониторинг и алертинг.
- Безопасность должна быть прозрачной. Она не в сокрытии информации, наоборот! И она не должна обременять operantions. Это вовсе не означает, что безопасностью можно пренебречь или нарушать принцип defense in depth. Это означает, что безопасность, — реализовывает ли её в каком-то случае dev, DevOps или SecOps, — не должна ломать дизайн, процессы и процедуры во имя себя самой.
Наверное, каждый айтишник, работавший в корпоративном секторе, сталкивался с ситуацией, когда безопасники замыкаются сами на себе и становятся самодостаточной структурой. Они производят правила, смысла которых уже не могут чётко и ясно объяснить, как и доказать их эффективность статистикой. В этом смысле нам близок подход PCI DSS, а также их основной постулат: прежде чем защищать, сузьте скоуп.
В какой среде люди работают эффективно
Какими характеристиками должны обладать среды, чтобы описанные выше люди, работающие в описанном выше стиле, могли их эффективно администрировать и разрабатывать?
- Infrastructure as a code.
- В рамках разумного — горизонтальное масштабирование и динамическое всё: каталог сервисов, service mesh и т. д.
- Меньше веб-морд, ещё меньше! Консолидируем.
- Если во время дизайна в графе «сценарий восстановления» стоит выбор между «пересоздать» или «из бэкапа», то нужно выбирать первое. Однозначно.
- Прозрачные структуры можно документировать менее подробно, а то и вовсе не документировать, достаточно скетчей (поэтому у нас сильно ругают за отступы от нейминг-конвенций и тому подобные «мелочи»).
Когда мы все это сформулировали, оказалось, что многое из вышеперечисленного подходит под манифест agile в целом и DevOps в частности. Тут очень важен порядок: мы не внедряли у себя agile-философию. Мы работали, вычленяли наиболее эффективные подходы — и обнаружили, что наша философия так называется.
DevOps-инструменты — это абстракция
Теперь об инструментах, с помощью которых все это реализуется. Нет универсальных DevOps-решений. Нет и быть не может. Можно, конечно, перечислить какие-то трендовые технологии и продукты, но зачем?
К примеру, в интернет-статьях в перечне DevOps-инструментов часто упоминается Jenkins. Да, Jenkins появился уже во времена DevOps. Но раньше его спокойно себе настраивали старые добрые сисадмины.
В интернете полно статей на тему «в компании Х используют Y». Но вас не должен интересовать тот факт, что такой-то бизнес использует Prometheus, Grafana или что-то ещё. Вам должно быть интересно, насколько данная компания похожа на вашу, какие задачи решает и почему именно этими решениями. Нужно смотреть, из чего выбирали, как долго используют, чем ещё из подобных продуктов пользуются, насколько глубоко внедрение. Может, уже собираются отказываться от этого инструмента. В общем, вам нужны мелочи. А названия самих продуктов не нужны. Сформулируйте конкретную проблему и ищите, какие инструменты её решают.
И даже если вам повезёт увидеть список нормальных инструментов, какая в нём ценность? Любые инструменты сегодня устаревают так быстро, что нет смысла их перечислять.
Какие выводы можно сделать из всего этого
Никакой «инструкции» по внедрению DevOps не существует. Более того, она не имеет смысла. Нет единой системы, по которой нужно организовывать DevOps в компании. У нас, к примеру, есть «девопсы девопсов» — некая core-команда, которая разрабатывает общие для всех команд вещи. Но в целом это виртуальная структура: системные задачи и субпроекты кочуют от человека к человеку. Нет отдельно техсаппорта и девопсов. В Megogo девопсы не потеряли ITIL-классификации сисадминов, как L3 техсаппорта.
Есть некое деление на энтерпрайз и продакшен, но обе метасреды поддерживают одни и те же люди. Поэтому наша задача — делать энтерпрайз как можно более гибким и ненапряжным: мы стараемся не плодить ненужные сервисы, чтобы их не нужно было поддерживать. И у нас получается.
Ещё раз: нет никакого «пошагового плана внедрения DevOps». Но если всё-таки попытаться сформулировать общие советы, то их всего два:
- Не бойтесь переделывать. Очень большая ошибка — делать рефакторинг работы во всём и всегда. Потому что переделывание — это, по сути, есть жизнь.
- Трезво оценивайте цену ошибок. Часто совершить ошибку дешевле, чем не допустить её.
