⌨️ Привет всем, добро пожаловать на наш канал!

Меня зовут Глеб, и я здесь отвечаю за публикации на темы администрирования Linux и DevOps. Иногда делюсь информацией о технических собеседованиях, даю советы по карьерному росту для начинающих специалистов, и тех, кто уже вышел на уровень джун+. Также помогаю с подготовкой к собеседованиям для специалистов уровня мидл. С радостью почитаю или послушаю об опыте специалистов любого уровня, если наши читатели захотят таковым поделиться. Больше информации обо мне можно найти на моей странице на сайте GetMentor, где я описал, с какими вопросами могу помочь лично вам. Там же вы сможете прочитать отзывы людей, с которыми я уже работал.

Вкратце про мою карьеру в IT: у меня нет профильного образования, выпустился со степенью бакалавра по специальности “Прикладная механика”, специальность, подходящая скорее для чисто инженерной карьеры, так и получилось, я 4 года работал на космос, рассчитывал прочность компонентов ракет-носителей, даже посчастливилось съездить в командировку на космодром Байконур и поучаствовать в пуске. Но денег в русском космосе для простого инженера было немного, поэтому пришлось поменять направление развития. Так я оказался в Sber Infra, работал там над несколькими проектами по сопровождению (распределенное хранилище Hadoop, кластеры NoSQL баз данных). Спустя 4 года я получил оффер от IT-отдела Кадастровой палаты и сыграл ключевую роль в интересном проекте по миграции огромного массива данных Росреестра, к сожалению, мне удалось поработать над этим проектом всего лишь меньше года, по определённым обстоятельствам пришлось сменить не только место работы, но и страну проживания. Сейчас я DevOps в Retail Rocket, работаю удаленно.

А ещё я практикую IT-репетиторство и на своих занятиях стараюсь давать практику, максимально приближенную к реальным рабочим задачам. Моя цель — чтобы студенты получали не только знания и опыт, но и удовольствие от процесса обучения.

Этот пост — для знакомства со мной и моей деятельностью. О содержимом канала и моих соавторах расскажу подробнее в следующих публикациях.

⌨️ Из чего сделаны наши процессы?

#process_management

Что такое процесс в OS Linux? Если подходить формально и давать наиболее краткое определение, то процесс — это экземпляр программы, загруженной в память сервера и выполняющейся в данный момент в системе. Процесс состоит из двух компонентов: адресное пространство и набор структур данных внутри ядра.

Первое — это виртуальная область памяти, которую процесс использует для выполнения своих задач. В этом пространстве содержится всё, что нужно процессу для работы: его код, данные, библиотеки, которые он использует, переменные и стеки.

Второе — это метаинформация о процессе, которую ядро использует для управления им, например, текущее состояние процесса, его приоритет, информация о используемых ресурсах и т.д.

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

👰‍♀️ Как точно НЕ получить работу в айти: 5 простых шагов. Вредные советы

#рекрутинг

Шаг 1. Скрываем абсолютно все контакты в резюме. Как известно, любой нормальный работодатель умеет пользоваться голубиной почтой и обязательно вас найдет.

Шаг 2. Эйчар-интервью - это пустая трата времени! Уверенно отказывайтесь его проходить и настаивайте сразу на общении с лидом.

Шаг 3. Если коварный рекрутер все же заманил вас на звонок с собой, нужно всем своим видом продемонстрировать ему, насколько вы недовольны этим фактом.

Шаг 4. Попросите друга сходить за вас на техническое интервью. Если камера не включена, то вас никто не спалит!

Шаг 5. Когда дело дойдет до оффера, скажите, что у вас их уже пять, и потребуйте сумму +100 тысяч к той, что вы обговаривали на прошлых этапах.

Ждем ваши “вредные советы” в комментариях ⬇️

⌨️ Немного о чудовищных собеседованиях

#собеседования

Всем привет и добро пожаловать в вечер пятницы!

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

