Онбординг нового человека в инфраструктуру: первая неделя по дням

MAATRIX

Есть два одинаково плохих способа встретить нового технического человека в первый день. Первый — вывалить на него все пароли и root-доступ сразу, чтобы «не тратить время на бюрократию»: он ещё не понимает, как устроена система, а уже может её сломать одной неудачной командой. Второй — выдать доступ ровно к одному тестовому серверу и заставить неделю ждать, пока кто-то «найдёт время» добавить остальное: человек демотивирован, ничего не успевает и начинает сомневаться, туда ли он попал. Оба варианта — следствие того, что онбординг не спланирован как процесс, а собирается на ходу. Ниже — рабочая схема на первую неделю, где доступ растёт постепенно и осмысленно: не по часам, а по дням, в логике «от знакомства — к самостоятельности».

День 1: минимальный доступ и общая картина, а не root ко всему

Первый день — не про то, чтобы дать человеку возможность что-то чинить. Он про то, чтобы человек понял, куда попал, прежде чем получит инструменты, которыми можно навредить.

Практический минимум на утро первого дня:

• Персональная учётная запись — не общий пароль от deploy и не чужой SSH-ключ, скопированный «на первое время». Доступ должен быть привязан к конкретному человеку с первой минуты, иначе потом придётся переделывать.
• SSH-доступ ровно к стейджингу или к тестовому окружению, без прав в продакшен. Если инфраструктуры для тестов нет вообще — это отдельная проблема, которую стоит решить до найма, а не компенсировать выдачей root на боевой сервер.
• Чтение (не запись) в репозитории инфраструктурных конфигов — Terraform/Ansible, docker-compose, systemd-юниты. Человек должен иметь возможность посмотреть, как всё устроено, до того как начнёт это менять.
• Доступ к обзорному документу по инфраструктуре — если он есть, это первое, что открывается в первый час, до раздачи паролей. Как собрать такой документ — то есть паспорт инфраструктуры на одну страницу вместо памяти админа, — разобрано отдельно в статье «Паспорт сервера: одна страница вместо памяти админа»; если у вас такого документа ещё нет, первая неделя нового человека — хороший повод его наконец написать, а не откладывать в третий раз.

Дальше — час-полтора на разговор, не на самостоятельное чтение конфигов. Кто-то из команды (не обязательно тимлид — подойдёт любой человек с полной картиной) проговаривает архитектуру на высоком уровне: сколько окружений, что где крутится, куда идёт трафик, какие есть внешние зависимости (провайдер, DNS, платёжный шлюз), кто за что отвечает. Цель — не выучить схему наизусть, а получить достаточно контекста, чтобы вопросы на второй день звучали конкретно, а не «а что вообще происходит».

Механика самого первого дня — таблица ролей, команды для создания персонального пользователя, конкретный чек-лист — подробно разобрана в статье «Подключение нового сотрудника к инфраструктуре: регламент на один день». Здесь день 1 — только первый шаг более длинной последовательности: не разовое событие, а начало недели, за которой должно последовать закономерное расширение прав.

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

Дни 2-3: погружение в конкретные системы и наблюдение за процессами

Со второго дня доступ остаётся на уровне стейджинга, но фокус смещается — с «познакомиться со всем на верхнем уровне» на «разобраться в конкретных системах, с которыми предстоит работать каждый день». Бэкендеру — база данных, очереди сообщений, деплой конкретного сервиса. DevOps-инженеру — оркестрация контейнеров, CI/CD, мониторинг. Разобраться во всей инфраструктуре сразу за два дня нереально: лучше глубоко в своей части, чем поверхностно везде.

Практически это выглядит так:

• Разбор конфигурации тех систем, с которыми предстоит работать: не абстрактная документация, а реальные файлы — docker-compose.yml, конфиг nginx, переменные окружения сервиса, cron-задачи. Лучше рядом с кем-то из команды, кто может объяснить, почему сделано именно так, а не иначе — в реальной инфраструктуре всегда есть исторические решения, которые не объяснить одной документацией.
• Тестовый прогон типового рабочего сценария на стейджинге: деплой тестового изменения, откат, просмотр логов после ошибки. Это быстрее и безопаснее учит инструментам, чем чтение мануала.

Отдельная и не менее важная часть этих двух дней — не техническая, а процессная: наблюдение за тем, как команда на самом деле работает, а не как написано в регламенте. Это включает:

• Как реагируют на инциденты. Если за эти дни случается реальный (даже небольшой) сбой — это возможность посмотреть со стороны: кто первым замечает проблему, куда пишут, кто принимает решение об откате, как формулируется постмортем. Новому человеку достаточно быть в канале и видеть последовательность действий.
• Как принимаются решения. Обсуждается ли изменение в чате перед деплоем в продакшен, нужен ли ревью пул-реквеста, кто утверждает рискованные правки firewall или миграции базы. Формальный регламент может говорить одно, а реальная практика — другое; новому человеку полезно увидеть именно практику.
• Куда идут вопросы. К кому обращаться по конкретной системе, а к кому нет — потому что человек с подходящей должностью на самом деле в этой части давно не разбирается, а разбирается кто-то другой.

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

Дни 4-5: первые самостоятельные задачи и расширение доступа

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

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

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

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

Если первые задачи проходят гладко, к концу пятого дня разумно расширить доступ до части продакшена, соответствующей роли — но не до всего сразу и не как формальность «пора, неделя прошла». Показатель готовности — не календарь, а то, задаёт ли человек вопросы про последствия («если откатить эту миграцию, что будет с данными, записанными за это время?»), а не только «как это сделать технически». Первое — признак мышления в категориях риска. Второе само по себе неплохо, но недостаточно для доступа в продакшен.

Как балансировать скорость и осторожность, не съезжая ни в одну крайность

Оба перекоса — реальный риск, и стоит явно понимать, чем расплачивается каждый.

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

Слишком медленная, избыточно осторожная выдача — тоже не бесплатна, просто цена не так заметна сразу. Человек, которого неделями держат на правах «только читать», не успевает набрать реальный опыт и теряет мотивацию: ощущение, что тебе не доверяют базовые вещи, демотивирует быстрее прямой критики. Практический эффект — либо человек начинает обходить процесс (просить коллегу выполнить команду от своего имени), либо перестаёт проявлять инициативу, потому что она каждый раз упирается в отсутствие доступа.

Работающий баланс — не найти правильную скорость один раз, а привязать расширение доступа к конкретным, наблюдаемым признакам готовности, а не к календарным датам:

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

Типичные ошибки первой недели

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

• Доступ выдаётся один раз в первый день и больше не пересматривается. Человек либо застревает на минимальных правах надолго, потому что «выдать по новой» никто не вспоминает, либо получает всё сразу «чтобы два раза не возвращаться» — оба сценария разобраны выше, и оба — следствие того, что расширение доступа не заложено как отдельный шаг процесса.
• Наблюдение подменяется присутствием на созвонах. Формально человек «был на всех стендапах», но по факту не видел ни одного реального решения — они принимались в личных сообщениях между двумя людьми в обход общего канала. Если у команды так принято работать, это стоит честно показать новому человеку, а не делать вид, что процесс идёт по написанному регламенту.
• Первая самостоятельная задача выбирается без учёта обратимости. Дать на четвёртый день задачу, которая при ошибке требует восстановления из бэкапа, — способ гарантированно испортить и задачу, и уверенность нового человека в себе.
• Расширение доступа происходит без фиксации. Даже когда решение принято правильно и обоснованно, если оно не записано, при следующей ревизии доступов эту историю придётся восстанавливать по памяти, а память у команды короче, чем кажется.

Чек-лист онбординга: сделать один раз, использовать для каждого следующего человека

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

Онбординг: [имя], роль: [роль], дата выхода: [дата]

День 1
[ ] Персональная учётная запись создана (не общий пароль, не чужой ключ)
[ ] SSH-доступ выдан только к стейджингу / тестовому окружению
[ ] Доступ на чтение к репозиторию инфраструктурных конфигов
[ ] Обзорный документ по инфраструктуре отправлен и прочитан
[ ] Проведён разговор об архитектуре на высоком уровне

Дни 2-3
[ ] Определены конкретные системы для погружения (под роль)
[ ] Разобрана конфигурация этих систем вместе с опытным коллегой
[ ] Выполнен тестовый деплой/откат на стейджинге
[ ] Человек присутствовал при разборе инцидента или обсуждении решения (если случилось)
[ ] Проговорено, куда идти с вопросами по каждой системе

Дни 4-5
[ ] Назначена первая самостоятельная задача (обратимая, ограниченный масштаб)
[ ] Задача выполнена, разобрана с закреплённым коллегой
[ ] Зафиксированы наблюдаемые сигналы готовности (см. таблицу сигналов)
[ ] Принято и записано решение о расширении доступа
[ ] Новый уровень доступа выдан и зафиксирован в реестре доступов

Итог недели
[ ] Обратная связь от нового человека: что было непонятно, чего не хватило
[ ] Обратная связь от закреплённого коллеги: готовность к следующему этапу
[ ] Дата следующего пересмотра доступа назначена (не «когда-нибудь»)

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

Частые вопросы