Насколько важна установка профессиональных требований к сотрудникам? Как задать её технически и организационно? К чему приводит искусственное сужение поиска и подбора кадров в компании?
Начнем с того, что технические рамки качества задаются руководителем отдела. В случае нашего IT, задаются они в выборе софта, оборудования, подходов к работе, подходов к документированию и контролю исполнения, способов поддержания порядка.
Допустим, мы хотим, чтобы нашей сетью занимались инженеры, способные докопаться до истины, и разобраться с оборудованием и софтом. Задача кажется банальной, но не всё так просто. Как понять, что человек может разобраться? Результаты в IT не наступают моментально - их видно минимум через год, а иногда и через два-три - аварийность, экономия денег на ресурсах, скорость релизов и прочие метрики. Кроме того - часто "голые метрики" по системе, которую коллектив вытачивал год - не говорят о том, что люди действительно могут разобраться в проблемах - даешь им другую новую систему и ничего не получается. Да, просто повезло. Да, просто не отхватили полный спектр проблем на предыдущем проекте. И еще куча мелких причин почему там получилось, а здесь нет. Главная первопричина едина - имеющийся коллектив не имеет инженерного подхода к работе и действует "решая проблемы по мере поступления", вместо создания расчётной конструкции с понятными и проверенными характеристиками. В IT-инфраструктуре такое практически в каждом отделе эксплуатации/DevOps/SRE/как-не-назови.
Почему так?
Во-первых, потому-что проще найти на рынке людей везучих и умеющих делать что-то одно, чем инженера с инженерными навыками готового решить условно "универсальную задачу" в области его знаний. Конечно проще - их тысячи. Инженеров - единицы.
Так зачем же искать инженеров?
Подход "я это уже делал" не работает в следующих случаях - в случае, когда каждый новый проект уникален по каким-то качествам (нагрузка, технологии, имеющийся легаси и т.п.) - на самом деле оно нужно в первую очередь подрядчику. Подрядчик, берущийся спроектировать и обслуживать инфраструктуру должен легко и быстро войти в имеющуюся данность и минимальными действиями модернизировать её до уровня требований. Конечно, дать на результат гарантии.
Второй случай - проекты с повышенной ответственностью, когда в принципе решаемая задача уникальна по своему качеству. Например, проект с требованиями <2 минут в год downtime. Или с какими-то своими уникальными особенностями.
Третий случай и самый частый для нас - длительное поддержание инфраструктуры на протяжении 5-8 лет. За это время отыграют абсолютно все ситуации, которые в ней возможны - от наивности разработчиков с их пятничным релизом, до взломов, физического старения оборудования, переездом между датацентрами и всеми остальными развлечениями, которые часто для временного менеджмента (1-4 года на проекте) остаются за кадром.
Ну так вот вернемся к тому, как искать.
Допустим, нам нужна очень хорошая команда сетевых инженеров. Давайте посмотрим - а какое сетевое оборудование популярно и обсуждаемо в интернете. Cisco, Juniper, Mirotik, HPE, Dell. И сразу откажемся от него полностью. На этапе старта, на этапе планирования будущего отдела, будущей инфраструктуры и закупок. Почему так? Потому что определить на слух на собеседовании может ли человек с чем-то разобраться, по вопросу "работали ли вы с популярным оборудованием XXX? - Да" невозможно совершенно. С ним все работали в какой-то степени и в каком-то объеме опыта.
Давайте посмотрим на другой рейтинг оборудования, более инсайдерский, и менее очевидный, чем обсуждения - сколько продано в штуках? D-Link, Huawei, TP-Link, далее список производителей SOHO-класса. Ок. Остановимся на D-Link и Huawei. Его можно. Давайте посмотрим - устраивают ли они нас технически под наши задачи? Да, устраивают оба. Давайте возьмем и найдем в этом оборудовании проблемы (баги и недочеты - они есть везде и всегда). Поймем - где они тривиальны, где они находимы, где они сложны для отладки - и возьмем средний случай по количеству проблем, но таких, чтобы они были обнаруживаемы без посторонней помощи (техподдержки вендора). У нас таким получился D-Link. Да, для этого нужно самому быть инженером и желать набрать инженеров в команду, либо иметь возможность проконсультироваться с инженером и опять же иметь желание этим заниматься.
И вот можно ли понять по вопросу "Есть ли у вас опыт работы с D-Link в продакшине? - Да.", действительно ли человек способен разобраться с оборудованием? По одному вопросу сложно, но да - вероятность того, что он реально работал с этим оборудованием больше, чем 2 часа в своей жизни, гораздо выше, чем в случае обсуждения того, что все обсуждают. Так же если где-то до нас выбрали такое оборудование - на это имелись свои причины, и они явно не популярность оборудования в прессе. Очень вероятно, что руководство на одном из его прошлых мест работы, рассуждало аналогично нашим рассуждениям (либо просто руководствовалось экономией, но получило аналогичные нашим результаты).
Куда мы идем дальше? А дальше мы обсуждаем реальные проблемы этого мало обсуждаемого оборудования - человек, знающий 3 из 5и проблем - действительно имел опыт, действительно разобрался с оборудованием (а не заменил его на другое) и 3 из 5 - это очень большой опыт. Чаще всего 0 из 5 - это примерно 90 человек из 100, или 1 из 5 - это 8 человек из ста. И вот оставшиеся 2 человека имеют реальный опыт длительной работы с железкой, подход инженера и решенные проблемы.
Наш опыт
Мы так и начали набирать сетевых специалистов. Изначальный кейс - мы devops/sre по подряду - проектируем и длительно обслуживаем инфраструктуру у клиента. И да, коммутатор нам набрал специалистов. Это был D-Link DGS-1216T, 2009 года покупки.
К моменту Икс у нас была сеть между пятью датацентрами, связывающая нас c клиентами, дающая им бекапы и безопасность, а нам возможность иметь связь с оборудованием клиента даже при упавшем наглухо провайдере.
В момент Икс наш сетевой отдел построил нам VPS-хостинг с уникальными на тот момент показателями (сейчас рынок уже усреднился и мы не впереди других по ним уже несколько лет, но зашли на определенный уровень качества одними из первых).
В следующий момент этот же сетевой отдел обеспечил нам череду переездов между датацентрами в бесперебойном режиме. И позже - обеспечил нашим клиентам быстрый перенос всего из-за рубежа в РФ и в обратную сторону в момент взаимного политического бана между Россией и Западом.
Так как же работал конкретный коммутатор?
Не усложнил ли жизнь инженеров и не был ли точкой создания трудностей. История его использования простая:
- Был первым коммутатором на первой площадке в ЦОД. Обслуживал наш доступ к серверам клиентов, позже обслуживал часть хостинга.
- Переехал на вторую площадку, где тоже долгое время работал. Обслуживал часть хостинга.
- Переехал в региональный офис, где обслуживал PC офисных пользователей.
- Переехал на третью площадку, где обсуживал еще одну часть хостинга.
- Позже был перенесен на малоответственную часть сети (ввиду долгих лет эксплуатации), где и завершил свою работу в сетях компании.
- Потом он оказался в музее компании, и попался в руки фотографу.
За всё время с 2009года по 2021год было три аварии - первые две, по признанным и понятным ошибкам инженеров. Третья - ввиду того, что оборудование уже изношено, вышел из строя окончательно и был снят с эксплуатации.
Хороший ли набрался отдел? Да прекрасный! Отличная команда, которая смогла решить и текущие задачи, и построить новое и решить потребности нашего бизнеса и бизнеса клиентов в сложное время.
Иногда задать минимальные требования к подходу к работе, к людям, к процессам - это то, что закладывает будущее компании в каком-то из направлений. Иногда - в приоритетном направлении. А главное - совершенно не нужно "заглядывать внутрь" или активно менеджить имеющийся отдел. Все рамки заданы техникой, все требования заданы ей же.