Начнем с классики: бесконечное техническое собеседование. В IT много энтузиастов, желающих выполнять свою работу хорошо. Иногда это доходит до абсурда. Скажем, встречается соискатель и интервьюер: один из них готов до бесконечности задавать вопросы, а второй с разной степенью успешности на них отвечать. В итоге выходит интересное противостояние, длящееся несколько часов, и неплохо было бы, чтобы одна из сторон нашла в себе силы прекратить его - лучше раньше, чем позже. В общем, когда договариваетесь о собеседовании, фиксируйте время интервью, ведь ситуация неравная хотя бы потому, что соискателю никто за лишний час интеллектуальной дуэли не заплатит, а интервьюер тратит свои рабочие, то есть оплачиваемые, часы. Лучше все моменты обговаривать заранее, оптимальная длительность одной секции интервью - 1, максимум 1.5 часа. Цените своё время.

Когда шарашкина контора слабая компания мнит себя Google, секций технического собеседования может быть ни одна, ни две, и даже ни три. Кроме того, всё это великолепие может быть скрыто за файрволом технического задания. Получив от HR интервью план, соотнесите своё желание работать именно в конкретной фирме с размером испытаний для соискателей, которая она предлагает.
Встретилась мне одна аутстаф-компания, в которой собеседование проводил аутстаф-интервьюер, что означало вечную спешку, непрерывный поток вопросов, и было противоположностью бесконечного интервью. Человек, которого наняли исключительно для собеседований и который на втором экране проставляет галочки в списке из десятка соискателей, постоянно торопится. Его время жестко ограничено, вы у него третий, а впереди еще три. Скажем так, такой тип собеседования не будет комфортным. Вы также не сможете спросить его о компании, в которую вы устраиваетесь (он о ней ничего не знает), и рассказать о своем опыте (в форме которую он заполняет подобные изыски не предусмотрены), это придется делать во время следующей секции, а мы помним, что количество секций должно быть строго пропорционально престижу работы в этой компании и уровню зарплаты. Станет ли уважающая себя компания отдавать на аутсорс собеседование, даже если это один из ранних его этапов? На этот вопрос придется искать ответ индивидуально, но что-то мне подсказывает, что в 90% случаев - “нет”.

Думаете, аутстаф-интервьюер - это самый худший тип интервьюера? Если подумать, всё не так плохо: если сильно попросите, то он даст обратную связь в конце интервью, и, что не менее важно, он знает правильные ответы на свои же вопросы. Тогда как джун-интервьюер не знает, да и вопросов у него поболее будет. Собес, который ведет джун - это два часа странной игры, в которой соискатель не понимает, что конкретно от него требуется сказать, отвечая на тот или иной вопрос, а интервьюер не в силах ему с этим помочь, он абсолютно не имеет понимания о правильности данных ответов. Интервью, разумеется, записывается, чтобы затем его мог посмотреть страшно в данный момент занятой старший товарищ (удачи ему в этом). Неделю спустя соискателю прилетит оффер, но пойдет ли он в компанию, где даже интервью не могут организовать нормально? Ответ очевиден.

Это только малая толика баек, которые я хотел вам поведать. Если вам понравилось, дайте знать реактами и комментариями. Через некоторое время планирую рассказать о провалах HR - поверьте, там тоже всё довольно интересно.

⌨️ Внутри процесса (thread inside)

#process_management

Поток — это единица выполнения внутри процесса, работающая независимо. Потоки обеспечивают параллельное выполнение задач, совместно используя пространство памяти и ресурсы процесса, что упрощает обмен данными между ними.

Основные компоненты потока:

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

- набор регистров: хранит контекст выполнения потока, включая значения регистров процессора, такие как счетчик команд и указатели стека.

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

