Сервис работает, а снаружи не отвечает. В чем причина?
Комментов под утренним постом набралось не мало, давайте разберем.
Но сначала хочу подсветить такой момент: собеседующему важно именно как вы рассуждаете и накидываете вариантов, пусть даже неправильных.
В целом есть три способа строить ответ, которые кстати применимы и к другим абстрактным вопросам.
1. Самый простой вариант — просто перечислять гипотезы. Фаервол, порты, DNS, балансер, сертификат, NAT и прочее.
Плюс: быстро видно кругозор.
Минус: интервьюер не понимает, умеете ли вы это сужать.
2. Идти по слоям. Взять путь пакета от процесса до клиента и двигаться по нему.
Плюс: самый безопасный формат, в котором сразу видно структуру.
Минус: если на каком-то слое пусто, то это тоже сразу видно.
3. Задавать встречные вопросы. «А что значит не отвечает?», «доступ на сервер есть?», «это железка, докер или кубер?».
Плюс: ближе всего к реальной работе. Вы превращаете ответ в реальное расследование, а собеседующий сам подкидывает вводные и сужает область.
Минус: вас могут намеренно завести в ситуацию, где вы поплывёте.
Лучше всего отвечать гибридно. Два-три вопроса, которые сразу сильно сужают область поиска, потом озвучить метод, потом идти по слоям, называя конкретные команды.
Конкретно тут сузить проще всего так:
— Как именно «не отвечает»? Таймаут / connection refused / connection reset / отвечает, но 502-504. Дальше по ответу: refused и reset означают, что пакет дошёл до хоста и кто-то ответил. Таймаут — где-то DROP, NAT или маршрут.
— Доступ на сервер есть или чиним вслепую?
— Где крутится сервис: bare metal, VM, docker, k8s? Есть ли перед ним прокси, балансер, облачный фаервол?
— Когда сломалось и что перед этим делали?
Минимальный хороший ответ:
ss -tulpn — слушает ли сервис вообще и на каком адресе. Классика 127.0.0.1 вместо 0.0.0.0
curl -v localhost:PORT — жив ли он локально. Если нет, journalctl -u service -e и дальше это уже не про сеть
Фаервол на хосте: iptables -nvL / nft list ruleset / ufw status. И отдельно — облачные security groups и периметровый фаервол.
tcpdump -ni any port PORT — пакеты вообще долетают до сервера?
С клиента: nc -vz IP PORT строго по IP. Работает по IP, если хотим проверить домен идём в dig
ip r, traceroute / mtr — маршруты и где обрывается путь
Этого в целом хватит, остальное даст глубину и может вас выделить среди других.
Полный чеклист:
— Сервис: процесс жив, bind-адрес, слушает ли IPv6 и IPv4, конфиг и unit-файл, логи, dmesg на предмет OOM-killer.
— Контейнер: проброс портов (docker port), тип сети. В k8s: селектор сервиса, kubectl get endpoints (пустой endpoints — очень частая причина), targetPort, ingress, NetworkPolicy, readiness probe.
— Хост: ip a — интерфейс поднят, адрес и маска верные. ip r — дефолтный шлюз и маршруты. SELinux/AppArmor. Переполненная таблица conntrack. rp_filter и асимметричный роутинг.
— Фаерволы: локальный, облачный, периметровый NGFW/WAF. Отдельно: правила могли не сохраниться и слететь после ребута.
— NAT: DNAT настроен и указывает куда надо, hairpin, проброшен TCP, но забыт UDP.
— Путь: traceroute/mtr, провайдер, блокировки, проверка из другой геолокации или через VPN.
— Балансер и прокси: health check мог выкинуть живой бэкенд, протух сертификат, не тот server_name или SNI и nginx отдаёт default server.
— DNS: A-запись, TTL и кэш, split-horizon.
— Клиент: его собственный фаервол, корпоративный прокси.
Если хотите совсем упороться:
— MTU и PMTU blackhole. Когда пинг проходит, TCP-хендшейк проходит, а TLS или крупные ответы виснут намертво.
— Переполненный conntrack. conntrack -S, дропы в dmesg.
— Рассинхрон IPv4/IPv6.
И не забывайте называть конкретные команды для проверки.
Те, кто не попал на скрины — не расстраивайтесь, скорее всего просто кто-то до вас ответил почти так же.
Комментов под утренним постом набралось не мало, давайте разберем.
Но сначала хочу подсветить такой момент: собеседующему важно именно как вы рассуждаете и накидываете вариантов, пусть даже неправильных.
В целом есть три способа строить ответ, которые кстати применимы и к другим абстрактным вопросам.
1. Самый простой вариант — просто перечислять гипотезы. Фаервол, порты, DNS, балансер, сертификат, NAT и прочее.
Плюс: быстро видно кругозор.
Минус: интервьюер не понимает, умеете ли вы это сужать.
2. Идти по слоям. Взять путь пакета от процесса до клиента и двигаться по нему.
Плюс: самый безопасный формат, в котором сразу видно структуру.
Минус: если на каком-то слое пусто, то это тоже сразу видно.
3. Задавать встречные вопросы. «А что значит не отвечает?», «доступ на сервер есть?», «это железка, докер или кубер?».
Плюс: ближе всего к реальной работе. Вы превращаете ответ в реальное расследование, а собеседующий сам подкидывает вводные и сужает область.
Минус: вас могут намеренно завести в ситуацию, где вы поплывёте.
Лучше всего отвечать гибридно. Два-три вопроса, которые сразу сильно сужают область поиска, потом озвучить метод, потом идти по слоям, называя конкретные команды.
Конкретно тут сузить проще всего так:
— Как именно «не отвечает»? Таймаут / connection refused / connection reset / отвечает, но 502-504. Дальше по ответу: refused и reset означают, что пакет дошёл до хоста и кто-то ответил. Таймаут — где-то DROP, NAT или маршрут.
— Доступ на сервер есть или чиним вслепую?
— Где крутится сервис: bare metal, VM, docker, k8s? Есть ли перед ним прокси, балансер, облачный фаервол?
— Когда сломалось и что перед этим делали?
Минимальный хороший ответ:
ss -tulpn — слушает ли сервис вообще и на каком адресе. Классика 127.0.0.1 вместо 0.0.0.0
curl -v localhost:PORT — жив ли он локально. Если нет, journalctl -u service -e и дальше это уже не про сеть
Фаервол на хосте: iptables -nvL / nft list ruleset / ufw status. И отдельно — облачные security groups и периметровый фаервол.
tcpdump -ni any port PORT — пакеты вообще долетают до сервера?
С клиента: nc -vz IP PORT строго по IP. Работает по IP, если хотим проверить домен идём в dig
ip r, traceroute / mtr — маршруты и где обрывается путь
Этого в целом хватит, остальное даст глубину и может вас выделить среди других.
Полный чеклист:
— Сервис: процесс жив, bind-адрес, слушает ли IPv6 и IPv4, конфиг и unit-файл, логи, dmesg на предмет OOM-killer.
— Контейнер: проброс портов (docker port), тип сети. В k8s: селектор сервиса, kubectl get endpoints (пустой endpoints — очень частая причина), targetPort, ingress, NetworkPolicy, readiness probe.
— Хост: ip a — интерфейс поднят, адрес и маска верные. ip r — дефолтный шлюз и маршруты. SELinux/AppArmor. Переполненная таблица conntrack. rp_filter и асимметричный роутинг.
— Фаерволы: локальный, облачный, периметровый NGFW/WAF. Отдельно: правила могли не сохраниться и слететь после ребута.
— NAT: DNAT настроен и указывает куда надо, hairpin, проброшен TCP, но забыт UDP.
— Путь: traceroute/mtr, провайдер, блокировки, проверка из другой геолокации или через VPN.
— Балансер и прокси: health check мог выкинуть живой бэкенд, протух сертификат, не тот server_name или SNI и nginx отдаёт default server.
— DNS: A-запись, TTL и кэш, split-horizon.
— Клиент: его собственный фаервол, корпоративный прокси.
Если хотите совсем упороться:
— MTU и PMTU blackhole. Когда пинг проходит, TCP-хендшейк проходит, а TLS или крупные ответы виснут намертво.
— Переполненный conntrack. conntrack -S, дропы в dmesg.
— Рассинхрон IPv4/IPv6.
И не забывайте называть конкретные команды для проверки.
Те, кто не попал на скрины — не расстраивайтесь, скорее всего просто кто-то до вас ответил почти так же.
🔥98👍20❤17🏆4🤝3
Еще один любимый вопрос с собеседований
На сервере восемь гигабайт памяти. Заходите, набираете free -h, а свободно двести мегабайт. Что не так?
На самом деле всё в порядке, потому что:
Свободная память — это бесполезная память. Она лежит и ничего не делает, поэтому ядро её и не держит.
Всё, что когда-либо читалось с диска, ядро складывает в страничный кэш и держит там до последнего. Второе чтение того же файла пойдёт уже из памяти, а не с диска, что будет гораздо быстрее.
То есть двести мегабайт свободно означает не то, что памяти нет, а то, что ядро исправно выполняет свою работу.
Смотреть надо на другую колонку —
Проверить это можно очень просто: запустите что-нибудь тяжёлое и посмотрите на
А вот когда уже сам
Сначала в ход идёт swap. Это фрагмент диска, который система использует как запасную память: страницы, к которым давно не обращались, выгружаются туда, чтобы освободить оперативку. Но диск в сотни раз медленнее памяти, поэтому если swap начал расти, значит сервер уже дышит на ладан.
Если swap тоже не помогает, включается OOM killer, задача которого убивать процессы, лишь бы высвободить память. У ООМ киллера есть специальный алгоритм выбора процессов на убой: у каждого процесса есть счёт, который тем выше, чем больше памяти тот съел. Так что под нож обычно идёт самое жирное.
А увидеть, что это произошло, можно в
Лайк, подписка, платформа.
На сервере восемь гигабайт памяти. Заходите, набираете free -h, а свободно двести мегабайт. Что не так?
На самом деле всё в порядке, потому что:
Свободная память — это бесполезная память. Она лежит и ничего не делает, поэтому ядро её и не держит.
Всё, что когда-либо читалось с диска, ядро складывает в страничный кэш и держит там до последнего. Второе чтение того же файла пойдёт уже из памяти, а не с диска, что будет гораздо быстрее.
То есть двести мегабайт свободно означает не то, что памяти нет, а то, что ядро исправно выполняет свою работу.
Смотреть надо на другую колонку —
available. Это сколько памяти можно отдать приложению прямо сейчас, включая всё, что ядро освободит из кэша по первому требованию. Обычно там большой запас, даже когда в free почти ноль.Проверить это можно очень просто: запустите что-нибудь тяжёлое и посмотрите на
free -h ещё раз, а кэш ужмётся сам.А вот когда уже сам
available стремится к нулю — это очень плохо, и ядро начинает выкручиваться из ситуации, причем для этого у него есть два механизма.Сначала в ход идёт swap. Это фрагмент диска, который система использует как запасную память: страницы, к которым давно не обращались, выгружаются туда, чтобы освободить оперативку. Но диск в сотни раз медленнее памяти, поэтому если swap начал расти, значит сервер уже дышит на ладан.
Если swap тоже не помогает, включается OOM killer, задача которого убивать процессы, лишь бы высвободить память. У ООМ киллера есть специальный алгоритм выбора процессов на убой: у каждого процесса есть счёт, который тем выше, чем больше памяти тот съел. Так что под нож обычно идёт самое жирное.
А увидеть, что это произошло, можно в
dmesg. Это буфер сообщений ядра: всё, что ядро считает нужным сказать, попадает туда. dmesg -T | grep -i oom покажет, кого и когда убили.Лайк, подписка, платформа.
👍125🔥57😁7🎉6💯6
Мощный коммент под роликом про SSH.
Че еще можно было бы добавить?
- Лимиты на попытки входа с fail2ban, чтобы банить IP после нескольких неудач.
- Файрвол, где закрыто всё, кроме того, что реально смотрит наружу, (хотя наверное это есть).
Что бы вы добавили к такому сетапу? Или и так ту мач?
Че еще можно было бы добавить?
- Лимиты на попытки входа с fail2ban, чтобы банить IP после нескольких неудач.
- Файрвол, где закрыто всё, кроме того, что реально смотрит наружу, (хотя наверное это есть).
Что бы вы добавили к такому сетапу? Или и так ту мач?
❤116🔥49👍19😁17👏5
Если вы хоть раз прикручивали домен к сайту, то это пост для вас.
Прописал запись, ввел адрес, а браузер говорит, что такого сайта нет. При обновлении все то же самое. Обновляешь ещё десять раз, лезешь перепроверять настройки, вроде всё правильно. Ну не должно быть проблем. Но не работает. А через пять минут оп, и открылось.
Почему?
Ваш комп не знает, какой IP у сайта, поэтому спрашивает у резолвера. Резолвер — это сервер, который переводит имена в адреса, ближайший к вам резолвер находится у провайдера. Дальше такой сервер делает все сам: идет искать адрес, находит, отдаёт вам ответ и заодно кладет его себе в память, чтобы в следующий раз уже никуда не ходить.
А мы же с вами как делаем: покупаем домен и сразу тыкаем, что там. Резолвер идет спрашивать и получает ответ, что такого имени нет. И запоминает именно такой ответ, ровно так же, как запомнил бы реальный адрес.
Поэтому надо помнить:
Свежекупленный домен должен сначала появиться в самой зоне (
Окей, домен появился в зоне, и дальше вы создаёте запись, когда домен уже в реестре. Эта запись тоже должна обновиться, пройдя тот же самый путь. Короче, одним ранним кликом можно словить 10+ минут (в зависимости от настроек и все 60) «имени не существует».
Ну а обновлять страницу бесполезно в принципе. Вы каждый раз спрашиваете не у своего сервера, а у той же самой записи в чужой памяти. Хоть сто раз обновите, ответ не изменится, пока не выйдет срок.
Время хранения записи задается параметром TTL, то есть сколько секунд ответ разрешено хранить. Только вот для ответа "имени нет", TTL задает сама зона, а там показатель может доходить до часа.
Поэтому для проверки DNS лучше всего использовать команду dig +trace prostodevops.ru, так как она не мусорит записями на резолверах, и соответственно возвращает актуальный ответ на каждый момент своего выполнения.
Завтра, кстати, выходит ролик про DNS
Если у вас тоже есть чем поделиться, что связано с днсом(про продавцов-консультантов не писать) , рассказывайте, интересно почитать
Прописал запись, ввел адрес, а браузер говорит, что такого сайта нет. При обновлении все то же самое. Обновляешь ещё десять раз, лезешь перепроверять настройки, вроде всё правильно. Ну не должно быть проблем. Но не работает. А через пять минут оп, и открылось.
Почему?
Ваш комп не знает, какой IP у сайта, поэтому спрашивает у резолвера. Резолвер — это сервер, который переводит имена в адреса, ближайший к вам резолвер находится у провайдера. Дальше такой сервер делает все сам: идет искать адрес, находит, отдаёт вам ответ и заодно кладет его себе в память, чтобы в следующий раз уже никуда не ходить.
А мы же с вами как делаем: покупаем домен и сразу тыкаем, что там. Резолвер идет спрашивать и получает ответ, что такого имени нет. И запоминает именно такой ответ, ровно так же, как запомнил бы реальный адрес.
Поэтому надо помнить:
Свежекупленный домен должен сначала появиться в самой зоне (
.ru, .com и тд). Регистратор отправляет его в реестр, и пока домен не опубликован в реестре, имени физически нет ни для кого. Обычно это занимает до 5 минут. Но ловушка-то остается: вы купили домен, тут же создали запись, тут же проверили, а домена ещё нет в зоне, вы получаете, что имени нет и вдобавок заражаете резолвер отрицательным ответом. Через время запись из памяти уходит.Окей, домен появился в зоне, и дальше вы создаёте запись, когда домен уже в реестре. Эта запись тоже должна обновиться, пройдя тот же самый путь. Короче, одним ранним кликом можно словить 10+ минут (в зависимости от настроек и все 60) «имени не существует».
Ну а обновлять страницу бесполезно в принципе. Вы каждый раз спрашиваете не у своего сервера, а у той же самой записи в чужой памяти. Хоть сто раз обновите, ответ не изменится, пока не выйдет срок.
Время хранения записи задается параметром TTL, то есть сколько секунд ответ разрешено хранить. Только вот для ответа "имени нет", TTL задает сама зона, а там показатель может доходить до часа.
Поэтому для проверки DNS лучше всего использовать команду dig +trace prostodevops.ru, так как она не мусорит записями на резолверах, и соответственно возвращает актуальный ответ на каждый момент своего выполнения.
Завтра, кстати, выходит ролик про DNS
Если у вас тоже есть чем поделиться, что связано с днсом
👍75❤38🔥17🤝4💯1
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Как домен превращается в IP
Подробный разбор DNS - https://prostodevops.ru/l/vidos-dns
00:00 Сайт не открывается
00:47 Файл с адресами
02:08 Почему единого списка имён не существует
02:35 Файл hosts на компьютере
03:23 Резолвер, рекурсивный и итеративный запросы
04:02 Корневые серверы…
00:00 Сайт не открывается
00:47 Файл с адресами
02:08 Почему единого списка имён не существует
02:35 Файл hosts на компьютере
03:23 Резолвер, рекурсивный и итеративный запросы
04:02 Корневые серверы…
🔥65👍30🎉8👀5❤3
Просто Devops
Если вы хоть раз прикручивали домен к сайту, то это пост для вас. Прописал запись, ввел адрес, а браузер говорит, что такого сайта нет. При обновлении все то же самое. Обновляешь ещё десять раз, лезешь перепроверять настройки, вроде всё правильно. Ну не должно…
Когда писал пост про DNS-записи и дошел до абзаца с TTL, сразу вспомнил интересную деталь про этот параметр.
Расшифровывается он как time to live, или же время жизни. Звучит однозначно, хотя на самом деле это время измеряется по-разному в разных вещах.
Пример первый.
Чаще всего TTL — это секунды с обратным отсчётом.
— В DNS TTL сообщает, сколько резолверу разрешено держать ответ у себя в памяти.
— В redis это вообще отдельная пара команд:
— В DHCP адрес выдаётся не навсегда, а в аренду на N секунд, и клиент обязан его продлевать, иначе адрес уйдёт другому.
Механика элементарная везде — просто обратный отсчет в секундах.
Пример 2. IP-пакет.
Тут тоже есть поле TTL, но оно никак не связано со временем. Это счётчик прыжков (они же хопы) между маршрутизаторами, причем каждый маршрутизатор, получая пакет, прежде чем отправить его дальше, уменьшает этот TTL на 1, таким образом на каком-то маршрутизаторе (если пакет не найдет получателя раньше), он исчерпает лимит хопов, отправителю вернется ICMP-ответ о том, что время пакета вышло и он исчезнет из сети.
Фан-факт: изначально тут тоже были секунды, просто никто никогда их не считал, потому что вычитать единичку оказалось проще. И в IPv6 его переименовали в Hop Limit.
Пример 3. Миллисекунды
В RabbitMQ время жизни сообщения в очереди задаётся в мс, у редиса рядом с EXPIRE лежит PEXPIRE, тоже в мс. Это самый подлый момент, потому что в перепутать в конфиге сек вместо мс или наоборот = создать разницу в 1000 раз.
А вообще почему я об этом вспомнил: на собеседованиях любят спрашивать "что такое TTL и в чем измеряется", и многие тут теряются, либо потому что нервничают, либо потому что не помнят, но смысл в том, что ответ на вопрос зависит от контекста, и если сможете назвать все три — это будет явно бонус в вашу пользу.
Поэтому сохраняйте, не забывайте, проходите собесы.
Расшифровывается он как time to live, или же время жизни. Звучит однозначно, хотя на самом деле это время измеряется по-разному в разных вещах.
Пример первый.
Чаще всего TTL — это секунды с обратным отсчётом.
— В DNS TTL сообщает, сколько резолверу разрешено держать ответ у себя в памяти.
— В redis это вообще отдельная пара команд:
EXPIRE key <число> вешает на ключ срок, а TTL key показывает, сколько ему осталось жить, и когда счётчик доходит до нуля, ключ просто исчезает.— В DHCP адрес выдаётся не навсегда, а в аренду на N секунд, и клиент обязан его продлевать, иначе адрес уйдёт другому.
Механика элементарная везде — просто обратный отсчет в секундах.
Пример 2. IP-пакет.
Тут тоже есть поле TTL, но оно никак не связано со временем. Это счётчик прыжков (они же хопы) между маршрутизаторами, причем каждый маршрутизатор, получая пакет, прежде чем отправить его дальше, уменьшает этот TTL на 1, таким образом на каком-то маршрутизаторе (если пакет не найдет получателя раньше), он исчерпает лимит хопов, отправителю вернется ICMP-ответ о том, что время пакета вышло и он исчезнет из сети.
Фан-факт: изначально тут тоже были секунды, просто никто никогда их не считал, потому что вычитать единичку оказалось проще. И в IPv6 его переименовали в Hop Limit.
Пример 3. Миллисекунды
В RabbitMQ время жизни сообщения в очереди задаётся в мс, у редиса рядом с EXPIRE лежит PEXPIRE, тоже в мс. Это самый подлый момент, потому что в перепутать в конфиге сек вместо мс или наоборот = создать разницу в 1000 раз.
А вообще почему я об этом вспомнил: на собеседованиях любят спрашивать "что такое TTL и в чем измеряется", и многие тут теряются, либо потому что нервничают, либо потому что не помнят, но смысл в том, что ответ на вопрос зависит от контекста, и если сможете назвать все три — это будет явно бонус в вашу пользу.
Поэтому сохраняйте, не забывайте, проходите собесы.
❤52🔥34👍23💯4💅1
Не о чем рассказывать на собеседованиях
Одна из трех причин, по которой вас не зовут на следующие этапы и не дают офферы, звучит именно так.
Что ждут от вас, спрашивая об опыте? Все хотят услышать, что вы умеете решать задачи, и тут важна КОНКРЕТИКА.
Условно, сказать: "ну я занимался кубером, писал helm-чарты и тд" — может кто-угодно, и большинство упирается именно в такие формулировки, и собеседующему приходится буквально вытягивать хоть что-то значимое из человека.
А теперь сравним с другим ответом, который звучал бы примерно так: "в целом работаю много с чем, например вот недавно решил такой интересный инцидент: у нас была джоба для выгрузки, которая должна отрабатывать ночью, но прикол в том, что она никогда не отрабатывала, когда пошел разобраться, выяснил, что в манифесте был прописан RestartPolicy: Always, а джоба такое вообще не принимает, поправил, но это тоже до конца проблему не решило, джоба создалась, но сразу зависла, тут причина оказалась в том, что она тянула параметры из конфигмапы, которой просто не было в неймспейсе. Добавил этот конфигмап, все завелось и отработало. Если хотите, могу еще что-то рассказать, или дальше по стеку пойду"
И так можно рассказать почти о любой задаче, и разница между 1 и 2 типом ответа состоит не в опыте, а в умении рассказать, что было.
Окей, вы скажете, а если не приходилось сталкиваться с задачами, которые стоят внимания, что делать? А тут, друзья, к вам на помощь приходим мы.
20 августа (то есть уже через 2 дня), на нашей платформе появится 76 лаб, в которых мы взяли за основу реальные задачи и инциденты. Все так же прямо в браузере (там уже не только терминал, но и текстовые и редакторы, и еще одинбраузер ).
10 лаб будет доступно сразу абсолютно бесплатно (нужен только аккаунт на платформе).
А пока можете пойти смотреть "Введение в девопс", чтобы настроиться на задачки.
Мы очень старались, надеемся, всем очень понравится. ❤️
Одна из трех причин, по которой вас не зовут на следующие этапы и не дают офферы, звучит именно так.
Что ждут от вас, спрашивая об опыте? Все хотят услышать, что вы умеете решать задачи, и тут важна КОНКРЕТИКА.
Условно, сказать: "ну я занимался кубером, писал helm-чарты и тд" — может кто-угодно, и большинство упирается именно в такие формулировки, и собеседующему приходится буквально вытягивать хоть что-то значимое из человека.
А теперь сравним с другим ответом, который звучал бы примерно так: "в целом работаю много с чем, например вот недавно решил такой интересный инцидент: у нас была джоба для выгрузки, которая должна отрабатывать ночью, но прикол в том, что она никогда не отрабатывала, когда пошел разобраться, выяснил, что в манифесте был прописан RestartPolicy: Always, а джоба такое вообще не принимает, поправил, но это тоже до конца проблему не решило, джоба создалась, но сразу зависла, тут причина оказалась в том, что она тянула параметры из конфигмапы, которой просто не было в неймспейсе. Добавил этот конфигмап, все завелось и отработало. Если хотите, могу еще что-то рассказать, или дальше по стеку пойду"
И так можно рассказать почти о любой задаче, и разница между 1 и 2 типом ответа состоит не в опыте, а в умении рассказать, что было.
Окей, вы скажете, а если не приходилось сталкиваться с задачами, которые стоят внимания, что делать? А тут, друзья, к вам на помощь приходим мы.
20 августа (то есть уже через 2 дня), на нашей платформе появится 76 лаб, в которых мы взяли за основу реальные задачи и инциденты. Все так же прямо в браузере (там уже не только терминал, но и текстовые и редакторы, и еще один
10 лаб будет доступно сразу абсолютно бесплатно (нужен только аккаунт на платформе).
А пока можете пойти смотреть "Введение в девопс", чтобы настроиться на задачки.
Мы очень старались, надеемся, всем очень понравится. ❤️
❤92👍30🔥18🤝3👎2
76 практических задач для девопса
Полигон официально релизнут, и в нем абсолютно бесплатно открыто 10 задач по 8 инструментам.
Можно решать в любом порядке, можно перерешивать, можно решать на скорость — проверки автоматические, сверяют среду с целевой картиной, поэтому любой набор команд, который привел к нужному результату засчитывается вне зависимости от порядка и содержания.
Да и в целом, что я тут рассказываю, просто зайдите и попробуйте сами.
А ребята с буткемпа уже могут написать в комментах первый фидбек по полигону, если захотят, конечно)
Полигон официально релизнут, и в нем абсолютно бесплатно открыто 10 задач по 8 инструментам.
Можно решать в любом порядке, можно перерешивать, можно решать на скорость — проверки автоматические, сверяют среду с целевой картиной, поэтому любой набор команд, который привел к нужному результату засчитывается вне зависимости от порядка и содержания.
Да и в целом, что я тут рассказываю, просто зайдите и попробуйте сами.
А ребята с буткемпа уже могут написать в комментах первый фидбек по полигону, если захотят, конечно)
🔥160❤38👍17💯6🤝2
На канале новый ролик
Разбираем траблшутинг и причины тормозов серверов
📱 Смотреть: https://youtu.be/d4fTu0nP1g0
Разбираем траблшутинг и причины тормозов серверов
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
ТРАБЛШУТИНГ СЕРВЕРОВ НА ПАЛЬЦАХ
76 сломанных серверов, которые надо чинить.
Начать бесплатно - https://prostodevops.ru/l/troubleshoot
Разбираем порядок, в котором траблшутить сервера:
с чего начинать, что смотреть дальше и как на каждом шаге понять, копать здесь или идти дальше.
- Почему…
Начать бесплатно - https://prostodevops.ru/l/troubleshoot
Разбираем порядок, в котором траблшутить сервера:
с чего начинать, что смотреть дальше и как на каждом шаге понять, копать здесь или идти дальше.
- Почему…
🔥57❤17👍13🎉8👀2
СОБЕСЕДОВАНИЯ != РАБОТА
Я думаю, каждый из вас хотя бы раз слышал эту фразу, да и мы и сами как-то давно об этом писали в канале.
Почему это так и так ли это вообще?
Люди по своей натуре - ленивые, а компании по своей натуре стремятся внедрять стандарты во все процессы, а найм - это один из таких процессов.
Что происходит из-за лени людей? Тот, кто должен искать кандидата, не хочет заморачиваться с подготовкой к собеседованию, он идет и ищет типа "100 вопросов для собеседования в DevOps" - выбирает понравившиеся и вот его методика собеседования готова.
Что происходит из-за стандартов? Компании берут и составляют собственные списки вопросов к собеседованиям на те позиции, которые в компании есть, чтобы лид шел не гуглить эти вопросы, а брать из каким-то образом продуманной внутренней базы, чтобы компания понимала, что каждый лид будет оценивать кандидатов по одной модели.
Конечно, никто не отменял блок рассказа о себе и своих кейсах, задачах и факапах - тут вас не вгоняют в рамки, опять же напоминаю про полигон, где можно бесплатно выполнить 10 простых, но хороших, распространенных кейсов, чтобы разнообразить свой рассказ, кстати за последние дни выкатили много фиксов в лабах, тоже повод вернуться и пройти.
И в итоге, мы имеем картину: ленивый лид берет вопросы из стандартного пака. И так как перечень вопросов широкий - без подготовки к собеседованию, без изучения вопросов предварительно - пройти собес почти нереально, такая вот у нас специфика рынка. Вы можете быть крутым специалистом, но не вспомнить какие-то банальные вещи на собеседовании, потому что давно не встречались - и все.
И хотя мы всегда на сопровождении всем говорим, что собеседование - это не экзамен, и не нужно его бояться, потому что их будет огромное количество, но вот процесс подготовки к собеседованию очень напоминает процесс подготовки к экзамену, просто можно чуть менее нервно готовиться.
Так что для работы - нужны практические тренировки так скажем, а для того, чтобы на работу попасть - теоретические.
Мы, например, именно поэтому отдельно добавили блоки вопросов с собеседований в буткемп, потому что теории много, но она нужна для разного, а когда у тебя перед глазами еще и вопросы с собеседований, ты понимаешь, какую часть теории надо обязательно не забывать, потому что она даст дорогу к новым достижениям, карьерным ступенькам и так далее.
Ну а если ваше направление - это не девопс, и вы не знаете, где взять вопросы для подготовки, то опять же загуглить "100 самых популярных вопросов по <профессия>" - в целом даст нормальный результат, а начнете проходить собеседования, и уже сориентируетесь, что надо дополнительно перед следующими повторять.
🕺 Наша платформа
Я думаю, каждый из вас хотя бы раз слышал эту фразу, да и мы и сами как-то давно об этом писали в канале.
Почему это так и так ли это вообще?
Люди по своей натуре - ленивые, а компании по своей натуре стремятся внедрять стандарты во все процессы, а найм - это один из таких процессов.
Что происходит из-за лени людей? Тот, кто должен искать кандидата, не хочет заморачиваться с подготовкой к собеседованию, он идет и ищет типа "100 вопросов для собеседования в DevOps" - выбирает понравившиеся и вот его методика собеседования готова.
Что происходит из-за стандартов? Компании берут и составляют собственные списки вопросов к собеседованиям на те позиции, которые в компании есть, чтобы лид шел не гуглить эти вопросы, а брать из каким-то образом продуманной внутренней базы, чтобы компания понимала, что каждый лид будет оценивать кандидатов по одной модели.
Конечно, никто не отменял блок рассказа о себе и своих кейсах, задачах и факапах - тут вас не вгоняют в рамки, опять же напоминаю про полигон, где можно бесплатно выполнить 10 простых, но хороших, распространенных кейсов, чтобы разнообразить свой рассказ, кстати за последние дни выкатили много фиксов в лабах, тоже повод вернуться и пройти.
И в итоге, мы имеем картину: ленивый лид берет вопросы из стандартного пака. И так как перечень вопросов широкий - без подготовки к собеседованию, без изучения вопросов предварительно - пройти собес почти нереально, такая вот у нас специфика рынка. Вы можете быть крутым специалистом, но не вспомнить какие-то банальные вещи на собеседовании, потому что давно не встречались - и все.
И хотя мы всегда на сопровождении всем говорим, что собеседование - это не экзамен, и не нужно его бояться, потому что их будет огромное количество, но вот процесс подготовки к собеседованию очень напоминает процесс подготовки к экзамену, просто можно чуть менее нервно готовиться.
Так что для работы - нужны практические тренировки так скажем, а для того, чтобы на работу попасть - теоретические.
Мы, например, именно поэтому отдельно добавили блоки вопросов с собеседований в буткемп, потому что теории много, но она нужна для разного, а когда у тебя перед глазами еще и вопросы с собеседований, ты понимаешь, какую часть теории надо обязательно не забывать, потому что она даст дорогу к новым достижениям, карьерным ступенькам и так далее.
Ну а если ваше направление - это не девопс, и вы не знаете, где взять вопросы для подготовки, то опять же загуглить "100 самых популярных вопросов по <профессия>" - в целом даст нормальный результат, а начнете проходить собеседования, и уже сориентируетесь, что надо дополнительно перед следующими повторять.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤42🔥11👏8👀3💯1