Облачный хостинг VDS за 2 минуты

Настоящий облачный VDS-хостинг от UltraVDS: тестируем производительность

Дельта-синхронизация крипто-дисков

Существуют разные способы зашифровать "облако". Один из них - поместить в облако крипто-диск. В предыдущей статье мы писали, почему это не всегда удобно.

Дельта синхронизация без облака

Ранее мы показывали разные способы синхронизации криптодиска между ПК и Android-устройством.

Смотрим плавность хода с помощью BMW Rheingold

Всем знакома ситуация, когда двигатель немного "троит", но пропусков зажигания нет...

Работа для линуксоида


Сотрудники Virtuozzo рассказывают о себе и о том, чего ждут от кандидатов

ВСТУПЛЕНИЕ. Компания Virtuozzo — это разработчик гиперконвергентной платформы в основе которой лежат технологии виртуализации и хранения данных . Мы поговорили с менеджерами компании, чтобы узнать, кто и как разрабатывает такие решения в России, а также рассказать читателю о том, что нужно, чтобы пойти работать в такую фирму.

Как и в любой другой компании, в Virtuozzo есть несколько отделов или команд - команда технической поддержки, команда разработчиков, команда програм-менеджеров, а также один человек, заменяющий собой целый отдел - разработчик ядра Linux. Теоретически, ты можешь попытаться трудоустроиться в любую из этих команд, но обрати внимание на уровень сложности: проще всего устроиться на работу в группу технической поддержки. Тебе достаточно уметь разговаривать на английском, а также иметь представление о командной строке (пусть даже в Windows - даже Linux знать необязательно) и понимать, как работает сеть. Подробнее о работе техподдержки расскажет Мария Антонова - руководитель группы технической поддержки.>

# Мария Антонова, руководитель группы технической поддержки

**Работа:** инженер техподдержки
**Уровень сложности:** EASY
**Необходимые знания:** разговорный английский, стрессоустойчивость, толерантность, 
                        знание Linux и сетей 
**Что получишь кроме денег:** знание Linux и сетей, знание Virtuozzo, 
                              опыт общения на английском
**Карьерные возможности:** старший инженер техподдержки, другие должности в компании

Я руковожу группой технической поддержки Virtuozzo. Когда у клиентов возникают какие-то проблемы с инсталляцией или с использованием наших продуктов, они приходят к нам. Обращения бывают самые разные: от неспешной настройки или анализа производительности до авралов с лежащим продакшен-сервером. И хотя по факту мы являемся фронтлайном – все заявки сразу попадают в мою команду – по сложности заявок мы вторая линия.

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

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


Мария Антонова

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

Бывает, разговоришься и вдруг узнаешь, что кто-нибудь из зарубежных клиентов очень хочет приехать в Россию, в какой-то определенный город, выучить русский язык. То есть общение переходит и на личные темы.

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

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

Из технических навыков нужно понимание работы сетей. Многие сложные случаи связаны именно с сетями. Причем нужно понимать, как работает сеть не только в нашем продукте, но и знать основы – модель OSI, стек протоколов TCP/IP, что такое VLAN,и т.д. Также нужно иметь хотя бы минимальный опыт работы с Linux.

На самом деле, у меня нет каких-то четко прописанных требований и списка навыков. Я смотрю на баланс: на английский, на понимание основ ОС. Если человек не знает Linux, но работал с командной строкой Windows и имеет представление о сетях, то ему просто потребуется больше времени и больше сил на освоение новых вещей. Главное — чтобы соображал хорошо.

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

В поддержке есть, куда расти в смысле карьеры. У нас где-то пять градаций — от junior-инженера можно дорасти до chief-инженера. Плюс у нас сейчас только один technical account manager — человек, который работает с определенными клиентами, с большим погружением в их инфраструктуру, разбирается в бизнес-планах и проектах, которые они собираются внедрять. Также мы планируем развивать направление customer success. Туда будут входить роли technical account manager и, в некотором виде, professional services. Это может быть консультирование клиента, помощь в первоначальной настройке. Плюс наши сотрудники будут писать тренинги, которые мы будем предлагать клиентам.

Для оценки эффективности работы мы используем набор стандартных метрик: время, за которое мы найдем решение нетривиальной проблемы (initial response time, time to workaround), время на решение для заявок с высокими приоритетом. Мы стараемся отслеживать общее время, которое уходит на закрытие тикета. Отслеживаем и общее удовлетворение клиента и качество обслуживания (customer satisfaction rate и quality). Есть внутренние инструкции, где описано, как поступать в таких-то случаях, как категоризировать заявку и так далее.

Раз в пару недель я стараюсь встречаться с каждым инженером из моей команды, чтобы «синхронизоваться» - узнать общий настрой человека, обсудить его успехи/проблемы, дальнейшее развитие, получить/дать обратную связь.

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

Бывают интересные и сложные в техническом плане тикеты. Например, долго пытаешься понять, почему у виртуальной машины не работает сеть, а потом оказывается, что проблема вытекает из определенного конфликта обновленной прошивки на Cisco и последнего обновления сетевого драйвера Red Hat. Пока до этого докопаешься, семь потов сойдет, со всеми переговоришь и обратишься, куда только можно.

Ну и, конечно, в нашей работе происходит масса забавных случаев. Однажды нам пришел тикет — начинаем его читать и понимаем, что что-то не то. Оказывается, человек написал его в стихах! Что делать, отвечать пришлось тоже стихами. Потом с клиентом посмеялись, он сказал: «спасибо, что поддержали, прямо можно распечатать и на стенку повесить».

Как видишь, техподдержка - это совсем не скучно, во всяком случае в Virtuozzo. Но если ты - умеешь программировать на С, знаешь один из скриптовых языков (например, bash), и тебе совсем не хочется общаться с не всегда уравновешенными клиентами, тогда обрати свое внимание на команду разработчиков Virtuozzo Linux. О том, что представляет собой эта команда, расскажет ее лидер - Денис Силаков.>

# Денис Силаков, лидер команды Virtuozzo Linux

**Работа:** разработчик
**Уровень сложности:** MEDIUM
**Необходимые знания:** продвинутое знание Linux, желательно знание C/C++ и 
                        одного из скриптовых языков
**Что получишь кроме денег:** ещё более продвинутое знание Linux, опыт 
                              разработки дистрибутива, опыт работы в команде
**Карьерные возможности:** senior developer, работа в любой другой компании, 
                           связанной с Linux

