DevOps // Human Help

👰‍♀️Когда сопроводительное действительно нужно?

#рекрутинг

В прошлый раз я рассказала о некоторых секретах того, что случается с сопроводительными письмами после того, как кандидат нажал кнопку “Откликнуться”. Давайте разберемся, в каких случаях сопроводительные письма по-настоящему полезны?

1. Первое и самое главное: когда в тексте вакансии прямым текстом указывается его необходимость и предполагаемое содержание.
2. Когда у вас скрыты контакты и в сопроводительном вы указываете их.
3. Если вакансия действительно (а не как те сто остальных, на которые вы отправили отклики) сильно запала вам в душу и вы хотите сообщить об этом.
4. Если по названиям компаний и описанию опыта не до конца понятно, чем вы занимались, в то время как в реальности эта сфера очень близка к описываемому проекту. Например, вы работали в компании-интеграторе на банковском проекте, а теперь откликаетесь на вакансию в самый настоящий банк.
5. Если вы точно знаете, что компания обращает внимание на них.

А помогали ли сопроводительные вам, и если да, то в какие компании? Давайте делиться опытом в комментариях ⬇️!

⌨️ Мета вопросов в технических собесах

#реальные_вопросы

Разберемся, что понимается под метой технического интервью. Как, возможно, читатели догадались “мета” - это греческая приставка или предлог. Её позаимствовали многие языки для обозначения чего-то, что абстрагирует и/или агрегирует знания о предмете, который следует за этой приставкой. Например, можно привести следующие слова: “метаданные” - данные о данных, “метаирония” - ирония над иронией. И самое близкое по значению к слову, которое я хочу ввести: “метагейминг” - то есть попытка игроков выйти за пределы геймплея, получить больше информации об игре и своих в ней соперниках, чтобы улучшить свой результат. Мета в конкретной игре означает данные о состоянии игры в целом и конкретных её элементов. Например, метовые колоды, в коллекционных карточных играх это самые сильные и часто встречающиеся наборы карт, мета в шутерах - выбираемое игроками оружие, в MOBA - герои, в батлроялях - точки высадки, и тому подобное.

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

Мета может меняться, это случается когда вопрос становятся настолько заезженным и так долго висит в топе различных тематических репозиториев, что превращается в общее место. Ответ на него знают все соискатели, он становится неинтересным и выходит из оборота. Так случилось с королем всех вопросов, касающихся Linux:

Что такое load average? (с комплектом дополнительных вопросов, вроде что показывает эта метрика, почему там три значения, в чем измеряется показатель LA и тому подобное).

Его настолько затерли, что задавать его скоро станет плохим тоном.

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

Linux
- Порядок загрузки дистрибутива Linux (длинный вопрос, который уже всем надоел до зубного скрежета, вполне заслуженно)

- Что такое inode и какова его роль в файловой системе? (у вас когда-нибудь заканчивались inode на сервере? У меня тоже не заканчивались, но базовые концепции OC знать надо)

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

- Объясните модель OSI и ее уровни (пресловутая семиуровневая модель, самое теоретическое, что вообще встречается среди вопросов, тем не менее, знать к какому уровню относятся коммутатор, а к какому маршрутизатор, строго обязательно).

K8s
- Опишите архитектуру кластера Kubernetes, из чего состоит? (надо перечислить основные компоненты control plane и worker nodes, рассказать про их взаимодействие и основные концепции, такие как Pod, Service, Namespace и т.д.).

- В чем разница между Deployment и StatefulSet? (вопрос на сравнение контроллеров Kubernetes)

- Какие существуют пробы в k8s (Readiness, Liveness, Startup), чем они отличаются?

Контейнеры
- Виртуализация vs контейнеризация (без комментариев)

- Каким образом в Docker реализована изоляция контейнеров друг от друга? (Namespaces, cgroups, сетевые интерфейсы, CoW, UnionFS, OverlayFS и так далее)

- Какие команды порождают слои? (те, которые изменяют файловую систему)

А еще есть один новичок в мете, это вопрос о контейнерах. Ответ на него очевиден не всем, но он настолько прост, что долго в мете вопрос не продержится, я расскажу о нем в своем следующем посте.

👰‍♀️А нужно ли сопроводительное?

#рекрутинг

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

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

- Куда меньший грех - копировать и вставлять одно и то безликое сопроводительное на все вакансии. Это тоже видно, но, если писать отдельный сопровод к каждому объявлению о поиске, можно поехать крышей, и мы, рекрутеры, тоже это понимаем 🙂

- Длинные сопроводительные вряд ли будут дочитаны до конца.

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

👰‍♀️ Немного мотивации и добрых слов для джунов, которые ужасно устали от поиска работы 🥹

1. Лучше делать плохо, чем никак. Что угодно - откликаться на вакансии, проходить собеседования, решать тестовые.

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

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

Успехов тебе на этом нелегком пути! 💕

⌨️ Вопросы с реального собеседования #1

#реальные_вопросы #2024год

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

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

Крупные клиенты: Детский мир, М Видео, Билайн, HH, Рольф, Тануки, Fixprice, Магнит.

Размер компании: средний (300+ сотрудников)

Требуется: middle System Engineer (DevOps), удаленная работа 200 000 - 230 000 на руки

