Speaker A
Друзья, всем привет. Сегодня у нас интервью на позицию инженера DevOps с зарплатой в 400 000 руб. на руки, где используются закрытые контура и, соответственно, нужно администрировать инфраструктуру, Docker и так далее.
Интервью на позицию DevOps инженера с разбором технических вопросов и советами по прохождению собеседований в IT.
Key Takeaways
- Не бойтесь ошибаться на собеседовании — это нормальная практика.
- Понимание базовых процессов Linux, таких как загрузка системы и управление процессами, важно для DevOps.
- Высокий load average при низкой загрузке CPU может указывать на проблемы с дисками или файловыми системами.
- Виртуальные файловые системы и LVM — ключевые понятия для администрирования Linux-серверов.
- Постоянная практика и прохождение интервью помогают улучшить навыки и повысить шансы на трудоустройство.
What the video covers
- Интервью на позицию DevOps инженера с зарплатой 400 000 рублей и администрированием инфраструктуры и Docker.
- Обсуждение процесса загрузки Linux, включая BIOS, загрузчик GRUB и systemd-юниты.
- Разбор понятия load average и его связи с количеством ядер и нагрузкой на сервер.
- Диагностика проблемы с сервером, когда load average очень высокий, но загрузка CPU и память низкие.
- Обсуждение возможных причин проблем с сервером, включая деградацию диска и проблемы с файловыми системами.
- Объяснение виртуальных файловых систем на примере /proc и NFS.
- Краткий разбор LVM и его роли в управлении логическими томами.
- Советы по прохождению технических собеседований и важности практики для повышения навыков.
- Подчёркивание, что ошибки и незнание некоторых вопросов на интервью — это нормально.
- Рассмотрение различных технических тем, связанных с Linux, сетями и DevOps.
Chapters
- 00:00Введение и описание позиции DevOps инженера
- 01:56Процесс загрузки Linux и роль загрузчика GRUB
- 04:21Понятие load average и его анализ
- 07:00Диагностика проблемы с высокой нагрузкой на сервере
- 09:18Анализ логов и возможные причины ошибок 500
- 11:38Обсуждение причин высокой нагрузки без загрузки CPU
- 14:48Виртуальные файловые системы и пример /proc
- 16:48Обзор LVM и управление логическими томами
Full Transcript — Download SRT & Markdown
Speaker A
Интервью я выкладываю исключительно для того, чтобы показать, насколько это всё достаточно просто. Можно провалить половину вопросов и всё равно устроиться. Это как бы абсолютно нормальная практика, если ты что-то не знаешь, потому что в разных компаниях используется разный стек, разные
Speaker A
технологии. Ты можешь вообще банально что-то забыть. Бывают у меня из головы вылетают вообще какие-то элементарные вещи, прямо азы, азов. Но на какие-то сложные вопросы я прекрасно знаю ответы.
Speaker A
То есть ошибаться и что-то не ответить на интервью — это абсолютно нормально. И не нужно этого бояться. Важно проходить интервью, собеседоваться, повышать свои скилы в прохождении интервью.
Speaker A
Вот. И рано или поздно вы устроитесь на работу, если у вас есть такое желание.
Speaker A
Дальше вы можете прекрасно работать, получать опыт на работе уже непосредственно и развиваться в компании. Давайте перейдём тогда к вопросам. М Дмитрий нам поможет.
Speaker A
Вот я в конце задам какие-нибудь ещё. Да, ещё раз приветствую. Э, первый вопрос. Как происходит процесс загрузки операционной системы Linux с момента включения сервера?
Speaker A
Мм, как он происходит? Как он происходит? Мы нажимаем на кнопку питания, потом загружается у нас, соответственно, BIOS, вот, который инициализирует и опрашивает компоненты, там память, про все вот эти вот дела.
Speaker A
А потом у нас происходит обращение к диску и загружается, я не помню, как это называется, первый сектор. Короче говоря, инициализируется загрузчик. Если брать Linux — это самый популярный GRUB, GRUB, LILO, по-моему, ещё раньше был. Не знаю, сейчас используется или нет.
Speaker A
А дальше загрузчик инициализирует у нас ядро операционной системы, которая, соответственно, у нас тянет все остальные systemd-юниты и вот, ну, всё, соответственно, остальное.
Speaker A
Ну, это в моём понимании простыми словами. Это, конечно, максимально сейчас не технически было, но я не знаю, как это.
Speaker A
Да нет, вполне хорошо.
Speaker A
Окей. А что такое load average?
Speaker A
А, это определённая метрика, метрика ядра, а, по которой мы, зайдя на сервер, наверное, первое, что надо смотреть — это, ну, команду top вызываем. Смотрим load average.
Speaker A
Если оно у нас, соответственно, растёт, то стоп, соответственно, процессы. Но тут всё зависит от количества ядер. Если у нас там ядер два, там, ой, ядер, не знаю, там 10-12 ядер, а у нас там в районе четырёх-пяти, то это
Speaker A
как бы нормально. Вот если у нас ядер четыре и load average уже четыре, то это как бы хреново, потому что ядра не успевают обрабатывать процессы. Это значит, у нас что-то повисло и, ну, как бы ядро пытается обработать сначала одни задачи,
Speaker A
на которых висит и не может переходить условно к следующему.
Speaker A
Окей, хорошо. А, предположим, есть у нас сервер под управлением Linux, на нём nginx, 4 гига, ой, четыре ядра, 8 гигов оперативки. Там лежит какая-то статика, никакого там нету.
Speaker A
Пользователи начали жаловаться, что сервер пятисотит. А мы заходим на сервер, видим load average 100. Такого я не видел ещё.
Speaker A
Ну, бывает такое. А при этом утилизации процессора нету. Там системная утилизация 3, 5, 10%, памяти свободной много, там занято 800 Мб. Вот в чём может быть проблема, как можно её решить?
Speaker A
Так, ну, то, что load average, да, растёт, я понял. А нагрузка по ядрам, соответственно, по процессам, то есть можно посмотреть, какие процессы сейчас максимально отжирают ресурсы.
Speaker A
Я говорю, утилизация процессора 3-5%, там, может, 10 — это системная загрузка. Ну, например, сетевое хранилище отвалилось, либо же, не знаю, на диске закончилось место, например, и, соответственно, мы не можем писать на диск. И, соответственно, load растёт, но при этом процессор не будет
Speaker A
нагружен, память. Также вот как один из вариантов — сетевое хранилище отвалилось, например, примонтированный том какой-то отвалился, куда всё это дело должно писаться, а при этом процесс не может, ну, короче говоря, обработать, завершить его корректно и всё. Хорошо, проверили. Ну, сетевого хранилища у нас
Speaker A
нет, проверили место. Место есть. Айноны могли кончиться, как бы место покажет на диске есть. По факту записываться не сможет. Айноны проверены, айноны занято 10%.
Speaker A
А какой-то файл грохнули, в который был, не знаю, огромный разросшийся лог. Мы его удалили через rm, но при этом не завершили процесс, и в него продолжается запись. Можно и lsof-ом посмотреть открытые файлы. Смотрим. Место есть. То есть
Speaker A
мы бы увидели, даже если процесс занял файл и мы его удалили и он не удалился, то, ну, его заголовок не удалился, то мы всё равно видели, что он занимает место, пока процесс его не отпустит. Но такого мы не видим.
Speaker A
А проблемы с сетью банальные? Проверили IP-адреса. Не знаю, всё нормально.
Speaker A
Мм. Мм, логи, логи в первую очередь. Чуть также логи. В логи надо глянуть. Nginx.
Speaker A
Почему пятисотка? Глянули. Глянули логи, пятисотки возвращает. Да, но в логах что-нибудь ещё должно быть? Не знаю. Там не больше ничего нет.
Speaker A
А так бэкенд мог отвалиться. Нет бэкенда. Отдаём статику с дисков. Мм, сейчас, одна секунда.
Speaker A
Что ещё может быть? Ну, какие-нибудь сетевые проблемы на уровне... Не знаю, там петля образовалась, наверное, и нет. Ненене, не.
Speaker A
А, ну можно попробовать перезагрузить, ну, рестартануть сервис nginx. Рестартанули, не помогло. База данных отвалилась. А, ну хотя, если статика, то, наверное, без базы данных. Базы данных тоже нет.
Speaker A
[музыка] Так, ну, у меня вроде как будто бы кончились сейчас варианты, если дальше не размышлять.
Speaker A
Из подсказок мы, когда смотрим, видим процессы, видим, что они в постоянном состоянии ожидания. Наверное, на это сейчас в таком контексте не отвечу. Прокся или что-то такого рода.
Speaker A
Нет. У процессов есть состояние, да, а определённые. Мы видим, что в состоянии ожидания. Что ещё можно посмотреть, ну, на что можно ещё ориентироваться?
Speaker A
М, не знаю, наверное, единственное, что сейчас приходит в голову — это на дочерние процессы, но, наверное, нет. Я, наверное, не отвечу.
Speaker A
Окей. Ладно, пойдём дальше. А в чём, ну, как бы что конкретно имелось в виду?
Speaker A
Ну, диски надо было посмотреть. Так, я же говорил изначально про диски, что могли отвалиться, могло место кончиться и всё вот это вот дело в сетево. Вы сказали, мог отвалиться, но диск не отвалился. Он не сетевой и место не кончилось. С айнонами всё
Speaker A
нормально. Есть ещё причины, по которым может быть такая проблема? Ну, точнее, есть только одна причина, почему может быть такая проблема.
Speaker A
Ладно, окей. Это деградация диска. То есть надо было посмотреть там, а, либо atop-ом, либо iostat-ом, а чтение-записей,
Speaker A
время доступа к блоку, скорее всего, вы бы увидели деградацию и что время доступа к блоку там приближается к бесконечности.
Speaker A
Вот. Потому что непосредственно нагрузка на диск — это вычисляемое значение, которое, в том числе, опирается на время доступа к блоку. Угу. Окей.
Speaker A
Ну зато вы параллельно ответили на парочку ещё вопросов. А сейчас отмечу. А так, а что такое виртуальные файловые системы? Приведите их пример.
Speaker A
М виртуальная файловая система. Это, например, у нас, по-моему, она так и называется, VFS — Virtual File System.
Speaker A
Ну а да. А пример какой-нибудь? NFS, если я не ошибаюсь, я не работал с ними, не скажу здесь, по-моему, из подсказок мы их пример можем видеть просто на свежеустановленном дистрибутиве Linux.
Speaker A
Мм, может быть, когда мы смотрим так, не, наверное, не скажу, честно даже гадать сейчас не буду, потому что у меня с этим ничего сейчас не ассоциируется в голове.
Speaker A
Окей. Где в Linux хранится информация о процессах? /proc этот, блин, как его, psproc. А, ну вот, кстати говоря, proc — виртуальная файловая система, наверное, где процессы сохранятся, да? Хорошо. На два вопроса ответили.
Speaker A
А что такое LVM? KVM или LVM? LVM. А Logical... Нет, стоп. Это короче. Не, ну что, что это?
Speaker A
Понятно. Расскажите там уровни абстракции, какие у него есть. Менеджер логических томов, это понятно. Хочется про техническую часть узнать побольше.
Speaker A
М, я с этим сталкивался только па...
Speaker A
Вот. И, соответственно, мы можем моментально поднять интересующийся на интересующий нас, например, сервис тот же Engжинкс минимально каким-то возможным образом, а не ставить полноценную даже убунту в её нет инсталляции, которая будет ставиться достаточно долго и тянуть за собой кучу
Speaker A
ненужного. О'кей хорошо. Предположим, на сервере Sins встретились с ошибкой. Слишком много файлов открыто процессом.
Speaker A
Что нужно сделать? Поправить, посмотреть. Мм, так слишком много там есть ограничение точно по ядру на количество открытых файлов. Можно это скорректировать, если в этом есть необходимость.
Speaker A
Что будете корректировать? Где? А, чат у GPT. Напишу вопрос, какой файлик скорректировать для корректировки количества открытых файлов, потому что я сейчас его, к сожалению, и не помню, но это делал. Ладно, мы проверили. На уровне ядра лимит мы точно не упёрлись.
Speaker A
Там на уровне ядра максимальное количество файлов около миллиарда, по-моему. Есть ещё ограничения. Блин, ну это скорее всего в папке с жинксом, не знаю, куча, куча куча папок и подпапок. Это не связано с ингингсом, это связано с настройками операционной
Speaker A
системы. М просто - это, ну, как просто с ним все работали и никто не пугается.
Speaker A
[музыка] Возможно, лсофом можно это как-то посмотреть. Не, ну мы посмотрели, видим, да, действительно, много файлов держит.
Speaker A
много отдаёт, само собой много держит в промежутках. Ну и это нормально. Ну, условно соединение много держит. Да, я понял. А получается ошибка ошибка в чём? То есть где-то валится ворнинги еро или м Да, это ворнги.
Speaker A
[музыка] Я бы загуглил или, не знаю, у коллег спросил, потому что сейчас не скажу.
Speaker A
А с улимитами работали? Нет, что-то мне ни о чём не говорит. О'кей. Это настройки ядра или это Нет, это не настройки ядра, это больше безопасность.
Speaker A
Ну, Linux Security, не путать с Linux. А, всё, я понял. Нет, не сталкивался, не помню, чтобы редактировать приходилось.
Speaker A
Ну, есть команда её лимиit, можно посмотреть лимиты конкретного пользователя, посмотреть его ограничения, сколько процессов может открыть, сколько файлов может открыть. и тому прочее. Там много всяко всяких лимитов можно понастраивать.
Speaker A
Но что касается НСА, это там этим можно управлять непосредственно через конфигурацию. Ладно, идём дальше. А команда D сообщает о наличии 20 Гб занятого пространства.
Speaker A
При подсчёте, э, объёма команды DO она показывает результат в 10 Гб. Почему мы можем видеть разные объёмы, занятые в одном и том же месте?
Speaker A
Возможно, у команд разный разный принцип обращения к дисковой подсистеме где-то, может быть. Ну, с айнодами это не связано в очередной раз, правильно?
Speaker A
Или косвенно. Ну, есть ноды, есть айноды. Если они, соответственно заполнились возможно одна из команд выдаёт неверные значения, потому что она не у Нет, не не в эту сторону. А тогда тогда тогда потому что где-то возможно открыт файловый ещё дескриптор файл удалён, и
Speaker A
одна из команд показывает без учёта этого. Ага. А мы можем как-то его найти? [музыка] какой-то флаг и можем посмотреть, да, ну не только через там ещё есть команда можно грепнуть просто, да, в принципе, правильно.
Speaker A
А так немножко поговорим про сети. А есть возможность чат открыть, посмотреть? чат. Ну, чат у меня открыт на экране. А, всё, не просто некоторые с телефона сидят.
Speaker A
Так, предположим, мы зашли на какой-то сервер. Там в таблице машетизации видим две такие записи.
Speaker A
А через какой шлюз пойдёт у нас трафик, если мы обращаемся к хосту 192 168 100.10 через единицы.
Speaker A
Почему? А, блин, подожди, где 100.102. Нет, через 4двойки. Почему? А потому что потому что потому что маска Хотя нет, стоп, не всё-таки через двадцать четвёртый, потому что маска под сети 24 и это все, весь трафик 192168 100.255 255 будет ходить до четырёх единиц,
Speaker A
потому что сш - это как бы, ну, окончание на 255, 100.25. Вот все IP-адреса до этого значения будут входить через четыре единицы.
Speaker A
Я не утверждаю, что это верный ответ, потому что я что с сетями немного плаваю. Я понял. Нет, неправильно.
Speaker A
А чем отличается TCP от UDP? TCP требует Ой, ну TCP подразумевает подтверждение доставки пакетов. UDP нет, потому что, ну, в UDP можно использовать стриминги, там, не знаю, в телефонии, когда часть профакапленных пакетов как бы не критично.
Speaker A
Вот отличие в подтверждении доставки пакетов до хоста. Угу. А как устанавливается TCP соединение? Через ншейк, что ли, это называется? Ну, в общем, мы отправляем заголовок, может ли хост принять как бы подключение. Дальше мы получаем ответ, можем. И, соответственно, через три
Speaker A
рукоподжатия, если я не ошибаюсь, называется, в общем, хост отправляет туда пакет, получает ответ и дальше начинает пересылать данные и получает подтверждение доставки, если этот CP. А заголовки какие при поднятии соединения передают?
Speaker A
Так как бы я повседневно никогда не сталкиваюсь. Это нужно там условно на интервью ответить.
Speaker A
Вопрос, поэтому не скажу. Это это ошибочное суждение. Ну, видимо, зависит от специфики работы, потому что если там постоянно с сетями, может быть, как-то взаимодействуешь с какими-то сервисами, возможно, мне это, ну, не требовалось, поэтому не отвечу. Хотя вопрос простой,
Speaker A
как бы, максимально. Ну ладно. А что такое ретрансмиш? Не отвечу. О'кей. А, о'кей. Что такое и как он работает?
Speaker A
Trroad у нас делает трассировку пакетов дохостаун соответственно это отражает у нас промежуточные хосты, через которые проходит трафик. Соответственно, он шлёт до ближайшего маштизатора, я так понимаю.
Speaker A
Ну, через получает ответ от маршрутизаторов по путиследования пакета до хоста. А как он нам отрисовывает все хосты, через которые прошёл пакет? Ну, я предположу что до хостов, до которых по цепочке доходят пакеты, соответственно, он дописывает, наверное, какой-то заголовок, чтобы
Speaker A
получился обратный ответ с возвращением имени айпишника или, ну, айпишника, наверное да. Но получается нам, что каждый через каждый хост, через который прошёл пакет, он нам должен ответить, что он пакет получил. М на один пакет слишком много флуда будет,
Speaker A
особенно если много через много мужетисаторов придётся пройти, да, поэтому тут затрудняюсь с ответом. О'кей.
Speaker A
А какой транспортный протокол используют ДНС? По-моему, это четвёртый уровень модели. Осень Нет, или пятый.
Speaker A
А так, ну, ДНС у нас работает на пятьдесят третьем порту. Вот по поводу транспортного протокола.
Speaker A
Ну TCP проще задам TCP или UDP. А он может работать и по TCP, и по UDP.
Speaker A
А в каких случаях он работает по TCP? В каких поP? М, в зависим предположу, что в зависимости от настроек сервера.
Speaker A
От настроек ДНС сервера. О'кей. А, о'кей. Как работает НАТ? Зачем он нужен? Какие виды НАТО бывают?
Speaker A
Над нужен для того, чтобы использовать, например, один внешний IP-адрес на группу, группу компьютеров, которые или серверов, которые стоят за натом, чтобы у них была внутренняя адресация, но наружу они выходили через, соответственно, над сервер.
Speaker A
Вот. классический нат, где как бы который работает как в режиме, можно сказать, машутизатора и другие виды натов я не назову.
Speaker A
Ну тот, который вы описали - это SNТ, да? А ещё какие-нибудь виды НАТО бывают?
Speaker A
М они однозначно бывают, но не помню, чтобы я сталкивался за последние 5 лет с этим.
Speaker A
Донат не настраивали? Нет. О'кей. А что он свое отличие? Если секрет, а что происходит с пакетом, например, при SNAT прави как? Ну, дописывается, соответственно, внутренний адрес и дальше он, соответственно, имеет внешний адрес.
Speaker A
Когда он обратно приходит, он приходит на внутренний адрес. Ну, типа, в IP-пакете передаётся два адреса.
Speaker A
Возможно, там какие-то заголовки используются. Я вот так детально не отвечу на этот вопрос. О'кей.
Speaker A
А что происходит в сети, когда мы в консоли вводим курlon?ru. Чем подробнее расскажете, тем лучше.
Speaker A
Нуно, какой-то хост, правильно? Konru. Ну, сначала у нас идёт обращение к файлу, если это Linux etc hosts.
Speaker A
Смотрится там соотношение айпишника и имени хоста. Если его там нету, то, соответственно, по цепочке идёт дальше обращение к ДНС кэшу. И если там нет адреса, то к DNS, соответственно, серверу.
Speaker A
Мм, дальше к корневым ДНС-серверам по необходимости. И дальше, соответственно, до хоста определяется айпишник и устанавливается соединение.
Speaker A
Хорошо. А как веб-сервер понимает, что вы пришли на kon.ru, а не на какой-то другой домен? Например, там у нас один внешний адрес, а доменов там, ну, несколько.
Speaker A
Да, я понял вопрос. Он тоже максимально простой. Вылететь его из головы. Там используется, блин, вылеть его из головы.
Speaker A
Действительно не заголо или заголовок, по-моему используется. В общем, там что-то указывается, то, что передаётся, и мы попадаем туда, куда нужно.
Speaker A
А как это называется? Да я говорю, вот вылетело из головы. На самом деле вопрос понятен. Я с этим недавно совсем сталкивался. Блин, это ещё в нжинксовской конфигурации задаётся.
Speaker A
Ну, в гинкосовской конфигурации там чуть-чуть по-другому это называется, но это можно при проксировании запроса переопределять, скажем так. Там вот прямо правильно называется.
Speaker A
А, в общем, я понимаю, о чём идёт речь. Назвать название не могу. К сожалению, вылетело прямо из головы.
Speaker A
Хорошо, говорим про кубер. А опиши архитектуру бернат кластера. Из чего он состоит? А кластер куба состоит у нас из кучи запущенных контейнеров.
Speaker A
Вот каждый отвечает за какие-то свои задачи. Соответственно, обращение у нас идёт к аписерверу и взаимодействуемый через кубкtl с аписервером путём, соответственно, запросов к нему.
Speaker A
Вот дальше CD для хранения конфигурации. А кубилет, который на хостах м купроксидур. А что я ещё не назвал?
Speaker A
IP сервер. ETCD что-то ты ещё не назвал. Ну, в целом хорошо. А что такое под?
Speaker A
Под сущность кубер, внутри которого, соответственно, у нас запускается контейнер. О'кей. Ну, там сначала, вернее, инициализируется вот то, что через Sunbox инициализирующий контейнер, который всё это дело поднимает, а потом уже запускается непосредственно сам сервис.
Speaker A
Ну да. А в чём разница между подом и контейнером? Мм, в том, что внутри пода может находиться несколько контейнеров.
Speaker A
Угу. Как правило, один под, один контейнер, но бывают случаи, когда нам надо внутри подать несколько контейнеров, например, там бэкэнты и базу. Бывают такие случаи, когда это нужно, и они будут использовать, естественно, единое пространство.
Speaker A
А вот если взять под какие виды контейнеров бывают, ну, там можно несколько типов запустить.
Speaker A
М, речь про, блин, как это называется-то? Про криоконтейнеры, про вот их разновидности. Ненене. Мы больше говорим про специфику этих контейнеров.
Speaker A
Ну, из подсказок они иногда используются для предконфигурации, например, там что-нибудь скачать для запуска основного контейнера или в процессе жизни, например, быть коллектором чего-либо для основного контейнера. Ну, это вот которые сандбоксовские образы инициализации, как бы.
Speaker A
М, блин, наверное, так не отвечу на этот вопрос. О'кей. А в чём отличие stateful setта от deployment?
Speaker A
Stateful set хранит состояние подов. А ещё какое-нибудь отличие большое? Так, стоит лиц. Ну, из подсказок это связано, наверное, со стороными.
Speaker A
Может быть, как, блин, не отвечу. Может быть, какое-то взаимодействие солумы, типа PVC, пивишки, вот это вот все исто.
Speaker A
Ну да, да, да, там есть особенность. М, вот этот особенность сейчас не назову. О'кей. А зачем нужен Diamond set?
Speaker A
Diamond set гарантирует, что у нас на каждой ноде будет запущено бусервис будет запущен на каждой ноде, если там нет исключений.
Speaker A
То есть мы можем там какие-то ноды под базой данных конкретно выделять и так далее. Тогда это игнорируется. Так, Diamond вообще запускает на всех нодах, если они селекторами отдельными указаны.
Speaker A
Хорошо. А что такое сервис? сервис тоже сущность кубера, которая у нас отвечает за, ну, соответственно, чтобы мы к подам могли обращаться через сервис, когда они используются.
Speaker A
А какие типы сервисов есть? Так, типа сервис сейчас. не ну классический который используется, другие не назову.
Speaker A
А что такое классический? Это когда мы в Ямле описываем, соответственно, у нас сервис, который как именно как приложение работает у нас внутри кубера.
Speaker A
И, соответственно, мы под него создаём ямом сервис и чтобы до него, соответственно, к нему была возможность подключиться.
Speaker A
Ну, там как бы все варианты позволяют подключиться, и, наверное, они все классические, но у них есть там четыре типа, ну, и будем говорить так, три основных. А, ну это речь про notпор, баланс, вот эти вот истории, да? А
Speaker A
lo банпорт, э, кластер IP и какой-то ещё, наверное, потому что я знаю только эти три в основном.
Speaker A
О'кей. А что такое лимит и request? М, лимиты реквест у нас через них мы можем ограничивать, сколько у нас потребляет соответственно ставить ограничения по процу, по памяти в ямле описания пода.
Speaker A
Угу. А что произойдёт с контейнером, если он превысит потребление ЦПУ? Его, соответственно, грох грохнет. О, нет, короче говоря, какой-то киллер его грохнет.
Speaker A
А если по памяти? По памяти, по-моему, возможно, та же история. А разве мы можем как-то контролировать приложение по ЦПУ, чтобы его грохать?
Speaker A
Ну, количество, сколько он потребляет процессорного условно времени в плане ресурсов, по-моему, можем. Да, мы при написании приложения можем сказать.
Speaker A
Три так-то что-то вычисляем, два так-то ничего не вычисляем. Нет, мы же можем в поде задать при при описании, я имею в виду депломента задать границы, за которые не может выходить. О, да. Вот мы указали, говорим вот 1.000 милис.
Speaker A
Э, он потреб хочет потребить полторы, и мы пойдём его прибьём. А скорее, скорее нет, чем да, мы скорее упрёмся, да, в лимит и просто будет, ну, ожидание всё это дольше будет выполняться. Но нет, да, по-моему, ничего не прибьётся в данном случае по
Speaker A
процу. Угу. Хорошо. А что такое славный стартап пробы? Зачем они нужны? Чем они отличаются?
Speaker A
Так, ну, одна проба у нас переводит под в состояние, когда вот, ну, под стартанул, запущен.
Speaker A
Мм, это когда у нас запускается сам контейнер. Мы получаем, по-моему, пробу о том, что у нас всё запустилось.
Speaker A
Алайнос проба - это когда у нас поднялся сервис, который там должен работать. Например, Инкс отдал двухсотую ошибку, код ответа, тогда мы понимаем, что, ну, как бы поднялся, отдаёт ответ и сервис считается запущенным.
Speaker A
Хорошо. Предположим, у нас Redn Pro не проходит. Тшфол там прошёл, который мы указали. Что произойдёт с контейнером?
Speaker A
М, если не ошибаюсь, он будет спустя какое-то время пытаться перезапуститься. Хорошо. А если по тем же причинам не проходит лайвна проба?
Speaker A
М, скорее всего, он так и будет просто висеть вот пока мы в него не зайдём и что-нибудь не сделаем.
Speaker A
Ну, это неточный ответ, потому что я путаю путаю эти две пробы. А если поразмышлять, а возможно, ну, если говорить про тот же Джинкс, то будет перезапускаться не сам контейнер, а возможно рестартоваться сама служба Джинсо это предположение.
Speaker A
А разве губернатор знает процесс запуска процесса в рамках контейнера? Как его можно перезапустить? Как его можно остановить?
Speaker A
Нет, не знает. Тогда тогда ответ, что ничего не будет происходить, просто будет как бы отдаваться самому условно этот пробушь. Он не недозапущенный. Тот же Джинс не отдаёт двухсотую ошибку.
Speaker A
По-моему, он так и будет висеть. М. О'кей. А так, что такое? Ангресс - это у нас точка точка входа в кубер из внех по по имени, ну, короче говоря, по по имени Хстов.
Speaker A
Ну, если мы берём классический, не знаю, который все используют Enginress, то мы можем, соответственно, через связать внутренние группу подов или под или внутренние там, не знаю, сервисы и так далее работающие по восьмидесятому 44 третьему порту через, чтобы к нему
Speaker A
был доступ. О'кей. А в чём преимущество использования э в чём преимущество использования Ингресса против сервиса при обращении приложений в рамках одного кластера друг другу?
Speaker A
Ну, например, у нас есть кластер, там есть там, ну, пять сервисов, они должны обращаться друг к другу. Почему выгоднее, если они будут ходить через ингресс, а не через сервис?
Speaker A
Мы откинем удобство там, что Инрес там в SSR умеет, там можно локейшены описать, и вот это вот всё мы с более технической точки зрения подходим.
Speaker A
Понятно, что он там удобнее, но он как бы является прокладкой дополнительной. Вот почему всё-таки с ним работает лучше, чем без него?
Speaker A
Мм, возможно, он работает на другом соответственно уровень абстракции выше, и используют сетевые плагины, вроде калики и так далее, и можно прикрутить какие-то дополнительные штуки, но это предположение не связано с плагинами.
Speaker A
не связано с Калика. Калика вообще немножко другим занимается, но вот другая зона ответственности. А, возможно, дополнительная куча параметров, которые мы можем задать в нгрейсе, но не можем задать в сервисе.
Speaker A
Ну, это понятно. А основная-то основное преимущество какое? [музыка] Что-то ничего на ум не приходит, честно.
Speaker A
О'кей. Ну, у меня вопросы закончились. Промиль. А дополнительные вопросы задаёшь? Мм, да. Аэ, так.
Speaker A
Ээ какие основные э артефакты бывают у Android? У андроида у Android приложений? Так, я в начале интервью сказал, что я не сталкивался со сборкой под Android.
Speaker A
Ну, если мы про Java говорим, там козлом собираем, то это джарники непосредственно наверное. О'кей. А у вас Android смартфона не было никогда? Акашки.
Speaker A
Угу. Угу. Всё верно. Да. А не слышали о такой штуке, как А? Не так давно, пару роль назад. Мм. А.
Speaker A
А, ну, Android Bundle, если со Нет, не слышал я. Вот, что касается мобильной разработки, максимально не сталкивался.
Speaker A
Так сейчас аа, а, какие, вот какие языки и платформы собирали вообще? То есть Java, там C.
Speaker A
Не знаю, вот был опыт совсем давно с дотнетом, соответственно, большая часть - это в основном джавовый стек через Угу. Хорошо.
Speaker A
Какие настройки для градла мы можем накрутить, а для того, чтобы умерить аппетиты сборки? Какие сущности вообще есть у Градула?
Speaker A
М, не скажу. Грабил демон. Встречались с таким. А м на ум не приходит? Нет. Угу. А-э, так хорошо.
Speaker A
Если вы с Ja, помимо ограничений ресурсов в контейнерах, нам нужно ещё, ээ, сообщить Джаве каким-то образом, да, а либо сколько она может потреблять ресурсов, либо сколько процентов от ээ э контейнера ресурсов она может потреблять. Да. Ээ, знаете, какие ключи
Speaker A
для этого применяются и что с этим можно сделать? Не, ну мы же можем это всё ограничить в Java BM, вот которое стартует.
Speaker A
Угу. А какие ключи там? Ну какие ограничения бывают? Ну, хотя бы так, может, по названиям не вспомните, но так блин, надо просто открыть config любой Java VM и посмотреть эти лечения. XMX XMS дада. Это по по как раз-таки
Speaker A
ресурсам. Там точно оперативка где-то указывается. Вот что касаемо что указывается там по процу, не скажу. Там либо в соотношении процентах, либо процессорное время, либо рацю. Я не помню, что вообще в принципе есть ограничение. Ну о'кей.
Speaker A
Мм. А так хорошо. Фронт вы собирали, да, по-моему, но ноды. Но трогали, да? [музыка] М.
Speaker A
Не совсем сейчас понял вопрос. Фронт. Ну, с НПМом сталкивались. JS, блин, только вот самое вот классический запуск да через MPM install, вот эти вот все дела.
Speaker A
Хорошо. С файликом NPMC сталкивались? М, возможно, там, скорее всего, ресурсы задаются, судя по названию.
Speaker A
Аа у вас во всех компаниях, ээ ну вот ээ была сборка мм с состоящая из нульщи внешние компоненты, да. Ну, скорее всего, да, любой продукт использует какие-то библиотеки извне, правильно?
Speaker A
Угу. Вот. А, ээ, обеспечение безопасности и уязвимость неуязвимости каким образом у вас осуществлялось? Мм, где-то использовался Sunarub, например, в процессе сборки, который чекал все эти моменты. Есть другие инструменты при сборке, которые проверяют пакеты, которые тянутся извнен по базам, соответственно, уязвимостей.
Speaker A
Угу. То есть у вас был какой-то инструмент который проверял библиотеки, да? Угу. Да. За этого за это отдельная команда как бы отвечала, которые вот по бизнесу Не, я понимаю, я просто вот спрашиваю, как организовано было и, ну, сталкивались ли
Speaker A
пресекались. Хорошо. С Санаром, значит, тоже, да, имели опыт работать. Ну, он максимально просто прикручивается в целом да?
Speaker A
Хорошо. Как прикручивается к Java проектур, к примеру? РКУ он встраивается в, соответственно, одну из в один из стейджей как бы пайплайна и проверяет используемые мм что он проверяет у нас Мм, он, соответственно, проверяет код на наличие наличие уязвимостей по базе.
Speaker A
Хорошо, я понял. Э, так, ну, в целом, наверное, у меня вопросы закончились. Вот. Ээ, может, какие-то вопросы у вас к нам возникли?
Speaker A
А, наверное, основной вопрос это что есть сейчас? Что бы хотелось получить после завершения, не знаю, испытательного срока инженера на данной позиции? То есть это разгребание бэклога, либо же это внедрение каких какого-то нового функционала, либо просто погрузиться и разгрузить текущих
Speaker A
инженеров по текущим задачам. CCD сейчас уже есть. Вот нужно, ну, а то, что нужно на первый этап - это работа с фичстендами и конореечным деплоем. Ну, соответственно, э последним шагом будет перевоз всего в новую инфраструктуру.
Speaker A
А сейчас заменка наречного деплоях используется BLгрин развёртывание либо же ничего не используется. Так о'кей понятно. А основные скилы, которые требуются, это всё-таки упорно м, короче говоря, с мобильной разработкой. Либо же это всё-таки Kuber, либо это CICD сети.
Speaker A
То есть, ну вот максимально экспертные знания нужны по какому направлению под данную позицию? А, ну мы рассчитываем, что клиентские приложения можно всегда м изучить. Ээ в основном это просто базовые знания, это знание куба, знания джинкса.
Speaker A
Вот. И, ну, э-э, клиентские, ну, всё остальное клиентское приложение, сборки - это, э, ну, тоже на основе базовых знаний. Если вы знаете, как, э, Linkс работает с памятью, как Java работает с памятью, то проблем не возникнет. Это всё можно изучить,
Speaker A
прочитать э статей 100, 500 млн. Документация градла очень подробная. Есть G5 [музыка] GP не поможет в этом плане вообще никак.
Speaker A
Не, с МЦПшкой он нормально работает. Без знаний ничего не поможет. Нет, ну им хорошо документацию читать, когда он даёт выдержки именно из всей огромной документации. У меня эта [ __ ] получится полная. Угу. Если вот в документациях Градла там
Speaker A
каждая строчка имеет супервысокую важность. Если ты неправильно прочитал, э-э, там, не знаю, один абзац и не понял, ээ все нюансы, то ты получил, ээ, непоня непонятно как работающую историю. То есть ты будешь сидеть и думать, но не понимать, как это
Speaker A
работает. большие документации, может быть, да, как-то где-то, но опять же все эти м сложение документации в краткий пересказ, то же самое, что там, не знаю, войну и мир на тридцати страницах прочитать. Да, контекст ты поймёшь, но ты не будешь знать, как Нет, я согласен.
Speaker A
Согласен, что технические нюансы максимально важны. Просто иногда где-то нужны общие там тезисы, понимания, особенно из зарубежной документации, поэтому иногда где-то чат GPT помогает в этом плане.
Speaker A
Ну о'кей. А, ну вот примерно так. Так, о'кей. А формат работы гибрид или полная удалёнка? Я вот этот вот момент упустил.
Speaker A
Мне не принципиально. А вы где, в каком регионе живёте? Я я 90% времени в Москве.
Speaker A
А, ну, соответственно, если а по возможности будете приходить в офис там четвергам, в основном коллеги собираются, ну, восстанов своей массе, так, чтобы просто поддерживать нетворкинг, скажем так, да, и в глаза посмотреть с кем вы работаете, потому что там в основном в Москве
Speaker A
команда а фронтовой разработки она, ну, короче, в основном она там и в основном Они как раз в офис входят.
Speaker A
Вот так. Это не обязательно. Я понял. Тогда у меня пока, наверное, других вопросов нет. Спасибо. M.
Topics:DevOpsсобеседованиеLinuxзагрузка системыload averageвиртуальные файловые системыLVMадминистрированиеDockerтехническое интервью