Аналогия: продолжая наши офисные инсинуации, где процесс — это клерк, потоки можно представить как его левую и правую руку. Одна рука может делать заметки, а другая параллельно печатать годовой отчет. Эти руки работают независимо, но при этом остаются частью одного и того же клерка. Ничто не мешает одной руке помочь другой: например, левая рука может подать папку с документами правой, передвинуть курсор мыши или выполнить другую вспомогательную задачу. Руки клерка не являются изолированными единицами; они могут взаимодействовать и координировать свои действия. Однако, они также могут мешать друг другу, конкурируя за доступные клерку ресурсы, но об этом как-нибудь в другой раз.

Более подробно читаем тут

👰‍♀️ Так почему они вредные?

#рекрутинг

Надеюсь, вы все посмеялись над прошлым постом с вредными советами. А теперь разберем, чем же так плохи все перечисленные в нем советы

1. Чем больше контактов вы укажете в резюме - тем легче и удобнее будет вас найти. Если вы не хотите, чтобы коллеги с нынешней работы видели, что вы в поиске, то на ХХ есть возможность скрыть резюме от конкретной компании или нескольких.

2. В каждой компании существуют (более или менее) отлаженные процессы, и никто не станет делать исключение ради одного, пусть даже сильного кандидата. По крайней мере, не на начальных этапах. Требуя пропустить эйчар-интервью, вы, в лучшем случае, испортите настроение рекрутеру и попадете в “черный список” компании, а в худшем - в “черный список” побольше, ведь многие эйчары общаются между собой 👾

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

4. Ни для кого не секрет, что айти - очень желанная сфера, поэтому обман со стороны кандидатов встречается часто. Для многих работодателей выключенная камера даже на первичном собеседовании, не говоря уже о техническом - это огромный красный флаг. Если вы хотите подстраховаться на интервью, делайте это с умом.

5. Ходит легенда, что итоговую сумму в оффере можно повышать бесконечно, но это не так. Да, может получиться прыгнуть на 10-20 тысяч выше верха вилки, но, если торговаться во множество этапов и особенно прикрываться несуществующими офферами на значительно большую цифру, чем та, о которой вы говорили изначально, скорее всего, к такому кандидату потеряют интерес.

Всем привет! Благодарю за активность под постом про выбор любимой OS. Победила ubuntu, хотя лично я болел за debian. Мэйнил же я совершенно разные оси, и это, конечно, зависело от текущего место работы. В разные годы это были rhel, centos и debian. Как-нибудь обязательно напишу пост на схожую тематику, а сегодня поздравляем победителя! Как и обещал, его символ повисит в названии канала неделю. 👩‍💻
Upd. Оказалось, что кастомный эмодзи в название канала поставить нельзя, придется выкручиваться.
Upd2. Теперь у пингвина на неделю брендирована кружка.

⌨️ Имя отчество (PID PPID)

#process_management

Здесь все довольно очевидно: PID (Process ID) — это уникальный номер, присваиваемый процессу ядром для контроля его выполнения и предоставления ресурсов. Каждый процесс также имеет атрибут PPID (Parent Process ID), который совпадает с идентификатором PID родительского процесса, то есть процесса, который его инициировал. В системе каждый процесс имеет родительский процесс, который запустил его, ну или усыновил, о чем ниже.

Варианты получения PID и PPID процесса вы найдете в статье по этой ссылке.  Лично мне нравится использовать команду:

pstree -p

(доступна через установку пакета psmisc на вашей OS) для построения дерева процессов, а далее в /proc/<PID> выяснять подробности.
Если знаете какие-то интересные примеры работы с PID и PPID пишите в комментарии ⬇️

⌨️ Как они размножаются? fork()/clone() exec()

#process_management

Итак, мы погружаемся в жизнь процессов всё глубже и глубже, и настало время узнать, откуда берутся новые процессы. Чтобы создать новый процесс, существующий процесс использует системный вызов fork() (технически в Linux используется вызов clone(), но для удобства повествования пока пропустим это). В результате выполнения fork() мы получаем два почти идентичных процесса, с одним важным исключением: системный вызов fork() возвращает два разных значения. В дочернем процессе это значение равно 0 (всегда помним, что согласно Linux-нумерологии 0 обозначает успех), а в родительском процессе возвращается идентификатор PID процесса-потомка.

