Dronov.net

Зачем грузить Linux?

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

Вопрос собеседования и поиска хорошего инженера это в целом творческая задача. Тебе (желательно) за достаточно короткое время нужно не только узнать, насколько глубоко человек разбирается в предметной области, но и понять, насколько хорошо он впишется и в команду и в процессы внутри компании. В каждой компании у команд обычно складывается свой флоу собеседований. А кандидатов много, все эти собеседования тратят время, а ещё свою работу надо как-то успевать. Как жить?

Сам я стараюсь придерживаться идеи о том, что собеседование не должно выглядеть для потенциального члена моей команды душным мероприятием, сжирающее от часа до двух полезного времени. В целом, мне же себе (или коллегам) напарника искать надо в первую очередь, а не читать ему вопросы из тетрадки по башу. Собеседование это всегда стресс, и неплохо было бы его уменьшать. Я, конечно, не проводил по 50 собеседований в неделю, и меня можно этим тыкнуть. Зато был в качестве соискателя на собеседованиях, где собеседующему было важно, чтобы мои ответы демонстрировали не понимание вопроса, а были слово в слово как в тетрадке. Ну, то есть, альтернативные творческие пути решения задачи (которые, собственно, и показывают кругозор) – это, конечно, хорошо, но надо делать вот как записано. И не важно, если записано использование депрекейтед утилит, к примеру. Экспириенс так себе, скажу я вам.

Недавно друг задал довольно интересный вопрос: а зачем спрашивают как загружается Linux? Что там можно интересное услышать? Ведь для любой ОС в целом это bios/uefi+бутлоадер+сама ОС.

Конечно, если вопрос появился из тетрадки, то ничего интересного не услышать.

Но у меня это один из любимых вопросов, которые можно задать соискателю :) В общем и целом, вопрос про загрузку Линукса это творческий вопрос из разряда "Объясни как работает Интернет". Сам по себе DNS может быть не интересен в рамках собеседования. Эти вопросы - ключ к пониманию, насколько широко представление, так сказать, о мире и насколько глубоко человек в этот мир погружен. В идеале, за беседу про то, что происходит до, во время и после загрузки Линукса, кандидат тебе сам бОльшую часть ответов на вопросы и расскажет. Причём, это работает не только на админских, инфраструктурных или devops позициях, но и в эмбеде, где линукс такой же, просто поменьше размером.

Если покопаться поглубже, то вопрос загрузки ОС это, скорее, размышление о том, как ОС работает в рантайме на протяжении условного жизненного цикла и как хорошо (или плохо) работает в рантайме то, за что ты ответственен. В случае эмбеда, это может быть что угодно, от драйвера до системной приложухи в юзерспейсе. В случае инфрастуктуры задача примерно та же, только ты (в основном) не пишешь код сам, а запускаешь уже написанный.

О чём расскажет хороший кандидат?

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

До загрузки ядра Linux

Кандидат может начать с объяснения того, что при включении машины выполняется прошивка BIOS или UEFI, которая инициализирует железо и передаёт управление загрузчику. Затем, загрузчик (чаще всего GRUB или systemd-boot) определяет, какое ядро и initramfs необходимо загрузить, и какие параметры командной строки передать.

На этом этапе можно продемонстрировать знание структуры GRUB, понимание таких параметров как root=, init=, quiet, console=ttyS0 и умение работать с UEFI Secure Boot (например, объяснить, как загружаются подписанные ядра, и что такое shim, MOK, и как ими управлять через mokutil).

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

Загрузка ядра

О чём поговорить тут? После перехода управления от загрузчика к ядру начинается инициализация: запускаются драйверы, настраивается виртуальная память, инициализируются CPU и подсистемы ввода-вывода. Если ядро не может напрямую использовать root FS, оно загружает и распаковывает initramfs — временную корневую файловую систему. Здесь уместно рассказать, как и с помощью каких инструментов можно собрать собственный initramfs (dracut, mkinitcpio, busybox), что происходит внутри него, как выполняется switch_root или pivot_root, и что произойдёт, если на этом этапе произойдёт ошибка.

Зачем? Полезно понимать как ядро обеспечивает рантайм твоего софта. В особенно критичных или embedded-средах знание ручной настройки initramfs или умение диагностировать проблемы на этом уровне (например, "kernel panic — unable to mount root fs") может быть очень полезным.

Переход в юзерспейс

Как только ядро запускает первый процесс (PID 1), начинается userspace-фаза. Современные дистрибутивы чаще всего используют systemd, но могут попадаться и SysVinit, OpenRC. Кандидат может продемонстрировать знание юнитов systemd, их типов (service, socket, target, mount и т.д.), последовательности запуска и способов диагностики (systemctl, journalctl, systemd-analyze). А как только дошло дело до systemd можно поговорить и в целом о нём.

Доводилось ли загружаться rescue или emergency режимы? Описывать, как вручную монтировать root, восстанавливать систему без сети, или править конфигурации для запуска ssh и отладки удалённо? Загружаешь виртуалку, а там в терминале просто черный экран и курсор мерцает, пробовал фиксить? Это покажет практический опыт в восстановлении систем после неудачных обновлений, ошибок в fstab, повреждённых initramfs или сломанного загрузчика.

Работа системы в рантайме

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

Можно поговорить и про межпроцессное взаимодействие (IPC) — pipes, сокеты, очереди сообщений, сигнализация, shm, mmap, eventfd, epoll и их использование.

Также уместно обсудить такие темы, как загрузка и выгрузка модулей (modprobe, lsmod), управление устройствами через /sys, udev, использование cgroups и namespaces для ограничения и изоляции, особенно в контексте контейнеров. Хороший кандидат может также упомянуть SELinux, AppArmor или seccomp, если был опыт с безопасностью ядра. А может и не упомянуть :)

Работа с инцидентами и нагруженными системами

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

Из теории он может объяснить:

  • как пользовался top, htop, iotop, vmstat, dstat для экспресс-диагностики;
  • доводилось ли включать трейсинг системных вызовов через strace или профилировал CPU через perf;
  • как применял bpftrace, ftrace или eBPF-скрипты для анализа “горячих точек” в ядре;
  • что делал с out-of-memory (OOM) ситуациями, анализировал ли dmesg и логи ядра;
  • использовал ли cgroups для ограничения runaway-процессов или debug-сценарии через systemd;
  • приходилось ли делать пост-мортем анализ через crash dumps и kdump;
  • был ли мониторинг, какой именно, на какие метрики он ориентировался;
  • настраивал ли swap и вообще отношение к нему.

В целом, обсуждая определенные технологии, можно опираться и на опыт инцидентов других компаний. Благо, многие пишут открытые пост-мортемы. Иногда, и веселые.

Эти вопросы — переход ещё более творческие темы обеспечения availability, кластеризации, и т.д.

А зачем всё это, если наши серверы в облаках?

Да незачем, только облака — это тоже чей-то компьютер. И линуксы разломаться могут там также, как и на бареметале.

Знание, как загружается Linux — это не магия и не фетиш.

Это просто хорошее инженерное понимание того, в какой среде работает твой код или сервис. Иногда оно спасает прод. Иногда — просто помогает объяснить, почему что-то пошло не так. А иногда — просто приятно знать, как всё устроено. И этого уже достаточно.

Дополнительная литература: