Как поменяется профессия ИТ-инженера сейчас, и почему быть адским занудой теперь — важный софт-скилл15.09.2022 14:16

Иллюстрация: Ignisnocte.

Привет, Хабр!

Я системный архитектор и ситуацию в ИТ в нашей стране сейчас могу образно описать как «цирк с велосипедами» и «зоопарк приехал». С велосипедами — потому что, например, по части ИТ-инфраструктуры теперь нам на ровном месте приходится изобретать то, что ещё несколько месяцев назад хорошо и надёжно закрывалось одним решением западного вендора. А зоопарк — это конструкторы из нескольких опенсорс-решений, каждое из которых выполняет свою функцию, но изначально не связанных между собой. Ладно, будем честными, — зоопарк из Open Source ещё не захватил ИТ-инфраструктуры крупных компаний, но уже слышны звуки его приближения.

Итак, ИТ-ландшафт российских компаний начинает меняться.

Соответственно, от ИТ-инженера сейчас будет требоваться иное, чем годом ранее. Например, одно из самых ярких грядущих изменений — больше нельзя просто делать так, как просит бизнес. Теперь нужно лезть в саму задачу, критически переосмысливать требования, потому что они не всегда обоснованы реальными потребностями и могут быть нереализуемыми на отечественных и Open Source решениях. И потом долго и упорно объяснять заказчику, почему всё будет сделано по-другому, а не так, как он привык, и доказывать, что так тоже можно, а в нашей ситуации и нужно. Думаю, первый год такой подход точно будет восприниматься как посягательство на святое. Отсюда и тезис про адское занудство.

Что именно поменялось

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

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

Как сейчас решаются инфраструктурные задачи

Главная проблема — не из чего выбирать.

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

Теперь смысл не в том, как лучше решить задачу, а в том, можно ли вообще решить её в тех формулировках и с теми требованиями, которые пришли от заказчика. Сейчас рамки вариативности сильно сузились. Задача может переделываться под возможности имеющегося вендорского решения, а на невыполнимые требования придётся просто забивать. Почему так? Есть Open Source и разные вариации коммерческих продуктов примерно на тех же «открытых» решениях. Все потребности рынка ими не покрываются, придётся думать. Какие-то задачи получится решить доступным набором средств, какие-то будут проигнорированы. Местами это не принесёт большого вреда. Мы на опыте знаем, что требования заказчиков часто бывают избыточными. Раньше можно было пренебречь в некоторой степени здравым смыслом и сделать, как написано в ТЗ — позволяли технологии. Теперь так поступить сложнее.

Вендорские продукты — больше не «коробки»

Переход с VMware на Hyper-V, который многие делали и раньше для оптимизации затрат на платформу виртуализации, — это не то же самое, что нынешние переходы с VMware и Hyper-V на KVM-like платформы. Раньше можно было изучить новые названия тех же инструментов, разобраться в парочке нюансов, причём сделать это по хорошо написанной документации, и вуаля! — вы уже специалист по Hyper-V. Нынешний переход с технологии на технологию будет более сложным. Он затронет сам подход к построению ИТ-инфраструктуры. Open Source — это почти всегда набор изначально несвязанных между собой отдельных программных продуктов, каждый из которых решает узкую задачу. Запуск. Мониторинг. Управление. Комплексные коробочные продукты у отечественных производителей встречаются редко, а хорошо работают ещё реже. Даже если они и позиционируются как законченные решения.

Что сейчас происходит

Конкретно мы, например, сейчас занимаемся импортозамещением там, где это можно сделать относительно малой кровью. Предлагаем начинать с пилотов, потому что очень сложно показать в картинках и графиках, что изменится. Нужно ставить, скажем, отечественное железо и наблюдать глубину проблем. Брать группу пользователей, сажать их на альтернативное решение и смотреть, как громко они начнут кричать. И так надо делать со всем — от виртуализации до почты. Потому как даже в той же электронной почте только пилот показывает, насколько критично сказывается на работе пользователей наличие каких-нибудь общих календарей. Или пример с виртуализацией. Если у вас серверы с локальными дисками, то раньше всё было просто: берёте гиперконвергентное решение от VMware или Nutanix и делаете кластер с общим хранилищем. Теперь такой возможности просто нет: нужно долго копаться в огромном количестве безликих решений, обещающих золотые горы и Software-defined storage, и думать, как всё это прикрутить к какому-нибудь oVirt-у. С бекапом тоже стало труднее. Отечественные решения, например, пока не поддерживают коннекторы к облачным хранилищам. А значит придётся либо покупать ленточную библиотеку или отдельное железо для хранения, что требует вообще другого уровня вложений.

Вопрос стабильности

В России все финансы, розница, телекомоператоры — это ИТ-driven-бизнесы. У них самые высокие требования по ИТ-инфраструктуре, и многое должно работать 24/7 на уровне четырёх девяток. Мы 10 лет строили традиционные отказоустойчивые архитектуры: минимум два места хранения, два дата-центра и между ними — двунаправленная синхронная репликация по подтверждению записи, чтобы ни одна транзакция не потерялась. Теперь стабильных решений, на которых всё это основывалось, не стало. Да, есть китайский рынок, но он не всегда может предложить замену привычным продуктам. Потому что большинство китайских производителей — не транснационального уровня, они фокусировались на локальных клиентах — на малом бизнесе и госзаказчиках. А российскому enterprise нужны решения другого класса.

Востребованность специальности

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

Поэтому и сейчас и в будущем ИТ-инженеры будут ой как востребованы! И вот что поменяется в профессии:

• Нужно будет понять и принять новую идеологию решений, которые будут составлять новую основу ИТ-инфраструктуры. Чем дольше мы будем относиться к новым продуктам по-старому, тем сложнее будет адаптироваться.

• Вернуться к старому доброму самообучению и Гуглу. Кроме как на себя, свой технический бэкграунд и свои познания в ИТ, рассчитывать будет не на кого. Есть по новым технологиям хорошие обучающие курсы? Едва ли. Даже если поисковик выдаёт множество вариантов обучения по нужному вам направлению, то это больше похоже на инфоцыганство.

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

На мой взгляд, самое главное — перестать говорить «Не знаю». Нас зовут, когда не знают, как делать, и наша работа — искать ответы и разбираться в непонятном. Сейчас эта культура не так распространена. Большинство людей ведёт себя иначе: я работаю отсюда и до сих пор, потому что это моя компетенция, а дальше… Думаю, в новых условиях это работать не будет.

Второе — начать задавать вопрос «Зачем?». Зачем вам синхронная репликация? Зачем резервное копирование каждые пять минут? Зачем виртуальная машина с 20 ТБ vHDD на борту? И так далее. А иногда придётся погружаться ещё глубже, разбираться в архитектуре приложения и данных в ней, чтобы помочь разработчикам сформировать корректные требования. Это как раз про токсичность из заголовка.

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

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

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

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

© Habrahabr.ru