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

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

В моменты, где речь шла о том, чем я реально занимаюсь, разговор шел легко. Но некоторые базовые вещи, которые я прекрасно знаю, вылетели из головы от волнения. Затронули пару тем в которых мои знания были достаточно поверхностными. Чаще работаешь с абстракциями, а какой под ними фундамент тяжело вспомнить. А что то просто не знаешь.

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

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

Что я из этого вынес.

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

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

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

Итог.

Работа проверяет, умеешь ли ты решать задачи. Собеседование проверяет, умеешь ли ты рассказывать о том, как ты их решаешь. Это связанные, но разные навыки, и их надо тренировать.

Собеседование не было гладким, но оффер я получил. К тому же я увидел в каких темах у меня есть пробелы. Список на подтянуть составил, надо закрывать дыры.

Настройка VPS начинается со сверки: тот ли сервер выдали и кто, кроме вас, может на него войти. После первого входа нужно сверить параметры заказа, подтвердить SSH-отпечаток, создать отдельного администратора, ограничить входящие соединения и сохранить базовые метрики. Установка VPS по этой схеме рассчитана на образ Ubuntu 24.04 LTS с одним администратором. Панель или cloud-init могут менять эти шаги, поэтому некоторые пункты стоит проверять.

Что сделать сразу после получения доступа к VPS?

Для начала сверьте IP, регион, образ и ресурсы с заказом, затем найдите аварийную консоль и проверьте SSH-отпечаток. После входа создайте отдельного пользователя с sudo, подтвердите доступ по ключу во втором сеансе и только потом включайте firewall и запрещайте парольный вход. Для панели или готового образа сначала посмотрите уже открытые порты.

Что приходит после заказа VPS и что проверить до входа

В личном кабинете или письме указаны IPv4, логин, начальный пароль либо открытый ключ, а также IPv6, если он выдан. Сверьте с заказом регион, образ ОС, vCPU, RAM и диск. После загрузки проверьте их командами nproc, free -h, lsblk и cat /etc/os-release. С ошибкой в регионе или тарифе обратитесь в поддержку до размещения своих данных на сервер.

До первого SSH-входа найдите VNC или другую аварийную консоль, а также порядок запуска rescue mode. Это может понадобится, если ошибка в sshd_config или firewall закроет сетевой доступ. Инструкция Aéza по аварийному режиму показывает, где включается среда восстановления. Конечно, сама она не заменит резервную копию.

Пароль из письма нельзя считать постоянным секретом, так как он прошёл через почту и мог попасть в журнал уведомлений. Если после установки VPS доступен парольный вход, используйте его только для перехода на собственный ключ. Когда образ уже принимает заданный при заказе ключ, не включайте пароль ради удобства. Для нестандартного ISO также проверьте контрольную сумму или подпись.

Как подключиться к VPS и проверить отпечаток ключа

В Linux, macOS и Windows Terminal SSH-клиент вызывается одинаково. В примере данные замените на те, что в карточке сервера:

При первом соединении OpenSSH показывает тип ключа хоста и SHA256-отпечаток.

The authenticity of host '203.0.113.42' can't be established.
ED25519 key fingerprint is SHA256:Wq6...K3A.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Не подтверждайте yes, пока не получите отпечаток другим путём. Откройте аварийную консоль и выполните ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, затем сравните строку целиком.

После переустановки ключ хоста меняется. Если сервер не переустанавливали, предупреждение REMOTE HOST IDENTIFICATION HAS CHANGED требует остановки и проверки через консоль или поддержку. Команду ssh-keygen -R IP запускают только после подтверждения причины. На Windows запись хранится в %USERPROFILE%\.ssh\known_hosts, в Linux и macOS – в ~/.ssh/known_hosts.

Отдельный пользователь, sudo и вход по ключу

Сначала создайте учётную запись и каталог для ключа. Текущий сеанс пока не закрывайте:

На рабочем компьютере создайте ключ ssh-keygen -t ed25519 -a 100, если его ещё нет. В Linux перенесите открытую часть командой ssh-copy-id operator@IP. В macOS и Windows Terminal при отсутствии ssh-copy-id добавьте содержимое .pub в /home/operator/.ssh/authorized_keys через открытый сеанс, затем задайте владельца operator и права 600. Приватный ключ на сервер копировать не нужно. Войдите как operator во втором терминале и выполните sudo -v. После проверки можно продолжать настройку VPS сервера.

