Доброго времени суток, пикабушники.
Прочитал пост @disabler и хотел бы рассказать обратную сторону поиска работы на должность админа Linux или DevOps.
Первый мой пост, не судите строго.
Для начала разберемся с теорией и почему я был не прав.
Задачи DevOps:
- понимание своей роли в процессах разработки по гибкой методологии
- обеспечивать CI/CD для быстрого тайм-ту-маркет сервиса или фичи
- использовать суперкрутые декларируемые средства автоматизации (SaltStack, Ansible)
- владеет Git и крутыми аналогами
- использует Bash, python для автоматизации
- собирать пакеты deb/rpm
Linux админ:
- админит сервисы (DNS, DHCP, файловую систему)
- админит веб-сервера
- админит виртуалки (c linux конечно 80%, ну у нас есть некоторые сервисы на Windows их тоже надо админить, частенько это слышу, но это скорее, как хвостик, чем приоритет, оно и понятно)
- сеть виртуалок (iptables, firewalld, автоматизируй, как скажут или как хочешь)
- админит гипервизоры
- диагностирует сбои на виртуалках и гипервизорах
- организует и следит за бекапами
- Kubernetes, PostgreSQL, HAProxy
- использует Bash, python для автоматизации
- все, что угодно в зависимости от требований компании
Поясню, по требованиям, которые встречаются на Linux-админа складывается ощущение, что мир немного изменился.
Если раньше, например, в банках и крутых организациях было модно на каждый продукт, на каждый компонент, типа приложения, Windows и Linux, гипервизоры, найти своего инфраструктурного или прикладного админа, то и гиганты передовики ищут такого админа, который каким-то образом освоил ansible или saltstack, есть понимание как работает CХД, как объявлять LUNы и т.д. и как это сделать устойчивым, работал с железными серверами, SAS или FC коммутаторами, умеет работать с гипервизорами, но еще и успел поработать с модными технологиями типа ElasticSearch.
Как обстоят дела с банками сейчас я не знаю.
Погуглите hh.ru, увидите сколько всего должен уметь Linux-админ. А потом загуглите на hh.ru что должен делать DevOps. И попробуйте понять кто им, блин, нужен.
Очень часто на вакансию DevOps откликаются с предложением Linux-админа. Не вопрос, все обсуждается.
Вспоминается картинка
Неважно, работодатель всегда прав, он же решение принимает, впрочем, вы всегда можете отказаться, если вам сделают офер.
А если ты интроверт, который не готов доказывать, что "Это не девопс", "Это не админское", ну сорян, да погрязнем. Я такого подхода не сторонник, всегда надо смотреть на бест-практики, смотреть на опыт "буржуев" в этих вопросах.
Давайте разберем вопросы, которые спрашивают на собеседовании
Поговорим о linux-админе:
"Работали ли вы с OpenStack или OpenNebula"
Вот и думай, что вспоминать, как LUN к серверу подключается и общее хранилище для гипервизоров делается или поднимай этот OpenStack на i7.
"расскажи, что есть в top"
Я, кстати, завалился на load average и %Cpu(s), чет их много, поставил галочку изучить.
"Есть пользователь, который выгружает доки по FTP в Интернет, у себя дома у него работает, на работе нет, что это может быть"
Я сказал, что причин может быть много. Могут быть закрыты порты по политикам у пользователя, могут быть порезаны порты на роутере, на межсетевом экране, на прокси, с которого он ходит по любому, где-нибудь да вскроется несоответствие. Должно где-то логироваться, мы рано или поздно увидим.
"Если у нас очень много всего и логировать близко к нереальному, забьем место логами и сломаем что-нибудь еще"
Вот тут я уже подзадумался, как люди без логирования живут, на крайняк можно настроить логи так, чтобы выскакивало только наше событие. На сервис мониторинга можно настроить, rsyslog. Разве нет?
Честно говоря, надо было спросить правильный ответ, что ожидалось, а может это вопрос на логику и дебаг?
"Приложение критически важное, сервис и виртуалка не перезагружается, в логах мы видим только ошибку, связанную с превышенным количеством файл-дескрипторов"
Тут смысл в том, на сколько критичны данные, если критичны - потренируйся перенаправлять данные через пайпы "|" в Bash.
Если не критичны - очистить открытый файл через файл-дескриптор.
Лучше отработать это заранее, никто не хочет, чтобы ты учился на боевых серверах.
Изучить: lsof, strace, Inode, файл дескрипторы.
Лично у меня была проблема в том, что у нас не было жесткого SLA, перезагрузить сервер или сервис не считалось чем-то супер-зашкварным, сложнее, когда, ты можешь решить проблему перезагрузкой/перезапуском, а вместо этого ты лезешь в lsof, strace и у тебя над душой стоят люди и оценочно смотрят на твою деятельность. Прям физически стоят.
Запомнить: решил проблему быстро, но она может повториться, сделай все, чтобы не повторялась, желательно по Best-practice.
Отступление: А вот теперь представь, если ты админ-нулевик. Где ты этому научишься? Конференции, виртуалки, халтурки, курсы за деньги?
"Физический сервер встает клином, по сети и другим вещам не доступен, что будешь делать"
Обычно вендоры предусматривают не только подключение к серверу по KVM в серверной, но и подключение по iKVM.
Если сервер встал, скорее всего iKVM тоже повиснет, хоть так, хоть эдак.
Тогда нужно что-то типа HP iLO или IMPI, этим модулям, как я понял, плевать что у тебя крутится на сервере и если сервер не сгорел, эти средства управления железкой подскажут тебе, где и что сломалось.
А вообще может навернуться диск, может температура нагреться (этого я не вспомнил, но на практике случалось) из-за вентилятора или кондиционера, может ОЗУ выйти из строя, причем определенная планка памяти.
Правильный ответ опять не спросил.
Вы заметили, что железные вопросы пошли, может это вопросы для админов-нулевиков? Может другим гениям такого не задают вообще?
Поговорим о DevOps
Недели две назад я ходил на собеседование как раз на DevOps, это было самое жесткое собеседование.
Для начала, мои советы:
-точно знай "что" делает DevOps
-почему бытует мнение, что в России нет DevOps
-готовься и гугли технологии
-ИДИ
-ВСЕГДА
-С ЧИСТОЙ
-ГОЛОВОЙ
-ОТ ДРУГИХ
-ПРОБЛЕМ И ЗАДАЧ.
А теперь забудьте это и смот как я умирал на собеседовании.
"поговорим об ansible"
К ансиблу нужно готовиться, знать, что делает inventory, group_vars, как запускается плейбук на определенные хосты.
Изучить: стуктура ansible, бест-практики.
"поговорим о python, у нас есть список элементов из числел, напиши код, который выдает нам простые числа"
Вот тут почувствовал себя немного ленточным накопителем с последовательным доступом.
Знаете, я тут с помощью линейной регрессии на sklearn определяю стоимость квартиры, основываясь на 15 параметрах...
в целом, сам виноват, фундамент знать нужно, желательно, даже если ночью спросят.
"поговорим о python"
Бывали задачи на базовые алгоритмы, причем написать на бумаге или доске, такие как алгоритмы сортировки, честно, ненавижу их, но надо.
Изучить: базовые алгоритмы компьютер саенс.
"поговорим о JOIN и SQL"
Честно говоря, если меня попросят написать Жойны на бумаге я завалюсь, опыта в этом у меня нет. Тут два варианта, вызубрить и практически потренироваться в JOINах, желательно в Python, это модно.
Изучить и практика: Понять роль первичного, уникального, внешнего ключа, виды JOIN, каждый отработать.
Сразу скажу, то, что ты защитит лет 12 назад диплом Delphi + MS SQL - никого не впечатляет. Бизнесу это не интересно, имхо, сложилось впечатление, что это равносильно вспомнить Turbo Pascal, который вы проходили в школе.
Один раз был забавный случай, когда мне нужно было найти результат запроса, я его нашел.
Затем нужно написать немного другой запрос, я в этом плаваю, но логику увидеть могу, получилось так, что я начал переписывать запрос по-аналогии с предыдущим запросом и нашел там ошибку, в первом запросе. Внимательней надо быть!
"зачем вообще DevOps"
Рассказал про гибкие методики, про классическую waterfall model и что она немного не актуальна, а на практике время показало, что требования бизнеса очень переменчивы, соответственно все эти DevOps методики и инструменты позволяют быстро предоставить то, что нужно бизнесу или пользователям.
А мне сказали, что DevOps способствует time-to-market.
Подзадумался. Ответ зачем DevOps нужен я так и не получил.
Самые жесткие собеседования - самые интересные, за что собеседующим и спасибо.
Немного организационных моментов:
1. Всем нужны девопсы, конкуренция большая, желательно с опытом работы, желательно в продакшене, желательно с высоконагруженными сервисами, с опытом балансировки веб-сервисов.
2. Работодатели редко отвечают за 1-2 рабочих дня, тянется это все неделями, сразу после собеседования редко кто может сказать: "Да, знаешь, чувак, чет рановато тебе к нам". Надо посовещаться. Этика?
3. Очень большое количество технологий пересекается в вакансиях на DevOps и на Linux-админа.
В моем понимании админ больше работает с DevOPS, сетевиками и железом, DevOps - с разработчиками, QA, тестировщиками и т.д. Все зависит от того, как выстроены процессы.
Так что Вам нужно, дорогие работодатели?
Дискас.
Красноречие 100
