Привет, Хабр! Меня зовут Марат Цконян, я из солнечной Испании, университет Аликанте. Компьютерный инженер по образованию, по опыту работы — системный администратор.

В прошлом году я наткнулся на исследование отечественного DevOps-рынка за 2022 год: там Холдинг Т1 проводил аналитику трендов, а также формализовал проблематику индустрии. Теперь же благодаря Хабру мне предоставилась возможность обсудить накопившиеся вопросы непосредственно с авторами этой работы. 

Я поговорил с Евгением Калашниковым, соавтором исследования и директором по продуктам инженерных инструментов платформы «Сфера». Мы обсудили исследование, поняли, что такое DevOps и кто такие девопсеры, порассуждали, существуют ли DevSecOps и зачем компаниям облака. Заодно заглянули в будущее, узнав, что нас ждёт в исследовании за 2023 год.

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

DevOps под микроскопом

Марат: Ваше исследование сконцентрировано вокруг решений DevOps. Хотелось бы для начала определить, что это вообще такое. Во введении вы пишете, что это «сочетание культурных принципов, подходов», но из такого определения появляется больше вопросов, чем ответов.

Евгений: Говоря кратко, DevOps — это боль. В классическом понимании DevOps — это смежная методология на стыке нескольких различных дисциплин и подходов к работе. Разработка, деплой, саппорт — всё в одном флаконе. 

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

Марат: Выходит, сейчас девопсер — это тот, кто находится в лимбо между админом и разрабом, и делает то, что другие не хотят или не могут. А ещё, судя по моему опыту, пройдясь по 10 вакансиям на DevOps, мы обнаружим совершенно разные описания. Какого-то стандартизированного девопсера мало кто ищет. 

Евгений: Верно, стандартизация — ахиллесова пята нашего рынка. Наш опрос вскрыл самые острые болевые точки отечественной разработки: это густой лес сложных регламентов, беспорядочное нагромождение требований и огромное количество ручных процессов. Только эти три проблемы, исходя из нашего опроса разработчиков, дают 54% от всех трудностей, замедляющих разработку. А всё потому, что стандартизации в этой сфере нет. Поэтому компании не всегда представляют, кого и зачем они ищут, а специалисты не понимают, чего от них хотят. 

Марат: С DevOps’ом разобрались, а кто такие DevSecOps’ы? По вашей статистике, 30% компаний уже озаботились вопросами безопасности на этапе проектирования. Но в то же время остальные 70% — всё ещё нет. Возможно, они тоже не знают, что такое DevSecOps.

Евгений: DevSecOps’ы — это те, кого, к сожалению, почти не встретишь. DevSecOps-инженеры — не только DevOps-инженеры, но и специалисты службы ИБ. Тут идёт совмещение двух важных компетенций: безопасности и администрирования. Но у нас они как йети: говорят, что существуют, но никто их не видел. В большинстве компаний DevOps-инженер и безопасник — два отдельных человека.

Марат: Раз эту задачу и так выполняют два отдельных человека, почему для них не создавать смешанные отделы? Для чего нужен отдельный класс работников, которым придётся выполнять роль человека-оркестра — даже в большей степени, чем обычному DevOps?

Евгений: Положение на рынке наглядно показывает, что DevOps- и Sec-специалисты по отдельности не могут столь же эффективно решать поставленные перед ними задачи, как это умеют DevSecOps’ы. А почему так получается: девопсеры и безопасники не могут оценить всю картину целиком. DevSecOps’ы подходят к решению задач комплексно, чего может не хватать отдельным специалистам. Добавьте сюда проблемы межкомандной коммуникации — и становится понятно, почему в новостях стабильно всплывают печальные истории о кибербезопасности в разных компаниях.

Марат: Выходит, DevSecOps — это костыль, нужный компаниям из-за их неспособности нормально решить эти проблемы. А зачем тогда компаниям выстраивать межкомандную коммуникацию? Можно ведь оставить проблему на потом, а вместо решения заткнуть её новой вакансией DevCommunicationOps.

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

Коммуникацию в большинстве компаний не всегда просто настроить. Вдобавок на рынке мало продуктов и сервисов, которые бы сделали нормальную коммуникацию для разработчиков. Самое странное, что потребность в подобных сервисах есть: согласно нашему исследованию, 66% компаний поощряют налаживание внутрикорпоративной коммуникации, 48% внедряют инструменты для этого, а ещё 17% выходят дополнительно за пределы корпоративной среды.

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

