Привет! Меня зовут Сергей, я занимаюсь направлением DevOps в KTS. Рассказываю, как запустить новую услугу в компании по уму, а не как это обычно бывает.
Содержание:
Зачем нам нужно было отдельное направление DevOps
С 2015 года специализируемся на сложных высоконагруженных сервисов для крупных корпораций, таких как Mail.Ru или X5. Из-за того, что мы занимаемся аутсорсом разработки, у нас в работе одновременно много проектов. В одном только направлении cпецпроектов — там, где мы делаем игровые механики для брендов — каждую неделю проходит по 1-2 запуска. На разработку и поддержку каждого требуется много времени и ресурсов.
Мы уделяем большое внимание инфраструктуре и различным способам повышения эффективности разработки. Например, у нас есть готовый CI/CD под типовые проекты, а также развёртывание динамических окружений под ветки разработчиков.
В общем, по сути это и есть DevOps — Development & Operations. Только отдельных специалистов для этого у нас не было: задачи закрывали хаотично и силами лидов (в том числе мной).
В какой-то момент основатели KTS поняли, что услуга может быть актуальна на рынке: если у нас есть такая проблема, значит и другие компании с ней сталкиваются. Потенциал увидели, но не нашли человека, которому можно было бы отдать это на реализацию.
Тут возник я. До DevOps-направления я был лидом в backend-разработке, и уже чувствовал над собой стеклянный потолок. Одни и те же задачи не вдохновляли, хотелось большего.
Почему мы решили, что рынку нужен DevOps на аутсорсе
DevOps нужен не всем компаниям. Команда разработки должна вырасти хотя бы до пяти-семи человек, чтобы стал нужен хотя бы один DevOps-специалист. Если разработчиков меньше, задумываться об оптимизации процессов ещё рано. Тем не менее, даже небольшая команда со временем может потерять производительность. Что с этим делать — неясно.
У найма DevOps–инженера в штат есть свои сложности. Во-первых, сейчас очень большой спрос на таких специалистов, и на этой волне популярности их зарплаты поднялись до космических высот. Для небольших компаний нанимать такого специалиста в штат невыгодно, потому что задачи DevOps-инженера часто имеют разовый характер.
На старте работы специалист должен максимально эффективно наладить нужные для разработчиков процессы и инфраструктуру. Это большой пласт работ, но со временем, когда процессы уже налажены, остается только поддержка. Получается, что количество сложной работы резко упадёт: специалисту станет скучно.
При условной зарплате в 300 тысяч рублей в месяц за год DevOps–инженеру вы заплатите около 3 600 000 ₽ на руки + 20,8% налогов (если работаете с IT льготой) = 4 348 800 рублей. Или 43,2% налогов (если IT льготы нет) = 5 155 200 рублей. Даже если 4-5 миллионов вполне вписываются в бюджет, одним специалистом компании обойтись будет сложно. Нужно как минимум 2-3, чтобы обеспечить бесперебойность и не завязывать все процессы на одном человеке.
Если специалист один, то во время его отпуска и болезни, некому будет решать срочные проблемы. Да и в обычное время один человек вряд ли сможет справиться: в работу DevOps-инженера входит поддержка работающих сервисов и решение неожиданно возникающих проблем с серверами. Это значит, что специалист должен быть на связи и тушить пожары 24/7 — и ночью, и в воскресенье, и 1 января. Чтобы он не сошёл с ума, нужны сменщики.
Что в итоге.
С одной стороны, одного специалиста в штате не хватит для DevOps-поддержки, а с другой — полноценной интересной работы на него тоже не хватит → аутсорс эффективнее чем in-house
Этап 1. Проводим исследование рынка
Мы обратились к нашим знакомым из компании, которая занимается проведением CustDev. Рассказали им свои гипотезы: что, по нашему мнению, может быть востребовано у клиентов. Потом попросили провести профессиональное исследование рынка, опираясь на наши данные.
Суммарно ребята провели 15 интервью с нашей целевой аудиторией: СТО и владельцами компаний. Рассказали им наши предложения по оптимизации и дополнительно спросили, что ещё мешает нормальной работе. Так, например, мы узнали, что во многих компаниях есть проблемы с мониторингом ошибок. В итоге собрали дополнительные варианты DevOps-модернизаций.
Мы просмотрели интервью и выписали все боли клиентов. Получился список из примерно 30 пунктов. Потом выбрали самые частые проблемы и те, которые мы уже решали. Каждому пункту поставили ранг приоритета для отбора в заключительный опрос. Опросили около 70 представителей аудитории, чтобы подтвердить гипотезы.
Респондентов искали с помощью рекламы в Facebook* и Google вот с такими креативами.
После завершения исследований мы сделали две таблицы: разделили ответы экспертов, которые живут в России и за её пределами. Была гипотеза, что какие-то проблемы могут отличаться в зависимости от специфики рынка.
Ответы внутри РФ:
Ответы среди экспатов:
Кстати, с CustDev мы получили не только ответы на вопрос об актуальности нашей услуги, но и первого клиента. Мы до сих пор помогаем ему с поддержкой инфраструктуры на аутсорсе.
Этап 2. Анализируем результаты исследования
Кроме того, что русскоязычные айтишники за границей охотнее проходят опросы, мы выделили следующие проблемы.
Проблема 1. Инфраструктура в компаниях держится на одном человеке
Он может уйти в отпуск или уволиться. В этот момент всё останавливается, потому что никто больше в компании не разбирается, как работает целая инфраструктура.
Проблема 2. В компаниях нет круглосуточной поддержки
Время = деньги, а время простоя = упущенные деньги. Если сервис падает ночью, и пользователи не могут заплатить, то никому не хочется ждать, пока сотрудник откроет свой ноутбук в 11 утра и все починит.
Наладить круглосуточную поддержку своими силами очень сложно: нужно организовать смены нескольких DevOps-инженеров. Для небольших компаний, которые весь бюджет пускают на тестирование новых продуктовых гипотез и разработку, это непозволительная роскошь.
Проблема 3. Нет постоянного мониторинга состояния системы
Если мониторинг не настроен, о поломке компания узнает двумя способами: случайно наткнувшись на нее, либо получив отзыв от озлобленного клиента.
Проблема 4. В командах нет отдельно выделенного девопсера
Обычно в небольших компаниях DevOps занимается один из разработчиков: как правило, ведущий бэкендер. Когда возникают DevOps-задачи, он полностью вылетает из процесса обычной работы. Это значит, продукт в это время не развивается, и компания теряет деньги. Более того, DevOps достаточно сложный, в нём куча всяких технологий, и далеко не каждый (даже очень опытный) бэкендер хорошо в нём разбирается.
Кроме выделения проблем и подтверждения наших гипотез, мы понимали, что DevOps-задачи намного проще передать на аутсорс. Ведь DevOps-инженеру достаточно разбираться в проекте на уровне компонентов и использовать общий стек инструментов, который решает основные проблемы. Нам кажется, что это даёт большое преимущество при выборе аутсорс vs инхаус.
Этап 3. Делаем маркетинговые материалы и показываем потенциальным клиентам
Когда гипотезы подтверждены, можно формировать предложение для рынка. Разработкой всех маркетинговых материалов — лендингов, презентаций — полностью занимался я. Признаюсь, что писать тексты и формулировать предложения мне как бэкендеру было тяжело. Но потом вошёл во вкус и даже выпустил две статьи на VC — первую и вторую.
Подготовил контент и валидировал дизайн для отдельного сайта DevOps-направления с общим описанием услуг и два лендинга — предложения по каждой из ключевых болей:
Самая жаркая проблема — инфраструктура держится на одном человеке.
Сделали акцент на том, что клиент покупает команду, а всю информацию о проекте мы документируем, так что клиент не останется без поддержки. И даже в случае перехода на DevOps инхаус-команду у них будет вся документация, чтобы быстро влиться в процесс.
Другая жаркая проблема — отсутствие постоянного мониторинга ошибок и падений
Сделали акцент на срочности реагирования о таких проблемах. Однако результатов этот лендинг принёс меньше: по нашему опыту, пока клиент с проблемой не столкнётся и не потеряет деньги, он редко думает о быстрой реакции заранее.
После лендингов запустили рекламу. И за пару месяцев уже получили результаты.
Рекламу запускали в Facebook* и Instagram* на СТО и владельцев IT-компаний. Креативы были такие:
Результаты
От идеи запуска нового направления до первого клиента прошло ровно четыре месяца: в мае мы загорелись DevOps-направлением, а в сентябре получили первого клиента через CustDev.
Первые несколько месяцев задачи клиентов я закрывал сам вместе с сооснователями KTS Сашей Опрышко и Игорем Латкиным. Параллельно занимался наймом, продажами и работой над маркетингом.
Осенью начали активно думать над продвижением — привлекли ещё одного клиента. В декабре пришёл третий. К февралю у нас их было уже шесть: 3 из клиентов KTS на других направлениях и 3 новых. Собрались с мыслями и выпустили две статьи на VC: набрали целых 600 просмотров.
За непростой 2022 год появилось 13 клиентов. Кажется, нам доверяют, потому что мы прошли все боли клиентов сами как разработчики. Мы создали эту услугу из внутреннего запроса, и она оказалась востребована на рынке.
Оказалась востребована на рынке наша экспертиза и в другом ключе: я и другие DevOps специалисты из KTS участвовали в записи курса Skypro. Вместе с Яндексом запустили курс по Яндекс Cloud, ну и конечно записали собственный курс по DevOps. Приходите учиться!
Кстати, если у вас не доходят руки до оптимизации инфраструктуры или разработчики стали тормозить с новыми релизами, предлагаю созвониться и обсудить, что можно сделать в этом случае.
Оставляю свой Телеграм для быстрого контакта: @s_malenko
Другие статьи про DevOps для начинающих:
Другие статьи про DevOps для продолжающих:
* Meta, которая владеет Facebook и Instagram, признана экстремистской организацией на территории России.