Шаблоны золотых путей
Заранее одобренные отправные точки для нового сервиса, чтобы у разработчика логирование, мониторинг и развёртывание были настроены правильно уже с первого коммита, без лишних вопросов.
DevOps
Инструменты самообслуживания, золотые пути и внутренняя платформа для разработчиков, которые позволяют вашим разработчикам выпускать релизы, не дожидаясь запросов к инфраструктуре.
Растущий бизнес в Дубае с более чем одной продуктовой командой обычно решает нанять платформенного инженера, когда одну и ту же работу с инфраструктурой начинают повторять разные люди, или когда один опытный разработчик незаметно становится тем, к кому все идут с вопросом, как что-то развернуть. Вместо разработки продуктовых функций платформенный инженер строит инструменты, шаблоны и интерфейсы самообслуживания, которые позволяют другим разработчикам делать эту работу самим, последовательно, не дожидаясь помощи каждый раз.
Собственный White Paper о платформах от Cloud Native Computing Foundation описывает внутреннюю платформу для разработчиков как “интегрированный набор возможностей, определённых и представленных в соответствии с потребностями пользователей платформы”, относясь к другим разработчикам как к реальным пользователям работы платформенной команды, примерно как у внешнего продукта есть клиенты. Эта формулировка служит полезной проверкой для кандидата: говорит ли он о сокращении числа шагов для другого разработчика до успеха, или только о самих инструментах.
На этой странице разобрано, что обычно строит платформенный инженер, какие навыки стоит проверить, прежде чем нанять платформенного инженера в Дубае, и как оценить кандидата по этому критерию.
Что строит платформенный инженер
Интерфейсы и шаблоны, а не инфраструктура, которую вручную ведут под каждый запрос.
Заранее одобренные отправные точки для нового сервиса, чтобы у разработчика логирование, мониторинг и развёртывание были настроены правильно уже с первого коммита, без лишних вопросов.
Единое место, чтобы видеть, какие сервисы существуют, кто за них отвечает и их текущий статус, вместо разрозненных таблиц и знаний, которые держатся в голове у отдельных людей.
Способ для разработчика поднять тестовое окружение или новую базу данных без подачи заявки и ожидания, пока кто-то другой её обработает.
Единый способ развёртывания для каждой команды, чтобы знания и инструменты, созданные для одной продуктовой команды, чисто переносились на следующую.
Разумные настройки по умолчанию и автоматические проверки, которые удерживают команды в рамках политики, вместо ручного согласования на каждый запрос.
Честное измерение того, реально ли команды пользуются платформой и находят её быстрее ручной работы, а не просто её создание в надежде на лучшее.
Важные навыки
Продуктовое мышление, применённое к внутренним инструментам для разработчиков.
| Навык или инструмент | Как выглядит хороший уровень | Почему это важно |
|---|---|---|
| Kubernetes или похожая оркестрация | Уверенно работает с собственной моделью нагрузок и сервисов платформы, согласно её документации | Большинство внутренних платформ для разработчиков построены поверх этого слоя |
| Инфраструктура как код | Пишет переиспользуемые, хорошо задокументированные модули, которые другие команды могут уверенно применять | Разовый скрипт, это не платформа, которой могут доверять другие команды |
| Проектирование API и инструментов | Проектирует интерфейсы, сначала спросив разработчиков, что им реально нужно | Платформу, которой никто не хочет пользоваться, обходят стороной, а вложения пропадают зря |
| Привычка документировать | Пишет понятные руководства как часть релиза, а не как что-то дополнительное потом | Самообслуживание работает только если разработчики могут найти ответ сами, не спрашивая |
| Общение с заинтересованными сторонами | Может объяснить решения по платформе другим разработчикам простыми словами | Внедрение зависит от доверия не меньше, чем от самих инструментов |
White Paper CNCF о платформах описывает работу платформенной команды как изучение потребностей пользователей и снижение когнитивной нагрузки для продуктовых команд, и это хорошая мысль, которую стоит принести на собеседование, когда вы решаете нанять платформенного инженера в Дубае, поскольку она отделяет платформенное мышление от общей работы с инфраструктурой.
Форматы сотрудничества
Выделенный инженер подходит бизнесу с несколькими продуктовыми командами и постоянно повторяющейся работой с инфраструктурой, где платформа растёт вместе с командами, которым она служит. Проект с чёткими рамками подходит для конкретной цели, например построения шаблона золотого пути для одного типа сервиса или запуска базового портала для разработчиков, с передачей документации по завершении. Поддержка в подборе персонала подходит бизнесу, который хочет нанять этого человека напрямую и со временем развивать роль внутри штата. Консалтинг подходит команде, которая хочет получить независимую оценку того, оправдана ли платформенная инженерия как вложение вообще, прежде чем выделять на неё бюджет.
Оценка кандидата
Проверки, которые раскрывают продуктовое мышление, а не просто техническую широту.
Эти проверки работают вне зависимости от того, проводите ли вы их сами или просите нас провести их в рамках поддержки в подборе персонала, когда вы решаете нанять платформенного инженера в Дубае.
Кандидат с реальным опытом может описать что-то, что он построил технически безупречно, но чем пренебрегли, и почему, показывая, что он понимает: внедрение не происходит само собой.
Опрашивал ли он разработчиков перед тем, как строить, или угадывал. Платформа, построенная без опроса пользователей, склонна хорошо решать не ту проблему.
Спросите, от чего он защищает, что предполагает, и как другая команда расширила бы его под свои нужды.
Сильный кандидат может рассказать случай, когда он ослабил ограничение, потому что оно мешало законной работе, а не только про ужесточение контроля по умолчанию.
Цифры внедрения, сэкономленное время или меньше запросов в поддержку, это конкретные ответы. Смутное ощущение, что “командам вроде бы стало приятнее”, это более слабый сигнал, и именно такой пробел этот список призван поймать, прежде чем вы наймёте платформенного инженера в Дубае.
Сертификации
Сертификации, которые поддерживают платформу, поскольку у самой платформенной инженерии нет единого сертифицирующего органа.
Cloud Native Computing Foundation совместно с Linux Foundation выпускает дипломы Certified Kubernetes Administrator и Certified Kubernetes Application Developer, оба актуальны, поскольку большинство внутренних платформ для разработчиков построены поверх Kubernetes или похожей системы.
Собственный White Paper CNCF о платформах служит лучшим общим ориентиром для самой роли, чем любой сертификат, поскольку он определяет, для чего вообще нужна платформенная команда. Спросите кандидата, читал ли он его, это один из вопросов, которые мы задаём, когда клиент просит нас найти платформенного инженера в Дубае.
Особенности ОАЭ
Одна область, которая становится важной, когда платформа обслуживает несколько продуктовых команд.
Окружения самообслуживания могут облегчить разработчику копирование продуктовых данных в тестовое окружение, не осознавая последствий. Федеральный декрет-закон № 45 от 2021 года, федеральный закон ОАЭ о защите данных, продолжает действовать и в отношении этой копии, и именно поэтому некоторые компании в Дубае решают нанять платформенного инженера специально, чтобы встроить такие ограничения по умолчанию.
Там, где платформа обслуживает команды, создающие интерфейсы на арабском и английском, шаблоны, которые с самого начала правильно обрабатывают раскладку справа налево, избавляют каждую внедряющую их команду от решения одной и той же проблемы по отдельности.
Эта роль относится к нашей категории DevOps, части раздела нанять разработчиков в Дубае. Пайплайны и автоматизацию развёртывания, которые обычно оборачивает платформа, покрывает наша страница DevOps-инженер, а серверы, сеть и облачные мощности в основе всего этого лежат на инженере по инфраструктуре. Как только сервис запущен, за его аптайм отвечает SRE-инженер, а безопасность, встроенная в саму платформу, это фокус DevSecOps-инженера. Для небольшого бизнеса, у которого ещё нет нескольких продуктовых команд, наша страница облачные услуги может стать более простой отправной точкой.
Прямые ответы
DevOps-инженер часто строит и напрямую ведёт пайплайны и инфраструктуру для одной продуктовой команды. Платформенный инженер строит инструменты, шаблоны и интерфейсы самообслуживания, которые позволяют другим разработчикам делать эту работу самим, в бизнесе в Дубае с несколькими продуктовыми командами, использующими общую инфраструктуру.
Скорее всего, пока нет. Платформенная инженерия окупается, когда несколько команд повторяют одну и ту же работу с инфраструктурой, либо один опытный разработчик тратит реальное время на помощь другим с развёртыванием и окружениями вместо разработки продукта.
По-разному, но обычно это портал, набор шаблонов и инструмент командной строки, которые позволяют разработчику за несколько кликов поднять новый сервис, базу данных или окружение, автоматически следуя вашим стандартам, вместо того чтобы их каждый раз объясняли.
Подход похож, поскольку платформенный инженер относится к другим разработчикам как к пользователям платформы, изучает, что им нужно, и сокращает число шагов до успеха, но аудитория здесь внутренняя.
Часто на рабочем уровне да, но фокус платформенного инженера, это интерфейс, которым пользуются разработчики, а не обязательно серверы и сеть под ним. Именно для инфраструктуры наша страница про инженера по инфраструктуре покрывает этот фокус.
Источники
Фиксированная цена в письменном виде
Получили. Мы уже готовим ваше предложение.
В рабочее время вы получите его в течение 45 минут. Проверьте почту, там письмо с подтверждением.