Марат: Кажется, я понял: изобретение DevCommunicationOps откладывается, но коммуникацию компании хотят каким-то чудом починить. Только чинить некому и нечем. А как эту самую межкомандную коммуникацию помогут наладить новомодные методы Agile, а также сопутствующие ей методологии Scrum и Kanban, пришедшие на смену модели водопада? Нередко их рассматривают как панацею для налаживания всех бизнес-процессов, но в сообществе разработчиков многие не воспринимают такие методы.

Евгений: Практика показала, что статистически эти методы продемонстрировали большую эффективность. И, помимо сухой статистики эффективности, они решают ту самую проблему в общении внутри команды. Они помогают разработчикам лучше понимать менеджмент, а менеджменту — понимать, чем занимаются разработчики. Такое трудно себе представить в более детерминистических системах на основе тех же PERT или CPM, где процесс будет понятен человеку, знакомому с дискретной математикой, но трудно объясним человеку, с ней не знакомому.

Марат: Из этого объяснения можно сделать вывод, что в вопросе коммуникации эта проблема решилась лишь отчасти. Получается, что первопричина в виде некомпетентности одних в технических, а других — в социальных вопросах никуда не делась?

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

Open Source: за и против

Марат: Как я понял, девопсер — это человек из лимбо между разрабом и админом, чья участь — делать всё, что не могут они по отдельности. У DevSecOps’а та же история: добавляем задачи по безопасности и получаем йети, которого никто не видел. А есть ещё третья вещь, застрявшая в корпоративном лимбо — Open Source. Я до сих пор не понимаю, как в корпорациях происходит процесс интеграции OS-решений и чем это аргументируется. Просто приходит условный инженер к тимлиду и рассказывает, как он нашёл фреймворк на замену проприетарного или самописного решения? Из вашего отчёта в этом плане складывается достаточно оптимистичная картина: 90% компаний уже используют Open Source и треть — планируют расширять его применение. 

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

Марат: То есть инициативу проявляют работники на местах и дальше передают её вышестоящему начальству?

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

То есть Open Source в компаниях так или иначе появляется, и процесс появления может быть разный. Есть два варианта: top-bottom — когда внедрение идёт по решению технического руководства, и bottom-up — когда инициативу берёт разработка и аргументирует решение руководству.

Марат: У того самого руководства порой наблюдается заметный скепсис, а порой и негативное отношение к Open Source. OS-решения клеймят как менее безопасные. Что, в общем-то, если посмотреть на статистику, далеко от истины: проприетарные решения куда чаще преподносят неприятные сюрпризы. Так, судя по вашей аналитике, это отмечают и сами компании, где у 48% опрошенных основная претензия к проприетарным продуктам — это вендорлок.

Евгений: Это достаточно сложная тема. Действительно, есть ряд компаний, которые с большей осторожностью относятся к OS. Однако мы видим, что компании всё больше внедряют OS в корпоративные продукты.

Объективная причина, затрудняющая для компаний использование OS, — регламенты безопасности. Они накладывают дополнительные ограничения для использования OS, и если после всех проверок и доработок решение не подходит по этим требованиям, то его заблокируют. Также нужно учесть, что жёсткость регламентов зависит и от критичности систем. Бывает и такое, что со стороны компании есть дополнительные требования по наличию сертификата или нахождении в реестре отечественного ПО. И, как итог, в такой среде нередко формируются предубеждения у тех же безопасников, порой рассматривающих OS как решения со значительными рисками.

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

Поэтому OS-решения — это далеко не всегда легко и быстро. Иногда затраты и потенциальные риски того просто не стоят. Особенно если OS-решение добавили в продукт, а затем он начал висеть мёртвым грузом, так как его обслуживанием никто не хочет заниматься.

Марат: Однако все эти замечания актуальны и для решений, разработанных внутри компании, которые могут висеть мёртвым грузом legacy-решений. И всё равно печально, когда отказ от OS обусловлен иррациональными страхами или накопленными с годами стереотипами. Надеюсь, у вас нет таких стереотипов? Вернее, переформулирую так: с разработчиками каких продуктов из отечественных OS-решений сотрудничает Холдинг Т1?

Евгений: Мы активно сотрудничаем с «Астрой», а также широко используем ClickHouse. Это лишь несколько примеров. Конечно, мы используем и другие.

Марат: А что с вашим собственным решением «Сфера»? Что оно собой представляет, и в чём его преимущества?

Евгений: «Сфера» — это платформа полного производственного цикла, она включает в себя инструменты управления, разработки, мониторинга, тестирования, отработки и постановки задач. Всего их более 40. Они собраны, чтобы помочь повысить эффективность работы компании. Ну и помочь в вопросе импортозамещения.

