Облачное мышление: как развить DevOps-экспертизу в командах

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

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

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

Алексей Вахов: «Я начал работать на Uchi.ru в 2012-м году, тогда проект был в режиме стартапа, команда из пяти человек работала в квартире из старого фонда. Рынок EdTech в России только зарождался, уже случился хайп вокруг Coursera. Мы год искали модель, ходили по школам, вели занятия, сдували пыль со школьных компьютеров. В итоге пришли к тому, чтобы делать не просто видео, а интерактив.

В 2014 году на нашем сайте было 150 человек, практически всех мы, можно сказать, знали в лицо. К нам приходит генеральный директор с задачей: “Можем ли мы провести олимпиаду для школьников, в которой будут участвовать 12 тысяч человек одновременно? Я уже договорился”. Нужно было сделать все за месяц, не только механику олимпиады, но и настроить сервера на прием такого количества пользователей. Тогда мы поняли, что нам понадобится помощь».

Uchi.ru обратились с запросом на настройку площадки для олимпиады и серверов к Express 42. У продуктовой команды просто не было времени возиться с hi-load и серверами: они писали код олимпиады. Нужно было сделать платформу, которая выдержит большую нагрузку и сделать так, чтобы все сработало с первого раза.

E42 полностью подготовили площадку. Специально для олимпиады Uchi.ru арендовали 16 железных серверов, с запасом, провели нагрузочное тестирование. С точки зрения Hi-load все работало отлично. Оставалось только сохранять спокойствие и запускать олимпиаду.

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

Олимпиаду 2015-го года Uchi.ru встретили уже не на железных серверах, а на облаке. Чтобы не принимать весь трафик олимпиады в один час, разработчики изменили регламенты: после клика по кнопке «Я готов решать» для пользователя олимпиада начинается через час. С трафиком сразу стало гораздо легче. Предварительно Express 42 провели нагрузочное тестирование. В итоге олимпиада прошла расслабленно: запуск, мониторинг трафика, через час стало скучно, кофе-брейк.

Однако масштабный проект привел команду Uchi.ru к желанию работать с собственной платформой и платформенной командой, поставить все процессы на DevOps-рельсы, систематизировать и стандартизировать. Кому не хочется пить кофе во время больших и серьезных запусков?

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

Алексей Вахов: «После Э42 остались рецепты, мы взяли их и начали дорабатывать. Нам хотелось системности, стандартизации, роста, изменить ментальность команды. В нашем коде до сих пор можно найти следы кода Express 42 14-го года, хотя система кратно выросла. Это сотрудничество дало нам серьезный толчок».

Скриптование серверов. Когда растет масштаб и сложность проекта во всем нужна система. Если у вас есть 60 серверов, из них 50 – с 8 ядрами и 10 – с двумя, потому что администратор «так видит» – это странно. Приведите все к единообразию.

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

Тестовое окружение на каждую ветку. Таким образом вы не заводите predprod, а создаете множество тестовых окружений на легкой базе. В этих окружениях могут работать и тестировщики, и бизнес.

Основные сервисы: инструменты для администраторов развертывания нужного количества серверов, заведения приложений и выкатки; сервисы Continuous Delivery (CD).

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

Работая с компанией Uchi.ru, Express 42 предложили для реализации концепцию Team Topologies. Согласно этой концепции, в компании может существовать 4 типа команд:

Концепт Team Topologies – это, по сути, структуризация на основании здравого смысла. Он хорош, потому что используется в большинстве передовых компаний. Когда вы будете убеждать бизнес-менеджмент, что оно вам нужно, не придется далеко ходить за примером: Google, Netflix, – кому что нравится.

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

Что касается Enabling Team, то чаще всего специалист, который будет вводить новые подходы и решать проблемы нужен в компании не постоянно. Его можно найти на аутсорсе. В Uchi.ru эту роль выполняют инженеры Express 42».

Алексей Вахов: «В соответствии с этой концепцией мы разделили большую команду, которая занималась инфраструктурой, на две. Первая - платформенная, ее цель - делать self-service платформу для других команд. Вторая – это клауд-тим, которая ближе всего к SRE (Site reliability engineering). Это люди. которые помогают другим командам настраивать адекватные процессы в веб-приложениях.

Если команды коллаборируют, у них общий бэклог. Между командами есть три типа взаимодействия: фасилитация, коллаборация и X as a Service Они необходимы и достаточны в любой команде. Они заменяют пространные разговоры скрам-мастеров о том, что если вы хотите, чтобы команды вам что-то сделали, сделайте им кофе и это такой магический прием. Это всего лишь одна из фасилитационных практик. Для того, что в большинстве подходов описывают как магию в этой концепции есть конкретные термины».

Новые подходы требуют переобучения и дообучения сотрудников, а также смены требований к новым инженерам.

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

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

Главным для сотрудников обновленной команды как Express 42, так и Uchi.ru считают облачное мышление. Этому навыку можно научиться, но для этого нужно быть готовыми учиться и быть открытыми к новым практикам.

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

В нашей работе важно уметь разобраться в системе клиента быстро. Все заказчики разные, нет стандартизированного решения. У Uchi.ru – своя система, у Tinkoff – своя, у Авито – своя. Они все чем-то похожи, методически, но в нюансах и задачах – нет, челленджи перед ними стоят разные».

Чтобы решить кадровый вопрос, Express 42 запустили собственную стажировку для специалистов по DevOps и инфраструктурным решениям.

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

Александр Титов: «Мы взяли очень разных людей. Был парень без вышки, он учился по-своему, брал менторов из IT, копил деньги на обучающие курсы. Для меня была поворотная точка: я не верил, что человек, который не закончил хотя бы первые два курса вуза, может обладать критическим мышлением. Но у этого стажера были все данные.

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

Главной особенностью наших стажеров было то, что они видели неэффективность решений в своей текущей работы и хотели по-другому».

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

Александр Титов: «Участники вместе работают над домашними заданиями, подключают других людей из нашей компании. Таким образом, облачной культурой, культурой роста и критического мышления, исследования они пропитываются. Часть участников остаются у нас, часть – находят работу у наших клиентов. Основа платформенной команды Uchi.ru – это специалисты с нашей стажировки».

Разработка собственной платформы и введение DevOps-практик – это многоуровневая трансформация, которая изменит не только инструменты, но и привычный для сотрудников порядок вещей и в идеале – их мышление.

Хотите узнать, как реализовать это в вашей компании? В Express 42 мы изучаем DevOps уже больше 8 лет, в нашей команде – опытные инженеры и аналитики, которые помогут подобрать инструменты и практики, которые подходят именно вашему бизнесу. Чтобы задать вопросы или оставить заявку на экспресс-анализ – свяжитесь с нами input@express42.com

Следить за анонсами выпусками DevOps-стажировок Express 42 можно в наших социальных сетях:

https://t.me/express42

https://www.instagram.com/express42_ru/

Что почитать по теме:

Книга Team Topologies: Organizing Business and Technology Teams for Fast Flow, Matthew Skelton, Manuel Pais , Ruth Malan. (не переведена на русский)

https://teamtopologies.com/ – статьи, видео, онлайн-тренинги и кейсы от создателей книги.