Поскольку в остальном процессы идентичны, они должны проверить это значение, чтобы определить, кто из них родитель, а кто потомок, и, исходя из этой информации, планировать дальнейшие действия. В жизни родительского процесса мало что изменится, кроме новой ответственности за процесс-потомка, тогда как дочерний процесс изменится кардинально, выполнив один из вызовов exec (например, execl, execp, execv). Все вызовы этого семейства заменяют текущую программу в процессе, и вся память, связанная с текущим процессом, сбрасывается и перенастраивается в соответствии с требованиями нового исполняемого файла. И вот перед нами свежерожденный потомок, скорее всего он будет абсолютно не походить на своего предка, но кое-что он от него всё-таки унаследует, но об этом чуть позже и чуть ниже.

👰‍♀️ Странные вопросы на интервью

#из_первых_рук
#рекрутинг

Профессия системного администратора - что-то среднее между “настоящим” айти и мемами про потных бородатых мужиках в очках, своеобразный Лимб, откуда иногда попадают в девопсы. Из-за расплывчатого круга обязанностей, от “я что-то нажала и все исчезло” до настройки серверов, на собеседованиях на эту позицию частенько присутствует элемент хаоса. Я попросила знакомых админов рассказать об их опыте.

Самый странный вопрос, с которым я столкнулась на первичном интервью:
"Зачем вы работу ищете, почему бы просто замуж не выйти?"

А самый смешной диалог — это вот:

— Вам звонят из офиса, говорят, что ничего не работает. Ваши действия?
— Эээ... у вас в офисе свет есть сейчас?
— Поздравляю, проблема диагностирована!

Был ещё случай, как раз при приёме на нынешнюю работу, спросили на техсобесе про сокеты, я давай про сетевые, а они переглянулись — не, мы про матплаты. А я им на это честно сказала, что мне такие моменты погуглить проще.

Лариса, системный администратор и junior DevOps

⌨️ Отцы и дети (parent - child processes)

#process_management

Отношения родителей и потомков после непосредственно рождения/деления/клонирования, очень кратко, начнем с
наследства/наследственности/наследия, а закончим родительскими обязанностями.

Дети должны работать, таково их предназначение, поэтому родитель должен поделиться с ними всем необходимым. Дочерний процесс получает копию переменных окружения родителя, дескрипторов файлов, текущей рабочей директории, сигнальных масок и настроек обработчиков сигналов. Это обеспечивает преемственность и позволяет дочернему процессу работать в среде схожей с родительской.

Родительские обязанности включают отслеживание изменений статуса дочерних процессов. При получении сигнала о завершении или остановке дочернего процесса, родительский процесс должен вызвать wait() или waitpid(), чтобы определить причину изменения статуса. Это требование, в частности, ядра системы, прежде чем процесс окончательно исчезнет, его удаление должно быть подтверждено родительским процессом, это предотвращает образование зомби-процессов о которых расскажу в другом посте.

⌨️ Родился, потерпел и умер: Жизненный цикл процесса.

#process_management

Быть процессом в OS Linux — довольно безрадостное существование. Ты — клон своего родителя, созданный системным вызовом fork(). Затем ты изменяешься под чьи-то нужды с помощью вызова exec(), который полностью заменяет твое содержимое. То, что недавно было идентично родительскому, теперь становится новым и уникальным. Этот вызов дает старт твоей самостоятельной жизни: ты получаешь новую цель от exec(), а также ресурсы, инструменты и настройки, унаследованные от родителя.