То есть мы совмещаем всё необходимое в одном флаконе. «Сфера» позволяет одновременно импортозаместить продукты от таких вендоров, как Atlassian, MicroFocus, Microsoft Azure, JetBrains, Informatica и других.

Ко всему прочему, наша кодовая база самописна, что даёт нам контроль над процессом разработки.

Кадровый голод

Марат: В Open Source много разного: всех цветов и размеров, на вкус любой компании. Да вот только разработка OS-продукта порой любит прерываться, а сами разработчики порой как под землю проваливаются. И что с этим делать? Моё мнение — искать новых. Но поиски айтишников — это притча во языцех. Их всем не хватает. Например, в разных источниках упоминается цифра о приблизительной нехватке 500–700 тысяч IT-специалистов в России. Мне всегда было интересно: почему именно столько и откуда эта цифра? Если провести беглый анализ по другим странам, то складывается ощущение, словно все копируют её друг за другом, и, к примеру, в той же Испании мы также увидим цифру около 500 тысяч. А ещё непонятно, кого именно не хватает: как обычно, одних только сеньоров — а джуны в пролёте?

Евгений: Скажем так, не хватает примерно 350–500 тысяч сеньоров. Остальное — уже нехватка мидлов. Джуны, к сожалению, оказываются менее востребованными.

Но скоро при таких темпах развития IT-индустрии нам будет недостаточно даже миллиона. Анализ рынка вакансий показывает, что каждый год потребность в специалистах растёт на 7–15%.

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

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

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

Марат: Что если создать образовательную подразновидность DevOps, сфокусированную на автоматизации и оптимизации рекрутинга? DevEdOps.

Евгений: Прекрасная идея, но у нас такого пока ещё нет.

Одно из решений проблем с кадрами — заключить долгосрочные контракты на 3–4 года со стажёрами и джунами. Но я такое почти нигде не видел. Это встречается у образовательных платформ, но с курсами есть такой нюанс: несмотря на наличие договоров, они не гарантируют трудоустройство.

Марат: Справедливости ради, высшее образование тоже не гарантирует трудоустройство. В большинстве случаев оно, скорее, гарантирует его отсутствие.

Евгений: Мой личный опыт частично это подтверждает. Была возможность распределения во время учёбы, но работу пришлось искать самостоятельно. То был 2012 год, мне повезло: взяли без квалификации, дали возможность обучиться в процессе.

Марат: Раз уж с наймом всё так сложно, может быть, Open Source сможет помочь в проблеме кадров? Что я имею в виду: многие контрибьюторы крупных проектов — это граждане России. Так почему бы просто не нанимать на работу тех разработчиков, которые не «проваливаются сквозь землю», а долго работают над проектом? Тем более что 49% компаний, как утверждает ваше исследование, и так занимаются контрибьютингом, взаимодействием с сообществом OS.

Евгений: Наём через OS — это сложно. Первая проблема: юридическому лицу трудно нанимать целое сообщество из множества разработчиков. Вторая проблема: нередко лишь полтора человека на всём свете знают, как именно устроен конкретный OS-проект. И в случае чего найти замену или обучить кого-то чисто под этот проект становится нетривиальной задачей.

Марат: А если сложится ситуация, когда рынок будет переполнен специалистами? Например, западный рынок до сих пор штормит после лихорадочного набора кадров во время пандемии. За один только 2023 год в США было уволено почти полмиллиона человек, а за 2024 — уже почти 50 тысяч. Компании обнаружили, что большая часть нанятых сотрудников имеет отрицательную эффективность и приносит лишь убытки. Возможно ли такое в России?

Евгений: Наём без разбора иногда встречается. Но с учётом того, что специалистов очень мало, а на их поиск надо потратить несколько месяцев, об этом беспокоиться пока очень рано. Самый острый дефицит вижу среди DevOps-специалистов, аналитиков и разработчиков. Сбалансированная картина наблюдается в среде тестировщиков.

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

Евгений: Скорее всего, это сыграло свою роль. А ещё повлиял низкий уровень автоматизации тестирования в отечественных компаниях наряду с потребностью именно в ручном тестировании. Но на этот счёт мы исследования пока не проводили. Также тестирование — это самый быстрый способ войти в IT.

Боязнь облаков и AI-тренды

Марат: Выходит, большинство компаний любят Open Source. А те, кто не любит, просто его боятся. Почему же тогда отечественные компании не боятся зарубежных облаков? Многие очень упорно держатся за западных облачных провайдеров, неохотно мигрируя на отечественную инфраструктуру. Хотя из-за тех же санкций, в любой момент без объяснения причин, без компенсации ущерба или возврата денег, доступ к услугам иностранных облаков может быть закрыт. Так ещё и, с другой стороны, наше собственное законодательство становится всё строже к использованию инфраструктуры, географически находящейся за пределами России.

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

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

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