Задачи:
Администрирование серверов Linux (bare metal / виртуальные)
Проектирование, внедрение и развитие сервисов и IT-инфраструктуры компании
Эксплуатация и поддержка кластеров kubernetes

Требования:
Опыт администрирования Linux - от 3х лет
Инструменты оркестрации и контейнеризации (Kubernetes/Mesos) от 1 лет
Понимание стека TCP/IP, протоколов динамической маршрутизации (OSPF/BGP)
Опыт работы с системами настройки блочных устройств mdadm, DRBD
Системы управления конфигураций (Ansible, Pulumi)
Файловые системы: ZFS, ext4
Опыт с iptables, nftables, ipvs, DNS, DHCP
Языки программирования: Java/Python/Go

Полный список вопросов с собеседования: ссылка в telegra.ph

Подводя итоги: мне понравился список вопросов для этого собеседования. Он сбалансирован, требования к кандидату соответствуют содержанию вопросов, что позволяет хорошо подготовиться. В целом вопросы стандартные, не очень интересные, не слишком сложные. Есть упор на сопровождение серверов (из специфичных вопросов — только блок по ZFS). Вакансия, как и вопросы к ней, ближе к System Engineer, нежели к DevOps (и здесь описание не обманывает). Not good, not terrible. 6 из 10 (твёрдый средняк). Я ещё подумаю над шкалами оценки наборов вопросов.

Небольшое техническое сообщение

Статьи в канал пишут два человека. Подписывать посты, пользуясь стандартным инструментарием ТГ мы не хотим, поэтому принято стратегическое решение подписывать посты эмодзи.
👰‍♀️ - посты Кати
🧙‍♂️ или 👨‍💻 или👨‍💻или ⌨️ - посты Глеба
Предлагаю выбрать эмодзи для Глеба ниже. Он будет стараться помечать свои посты так, пока ему не нарисуют что-то более подходящее.

⌨️ Сигналы: 30 способов умереть или быть убитым

#process_management

Сегодняшний пост в формате Linux катехизиса.

1.Что такое сигнал?
Это уведомление посылаемое для оповещения о каком-либо событии

2. Уведомление кому?
Процессу

3. Уведомление от кого?
Технически сигналы исходят всегда от ядра, но другие процессы и пользователи могут инициировать сигналы, которые будут переданы ядром.

4. Что обычно посылает ядро?
Сигналы завершения и управления (умри сразу, умри, когда завершишь свои задачи, остановись, возобновись, управляющий тобой терминал закрылся, что чаще всего тоже значит умри, а если ты демон и тебе не нужен терминал - перезагрузись)
Ошибки (сегментации, арифметической операции, например, деление на ноль, некорректного доступа к памяти, недопустимой машинной инструкции)
Сигналы, касающиеся, взаимодействия с другими процессами (твой потомок умер, ты используешь канал (pipe), не имеющий адресата)
Таймеры и события (ты просил разбудить, пора что-то делать, ты сам знаешь что, если не знаешь что умри)
Прерывание пользователем (например , после нажатия Ctrl+C ядро посылает сигнал SIGINT он же может быть инициирован командой kill -2)

5. Какие сигналы чаще всего инициируются пользователем?
Кроме сигнала SIGINT,через Ctrl+C, который часто получают процессы, не желающие отдавать консоль терминала, это SIGTERM (kill без аргументов или kill -15), который чаще всего описывают как сигнал корректно завершения, но на самом деле предоставляет процессу возможность перехватить этот сигнал (подробнее в следующем посте) и сделать с ним всё что ему вздумается, по умолчанию он всё-равно убьет процесс, но всё-таки.
С сигналом безусловного завершения процесса SIGKILL (вызывается командой kill -9) всё проще, его невозможно перехватить, заблокировать или сообщить ему другой смысл; он просто завершает процесс.
Вводя команду ‘nginx -s reload’ вы посылаете процессу nginx SIGHUP (kill -1) вынуждая его перечитать собственную конфигурацию. А после закрытия управляющего терминала, такую команду получает связанный с терминалом процесс (и умирает).

6. Какие сигналы используются для таймеров?
Таймеры в Linux используют сигнал SIGALRM. Когда истекает время таймера, ядро посылает этот сигнал процессу. Этот сигнал часто используется для реализации ограничений по времени для различных операций, таких как ожидание ввода от пользователя или выполнения длительных задач.

7. Что происходит, если процесс не может обработать сигнал?
Если процесс не может обработать сигнал или не настроил его обработку, ядро выполнит действие по умолчанию для данного сигнала. Например, для SIGTERM или SIGHUP процесс завершится. Для SIGKILL и SIGSTOP нет возможности установить обработчик, и они всегда приводят к завершению или остановке процесса.

8. Целых 30?
Может быть даже больше, все посмотреть и почитать их сверхкраткие описания можно тут это для OS Debian и на русском.

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

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

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

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

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

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

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

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

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

⌨️ 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 и относится к процессам, которые не требуют активных ресурсов. Например, это может быть фоновая задача, ожидающая запуска по расписанию, подобно тому, как человек бездействует, ожидая, когда закончится время его обеденного перерыва и придет время начать следующую задачу.

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

#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): Процесс завершает работу, когда веб-сервер завершает свою сессию или получает команду остановки.

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

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

#process_management

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

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

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

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

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

#process_management

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

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

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

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

#process_management

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

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