Новый ноутбук разработчика: чек-лист настройки от шифрования до тулчейна

Прямой ответ

Настройка рабочей машины — процедура, а не творчество: правильный порядок экономит день и закрывает дыры безопасности, которые иначе живут месяцами. Короткая версия: сначала защита и обновления (шифрование диска, патчи ОС, аккаунты с 2FA), потом доступы (SSH-ключи, менеджер паролей), затем тулчейн (git, языки через менеджеры версий, Docker) и в конце — окружение (dotfiles, IDE, локальные сервисы). Первые два блока — в первый день до начала работы; остальное добирается за неделю по мере задач. Для б/у машины добавляется нулевой шаг — проверка состояния до покупки по чек-листу выбора б/у ноутбука.

День 1, блок «защита»: до почты и кода

1. Шифрование диска: BitLocker (Windows Pro; на Home — шифрование устройства, если доступно) / FileVault (macOS) / LUKS при установке Ubuntu. Без шифрования кража ноутбука равна утечке кода, ключей и .env — это фундамент, от которого зависят все остальные меры из статьи про секреты.
2. Обновления ОС до актуального состояния — до установки чего-либо: драйверные и security-патчи сначала.
3. Учётная запись с паролем и 2FA (локальный аккаунт + вход по PIN/биометрии); админ-привилегии — отдельной учёткой, если политика позволяет.
4. Менеджер паролей — установить и войти до того, как начнёте плодить аккаунты «с временными паролями».
5. Антивирус/EDR: на корпоративной машине — штатное решение ИБ + исключения для dev-каталогов (ускоряет сборки кратно); на личной — встроенного Defender достаточно.

День 1, блок «доступы»

6. SSH-ключ: новый, ed25519, с passphrase; старый ключ со списанной машины — отозвать на сервисах (GitHub/GitLab/серверы), а не копировать: компрометация старой машины не должна наследоваться новой.
7. Git: user.name/email, дефолтная ветка main, алиасы — всё это приезжает из dotfiles-репозитория (клон и развёртывание — по инструкции в статье про dotfiles).
8. GitHub/GitLab: добавить новый публичный ключ, revoke старого; включить 2FA на аккаунтах, если ещё нет.
9. Корпоративные доступы (VPN, SSO) — по регламенту ИБ, обычно до личного софта.

День 2–3: тулчейн

10. Пакетный менеджер: Homebrew (macOS) / winget+WSL2 (Windows) / apt (Ubuntu).
11. Языки через менеджеры версий, а не системные пакеты: Node — fnm/Volta (сравнение в статье про версии Node), Python — pyenv/uv, Rust — rustup, Go — официальный архив.
12. Docker: Desktop (Windows/macOS) или Engine в WSL2/нативно; лимиты ресурсов выставить сразу — дефолты на 16 ГБ машине агрессивны (порядок цифр — в материале про WSL2 и Docker).
13. Git-клиенты и IDE: VS Code (Settings Sync восстановит настройки), JetBrains Toolbox — если подписка; расширения ставить списком из dotfiles, а не «по памяти».
14. CLI-набор: gh (GitHub CLI), make, curl/httpie, jq, tmux — список в Brewfile/winget-экспорте.

День 3–5: данные и сервисы

15. Клоны репозиториев — рабочие и личные; проверка, что SSH-ключ работает (ssh -T git@github.com).
16. Локальные сервисы по проектам: БД, Redis, compose-стеки — поднимаются из конфигов проектов, ничего не ставьте «глобально про запас».
17. Бэкапы с первого дня: правило 3-2-1 (рабочие данные + dotfiles + ключи); корпоративный бэкап — по регламенту, личный — зашифрованный (правила — в статье про секреты, раздел про бэкапы).
18. Проверка восстановления: один тестовый файл из бэкапа восстановить реально — непроверенный бэкап бэкапом не является.

Ошибки первой недели

• Ставить «всё сразу»: половина глобальных утилит не понадобится; список растёт из реальных задач, фиксируется в Brewfile/dotfiles.
• Системный Node/Python из установщика рядом с менеджером версий — конфликт PATH гарантирован; сначала менеджер, потом версии.
• Проекты в OneDrive/Dropbox-папках — синхронизация убивает скорость git и сборок; рабочая папка — локальная, бэкап — отдельным механизмом.
• Копирование старого SSH-ключа — см. шаг 6: новый ключ, отзыв старого.
• Откладывание шифрования «до настройки» — именно в первые дни машина ездит с ключами без защиты; шифрование — шаг 1, не шаг 20.

FAQ

Сколько реально занимает полная настройка? С dotfiles-репозиторием — 3–4 часа до рабочего состояния, неделя до полного комфорта. Без dotfiles — день-два чистой работы, половина которой повторится на следующей машине.

Что делать со старой машиной? Отозвать её ключи и сессии на сервисах, выйти из аккаунтов, затем — сброс с затиранием (шифрованный диск делает затирание формальностью). Не продавайте машину, пока SSH-ключи не отозваны.

Настраивать Windows нативно или через WSL2? Для веб/backend-разработки — WSL2: тулчейн живёт в Linux-окружении, Windows остаётся оболочкой. Для .NET/игровых сценариев — нативно. Оба варианта совместимы на одной машине.

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

Вторая неделя: то, что легко отложить и зря

После базовой настройки остаются задачи, которые команды откладывают месяцами — и платят за это при первом же инциденте. Проверьте три пункта. Первый — восстановление доступа без основного устройства: что будет, если телефон с 2FA потерян; резервные коды восстановления сгенерированы и лежат в менеджере паролей? Второй — актуальность бэкапа ключей и dotfiles: новый SSH-ключ добавлен в зашифрованный бэкап, dotfiles-репозиторий запушен с новой машины? Третий — обновления поставлены на расписание: еженедельный слот под патчи ОС и тулчейна дешевле, чем квартальный аврал с мажорными миграциями.

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

Переносить ли Docker-образы и базы со старой машины? Образы дешевле пересобрать и скачать заново; переносить стоит только данные: дампы баз, volumes с рабочими данными, локальные артефакты. Кэш сборки (Gradle, cargo, npm) не переносите — он восстановится, а повреждённый кэш чинить дольше, чем набрать заново.

Источники: документация BitLocker (Microsoft Learn), FileVault (Apple), Pro Git (ссылки в шапке).