Основная фаза твоего жизненного цикла связана с выполнением кода программы, к которой ты относишься. Это может включать вычисления, обработку данных, взаимодействие с пользователем или другими программами, а также выполнение системных операций. У тебя будут ресурсы, чтобы идти к своей цели: виртуальная память для хранения данных и инструкций, дескрипторы для открытия, чтения, записи и закрытия файлов. Планировщик процессов будет решать, сколько времени CPU тебе выделить.

У тебя будут коллеги, с которыми ты сможешь перекинуться парой слов у кулера, то есть, обмениваться данными и сигналами через механизмы IPC, такие как пайпы, очереди сообщений, разделяемая память и сокеты. Ты сможешь посылать и получать сигналы для уведомления о событиях или запросы на выполнение определенных действий (например, завершение работы). Твой внутренний обработчик сигналов позволит тебе реагировать на изменения в системе или запросы других процессов.

Все хорошее рано или поздно заканчивается, как закончится и твоё существование в качестве процесса. Это случится, когда ты получишь сигнал завершения (например, SIGTERM или SIGKILL) или когда у тебя закончатся задачи. При завершении ты отправишь своему родительскому процессу весточку с просьбой гордиться тобой (сигнал SIGCHLD, сообщающий о твоём состоянии). Он, в свою очередь, подождет, убедится, что ты завершился и освободил ресурсы и, вызвав wait() или waitpid(), с чистой совестью уберет тебя из таблицы процессов. Ты выполнил свой долг, покойся с миром.

👰‍♀️ Лучший запрос самооценки, лучшая обратная связь

#из_первых_рук
#рекрутинг

Продолжаем цикл историй о самых смешных вопросах, которые слышали на интервью сисадмины!

Это был 2013 год, я только переехал в Москву, начал искать работу.
Сходил на около 10 собеседований, все они прошли стандартно для моей должности и были похожи друг на друга.
В итоге собеседовался в небольшую контору которая занималась разработкой ПО для метрологических служб, на должность сисадмина.

Собеседование было очень коротким. Шеф IT отдела был типичным бумером, как сейчас бы сказали. Сначала мне задали некоторые базовые технические вопросы уровня модели OSI и что делать если не открывается сайт или не печатает принтер, и довольно быстро прерывали мой развернутый ответ фразой "понятно, это тоже знаешь".

В итоге удовлетворившись ответами, очередной вопрос прозвучал примерно так: "Ну ты вообще нормально себя оцениваешь, не тупой?"
Я ответил, что в тех сферах где не хватает опыта, проконсультируюсь с коллегами и погуглю. Удовлетворившись ответом, шеф ответил "Вижу что не тупой, когда готов выходить?"
Так получил свою первую работу в Москве, на которой проработал до 2017 года.

Е., системный администратор, сейчас работает в Германии

⌨️ Биография. Вспоминаем и делимся

#process_management

Прошлый пост о процессах нагнал безысходности, но не всё так печально, давайте немного конкретики, попробуем представить более или менее реальный процесс, скажем процесс относящийся к веб-серверу, apache или nginx не столь важно. Попробуем написать краткую биографию этого процесса и хоть в своей сути это будет всё тот-же лайф цикл Born-Life-Death, сосредоточимся в этом посте на второй стадии.

I.Родился (Born or forked) Веб-сервер запускается, и для обработки запросов может создать несколько дочерних процессов или потоков с помощью системного вызова fork(). Наш герой один из них.

II.Жажда служения (Ready to run or runnable): Процесс находится в состоянии готовности к выполнению и ждёт процессорного времени. Он ожидает получения запроса от клиента (например, HTTP-запрос).

III. Бег (Running in user space or running in kernel space): Процесс начинает обрабатывать входящий запрос, возможно передавая его другим компонентам, таким как PHP для динамических страниц. В зависимости от задачи, процесс может работать в пространстве пользователя или ядра (например, выполняя системные вызовы для чтения файлов с диска).

IV. Небег (Blocked, Waiting, Sleeping, in an Interruptable sleep, or in an Uninterruptable sleep): Если запрос требует ввода-вывода (например, чтение данных с диска или из базы данных), процесс переходит в состояние ожидания завершения операции ввода-вывода.