Как безопасно перейти с пароля на SSH-ключи?

Добавьте открытый ключ отдельному пользователю, войдите им во втором сеансе и проверьте sudo. Затем создайте конфигурационный фрагмент, который читается раньше остальных, выполните sshd -t и загрузите новую конфигурацию службы. Исходный сеанс держите открытым до повторного входа, а при ошибке исправьте настройки через аварийную консоль.

В Ubuntu файлы из sshd_config.d читаются раньше основного sshd_config, а для большинства директив действует первое найденное значение. Имя 00-local-hardening.conf помещает локальный фрагмент в начало порядка чтения.

После sshd -t выполните reload и, не закрывая текущую сессию, откройте вторую новым пользователем. Проверка вторым сеансом важнее самой команды: на Ubuntu 24.04 с сокет-активацией reload может вернуть ошибку, если ssh.service не запущен. Если вход не работает, исправьте фрагмент через VNC и повторите sshd -t.

Запретить входящие и открыть только нужные порты

UFW в стандартном Ubuntu изначально выключен, а в облачном образе пакет и вовсе может отсутствовать. Проверьте его, задайте политики и откройте SSH-порт. Если sshd слушает не 22-й порт, возьмите значение из sudo ss -utlnp.

Перед ufw enable оставьте SSH-сеанс открытым. Второй терминал понадобится, чтобы проверить, как подключиться к VPS при действующих правилах. ufw status показывает эти правила, а ss -utlnp – слушающие сокеты и связанные процессы. Сетевой экран не останавливает сами службы.

Порты 80 и 443 добавляют после запуска веб-сервера. Базу данных, Redis и административную панель не нужно открывать всему интернету только потому, что приложение к ним подключается. Смена SSH-порта уменьшает шум от сканеров в журнале, но не заменяет ключи и запрет входа по паролю. В руководстве Ubuntu по UFW описаны простые правила, однако сетевой экран в панели провайдера остаётся отдельным уровнем.

Docker направляет трафик к опубликованным портам в обход обычных правил UFW. Сервис за обратным прокси привязывайте к 127.0.0.1. Для iptables правила пишите в цепочку DOCKER-USER: она документирована и не перезаписывается при перезапуске Docker. При другом бэкенде фильтруйте трафик в панели провайдера.

Обновления, время, локаль и swap без лишнего тюнинга

Разобравшись, как подключиться к VPS серверу, обновите систему и сверьте часы. Просмотрите предлагаемые изменения, установите пакеты и проверьте, нужна ли перезагрузка:

В стандартной установке Ubuntu 24.04 пакет unattended-upgrades ежедневно применяет обновления безопасности. Сторонние репозитории без отдельного правила он не охватывает, а автоматическая перезагрузка по умолчанию выключена. Ответственного за окно обновлений и перезагрузку лучше всё равно назначить, а результат контролировать по /var/log/unattended-upgrades/.

Для серверных журналов удобно оставить UTC: sudo timedatectl set-timezone UTC. Локаль C.UTF-8 уменьшает расхождения в выводе скриптов, если приложение не требует другой: sudo localectl set-locale LANG=C.UTF-8. Менять локаль ради отдельной команды не нужно, достаточно запускать её с LC_ALL=C.

Swap даёт ядру запас при резком пике памяти. При нехватке RAM этот механизм может вызвать длительные задержки при обращении к диску. Сначала проверьте текущий swap и профиль приложения. Для базы данных или сервиса, чувствительного к задержке, размер и vm.swappiness выбирают после замеров. Если в vmstat постоянно растут столбцы si/so, пересмотрите лимиты или тариф до увеличения swap.

Как доказать, что VPS работает после настройки

Сразу после настройки сервер пустой, и это лучший момент снять базовую линию. Через месяц, когда появится жалоба на медленную работу, сравнивать будет не с чем. Зафиксируйте дату, исполнителя, ОС, ядро, vCPU, RAM, диск и версии утилит. Для CPU сохраните минутный лог mpstat, для диска используйте временный файл, а iperf3 запускайте до своего узла в целевом регионе.

Как проверить безопасность и базовую производительность VPS?