Марат: Удивляет, что у компаний есть те, кто эти нормативные акты составляет, ведь, как мы выяснили, безопасников мало, а DevSecOps’ы и вовсе занесены в Красную книгу. Возможно, несовместимость нормативов происходит из-за того, что их составляли те, чьей компетенцией это не является. Если убрать за скобки этот вопрос нормативов по безопасности, что может повлиять на популярность отечественных облачных решений в положительную сторону? 

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

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

Марат: Получается, на рынке ситуация по отношению к облакам достаточно неоднозначная в зависимости от компании к компании. А что с другим модным трендом — AI-решениями? Какие ИИ-методы сейчас используются в DevOps?

Евгений: Я знаю про основные: анализ кодовой базы и софта на наличие уязвимостей. И уже понемногу используется AI в анализе качества кода. Из потенциального: очень полезным был бы AI в написании тест-кейсов.

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

Марат: Выходит, конкретно в DevOps применение AI ограничивается нейросетевыми помощниками. Кстати о помощниках: в январе этого года GitClear выложили исследование, как Copilot влияет на качество кода — динамика отрицательная. Возможно, использование AI-помощников для написания и анализа кода — это не лучшая идея в ближайшем будущем/настоящем?

Евгений: В Холдинге Т1 мы уже обсуждали, насколько оправданно использование AI-помощников в разработке. Последние исследования показывают, что ценой внедрения ИИ является безопасность. Например, было проведено исследование, из которого стало понятно, что код, написанный нейросетями, действительно был получен быстрее, но содержит ряд критичных уязвимостей. Сейчас ускорение темпов разработки оправдывает издержки, связанные с увеличением числа ошибок. Позже, когда темпы разработки снизятся, мы сможем сфокусироваться на качестве кода. Тогда и подумаем об ИИ-помощниках.

Марат: А какая картина наблюдается в кормилице всего DevOps — контейнеризации? Или сейчас я узнаю страшную тайну, что все в основном пользуются просто виртуалками?

Евгений: В стеке технологий всё без сюрпризов. Для контейнеров в основном используется Docker, а для оркестрирования контейнеров — K8s. Самописные решения — редкость. И это правда: компании предпочитают вместо K8s использовать виртуальные машины.

Марат: Но я знаю точно, где картина с самописными решениями противоположная. Почему-то компании зачастую не удовлетворены функционалом контроля версий, что предоставляет Git и построенная вокруг него инфраструктура в лице GitHub, GitLab, Gitea и тому подобных.

Евгений: Холдинг Т1 — не исключение, у нас есть собственный инструмент «Сфера.Код». Вообще, полностью самописные решения редки, чаще это просто форки GitLab. Но есть нюанс: форк нужно поддерживать, а в процессе накапливаются конфликты версий с оригиналом и нарушается совместимость проектов.

Чему нас научил 2022 год

Марат: Неоднозначная вышла картина. С одной стороны, малый и средний бизнес, который переходит в облака всё активнее, а с другой — крупный бизнес подумывает о гибридном варианте. Какие ещё тренды вы обнаружили в исследовании за 2022 год, и сохранились ли они дальше?

Евгений: Меняется подход к импортозамещению: переход от формата «берём что угодно, лишь бы работало» к тщательному отбору с кучей требований. 

Видим тренд на внедрение ML-решений и AI-ассистентов.

Поменялся подход и требования к специалистам: акцент сместился от хард-скилов к софт-скилам и поведенческим, социальным особенностям кандидата.

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

Марат: А как же тренд на low/no-code? Некоторые из ваших компаний-партнёров возлагают особые надежды на такие решения. Но я как-то слабо понимаю, что представляет собой no-code в DevOps. Docker Desktop, что ли, для людей, боящихся работы в терминале?

Подобные заявления про low/no-code звучат ещё с 80–90-х годов, когда визуальное программирование только зародилось. И я опять же слабо представляю, куда и зачем в DevOps можно впихнуть условное визуальное программирование.

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

Марат: Я знаю один no-code-подход, который точно снижает трудозатратность рабочего процесса — документацию. Какие инструменты Холдинг Т1 разрабатывает для технической документации проектов?