Я руковожу командой, создающей Virtuozzo Linux. Это наш собственный дистрибутив — практически собственная ветка CentOS с нужными нам изменениями, которые используются во флагманских продуктах Virtuozzo. Мы предлагаем Virtuozzo Linux и как отдельный продукт, но его главное применение — служить основой для наших флагманских продуктов, то есть Virtuozzo, [OpenVZ] (https://openvz.org/Main_Page) и [Virtuozzo Storage]( https://virtuozzo.com/products/virtuozzo-storage/). Сам Virtuozzo — это ядро и некоторые компоненты, но для его работы нужны многие вещи из пользовательского пространства. Вот это пользовательское пространство как раз и предоставляется Virtuozzo Linux.


Денис Силаков

В силу специфики наша команда работает над несколькими большими проектами. Это тестирование и автоматизация самого разного рода. Разных пакетов много, случаи сложные, и когда мы что-то берем из CentOS или откуда-то ещё, то хотим убедиться, что всё заработает гладко. У нас есть люди, которые по собственной инициативе дописывают некоторые вещи. И, поскольку у нас специфичные сценарии, мы часто ловим баги, которые не поймал RedHat. Поэтому общаемся с RedHat и патчим.

Человек, который придет к нам в команду, получит массу знаний о Linux и его устройстве. Как он загружается, как загружаются библиотеки, что такое systemd, как он устроен, где и какие сервисы стартуют, как устроена сеть. В силу специфики всякими графическими штуками мы не занимаемся, так что как пропатчить KDE под Virtuozzo мы не расскажем. В целом, нормальное такое системное программирование — слой, который лежит повыше ядра и обслуживает всю систему. В любых его компонентах приходится копаться.

У нас есть задачи на разный уровень подготовки и связанные с разными частями системы. Что точно придется изучить, поверхностно или глубоко, — это, например, сборку пакетов RHL. Нужны и спецы по безопасности. Но вообще узких областей, на которые мы бы искали человека для решения конкретной задачи, у нас нет. Наши сотрудники ориентируются во всей системе. Понятно, что вглубь во всё сразу не проникнешь, но надо быть готовым обучаться на месте. Мне кажется, что если человек нормально разбирается в Linux, то обычно он готов.

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

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

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

Анализ кода мы делаем через запросы на включение (pull request - прим. редактора). Для этого используем Git stash и свою утилиту, которая позволяет отсматривать и комментировать патчи обозримого объема, то есть где-то до тысячи строк. Если изменения большие, скажем, это первая выкладка какого-то большого компонента, общение идет либо в Jira, либо просто по почте.

Принимая человека на работу, мы в первую очередь — ещё до интервью, смотрим, что он может рассказать о себе и что показать. Как правило, если человек работает с Linux, то у него есть такие-то опенсорсные работки, на которые можно посмотреть — как минимум патчи на GitHub. А если есть свои проекты, то это вообще отлично. Мы смотрим, как человек кодит и как общается. Если есть такой бэкграунд, то потом на собеседовании всегда интересно поговорить о том, что он делал в других проектах.

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

Ещё нам важно проверить, насколько человек хорошо ориентируется в Linux — как пользователь или как сисадмин. На собеседовании можем, к примеру, дать ему написать какой-нибудь shell-скриптик и посмотреть, как он будет бодаться с синтаксисом bash и с командами.

Когда человек приходит в команду, мы обычно даем ему реализовать какую-нибудь небольшую фичу, чтобы он ознакомился с нашим рабочим процессом и процессом анализа кода. Заодно посмотрит, как мы работаем с комьюнити, как устроена Jira и так далее. Ну и заодно сделает что-то маленькое, приятное и полезное.

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

Иногда мы берем студентов — за несколько лет до окончания вуза. У них, начиная с третьего курса, идет базовая кафедра, в роли которой можно выбрать и Virtuozzo. Чем ближе к выпуску, тем больше времени они проводят у нас. Если стажер нам нравится и ему нравится у нас, то к концу обучения он фактически становится нашим работником. К примеру, на Физтехе на пятом курсе ты всего два дня в институте, в остальное время уже работаешь.

Если ни техподдержка, ни разработка тебя не привлекают, ты можешь попробовать себя на роли програм-менеджера. Все-таки руководящая должность - есть руководящая должность. Об особенностях этой роли расскажет Алексей Моруга.>

Алексей Моруга, директор управления программами компании Virtuozzo

**Работа:** program manager
**Уровень сложности:** HARD
**Необходимые знания:** технический бэкграунд, опыт управления и разрешения конфликтов, 
                        опыт в техподдержке или разработке, способность не терять точку 
                        зрения пользователя на продукт даже находясь внутри команды разработки
**Что получишь кроме денег:** ещё больше опыта в управлении, расширишь свой кругозор в 
                              современных технологиях управления виртуализацией и 
                              приложениями, знакомство с Linux и рынком виртуальной инфраструктуры
**Карьерные возможности:** старший менеджмент

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

Мы, в частности, решаем, что войдет в следующую версию продукта, получая информацию из разных источников – для существующих продуктов это прежде всего из общение с заказчиками и теми кто мог бы им стать, для новых и перспективных продуктов – анализ рынка, проблем потенциальных клиентов и решений конкурентов. Основная цель подобного планирования – это строить продукт который может быть успешен на рынке, который компания может продавать и зарабатывать на этом. Обрабатывать пожелания пользователей не так просто как может показаться; первое, что нужно понять, когда клиент просит добавить ту или иную фичу, — это какую проблему он пытается с ее помощью решить, и насколько эта проблема уникальна для конкретного клиента. Мы стараемся избегать ситуаций, когда мы добавляем новую функцию, а клиент говорит: «это не работает, вы неправильно сделали, я имел в виду не это». Нужно убедиться, что та фича, которую он предлагает, — это действительно решение. Или, возможно, нужно какое-то другое решение. Мы знаем продукт изнутри и часто можем предложить решение связанное, например, с внешней интеграцией, с вызовом продукта из командной строки, через API и тому подобное. В случаях когда проблема данного клиента уникальна и другим подобное не нужно – это обычно самый правильный способ.

В подобных ситуациях, если клиент хочет что-то, что нужно только ему, и при этом это не конфликтует с общей стратегией развития продукта, то тут может быть еще один вариант. У нас есть небольшая команда, которая может делать для конкретного клиента какие-то настройки, кастомизировать какие-то вещи в продукте или связанные с продуктом. Мы называем это professional services. Мы — не та компания, которая делает индивидуальные решения для каждого клиента, но если заказчик большой и финансово это имеет смысл, то мы можем построить и поддерживать что-то специально для него.

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

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

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

Кроме того, технические навыки важны, потому что програм-менеджеры должны понимать, может ли предложенное техническое решение реально решить проблему. Не понимая, как работает технология, очень тяжело предположить, когда она подойдет для решения проблемы и когда - нет.

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

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

А теперь настало время познакомиться с человеком, который заменяет собой целую команду - Павлом Емельяновым. Он является главным архитектором Virtuozzo и именно благодаря его стараниям теперь ядро Linux официально обзавелось [CRIU] (https://criu.org/Main_Page) (Checkpoint/Restore In Userspace) - софтом, позволяющим создать извне во время выполнения произвольной программы контрольную точку с возможностью возобновления работы программы с этой точки, в том числе в другом экземпляре операционной системы.>

Павел Емельянов, Главный архитектор Virtuozzo

**Работа:** разработчик ядра Linux
**Уровень сложности (сложно ли попасть):** IMPOSSIBLE 
**Необходимые знания:** знание C и ядра Linux, левитация, телекинез
**Что получишь кроме денег:** полное погружение в любимую работу, знакомства 
                              в сообществе, опыт решения нетривиальных задач
**Карьерные возможности:** разработчик ядра Linux

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

Для примера расскажу историю появления CRIU. Изначально все модификации Virtuozzo не шли в основную ветку ядра (т.н. upstream) — то есть в ядро Linux. Они были открытыми, но это, по сути, у нас была своя собственная ветка ядра. В какой-то момент мы начали отправлять всю эту функциональность Линусу Торвальдсу. Так появились подсистемы cgroups и namespaces, которыми сейчас все пользуются. А еще был третий компонент — живая миграция, которая у нас была целиком в ядре. Чем-то похожим занимались не только мы, но и IBM и еще несколько исследователей из Колумбийского университета. Несколько лет команда разработчиков ядра не принимала эти патчи: все говорили, что это слишком большая подсистема, которая выворачивает наизнанку всё ядро. Вы, мол, пока работайте, но отдельно от нас. Постепенно мы стали вытаскивать некоторые компоненты наружу, в user space. То есть была утилита, которая дергала один единственный вызов в ядре, типа восстановить или сохранить. Но вытащить всё в user space невозможно, и мы продолжали писать патчи для ядра.

В какой-то момент Линусу всё это надоело, и он сказал «всё, дальше можете даже не пробовать, я это брать не буду». Тогда я решил попробовать вынести в пользовательское пространство максимум. И написал прототип, который впоследствии и превратился в CRIU. Не помню, сколько в нем было строк, но даже тысячи, кажется, не набиралось. Он сохранял и восстанавливал программку, которая работала с открытым файлом. У нее не было ни сокетов, ни пайпов, ни сигналов, никаких хитрых отображений в памяти - несколько небольших патчей для получения о процессе то ли памяти, то ли регистров, и для создания процесса с заданным идентификатором (PID). Это можно было сделать в режиме отладчика, но тогда операции происходили бы побайтово, а мне была важна скорость. В общем, в результате появилось два патча и та малюсенькая программулинка. Народ посмотрел и решил, что это интересно — всего два патча, а возможностей открывается масса. Попросили развить эту идею.

Тут началась та же история, что и с попыткой занести все в ядро. Я добавил что-то еще — пайпы в том числе. Потом мне сказали: «зачем тебе модифицировать proc-файл для доставания памяти, доставай как отладчик». Мы переделали это, я тогда подключил к работе ещё одного сотрудника.

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

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

Так мы сделали CRIU 0.1. Мортон влил патчи в ядро, об этом были написаны статьи, я выступил на конференции с докладом. Тогда в Virtuozzo поняли, что, видимо, мы наконец-то выкинем из нашего ядра checkpoint restore (это та самая живая миграция) и перейдем на мой вариант. Так CRIU перестал быть моим pet project и стал поддерживаться официально.

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

Последний наш спикер - Алексей Кобец – Старший вице-президент по разработке Virtuozzo.

**Работа:** Старший вице-президент по разработке Virtuozzo
**Уровень сложности (сложно ли попасть):** IMPOSSIBLE 

В нашей команде [90 человек] (https://xakep.ru/2016/10/21/virtuozzo-interview/). У нас есть несколько функций, но основная - это девелопмент, ее выполняет отдел разработки. Там есть разработчики, там есть тестировщики, там есть программ-менеджмент, есть техрайтеры, которые описывают все фичи продуктов. Также у нас есть отдел, который занимается перспективными разработками. Это ключевые отделы, которые вместе создают наши продукты.

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


Алексей Кобец

Мы работаем с несколькими вузами, есть студенческие программы и интернатура. Начинающим можно прийти туда. Студенты, к примеру, занимаются CRIU. Через один-два года стажировки студенты приходят к нам на полный рабочий день и подключаются к серьезным разработкам. Если посмотреть на команду, у нас достаточно большое число людей прошли такой путь, начиная с меня самого. Недавно заметили, что студенты на стажировку к нам идут труднее. Начали разбираться почему, оказалось, что просто стали мало выдавать тем для дипломов с математикой. А куда на физтехе без математики? Шанс защититься куда меньше. От этого и студенты стали меньше брать наши темы. Относительно условий работы, я считаю, что мы все должны работать в офисе. На самом деле практика показывает, что многие задачи в офисе решаются быстрее и эффективнее. Рабочий день не нормированный. День начинается в 11, а заканчивается очень поздно, потому что мы работаем с Америкой и нужно, чтобы мы пересекались с клиентами по часам. Тестеры и разработчики должны обязательно пересекаться, то есть работать в одно и то же время. Чтобы не допускать абсурда, когда тестер нашел ошибку, а разработчика нет, приходит разработчик, воспроизвести не может, а тестера уже нет.