Эффективный DevOps08.09.2021 15:46

Статья по мотивам доклада «Эффективный DevOps / Максим Залысин (Ситимобил)» с конференции DevOps Live 2020 команды Онтико.

От автора статьи и доклада

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

Как автор доклада и этой статьи исправляю упущение в подготовке к выступлению и доведу материал до логического завершения.

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

Статья является расшифровкой доклада, в ней я опущу секцию «О себе» и сразу перейду к «Ремарке».

Ремарка

Слайд 3

Когда готовил слайды своего доклада, наткнулся на обзор книги Effective DevOps. Обзор небольшой, но там много отсылок к культуре, о которой пишут авторы этой книги. Мне книга очень понравилась, в ней рассказываются основы DevOps и все описывается с практическими примерами. Для меня книга стала отправной точкой в познании (или осознании принципов) DevOps. И не просто того, как применять DevOps в работе, а того, что такое культура DevOps и какую реальную пользу она приносит.

В оригинале название книги звучит как Effective DevOps: Building a Culture of Collaboration, Affinity, and Tooling at Scale. Читал не в оригинале, только в переводе на русский, но рекомендую ее всем, у кого еще есть желание ощутить DevOps как философию, и тем, кто нутром чувствует, что DevOps инженер — это не YAML-разработчик и не новое название должности системного администратора.

DevOps инженер — это последствие профдеформации в восприятии IT-культуры под натиском HR и маркетинга.

Содержание

DevOps — культура в компании

Слайд 6

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

Культ DevOps инструментов

Слайд 7

Второй, самый крупный раздел доклада, о культе вокруг DevOps инструментов. Не погружаясь в конкретику актуальных сегодня DevOps систем, хочу отметить главное: внедрение Kubernetes или запуск CI/CD без осознания необходимости или отсутствия ответственных за поддержание и развитие такой системы не значит, что DevOps уже есть. Культура DevOps не про инструменты.

Эффективность DevOps

Слайд 8

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

Поехали…

DevOps — культура в компании

Все понимают, что такое DevOps и для чего…

Слайд 10

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

Не бывает так, что пришел руководитель из топ-менеджмента и сказал: У нас теперь DevOps, и все системные администраторы теперь DevOps инженеры». Что якобы означает: теперь все станет хорошо. Это невозможно! Нужно, чтобы люди вместе двигались к единому, нужному им результату.

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

Неважно, в какой ты позиции!

Слайд 11

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

Пример из собственного опыта: работал с одной командой тестировщиков, и ребята жили автотестами на чистом Selenium. Была масса трудностей, чтобы готовить Selenium на выделенных машинах: это неповоротливые компоненты на Java. В какой-то момент ребята поняли, что нужно что-то менять, нужно делать проще и быстрее. И именно от них поступило предложение заменить Selenium на Selenoid. Делает все то же самое, но написан на Go, обернут в Docker и запускается в разы проще. Значительное упрощение эксплуатации среды автотестов позволило получать результаты тестирования намного быстрее и проще.

Точно так же очень хорошо, когда разработчики в команде (или командах) могут договориться о едином gitFlow: как версионируют код в репозитории, как развивают проект в рамках бранчей, как вносят фиксы и как код живет в CI. Именно люди из команды чувствуют эту боль. Они видят и знают, что можно исправить и какие возможны решения.

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

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

Придется побороться за свою идею

Слайд 12

Самое сложное в том, что за свою идею придется побороться. Просто так поменять Selenium на Selenoid невозможно. Нельзя прийти к системному администратору и сказать «Я больше не хочу пользоваться Selenium, который ты мне поднимал целых три недели, давай попробуем Selenoid». То же самое — поменять в команде gitFlow, поменять подход к версионированию кода или доставки логов — это очень непросто.

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

Модный инструмент не внедрит культуру

Слайд 13

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

Есть тот же Kubernetes, есть и его более простые, но менее функциональные «соплеменники» типо Docker Swarm. Каждый из них справляется со своей задачей — оркестрацией контейнеров. А так ли хорошо справится с выбранным инструментом команда эксплуатации? Может быть и не нужен тяжеловесный Kubernetes, поддержка которого в компании очень затратна, и стоит посмотреть на что-то попроще, что дает тот же результат.

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

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

В остатке

Слайд 14

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

Культ DevOps инструментов

Панацеи нет!

Слайд 15

Появление в компании Terraform, Kubernetes, Jenkins или GitLab не спасет процессы компании и не даст моментального результата. Но что точно, появление подобной системы создаст дополнительную нагрузку на эксплуатацию. Потребуется время на изучение инструмента и получение опыта в его эксплуатации, моментального ускорения в решении бизнес-задач не будет.

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

Кругозор — важный фактор в правильном выборе решения!

Слайд 16

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

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

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

Мультитул хорош на старте

Слайд 17

Когда инструмент делает много всего, то ничего из этого он не делает по-настоящему хорошо! (Постигнуто опытным путем.)

Универсальный мультитул — как монолит. Первое время отлично решает задачи, потом чего-то начинает не хватать, и он обрастает скриптами, костылями, потом оно начинает сбоить, ведет себя непонятным образом, и одна доработка ломает другую или вовсе оказывается, что поддерживать теперь это «рукоделие» некому. А еще большой риск потерять разом все функции. Упадет тот же GitLab и вместе с ним, помимо хранилища Git репозиториев, «ушли» CI/CD, Docker Registry и хранилище артефактов.

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

Инструменты для решения задач, а не ради инструмента

Слайд 18

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

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

Чем проще инструмент и итоговое решение, тем спокойней инженеру в отпуске. И проще передать это на поддержку менее опытным инженерам.

«Сделать простое иногда во много раз сложнее, чем сложное». ©️ Михаил Калашников

Сложный инструмент — замыкание на инженера

Слайд 19

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

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

В этом месте начинает формироваться bus factor, и стоимость поддержки сложного инструмента становиться головной болью. И далеко не всегда популярный инструмент типа Kubernetes, требующий существенных затрат, справится с задачей сильно лучше, чем его более простой (и в эксплуатации тоже) аналог вроде Swarm.

За сложный инструмент придется платить, в прямом и переносном смысле.

Тенденция «не глядя»

Слайд 20

Из-за сложности современных систем и часто нежелании инженеров в имеющейся текучке тратить время на их изучение возникла очень неприятная и яркая тенденция «не глядя».

Раньше это был просто подход с названием StackOverflow Certificated Engineer: без погружения копируется чужой ответ, и оно как-то работает. Сейчас, с развитием сложности в инструментах, это стало основным подходом.

Зачем разбираться, как устроен Kubernetes, если можно взять kubeadm / kubespray / OpenShift, и пускай оно само все запустится. А компоненты, определенные в такой «коробочке», тоже полностью соответствуют требованиям к целевой системе? А устранение инцидентов тоже этот инструмент обеспечит? В этой ситуации уже появляются вопросы к инженеру, который выбрал решение «не глядя».

А зачем оформлять свой Kubernetes манифест для сервиса и тратить время на анализ каждого ресурса в документе, если можно быстро взять чужой Helm? А ведь так разворачивают даже системные компоненты кластера с непонятными заранее правами в кластер. И тут уже возникает вопрос безопасности.

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

В остатке

Слайд 21

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

Эффективность DevOps

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

Желание сделать удобно не только себе, но и людям вокруг

Слайд 22

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

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

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

Коммуникации

Слайд 23

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

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

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

Это может выглядеть как brainstorm, а может быть и обычной плановой встречей. Самое главное — не молчать, когда есть мнение, в молчании коммуникаций не будет.

Документация

Слайд 24

Понятная документация, по моей практике, имеет 2 основных применения, каждое из которых освобождает собственное время.

Не объяснять одно и тоже по много раз. Внедряя какое-нибудь решение (инструмент), волей-неволей становишься носителем знаний по нему. И сразу же прикрепляется роль консультанта. Все, кому необходимо взаимодействие с этим инструментом, будут отвлекать, выясняя, казалось бы, очевидные вещи.
Не замыкать на себя — не растить bus factor. Замыкание на себя, по-моему, большая проблема в IT сегодня. Последнее время все больше встречаю инженеров, которые свою востребованность поддерживают через замыкание на себя. Иногда их называют рок-звездами, и круто, когда они действительно дают отличный и быстрый результат. Но что происходит, когда рок-звезда уходит из группы или выгорает от объема задач, которыми не хочет делиться? Или хотя бы отправляется в отпуск. Документация в таких картинах мира — хотя бы какое-то наследие, способное хоть в чем-то помочь всем остальным разобраться с проблемой.

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

Ревью

Слайд 25

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

Самым полезным примером эффективности ревью любого технического решения будет отпуск исполнителя. Несколько недель этот инженер в одиночку корпел над запуском какого-нибудь непростого кластера (CEPH, ELK, Kubernetes), за это время проделал отличную, по его мнению, работу. Как минимум все работает. Даже в production успел свой результат затащить и бизнес на него завязать. Все сделал, даже документацию написал, как что делал, и пошел со спокойной душой в отпуск в поход на 10 дней без мобильной связи. Вот тогда-то и выстреливают решения, объективно не проверенные командой, а отвечать и чинить будет уже кто-то другой. Команда в такие моменты разбирается с новым кластером, в холодном поту натыкается на вещи, которые в документации не учтены, а инженер в походе умирает от страшной икоты.

Ревью — это объективное принятия результата в команде с учетом опыта всех участников процесса. А еще это отличная возможность поделиться имеющимся опытом и защитить результат от возможных проблем, техдолгa или overengineering.

В остатке

Слайд 26

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

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

Конец

Слайд 27

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

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

Спасибо всем, кто дочитал до этой строчки!

P. S. Дописывая статью (расшифровку), я понял, что только успел набросать темы, по которым можно вести длительные монологи/диалоги, приводя все больше и больше примеров.

На HighLoad++ 2021 продолжится обсуждение практик DevOps и их влияние на развитие процессов. Конференция состоится 25–26 ноября в Москве. Приходите, будет интересно!
Доклады можно посмотреть здесь. Билеты дорожают каждый месяц. Вы можете забронировать билет сейчас и зафиксировать цену еще на несколько дней.