V. Дремлет чутко на работе (The process is sleeping, but it is present in main memory): Когда запрос обработан и сервер ждёт следующий запрос, процесс может оставаться в состоянии ожидания в оперативной памяти, готовый к быстрой активации.

VI. Спит крепко на дальних рубежах (The process is sleeping, but it is present in secondary memory storage): В случае, если сервер сильно нагружен и система вынуждена освобождать память, процесс может быть выгружен в swap, чтобы освободить оперативную память для более активных задач.

VII. Конечная (Terminated): Процесс завершает работу, когда веб-сервер завершает свою сессию или получает команду остановки.

Так вот то что между Родился и Конечная цикл может повториться энное количество раз и вариативно. Скажем Родился -> Жажда -> Бег -> Небег -> Бег -> Дремота -> Жажда -> Бег -> Небег -> Сон -> Конечная.

⌨️ STAT Жди, работай, спи

#process_management

Продолжаем искать в бытие процессов что-то хорошее, в прошлом и позапрошлом посте, выходило честно говоря не очень, но может быть в этом что-то получится. Итак статусы процессов. В этом посте рассмотрим только основные статусы процессов дополнительные флаги вроде (w,<,N, L, s) рассмотрим когда-нибудь ниже. сейчас набираем 'ps aux' и сосредотачиваем своё внимание на колонке STAT:

R — Running (Бегущий)
Это процесс в действии. Он либо выполняется прямо сейчас на одном из процессоров, либо ожидает своей очереди на выполнение. Развивая наши офисные метафоры, такой статус могут иметь белые воротнички активно что-то выстукивающие на клавиатуре, энергично идущие куда-то со своим отчетом или стоящие в очереди к копировальной машине.

S — Sleeping (Спящий)
Процесс ждёт события или ресурса. Возможно, он ожидает ввода от пользователя или данных из сети. Это лёгкий сон, из которого процесс легко пробудить. Представьте коллегу, который дремлет на рабочем месте, но сразу просыпается при звуке входящего письма.

D — Uninterruptible Sleep (Непрерывный сон)
Это глубокий сон, из которого процесс не может быть выведен сигналами. Обычно это происходит при ожидании операций ввода-вывода (записи на диск) на уровне ядра. Подобно человеку, в спрятавшегося от внешнего мира за амбушюры мощных наушников и смотрящего на экран монитора в ожидании завершения загрузки.

Z — Zombie (Зомби)
Процесс завершился, но его запись в таблице процессов ещё не удалена, так как родитель не забрал информацию о его завершении. Ресурсов этот призрак не потребляет, Это как сотрудник, который уже уволился, зарплату платить ему уже не надо, его рабочее место уже отдано другом, но всё ещё не убран из перечня штата отдела и еще парочки корпоративных списков.

T — Stopped (Остановлен)
Процесс приостановлен, обычно сигналом SIGSTOP. Он не выполняется, но может быть возобновлён сигналом SIGCONT. Представьте, что вы поставили фильм на паузу — действие замерло, но может продолжиться в любой момент.

I — Idle (Бездействующий)
Процесс не активен и находится в режиме ожидания. Это может касаться как системных процессов, так и пользовательских, которые временно не выполняют никаких операций и ждут определенного события, чтобы продолжить работу. Статус появился в некоторых версиях ядра Linux и относится к процессам, которые не требуют активных ресурсов. Например, это может быть фоновая задача, ожидающая запуска по расписанию, подобно тому, как человек бездействует, ожидая, когда закончится время его обеденного перерыва и придет время начать следующую задачу.

👰‍♀️ О моём опыте собеса на сисадмина (начало)

#изпервыхрук
#рекрутинг
#PersonalExperience

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

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

- Что вы знаете о компьютерных сетях?
- Честно? Ничего... - ответила я после долгого и тягостного молчания.