Привет! В прошлом посте вы неожиданно сильно начали интересоваться тем, какие же именно админы нужны в России. Если коротко, то пока по Долине ходят толпы голодных уволенных девопсов, в России админ может спокойно получать больше разработчика.
Понятное дело — не любой.
Если очень коротко, то есть дефицит железных админов, которые прямо занимаются конфигурацией железа и немного кодят. Немного — это когда железа уже не 10 стоек, а 100 и больше, и нужно обновить конфиги на всём. И потом подключить какие-то мониторинги. И следить за ними, чтобы просыпаться в три ночи из-за экскаваторщика.
Руками этого уже не сделать.
Сейчас я расскажу об общих вещах и конкретно — о практике наших админов. Понятно, что наша практика не очень показательна: из отчёта по крупной аварии может сложиться впечатление, что работа админа — держать руками патрубок дизеля. Но всё же наша практика может быть полезной для оценки рынка. Если вы админ, то, надеюсь, вы тоже поможете дополнить это со своей точки зрения.
▍ Что делает админ
Админ занимается железом. Для начала — разворачивает инфраструктуру. То есть принимает железо, вскрывает упаковку, визуально проверяет его, несёт в стойку (это уже чаще всего — чужими руками, хотя сильные админы всегда нужны) и затем подключает к сети управления, тестирует, накатывает нужное ПО, обвешивает мониторингами и добавляет в базу для возможности использования сервера конечными клиентами.
При переходе из разработчиков в админы или из студентов в админы очень легко наколоться в первую очередь на стадии «втыкает в сеть», потому что по нашему опыту найма очень мало кто разбирается в прикладных аспектах локальных сетей. Это без всяких инфинибендов, без вайфая, а просто старый добрый Ethernet. И нет, мы не просим обжимать кабель на собеседовании, мы просто спрашиваем, что такое IP-адрес.
После того как админ собрал железо в стойке, он нужен, чтобы просыпаться ночью. Точнее, ночью он просыпается в тех случаях, когда дублируется по схеме 2N+1. В остальное время он работает (ночью или днём, в зависимости от смены). Со стороны это выглядит, как будто он сидит и смотрит в консоль.
Наши админы, например, участвуют в L3 техподдержки (это самые сложные тикеты с миграцией серверов и так далее, где нужны железные знания), делают профилактические ремонты, время от времени вскакивают менять диски, выступают внешним интеллектом для удалённых рук в ЦОДах по миру и занимаются с этими ЦОДами сексом по телефону.
Ещё админ может что-то заботливо полировать в мониторинге, в утилитах обновления конфигов, что-то тестировать (привет, массивы NVMe) и подбирать конфигурации для будущих закупок.
Или вот пример: у нас стоит оборудование в ЦОДе в Турции. Они присылают нам тикет, что у них будут техработы. Соответственно, админ тоже должен оповестить всех, руководитель службы сопровождения клиентов, получив информацию от админа, идёт оповещать клиентов
Если тут для вас всё знакомо, то поздравляю, вы можете получать больше разработчика с таким же по длительности стажем. По крайней мере там, где есть крупные дата-центры в России, а это, например, Сбер.
Найдите две ошибки
▍ Чем админ отличается от девопса и эникея
Никто точно не знает, потому что админ обычно умнее, но ленивее. Я сейчас шучу, но чёткого круга обязанностей, как правило, нет. У всех своё видение, что входит в круг обязанностей. Внезапно где-то может пригодиться Питон (что, казалось бы, админу вообще не надо), где-то — SQL, где-то — ещё что-то. Но жить можно и без этого. Главное — знать консоль своей основной операционной системы.
Что совершенно точно понятно, так это разница между админом и эникеем. Последний мог называться «системным администратором» по штатному расписанию, 20 лет работать в этой должности, но только заправлять картриджи и менять мышки. Иногда — восстанавливать данные с диска, перекатывать бекапы и вынимать сетевой кабель из розетки 220 В в бухгалтерии.
Железо у нас приезжает всегда собранным (это не у всех так). У нас готовый сервер, в нём даже диски уже стоят. Хотя случается всякое, например, в Казахстане с завода приехал сервер, а там на слоты оперативной памяти была пролита термопаста, и она была не видна. Там «умные» руки, то есть компетентные админы с телеуправлением по телефону. В общем, админ всё это показал, потом вытирал руками под руководством нашего сотрудника. Справился бы и сам, кстати: реально на месте — хорошие специалисты.
Было такое, что сервер приезжает с завода, а диск не работает: он просто не видится в RAID. Иногда приходит битая оперативка. Один или два раза были гнутые ножки процессора.
Сборка сервера принципиально не отличается от сборки десктопного компьютера. Но есть детали именно по конфигурации, а не по самой физической сборке. Чтобы собрать оптимально, надо иметь глубокие знания по тому, как и что работает на практике (привет, NVMe). В чём бывают вопросы — в подборе конфигурации под задачу, например, вводится новая линейка тарифов, админы нужны для того, чтобы посоветоваться. Может оказаться, что 64 Гб оперативки и не нужны, потому что там будет особенность в высокой нагрузке процессора при малой утилизации памяти. Админ не должен такого знать, но на практике посоветоваться всё же стоит.
▍ Что стоит учить
Многие отсеялись на собеседованиях из-за непонимания разницы между TCP и UDP. Я не буду шутить про то, что до некоторых это просто не доходит, а отмечу, что это как раз те, кто знает админство со стороны конечных пользователей, то есть умеет менять мышки. Серверные задачи немного другие, и они тесно связаны с сетью.
Изучать сборку оборудования обычно не надо: её делают либо сотрудники вендора, либо сотрудники ЦОДа, либо вы быстро разберётесь исходя из общих знаний. Всё равно каждая линейка серверов имеет свои особые сюрпризы и особенности. Монтаж в стойку делают сотрудники ЦОДа, коммутацию до линий провайдера — тоже они. Дальше уже можно получить доступ к железяке по одному из управляющих протоколов и увидеть её консоль. Работа обычно начинается в этот момент. Причём это может быть управляющая панель низкого уровня, то есть не с уровня полноценной ОС, а с уровня технического загрузчика (обычно урезанного вендором Linux), который нужен как раз для того, чтобы админ поставил «большую» ОС.
После первичного конфигурирования ОС руками обычно можно запустить скрипт, который дальше работает сам. Кстати, это легко делают сотрудники поддержки, если машина для них готова и появилась в их интерфейсе администрирования.
Смены L3 легко настраивают любую машину, на каждый случай есть наработанные годами скрипты.
На сетевую инфраструктуру есть отдельный человек — сетевик. Админ трогает коммутатор только в случае проблем, но в мирной жизни ничего с ним не делает. Может, иногда добавляет строки к конфигу, чаще всего — ACL.
Понятно, что в тех же корпорациях гранулярность выше. Там не ищут мастеров на все руки, там один может собрать железяку, второй занимается только подключениями мониторингов, третий только пишет скрипты обхода, четвёртый только на случай аварии греет паяльник и так далее.
Кстати, про паяльник тоже было много вопросов. Это миф. Железо без гарантии было только в 2022 году, когда официальные гарантии послетали. Уже в 2023-м всё новое железо было с гарантиями продавцов, а всё то, что слетело в 2022 году, заменялось помодульно по мере выхода из строя. Никто с паяльниками не лазил. Ладно, мы лазили, но из интереса, потому что терять было уже нечего.
Мониторинги не надо уметь писать, но надо уметь настраивать. Помимо сборки нового железа, важная задача — это мониторинг текущего парка. У нас — Заббикс, градация критичности уведомлений. Где-то заканчивается что-то из ресурсов, где-то уже надо менять диск, где-то опять пропала сеть и так далее. Нужно уметь делать аналитические метрики, потому что если смотреть в Zabbix все ошибки, то там просто миллионы инцидентов: то серверу жарко, то ему холодно, то он сыпется, то не сыпется. Если вы примерно представляете, как настроите мониторинг под задачи уровня «менять SSD за неделю до того, как рассыпется рейд» или детекцию того, что рядом с нашим сервером в ЦОД поставили аномально горячее оборудование, то этого достаточно.
Самое прикольное явление — редеплой серверов. Это когда на одном из серверов начинают накапливаться проблемы. Условно они какие-то непонятные ускользающие баги. Признаки этих проблем могут исходить вовсе не из Zabbix, а от каких-то сторонних методов контроля. Например, в мониторинге всё чисто, а клиенты жалуются, что не создаются виртуальные машины. Дальше мы тестируем и понимаем, что проблема — в железе. Поддержка передаёт информацию админу. У железки оказывается всё хорошо, но как-то странно. В таком случае администратор принимает решение на редеплой сервера. Он просит руководителя поддержки организовать рассылку клиентам, что их виртуальные машины мигрируют на другие ноды. Этот заглючивший сервер вынимается, препарируется и исследуется. Причин там может быть миллион. Может, пересохла термопаста. Может, его просто надо было покатать по полу на колёсиках. Может, он соскучился по людям. Может, его прошил быстрый нейтрон. Может, на заводе он был создан просто для того, чтобы перезагружаться по пятницам. Чаще всего находится самая глючная часть железа, меняется на новую, и сервер переводится на нагрузочное тестирование. После того как станет понятно, что он стабилен, вводится в строй снова. При реновации по нашему протоколу также меняются все диски. Они всё равно имеют свой ресурс, поэтому лучше, раз уж мы его извлекли из оборота, то обновить по максимуму и не использовать старых накопителей.
И последнее, что нас интересует, — это то, как админ пишет свои админские скрипты. То есть это то же самое знание консоли, но расширенное. Это техническое собеседование, когда скрипт редактируется прямо на лету во время интервью по новым требованиям. На последних мы спрашивали конкретно PowerShell для Win-админов. Там тоже много кто сыпался.
Вот, собственно, всё, что я могу рассказать. Если вы админ и поделитесь тем, что вы как админ делаете и что нужно учить, чтобы вами стать, то, кажется, это будет интересно достаточно большой части сообщества. Заранее спасибо.
Автор: ntsaplin