Евгений: У нас есть собственный инструмент «Документы» в рамках решения «Сфера». Это продукт про разные форматы хранимых артефактов: даже архитектурных, а не одной лишь документации. Инструмент позволяет сократить время на работу со сложно связанными и структурированными документами (программными, техническими, юридическими). Можно интегрировать с различными источниками данных: ERP, CRM, HRM, LMS. Говорить о решении могу долго: тут лучше один раз увидеть.

Марат: Ранее мы обсудили, что все хотят изобрести велосипед для контроля версий. Что с этим делать и как стандартизировать этот бардак?

Евгений: Основная проблема в том, что компании не готовы развивать совместные решения, сотрудничать друг с другом и с клиентами. Лишь 19% опрошенных нами компаний расширяют границы своего взаимодействия и учитывают обратную связь с клиентами. 90% выбирают среды от иностранных поставщиков, и только 54% используют отечественные программные решения. На всякий случай: я умею считать до 100%, просто в опросах можно было выбрать несколько ответов.

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

Исследование 2023 года

Марат: Положение рынка, по-моему, непростое. ML и no-code используются не очень часто, а компании порой неохотно взаимодействуют с коллегами. Надеюсь, в 2023 году ситуация улучшилась, ведь я знаю, что вы проводите исследование и за 2023 год. В этом исследовании всё новое? Или какие-то подходы и практики вы перенесли из исследования за 2022?

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

Всё остальное мы изменили. Например, мы увеличили количество сфер, покрываемых аналитикой. Если в 2022 году посвятили внимание только DevOps, то за 2023 год добавилось исследование объёма рынка безопасности, облачных решений с искусственным интеллектом и HR.

Марат: Хотелось бы конкретики: как именно поменялось исследование, изменилось ли количество вопросов, их глубина и так далее...

Евгений: В целом всего стало больше: за 2022 год число респондентов, прошедших интервью, было около 150–200, а за 2023 оно увеличилось до 1000+. Добились мы этого просто: в прошлый раз мы самостоятельно проводили все интервью, а в исследовании за 2023 год нам помогали наши партнёры: Хабр, Яндекс, Касперский, Ростелеком, X-Com, ВШЭ, РАНХиГС и т. д.

Марат: Раз теперь у вас такой большой массив данных на руках, не стоило бы тогда проводить аналитику на больших отрезках времени — для большей точности? Почему вы решили проводить исследование рынка раз в год, а не в два, три, четыре года? 

Евгений: В плане темпов выпуска мы опирались на примеры Gartner и IDC. Коллеги из IDC в том числе непосредственно помогали в дизайне нашего исследования. Да и российский IT-рынок сейчас динамично меняется: планировать дальше, чем на год, многие компании считают бессмысленным.

Марат: Может, тогда у вас самих есть какие-то планы по изменению подхода к будущим исследованиям? Например, здорово хотя бы сделать PDF с выделяемым текстом, а не изображением.

Евгений: Сделаем обязательно :) В дальнейшем исследование будет в двух версиях: бесплатной и расширенной платной. Через обратную связь с коллегами мы всё чаще видим интерес и потребность к нашим исследованиям. А их монетизация позволит им не только выходить и дальше, но и даст возможность увеличивать масштаб исследований.

Марат: Мне всё же хочется услышать ещё немного инсайтов из ещё не вышедшего исследования за 2023 год.

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

Марат: А зачем IT-компаниям участвовать в ваших исследованиях? В чём профит и почему им просто не сделать свою, частную аналитику?

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

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

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

Разгружаем контейнеры. Финал эпопеи

Словно аргонавты Гомера, мы прошли через целое путешествие по морю идей и компаний, увидели наш путь в настоящем и заглянули за пелену будущего. Мы поняли, что DevOps и DevSecOps — это не просто профессии, это культура и друзья, которых мы завели по дороге. А также это плеяда задач, которые в компаниях некому решать, но кто-то должен. В опенсорс хотят не только лишь все, но многие сильно боятся. С наймом наблюдаются большие проблемы, как и с нейросетями в DevOps, а вот с переходом на отечественные облака всё получше. Оракулов у нас нет, поэтому современные проблемы мы решали современными решениями.

Но где кончается одна история, начинается другая. Вскоре мы ждём от Т1 исследование DevOps за 2023 год. Кстати, 3 апреля на РБК стартует прямая трансляция, где будут обсуждать результаты нового исследования: посмотреть можно на Rutube и VK. А пока приглашаю всех хабровчан делиться своими мыслями: какие тренды вы подтверждаете, а с какими не согласны? Видели ли вы «йети»? А ещё расскажите, с чем столкнулись, чтобы продвинуть в своей компании OS-решение — будет интересно узнать, через что вы прошли.