1. Сохраните эффективные параметры sshd -T, правила ufw status numbered и список слушающих сокетов ss -utlnp.

2. Сохраните минутный лог mpstat, запустите fio на две минуты и запишите p50/p95/p99, затем выполните прямой и обратный прогоны iperf3.

3. Приложите конфигурацию, версии и сырой вывод, затем повторите замеры в другое время. Один максимум не считается базовой линией.

date -Is; uname -r; lscpu | sed -n '1,16p'; free -h; lsblk
fio --version; iperf3 --version; mpstat -V
LC_ALL=C mpstat -P ALL 1 60 | tee mpstat.log
fio --name=baseline --filename=/var/tmp/fio.bin --size=1G --direct=1 \
--rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=1 \
--runtime=120 --time_based --group_reporting --percentile_list=50:95:99 \
--output-format=json --output=fio.json
rm -f /var/tmp/fio.bin
: "${IPERF_HOST:?Укажите адрес сервера iperf3}"
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 --json > iperf3-send.json
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 -R --json > iperf3-recv.json

fio нагружает диск, поэтому запускайте его в согласованное окно: на основном сервере и на соседних VM нагрузка будет заметна. iodepth=1 показывает задержку одиночной очереди, а не максимальные IOPS при глубине 32. Файл должен помещаться на диске с запасом. В документации fio JSON содержит IOPS и completion latency percentiles, включая заданные p50, p95 и p99.

На собственном контрольном узле запустите iperf3 -s, задайте его адрес в IPERF_HOST и выполните прямой и обратный прогоны с одинаковыми параметрами. Публичный узел не служит эталоном. По официальной документации iperf3 для теста нужны клиент и сервер. Между прогонами не меняйте конечные узлы и их конфигурацию. Сохраните JSON и повторите замер трижды. Оценивайте %steal вместе с загрузкой vCPU: одиночный всплеск не доказывает проблему хоста.

Привязать домен и не ждать TTL вслепую

A-запись содержит IPv4 сервера, AAAA-запись содержит IPv6. Перед добавлением AAAA проверьте маршрут, сетевой экран и прослушивание сервиса по IPv6. Первоначальная настройка VPS также требует проверить, проксирует ли DNS-провайдер веб-трафик и какой IP увидит пользователь.

TTL определяет, как долго резолвер может хранить ответ в кеше. После изменения запросите авторитетный сервер зоны, а потом несколько рекурсивных резолверов. До истечения прежнего TTL часть из них может возвращать старый ответ.

Если ответы расходятся, сравните их TTL с ответом авторитетного сервера. Очистка локального кеша не изменит запись у внешнего резолвера. Для HTTPS дополнительно проверьте сертификат и имя виртуального хоста, поскольку правильный A/AAAA ещё не подтверждает готовность приложения.

Для исходящей почты нужен PTR, который настраивает владелец IP-диапазона. Имя из PTR должно прямым запросом возвращаться к тому же адресу. Требования Gmail для всех отправителей включают согласованные прямую и обратную DNS-записи, а также SPF или DKIM. При отправке более 5000 писем в сутки на адреса Gmail нужны оба механизма и DMARC. Если сервер не отправляет почту напрямую, веб-сайту PTR не нужен.

Что добавить после первого часа: бэкап, мониторинг и сервис

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

Бэкапы храните вне VPS и регулярно восстанавливайте тестовую копию. Не стоит путать со снапшотами: они фиксируют состояние на момент создания, но не заменяют независимую копию и журнал восстановления. Частоту выбирают по RPO, а время восстановления по RTO. Для базы данных нужна согласованная копия средствами СУБД или остановка записи на время снимка.

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

Docker, панели и бэкапы требуют отдельных инструкций: у них разные сетевые правила, каталоги данных и процедуры обновления. Одного администратора и UFW недостаточно для командной работы, персональных данных, публичной БД или требований регулятора. В этих случаях нужны журналирование действий, раздельные роли, MFA, проверенное восстановление и контролируемый процесс выпуска изменений.

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

Через сутки после первого запуска повторите контрольные проверки. Убедитесь, что обновления завершились, место на диске не заканчивается, сервис отвечает, а задание бэкапа выполнилось успешно. Считайте, что настройка VPS закончена, когда текущее состояние можно проверить, а порядок восстановления понятен тому, кто будет сопровождать сервер.