Просто Devops
Куда уходит ваш приватный ключ, когда вы подключаетесь по ssh? Правильный ответ: никуда Готовили ролик про SSH (кстати завтра выйдет) и наткнулись на момент, который как-то редко рассказывают, хотя пользуются ssh ежедневно, да и на собесах такой вопрос может…
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥123❤36💯11🤯7🙏4
Сервис на сервере работает, а снаружи не отвечает. Где искать причину?
Это один из самых популярных вопросов на собеседованиях о траблшутинге. Он абстрактный, минимум контекста, по нему собеседующий пытается понять насколько у вас широкий кругозор в контексте поиска проблем с минимумом вводных.
Ну а сейчас объявляется интерактив: пишите в комментарии, как вы бы ответили на этот вопрос, к вечеру выложим эталонный ответ, а также отберем среди комментариев лучшие ответы и приложим их к посту.
Для калибровки: 👍 если формат нравится, 👎 если формат не нравится.
Поехали
Это один из самых популярных вопросов на собеседованиях о траблшутинге. Он абстрактный, минимум контекста, по нему собеседующий пытается понять насколько у вас широкий кругозор в контексте поиска проблем с минимумом вводных.
Ну а сейчас объявляется интерактив: пишите в комментарии, как вы бы ответили на этот вопрос, к вечеру выложим эталонный ответ, а также отберем среди комментариев лучшие ответы и приложим их к посту.
Для калибровки: 👍 если формат нравится, 👎 если формат не нравится.
Поехали
👍436❤8🔥4👎3🤯1
Год назад на ютубе нас было 7 тысяч. Сегодня 50.🎉
Повод оглянуться, потому что за это время поменялось примерно всё.
Год назад никакой платформы не существовало даже в планах. Сопровождение до оффера делалось на коленке: пара пдфок, созвоны голосом и понимание, в каком порядке объяснять темы. Из готового были только курсы на Степике. А ролики наполовину состояли из СДВГ-нарезок и гифокхех , и вы нам об этом писали регулярно и совершенно справедливо.
Сейчас ролики выходят в разы качественнее (за это спасибо монтажерам), но дожимать всё равно есть куда, и мы дожимаем, каждый следующий стараемся сделать лучше предыдущего. Потолка тут нет.
Спасибо вам за это, если честно. Без ваших комментариев, в том числе злых, мы бы шли сюда сильно дольше.
«Просто DevOps» с самого начала был про пользу, а не про продажи, и весь путь из этого и вырос. Сначала Степик, потом сопровождение, потом платформа.
Про Степик надо сказать честно: там были косяки. Мы их признаём, чинили как могли и максимально быстро, но это была проба пера — первое, что мы вообще сделали, и именно на этом набивали шишки. Сопровождение дало другое: оно нарастило мышечную массу. Больше сотни человек, под тысячу собеседований, реальные вопросы, самые разные кейсы, понимание, что работает, а что красиво звучит, но не работает.
А буткемп — это уже магнум опус. Всё, что накопилось за это время, собрано в одном месте: в программе только то, что реально нужно в работе, кейсы построены на настоящих задачах, внутри лежит база вопросов с реальных собеседований. Ничего для объёма ради объёма.
В сентябре выйдет большое обновление, и туда добавится полигон. Что это такое, расскажем отдельно, но если коротко — там придётся чинить сломанное. И прямо сейчас идёт активная разработка новых модулей.
И когда мы пишем про свои продукты - это всегда рост отписок, либо клоуны на пост.)) Но буткемп и сопровождение до оффера — это наши флагманы, и за них обоих не стыдно ни разу. Поэтому и рассказываем, потому что грех не рассказать).
И если вы дочитали досюда и вам стало интересно, что такое буткемп, то покупать его для этого не нужно. Зайдите на платформу, зарегистрируйтесь и пройдите бесплатное «Введение в DevOps». Там лежит тот же самый настоящий терминал, про который мы везде говорим, и потрогать его можно совершенно бесплатно.
Не зайдёт — ну зато пощупали прикольный терминал. А если поймёте, что душа лежит, то буткемп даст раскрыться по полной.
Регистрация на платформе тут.
Буткемп тут.
🔥 Ну и с пятьюдесятью тысячами нас) Если этот год для вас тоже что-то значил, киньте огня, дальше — больше.
Повод оглянуться, потому что за это время поменялось примерно всё.
Год назад никакой платформы не существовало даже в планах. Сопровождение до оффера делалось на коленке: пара пдфок, созвоны голосом и понимание, в каком порядке объяснять темы. Из готового были только курсы на Степике. А ролики наполовину состояли из СДВГ-нарезок и гифок
Сейчас ролики выходят в разы качественнее (за это спасибо монтажерам), но дожимать всё равно есть куда, и мы дожимаем, каждый следующий стараемся сделать лучше предыдущего. Потолка тут нет.
Спасибо вам за это, если честно. Без ваших комментариев, в том числе злых, мы бы шли сюда сильно дольше.
«Просто DevOps» с самого начала был про пользу, а не про продажи, и весь путь из этого и вырос. Сначала Степик, потом сопровождение, потом платформа.
Про Степик надо сказать честно: там были косяки. Мы их признаём, чинили как могли и максимально быстро, но это была проба пера — первое, что мы вообще сделали, и именно на этом набивали шишки. Сопровождение дало другое: оно нарастило мышечную массу. Больше сотни человек, под тысячу собеседований, реальные вопросы, самые разные кейсы, понимание, что работает, а что красиво звучит, но не работает.
А буткемп — это уже магнум опус. Всё, что накопилось за это время, собрано в одном месте: в программе только то, что реально нужно в работе, кейсы построены на настоящих задачах, внутри лежит база вопросов с реальных собеседований. Ничего для объёма ради объёма.
В сентябре выйдет большое обновление, и туда добавится полигон. Что это такое, расскажем отдельно, но если коротко — там придётся чинить сломанное. И прямо сейчас идёт активная разработка новых модулей.
И когда мы пишем про свои продукты - это всегда рост отписок, либо клоуны на пост.)) Но буткемп и сопровождение до оффера — это наши флагманы, и за них обоих не стыдно ни разу. Поэтому и рассказываем, потому что грех не рассказать).
И если вы дочитали досюда и вам стало интересно, что такое буткемп, то покупать его для этого не нужно. Зайдите на платформу, зарегистрируйтесь и пройдите бесплатное «Введение в DevOps». Там лежит тот же самый настоящий терминал, про который мы везде говорим, и потрогать его можно совершенно бесплатно.
Не зайдёт — ну зато пощупали прикольный терминал. А если поймёте, что душа лежит, то буткемп даст раскрыться по полной.
Регистрация на платформе тут.
Буткемп тут.
🔥 Ну и с пятьюдесятью тысячами нас) Если этот год для вас тоже что-то значил, киньте огня, дальше — больше.
🔥168❤38🎉22👍8🤡4
Сервис работает, а снаружи не отвечает. В чем причина?
Комментов под утренним постом набралось не мало, давайте разберем.
Но сначала хочу подсветить такой момент: собеседующему важно именно как вы рассуждаете и накидываете вариантов, пусть даже неправильных.
В целом есть три способа строить ответ, которые кстати применимы и к другим абстрактным вопросам.
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.
И не забывайте называть конкретные команды для проверки.
Те, кто не попал на скрины — не расстраивайтесь, скорее всего просто кто-то до вас ответил почти так же.
🔥88👍15❤14🏆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 покажет, кого и когда убили.Лайк, подписка, платформа.
👍109🔥51😁7💯6🎉5
Мощный коммент под роликом про SSH.
Че еще можно было бы добавить?
- Лимиты на попытки входа с fail2ban, чтобы банить IP после нескольких неудач.
- Файрвол, где закрыто всё, кроме того, что реально смотрит наружу, (хотя наверное это есть).
Что бы вы добавили к такому сетапу? Или и так ту мач?
Че еще можно было бы добавить?
- Лимиты на попытки входа с fail2ban, чтобы банить IP после нескольких неудач.
- Файрвол, где закрыто всё, кроме того, что реально смотрит наружу, (хотя наверное это есть).
Что бы вы добавили к такому сетапу? Или и так ту мач?
❤69🔥29👍15😁8👏5