Одна из особенностей работы большого интегратора — в том, что все знают или примерно представляют, что именно этот интегратор делает и для каких клиентов. Последнее обычно доводится до сведения масс либо неброскими пресс-релизами, либо логотипом интегратора в списке партнеров заказчика. Но очень часто многие не догадываются, как именно проводятся подобные работы, и забывают, что за большим логотипом компании трудятся живые люди.
Мы постараемся немного изменить ситуацию – предлагаем вашему вниманию интервью с руководителем одного из технических отделов ЛАНИТ Яковом Шуваевым. Отдел специализируется на реализации решений в области построения надежной и безопасной программной инфраструктуры информационных систем, сервисов, обеспечивающих производственный цикл разработки, а также на всем, что касается баз данных и информационной безопасности.
Яков, расскажите немного о себе и вкратце о своем отделе. Чем вы занимаетесь и над чем работаете сейчас?
Начну, наверное, с учебы. Я из РУДН. Учился на физмате на специальности «Прикладная математика и информатика». Первые три курса учеба занимала все время, на четвертом появилось немного свободы, и я решил, что пора взяться за работу. Шел 2006 год. Было три варианта. Основной план был сходить в те компании, о которых были реальные отзывы от моих друзей. Таких вариантов было два, и первым в списке оказался ЛАНИТ. Мой однокурсник, который учился на параллельном потоке какое-то время там уже работал. Он и организовал мне мое первое в жизни собеседование в ИТ-компании. На этом собеседовании меня встретили мой непосредственный будущий руководитель, руководитель группы разработки и вице-президент компании, который тогда вице-президентом не был, а был простым руководителем проектов – они сидели в одном боксе в опенспейсе. В то время я слабо представлял себе, какие бывают роли в ИТ-компаниях, поэтому пошел на ту же позицию, что и мой однокурсник – «Разработчик-стажер». К слову сказать, если бы тогда я хотел заниматься тем, чем занимаюсь сейчас, у меня бы это не вышло – на тот момент в структуре подразделения была пара специалистов по базам данных, а админов и инженеров по безопасности не было в принципе. После того, как руководитель группы разработки выяснил, что про GWT, JEE и сборщик мусора я мало, что знаю, а мой опыт программирования сводится к написанию лабораторных в вузе и игры судоку на C# для КПК, он передал меня моему будущему руководителю. Мне выдали лист А4 с задачами на логику. Как потом выяснилось, все, кого собеседовали в отдел разработки, прошли через эти задачи.
Интересный факт. Не все знают, но физмат РУДН плотно обосновался в ЛАНИТ. Только в одном подразделении, в котором работает Яков, трудятся еще 5 выпускников физмата РУДН.
Какие еще были варианты? Ты сказал, что было три.
Если бы я выбрал второй вариант, то сейчас я, возможно, работал бы в одной из приобретенных «Ростелекомом» компаний. Думаю, тоже неплохой вариант.
Третий вариант, запасной, заключался в том, чтобы разместить резюме на сайте с вакансиями, ждать обратной связи и забрасывать потенциальных работодателей письмами. К счастью, второй и третий вариант не пригодились.
Тогда
На одном из первых проектов мне поручили разворачивать систему у одного из заказчиков. Понравилось собирать из набора деталей работающую систему. Когда пришлось собирать кластер из серверов приложений, тогда еще BEA Weblogic, открылся «новый дивный мир».
Я выяснил, что для того, чтобы система заработала быстро, надежно и безопасно, одного кода не достаточно. Плюс, как показала практика, если код работает у разработчика – это еще не значит, что его можно просто так взять и запустить в кластере.
Дальше больше. Были новые проекты, на которых я уже полностью переключился с разработки на администрирование. Так в проектах подразделения, в котором я работал, появились Linux, SVN и сервер непрерывной сборки в его текущем виде. Единственное – меня смущало, что я долго не мог найти в интернете подходящего описания моей ИT-роли в проекте и команде. Это было немного шире, чем системное администрирование, термин DevOps появился только в 2008 году, а на аббревиатуру SRE я тогда не наткнулся. В итоге, долго ломал голову над тем, чем же на самом деле занимаюсь. Это напрягало.
С этими мыслями я написал своему руководителю, после чего он предложил эту активность назвать «ИТ-инфраструктурой», а соответственно мою роль на проектах как «специалист по ИТ-инфраструктуре». Жизнь обрела смысл и понеслась…
Да и как сейчас уже понимаю, инфраструктурой на тот момент я занимался лучше, чем писал код.
DevOps и SRE
В 2009 году стартовал проект по разработке одного из государственных порталов. Производственный процесс стал резко меняться в соответствии с потоком и масштабом новых задач: росла команда, росло число тестовых стендов. Стенды нужно было создавать, поддерживать в актуальном состоянии, нужно было готовиться к запуску системы в промышленную эксплуатацию. Меня одного на все активности стало не хватать, и мы начали расширять штат «инфраструктуровщиков». Как я уже говорил, на тот момент в штате были специалисты по БД Oracle, которых не совсем было понятно к какой административной единице отнести: то ли к разработке, то ли к администрированию. В итоге решили, что их буду курировать я.
На момент образования сектора в нем работало 5 человек, включая меня.
К 2016 году наше подразделение открыло дополнительные региональные офисы в Челябинске, Перми, Саратове и Ижевске. «Собачка немного подросла», и в 2016 году наша команда стала распределенной – свыше 30 человек. Встал вопрос о ее трансформации в более крупную административную единицу подразделения – отдел.
Во время подготовки к этому нужно было решить очень «сложный» вопрос – как назвать отдел. С одной стороны, команду давно знали по таким ключевым словам как «инфраструктура» и «базы данных». С другой стороны, область нашей деятельности с 2010 года значительно расширилась, да и слово «инфраструктура» у многих ассоциируется с железом, сетью, ЦОДами – всем тем, чем профессионально занималось и занимается другое подразделение ЛАНИТ.
На собеседованиях, которые я провожу, рассказывая, чем занимается наш отдел, обычно рисую картинку в виде пирамиды, которая условно представляет уровни абстрактной информационной системы, начиная с железа, на котором все работает, и заканчивая прикладным ПО, которое разрабатывает наше подразделение. Верхний уровень «Прикладное ПО» – уровень, которым занимается отдел разработки. Здесь реализуется прикладная функциональность, которая нужна заказчику информационной системы.
Ниже – это уровни, которыми занимается наш отдел. Какие-то уровни пирамиды мы закрываем полностью, какие-то – частично. Под частичным закрытием я понимаю то, что сотрудники отдела как минимум должны понимать, что происходит и там, и там, чтобы решать основную задачу – сделать так, чтобы ПО работало быстро, надежно и безопасно.
Эти задачи можно решать, выстроив «инфраструктурный периметр» вокруг прикладного кода, но очевидно, что чаще всего это сделать невозможно, поэтому мы тесно взаимодействуем с командой разработки и командой, которая занимается железом, сетью и виртуализацией для достижения этих целей.
При этом нужно понимать, что «забора» с уровнем ПО в верхней части пирамиды и уровнем физики снизу нет. Как минимум, чтобы ответить на вопрос, нужно ли оптимизировать код, добавить железа или «докрутить» ОС, надо либо разбираться во всех этих уровнях, либо уметь правильно провести диагностику и сформулировать вопрос к тому, кто разбирается.
По структуре отдел делится на секторы. Первый сектор предоставляет услуги по эксплуатации информационных систем. Обычно это третий уровень поддержки, что означает, что команда в курсе того, что из себя представляет система, как она работает, какие задачи выполняет и принимает непосредственное участие в процессе разработки системы. Целями работы этой команды являются обеспечение надежной, быстрой и безопасной работы ППО в промышленной среде и обеспечение непрерывности процессов производства. Основные задачи, которые решает команда сектора, включают в себя: создание и настройку решений по автоматизации развертывания, инфраструктурный и бизнес-мониторинг, управление конфигурациями, управление облачными ресурсами, обеспечение надежности и все, что с этим связано. К 2017 году, в отличие от времени, когда все начиналось, прогрессивное человечество успело придумать термины, которыми можно максимально точно описать то, чем сейчас занимается сектор – это смесь элементов DevOps и SRE.
Базы
Чем еще занимался отдел?
Второе направление – это сервисы. Jira и Wiki система уже давно стали неотъемлемой частью производственного процесса практически любого проекта подразделения. Кроме того, на базе Jira, помимо проектных, автоматизируется много сервисов самого подразделения, начиная от заказа канцелярии и получения VPN-доступа для удаленной работы и заканчивая процессом приема на работу новых сотрудников.
Третье направление работы сектора – предоставление облачных вычислительных ресурсов и ресурсов по хранению данных проектным командам подразделения. Мы предоставляем услуги по организации аренды ресурсов у разных облачных провайдеров, таких как Amazon, Selectel, OnCloud и автоматизации подготовки тестовых окружений для проектов в облаках.
Второй сектор – это команда специалистов по базам данных. В начале своего пути команда специализировалась только на СУБД Oracle. Со временем ребята получили большой опыт работы с СУБД PostgreSQL, NoSQL БД RIAK и рядом продуктов, которые тем или иным образом связаны с базами данных. Например, тот же Delphix.
С расширением компетенций команды трансформировался и класс решаемых командой баз данных задач.
Новый класс задач потребовал использования новых инструментов?
Источник
Бывает по-разному. Иногда приходит задача, и ее надо срочно решить. Тут уже не важно, какими инструментами. Если оказывается, что в этот момент ты умеешь держать в руках только микроскоп, то и все задачи, включая “забивание гвоздей”, будешь решать микроскопом. Это, кстати, нормально, если заказчик хочет микроскоп, платит за микроскоп и за построенный с помощью микроскопа дом и в конце получает то, что хотел. Со стороны ситуация может выглядеть странно, но если заказчик доволен, то цель достигнута.
По очевидным причинам мы таких ситуаций стараемся не допускать. Чтобы решать задачи, делать проекты и не выглядеть при этом странно, важно до получения новой задачи или старта нового проекта быть в курсе того, что происходит вокруг тебя в отрасли. Знание широкого круга технологий и решений дает возможность объяснить заказчику, что микроскоп – это не лучшая в мире вещь, и предложить наиболее оптимальный для решения задачи вариант.
И как вы это делаете?
Стараемся быть в курсе :) Смотрим вебинары, ходим на конференции, организуем митапы. Если позволяют сроки, пытаемся на некоторых задачах использовать новые технологии, чтобы, когда придет время, иметь возможность предложить и их.
Безопасность и надежность
Понятно. Инфраструктура и базы данных – это все, чем вы занимаетесь или есть еще какие-то направления?
Есть. В 2015 году мы начали заниматься направлениями информационной безопасности и проектированием катастрофоустойчивых решений. Среди результатов можно отметить завершение проектирования схемы резервирования двух крупных государственных информационных систем. В одном проекте система резервируется на два дата-центра, во втором – на четыре.
Насколько мне известно, тот же Amazon позволяет это делать практически из «коробки». В чем сложность?
Amazon предоставляет такую возможность на уровне своей инфраструктуры или сервисов – смотря, чем вы пользуетесь. При этом, в зависимости от технологий, которые используются у вас на проекте, работать это будет хорошо только тогда, когда вы на уровне кода своей системы учитываете возможность «переезда» между дата-центрами. В противном случае результат будет мало предсказуемым. В нашем случае задача была придумать схему резервирования для уже много лет работающей системы, которая бы гарантировала заданные показатели RTO и RPO.
ОК. А что с безопасностью?
В любой стране есть законы и регламенты, которые требуют от определенного класса систем соответствовать некоторому набору требований. В России основными законами в этой области являются 149, 152 и 63 ФЗ и соответствующие им приказы различных ведомств. Так как в основном мы занимается государственными информационными системами, в которых могут обрабатываться персональные данные, а еще может использоваться электронно-цифровая подпись, то мы должны учесть требования всей этой нормативки. Из результатов могу отметить завершение работ по аттестации одной из информационных систем, которую разрабатывает наше подразделение, по требованиям ФСТЭК, мы провели сертификацию программного обеспечения, входящего в эту систему, и две оценки влияния по требованиям ФСБ.
Помимо обязательных по закону мероприятий, внутри подразделения мы проводим обучение коллег из других отделов, тестирования и разработки по вопросам информационной безопасности при производстве и эксплуатации систем.
И как в итоге звучит название отдела?
«Отдел инфраструктурных решений, сервисов и управления данными». Длинно, но отражает суть того, чем мы занимаемся.
Чем особенно гордишься за время работы?
Горжусь тем, что удалось собрать профессиональную команду, с которой можно решать задачи и которой я доверяю.
О мотивации
Как вы мотивируете сотрудников добиваться нужных результатов? И в чем секрет успешной команды, на ваш взгляд?
Специально никого не мотивирую. В своей работе я исхожу из двух принципов. Первый – при постановке задачи помимо описания того, что я жду в качестве результата, стараюсь обозначить контекст: зачем и кому нужен результат этой задачи. На своем опыте знаю, нет более странного состояния, когда пытаешься угадать, чего именно от тебя хотят и в каком виде, особенно, если задачу получаешь на вход не от того, кому нужен результат.
Второй – я исхожу из того, что у нас все люди взрослые, включая стажеров. Всем, кто к нам приходит, я говорю, что, если задача непонятна, не надо пытаться гадать и додумывать, нужно подойти и спросить – по лбу никто не ударит, зато это может всем сэкономить кучу времени.
По поводу секрета успешности. Этот вопрос лучше задать моему руководителю – директору подразделения :) Если бы он гипотетически ответил, что наш отдел является успешным, я бы, опять же, гипотетически, ответил на этот вопрос историей. К сожалению, я не знаю, кто автор, но она мне очень близка по духу. Звучит она примерно так:
«У одного руководителя берут интервью.
— Скажите, вот у вас все сотрудники постоянно посещают разные конференции, получают сертификаты, ходят на разные тренинги и митапы в офисы других компаний… Вы не боитесь, что они за ваш счет всему научатся и уйдут от вас?
— Я боюсь, что они ничему не научатся и останутся».
Про найм сотрудников
Существует ли, на ваш взгляд, кадровый голод в ЛАНИТ и в ИТ-сфере в целом? Какие специалисты нужны ЛАНИТ сегодня, чтобы решить поставленные перед компанией задачи? И что нужно сделать, чтобы молодежь оставалась работать в компании?
Хорошие вопросы. Сложности с наймом специалистов есть, но эта ситуация характерна для всего рынка – не только для ЛАНИТ. Так как проекты, над которыми работает наше подразделение, обычно не предполагают работу «отсюда и до обеда», список специалистов, которые нам подходят, сильно сужается.
Вариантов, как быть в такой ситуации, на мой взгляд, несколько.
Первый – классический. Можно искать нужных тебе людей, применяя классические HR-подходы, – долго, но результат на выходе всегда качественный. Многие могут со мной здесь поспорить, но я могу сказать о своем опыте. Наверное, мне везло с нашими HR-ами.
Можно еще искать людей в регионах, можно брать стажеров и прокачивать их под нужные вам задачи. Все три способа не сделают текущей команде хорошо прямо сейчас, но в перспективе решат задачу.
Второй – пиарить компанию на рынке, в соцсетях и привлекать тех, кто раньше даже и не задумывался о работе в ЛАНИТ. Про Яндекс, Avito, Mail.ru знают все, а что вы знаете про ЛАНИТ? Всегда задаю на собеседованиях этот вопрос.
И что отвечают?
Обычно, если приходят из интеграторов, то скорее всего что-то слышали, но не обязательно про проекты, которыми занималось именно наше подразделение. ЛАНИТ – это группа компаний, и каждая из них специализируется на чем-то. Кто-то космодромы строит, кто-то банкоматами занимается – разные направления есть. Остальные про нас либо не знают ничего, либо могут ответить что-то типа «Да, слышал… Это же вы госуслуги делаете?» :) И это при том, что ЛАНИТ который год входит в тройку крупнейших ИТ-компаний России, а проектами, которые реализовало только наше подразделение, пользуются по всей стране.
Главное — не зацикливаться на одном подходе и, к счастью, в этом плане мы активно движемся в нужном направлении. Проводим митапы, вышли на Хабр. Плюс сейчас набирает обороты стажерская программа, по которой мы ищем молодых ребят к себе для обучения и дальнейшего трудоустройства.
Стараемся быть в тренде.
Про удержание сотрудников
В тренде – это хорошо. А как дальше удерживать сотрудников?
Для начала, я бы хотел сказать, что никто никого силой не держит :) Для того, чтобы сотрудники не хотели уходить, должны быть созданы условия, с которыми было бы сложно расстаться. В первую очередь – это возможность заниматься любимым делом, далее – чтобы сотрудники чувствовали стабильность и перспективы роста в компании, третье – чтобы они могли развиваться на пользу себе и компании.
Чтобы этого достичь, во-первых, мне кажется важным, чтобы каждый сотрудник понимал, чем занимается и живет подразделение, в котором он работает. Если он этого не понимает, он не будет понимать, что и зачем он делает и частью чего он является.
Очевидно, что мы не стартап и не продуктовое подразделение, хотя у нас есть и свои программные продукты и внутренние стартапы. В первую очередь, мы – интегратор, который делает проекты. Большие и сложные проекты «под ключ». Что это означает на практике? Это значит, что мы реализуем полный производственный цикл создания информационных систем, начиная со сбора требований и заканчивая эксплуатацией и развитием уже функционирующих в продакшене систем. Сами проекты, над которыми мы работаем, социально значимые, важные для страны. Одно осознание от того, чем ты занимаешься и сколько людей пользуется результатом твоей работы, мотивирует очень сильно.
Во-вторых, каждый сотрудник должен понимать, какие возможности открывает для него работа в компании, какие у него есть варианты развития и возможности для этого.
В подразделении накоплен колоссальный опыт, который можно перенимать и развиваться с его помощью с бешеной скоростью. Уверен, существует не так много компаний и подразделений, которые могут поделиться теми знаниями и компетенциями, которыми обладают наши эксперты. Бери и учись!
С теорией понятно, а как на практике? Все прямо так и работает?
Ну… мы не идеальны, но стараемся идти в этом направлении. Большую часть этой теории можно тут же «пощупать» на практике. Динамика наших проектов такова, что, попав в круговорот выпуска очередного релиза какого-нибудь федерального «космолета» под конец года, можно за месяц получить опыта больше, чем в иной компании за год.
Источник
В начале такая скорость сбивает с толку. Иногда вообще сложно понять, что происходит. Но погрузившись в эту атмосферу, уже сложно отказаться от этого ритма, который мотивирует тебя держать руку на пульсе прогресса и постоянно развиваться.
Ну и, конечно же, в-третьих – собеседования.
О собеседованиях
Чтобы сотрудника удержать, надо сделать так, чтобы его не надо было удерживать. А для этого надо, чтобы в команду попадали люди, которые на 100% впишутся в коллектив и сразу вольются в общий поток. Понять, попадет этот сотрудник в поток или нет, за несколько часов собеседования – это та еще задача. Начиная общение с кандидатами, я всегда первым делом синхронизирую с ними терминологию. Все, кто к нам приходит, обычно, где-то до этого работали. У всех есть свое понимание тех или иных терминов: кто-то говорит, что он архитектор, кто-то рассказывает про то, что они делали высоконагруженные проекты, кто-то рассказывает, что у них в базах данных хранилось много данных и т.д. Прежде, чем строить диалог, нужно понять, что вы разговариваете на одном языке. Если вы смотрели фильм «Прибытие», то вот тут примерно такая же история.
В случае нашего подразделения один проект может состоять из десятков частей, причем каждая часть – как отдельный большой проект для иных компаний. Каждый такой проект делает отдельная команда, состоящая из менеджера, аналитика, тимлида разработки и т.д. Когда на первой встрече человек говорит о том, что он «участвовал в 100 проектах, поддерживал 1000 серверов и разворачивал более 9000 баз данных», то на первый взгляд кажется, что человека с таким опытом надо брать в команду, не глядя. Но, если начинать погружаться в детали, часто все становится не таким очевидным.
Еще одна важная вещь, которую я всегда спрашиваю у людей, которых собеседую, это то, чем бы они хотели заниматься в ИТ-компании, если бы у них был выбор при прочих равных? К чему лежит душа, если хотите? Так как у нас постоянно открыты вакансии на разные роли, мы, как правило, не фильтруем людей под вакансию, а смотрим людей и, если есть такая возможность, даем им выбор – на какую позицию им пойти. Для меня главное, чтобы человек, которого мы возьмем, не только делал работу хорошо, но и получал от этого удовольствие – тогда вероятность, что он уйдет, будет меньше.
О наставничестве
В-четвертых, чтобы люди могли прокачиваться, расти, обмениваться опытом и самовыражаться, нужно поддерживать постоянный процесс накопления этого опыта и передачи знаний. Такие возможности у нас тоже есть.
Корпоративной базой знаний в формате Wiki, наверное, сейчас никого уже не удивишь, но сказать о ней все-таки стоит. В нашей базе собрано множество страниц, созданных сотрудниками, с примерами решения технических задач и статьями на различные ИТ темы. Это не статьи формата Хабра или что-то такое. Это скорее заметки сотрудников разной степени детализации для своих же коллег, которые быстро помогают сориентироваться новичкам в том наборе технологий, которые мы используем, и быстрее погрузиться в проект или вспомнить что-то, что было уже давно.
О митапах
Для тех сотрудников, которым тесно в корпоративной Wiki, да и чего скрывать, для PR тоже, мы в прошлом году запустили цикл мероприятий #TechGuruDay, с Твиттером и каналом в Телеграм. Митапы проходят на площадке ЛАНИТ с живыми докладами по ИT-тематике. Наши сотрудники могут выступить в компании приглашенных внешних спикеров. Запустили в этом году блог на Хабре, в который могут писать все сотрудники. Кстати, пользуясь случаем, приглашаю всех, у кого есть интересная тема для митапа, пишите мне на сайте meetup.com – если тема будет как-то пересекаться с тем, что мы делаем, организуем совместный митап.
Поэтому, резюмируя, могу сказать, что причин не уходить от нас, как мне кажется, больше, чем уходить! Но, жизненные ситуации бывают разные, и от нас тоже уходят. В этих случаях мы обычно очень грустим, но продолжаем работать дальше. Особенно, зная, что ушедшие сотрудники грустят вместе с нами и очень часто через какое-то время возвращаются назад.
О планах на будущее
Есть у вас в планах запустить какие-то новые активности?
В этом году хочется провести больше митапов TechGuruDay, чем было в прошлом году, хочется рассказать что-нибудь интересное на какой-нибудь конференции.
Что можете пожелать своим коллегам?
Не стоять на одном месте, постоянно развиваться и двигать мир вперед!
Если прямо сейчас народ захочет попасть к тебе в команду, где им узнать про ваши «космолеты» и кто вам нужен?
Сейчас будет как последний слайд на какой-нибудь презентации с конференции с большой надписью «WE’RE HIRING».
Про «космолеты» можно задавать вопросы в комментариях. Если коротко, то ищем спецов по базам данных PostgreSQL и Oracle, инженеров со знанием ansible и python в команду DevOps/SRE, архитекторов и инженеров по безопасности. Причем, всех уровней. Ну, и, как у всех, у нас есть сайт с вакансиями, где все более подробно расписано.
Автор: ГК ЛАНИТ