32 МБ свободной памяти, а утилите нужно 64 МБ. Разбираемся
Утилита может и запуститься, и успешно отработать. Но по этим двум числам однозначного ответа нет.
На собеседовании надо начать с уточнений:
— 32 МБ — это значение
— 64 МБ утилита запрашивает у ОС или действительно использует для своих данных?
— Есть ли swap и сколько в нём свободного места?
— Есть ли ограничения памяти у процесса или контейнера?
Допустим, открываем
Linux использует оперативку в том числе под файловый кэш. Часть этой памяти ядро может освободить для приложения. Поэтому маленькое значение
Для первой оценки смотрим на
1. Запуститься утилита может, даже если доступной памяти меньше 64 МБ.
Ей необязательно занимать все 64 МБ RAM сразу после старта.
Например, программа запросила через malloc буфер на 64 МБ, но записала данные только в небольшую его часть. Физические страницы под остальную часть могут выделяться позже, по мере записи.
Или есть overcommit: политика, при которой Linux может разрешать запросы памяти, даже если обеспечить все такие запросы одновременно не получится.
Это разные механизмы. Ленивое выделение позволяет предоставлять физические страницы по мере необходимости. Политика overcommit определяет, какие обязательства по памяти ядро разрешает принимать.
Но запуск сам по себе не гарантирован, потому что память нужна уже при старте, а её выделение могут ограничивать настройки системы и лимиты процесса.
Отказать могут и при запросе буфера: например,
2. Успешный запуск и успешный запрос памяти ещё не гарантируют дальнейшую работу.
Предположим, запрос прошёл, утилита начала заполнять буфер. Теперь для данных нужны реальные физические страницы.
Если ядро сможет освободить достаточно памяти, например за счёт кэша, утилита продолжит работу.
Если есть доступный и разрешённый для процесса
Дальше важен характер нагрузки. Если вытеснили редко используемые данные, влияние на скорость может быть небольшим. Если приходится постоянно возвращать страницы из
Если получить достаточно памяти не удаётся, возможен OOM. Ядро может завершить процесс, чтобы освободить память. При общесистемном OOM жертвой необязательно станет наша утилита.
Уже завершившийся успешный вызов
Отдельно проверяем лимиты контейнера или сервиса. Процесс может упереться в ограничение своей cgroup, даже когда на хосте ещё есть свободная RAM.
Если же условие строгое, то утилите нужны дополнительные 64 МБ одновременно в RAM, предоставить можно только 32 МБ и освободить больше нечего, значит выполнить это требование она не сможет. Overcommit дополнительную оперативку не создаёт.
Что проверить командами:
—
—
—
—
—
—
Для процесса дополнительно смотрим
Утилита может и запуститься, и успешно отработать. Но по этим двум числам однозначного ответа нет.
На собеседовании надо начать с уточнений:
— 32 МБ — это значение
free или available?— 64 МБ утилита запрашивает у ОС или действительно использует для своих данных?
— Есть ли swap и сколько в нём свободного места?
— Есть ли ограничения памяти у процесса или контейнера?
Допустим, открываем
free -m, а там: free — 32 МиБ, available — 300 МиБ.Linux использует оперативку в том числе под файловый кэш. Часть этой памяти ядро может освободить для приложения. Поэтому маленькое значение
free само по себе ещё не говорит о нехватке памяти.Для первой оценки смотрим на
available: сколько памяти предположительно доступно приложениям без подкачки.1. Запуститься утилита может, даже если доступной памяти меньше 64 МБ.
Ей необязательно занимать все 64 МБ RAM сразу после старта.
Например, программа запросила через malloc буфер на 64 МБ, но записала данные только в небольшую его часть. Физические страницы под остальную часть могут выделяться позже, по мере записи.
Или есть overcommit: политика, при которой Linux может разрешать запросы памяти, даже если обеспечить все такие запросы одновременно не получится.
Это разные механизмы. Ленивое выделение позволяет предоставлять физические страницы по мере необходимости. Политика overcommit определяет, какие обязательства по памяти ядро разрешает принимать.
Но запуск сам по себе не гарантирован, потому что память нужна уже при старте, а её выделение могут ограничивать настройки системы и лимиты процесса.
Отказать могут и при запросе буфера: например,
malloc вернёт NULL с ошибкой ENOMEM. Дальше всё зависит от программы: она может обработать отказ, сократить объём работы или завершиться.2. Успешный запуск и успешный запрос памяти ещё не гарантируют дальнейшую работу.
Предположим, запрос прошёл, утилита начала заполнять буфер. Теперь для данных нужны реальные физические страницы.
Если ядро сможет освободить достаточно памяти, например за счёт кэша, утилита продолжит работу.
Если есть доступный и разрешённый для процесса
swap, часть страниц можно вытеснить туда и освободить RAM. Причём вытесняться могут страницы других процессов.Дальше важен характер нагрузки. Если вытеснили редко используемые данные, влияние на скорость может быть небольшим. Если приходится постоянно возвращать страницы из
swap и вытеснять другие, производительность может сильно упасть.Если получить достаточно памяти не удаётся, возможен OOM. Ядро может завершить процесс, чтобы освободить память. При общесистемном OOM жертвой необязательно станет наша утилита.
Уже завершившийся успешный вызов
malloc задним числом ошибку не вернёт, так как нехватка памяти при заполнении буфера — это уже другой этап.Отдельно проверяем лимиты контейнера или сервиса. Процесс может упереться в ограничение своей cgroup, даже когда на хосте ещё есть свободная RAM.
Если же условие строгое, то утилите нужны дополнительные 64 МБ одновременно в RAM, предоставить можно только 32 МБ и освободить больше нечего, значит выполнить это требование она не сможет. Overcommit дополнительную оперативку не создаёт.
Что проверить командами:
—
free -m — значения free, available и состояние swap. Вывод здесь в МиБ.—
swapon --show — какие области swap подключены и насколько заняты.—
sysctl vm.overcommit_memory — политику overcommit.—
ps -o pid,vsz,rss,comm -p PID — виртуальную память процесса и объём, находящийся в RAM. VSZ и RSS здесь выводятся в КиБ.—
vmstat -y 1 — текущую активность подкачки в колонках si и so.—
journalctl -k -b — сообщения ядра, в том числе об OOM.Для процесса дополнительно смотрим
/proc/PID/limits, для контейнера или сервиса — ограничения его cgroup.❤90🔥51👍19🙏8💯7
Сегодня у нас важная тема: как защитить сервер
Если вы прямо сейчас поднимете новый сервакс публичным IP-адресом, то буквально через несколько минут увидите в логах десятки попыток зайти под root, admin, test и другими пользователями.
Все из-за того, что интернет постоянно сканируют боты для своих корыстных целей.
Посмотреть, кто стучится к вам, можно так:
И если вход по паролю у вас ещё включён, рано или поздно кто-нибудь из них пароль подберёт.
В ролике разобрали, что закрыть, чтобы бот не ломился, и как заметить и разобрать взлом, если он всё-таки случился
📱 Смотреть: https://youtu.be/SF6e_aYOGRE
Если вы прямо сейчас поднимете новый сервакс публичным IP-адресом, то буквально через несколько минут увидите в логах десятки попыток зайти под root, admin, test и другими пользователями.
Все из-за того, что интернет постоянно сканируют боты для своих корыстных целей.
Посмотреть, кто стучится к вам, можно так:
journalctl -u ssh | grep "Failed password"И если вход по паролю у вас ещё включён, рано или поздно кто-нибудь из них пароль подберёт.
В ролике разобрали, что закрыть, чтобы бот не ломился, и как заметить и разобрать взлом, если он всё-таки случился
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
КАК ЗАЩИТИТЬ LINUX
Бесплатный первый шаг по Linux с практикой: https://prostodevops.ru/l/yt-zashchita-linux
Анонс новых модулей в Telegram: https://t.me/devops_prosto
DevOps буткемп: https://prostodevops.ru/l/yt-zashchita-butkemp
Как защитить Linux-сервер за 10 шагов: что…
Анонс новых модулей в Telegram: https://t.me/devops_prosto
DevOps буткемп: https://prostodevops.ru/l/yt-zashchita-butkemp
Как защитить Linux-сервер за 10 шагов: что…
❤74🔥59👍9🏆9🤝4
Что самое сложное в изучении чего-либо?
Кто-то может сказать, что это поиск структуры, или, пользуясь привычными терминами - учебной программы, то есть: что именно учить, насколько глубоко погружаться, в каком порядке переходить от темы к теме. И это действительно может вызывать трудности, но, скажем прямо, в современном мире найти более-менее нормальный роадмап несложно. Просто часто мы пытаемся найти какой-то «идеальный» вариант, который будет самым-самым лучшим, только вот заранее мы все равно никак это не поймем, а на старте главное - просто начать.
Мы - канал про DevOps, у нас есть роадмап изучения девопса, который мы выстроили на основе реальных запросов рынка, а также тех задач, с которыми девопсы каждый день сталкиваются на работе. Он лежит вот здесь абсолютно бесплатно, и если вы его ещё не видели - пользуйтесь. Кстати, к концу года мы выпустим уже третье обновление, максимально актуализировав его по последним трендам.
Окей, структуру найти можно, но остаётся другой вопрос: как глубоко копать и, самое главное, где взять практику? С глубиной всё сложнее, потому что источников огромное количество, все говорят по-разному, а если пытаться собрать всё сказанное воедино, то получается, что каждый инструмент нужно чуть ли не по винтикам разбирать, прежде чем переходить к следующему. И сколько тогда уйдёт на весь путь - год, два, больше?
С практикой сейчас в каком-то смысле проще: в конце концов, можно попросить нейронку придумывать задания и проверять реализации, но такой формат закрывает далеко не всё.
Здесь у нас тоже есть свое решение. Если вы нацелились на девопс, хотите всё знать и уметь, а во время изучения не волноваться постоянно о том, что, может, чего-то не хватает, или, наоборот, «а не лишнее ли это, не зря ли я трачу время на эту тему», то вам подойдёт наш буткемп, о котором мы часто рассказываем в канале, а подробнее узнать о нём можно тут.
Но это ещё не всё. За последние три недели мы провели какое-то невероятное количество созвонов с теми, кто подавал заявки на сопровождение, кто купил буткемп, кто не купил буткемп, кто раздумывал, как ему двигаться в девопсе. В общем, всё это были люди, которые хотят развиваться в этом направлении.
И они раз за разом озвучивали одну и ту же проблему: в изучении чего-либо самое сложное - не забить. А забить можно по разным причинам: не понимаешь, достаточно ли качественно изучил тему, не хватает взгляда со стороны, а главное - тебя никто не контролирует и не подталкивает, а значит, в момент трудности или банальной лени возрастает риск всё бросить.
Хотя решение простое: нужен человек, который проверит, подскажет, объяснит и не даст забить. Поэтому мы сделали буткемп с куратором. Он пока закрыт, но запись откроется уже на этой неделе и продлится 3-4 дня, а следующий набор будет примерно через месяц. Те, кто уже купил буткемп, смогут апгрейднуться до кураторского формата. В любом случае всё подробно напишем в день старта здесь же, в канале.
Поэтому если вы чему-то учитесь, не важно чему, но сталкиваетесь с какими-то трудностями - постарайтесь понять, чего именно вам не хватает, для каждого причина своя: в этом посте мы перечислили как минимум 3. А когда причина ясна, то становится ясно и то, как от нее избавиться.
Вообще готовим очень много интересных активностей и материалов: ближайшие 3 месяца обещают быть насыщенными.
🖤 Всем хорошего вечера, всем лучших результатов!
Кто-то может сказать, что это поиск структуры, или, пользуясь привычными терминами - учебной программы, то есть: что именно учить, насколько глубоко погружаться, в каком порядке переходить от темы к теме. И это действительно может вызывать трудности, но, скажем прямо, в современном мире найти более-менее нормальный роадмап несложно. Просто часто мы пытаемся найти какой-то «идеальный» вариант, который будет самым-самым лучшим, только вот заранее мы все равно никак это не поймем, а на старте главное - просто начать.
Мы - канал про DevOps, у нас есть роадмап изучения девопса, который мы выстроили на основе реальных запросов рынка, а также тех задач, с которыми девопсы каждый день сталкиваются на работе. Он лежит вот здесь абсолютно бесплатно, и если вы его ещё не видели - пользуйтесь. Кстати, к концу года мы выпустим уже третье обновление, максимально актуализировав его по последним трендам.
Окей, структуру найти можно, но остаётся другой вопрос: как глубоко копать и, самое главное, где взять практику? С глубиной всё сложнее, потому что источников огромное количество, все говорят по-разному, а если пытаться собрать всё сказанное воедино, то получается, что каждый инструмент нужно чуть ли не по винтикам разбирать, прежде чем переходить к следующему. И сколько тогда уйдёт на весь путь - год, два, больше?
С практикой сейчас в каком-то смысле проще: в конце концов, можно попросить нейронку придумывать задания и проверять реализации, но такой формат закрывает далеко не всё.
Здесь у нас тоже есть свое решение. Если вы нацелились на девопс, хотите всё знать и уметь, а во время изучения не волноваться постоянно о том, что, может, чего-то не хватает, или, наоборот, «а не лишнее ли это, не зря ли я трачу время на эту тему», то вам подойдёт наш буткемп, о котором мы часто рассказываем в канале, а подробнее узнать о нём можно тут.
Но это ещё не всё. За последние три недели мы провели какое-то невероятное количество созвонов с теми, кто подавал заявки на сопровождение, кто купил буткемп, кто не купил буткемп, кто раздумывал, как ему двигаться в девопсе. В общем, всё это были люди, которые хотят развиваться в этом направлении.
И они раз за разом озвучивали одну и ту же проблему: в изучении чего-либо самое сложное - не забить. А забить можно по разным причинам: не понимаешь, достаточно ли качественно изучил тему, не хватает взгляда со стороны, а главное - тебя никто не контролирует и не подталкивает, а значит, в момент трудности или банальной лени возрастает риск всё бросить.
Хотя решение простое: нужен человек, который проверит, подскажет, объяснит и не даст забить. Поэтому мы сделали буткемп с куратором. Он пока закрыт, но запись откроется уже на этой неделе и продлится 3-4 дня, а следующий набор будет примерно через месяц. Те, кто уже купил буткемп, смогут апгрейднуться до кураторского формата. В любом случае всё подробно напишем в день старта здесь же, в канале.
Поэтому если вы чему-то учитесь, не важно чему, но сталкиваетесь с какими-то трудностями - постарайтесь понять, чего именно вам не хватает, для каждого причина своя: в этом посте мы перечислили как минимум 3. А когда причина ясна, то становится ясно и то, как от нее избавиться.
Вообще готовим очень много интересных активностей и материалов: ближайшие 3 месяца обещают быть насыщенными.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤81🔥43👍18💯4🤯2
Думаю, многим знакомо: взял курс, за первую неделю прошёл часть, вечерами сидишь, выполняешь задания, учишь теорию, одним словом - получаешь удовольствие от обучения. А потом на работе завал, и вечером хочется просто отдохнуть, потом надо уехать на выходные, и занятия отодвигаются на второй план. И потом просто не хочется возвращаться к обучению - тупо лень. Открываешь материалы через неделю и уже не помнишь, на чём остановился, что прошел, а новое в голову никак не лезет.
Когда учишься сам, никто ни о чем не спросит. Никто не укажет тебе на пробелы в знаниях, потому что их попросту некому оценить. И часто осознание этих пробелов приходит вообще на собесе, когда просят объяснить, как работает то, что ты вроде бы уже проходил.
Поэтому мы выпускаем буткемп с куратором, где им является практикующий девопс, который ведёт вас по буткемпу от начала и до конца. Этот человек станет вашей опорой на ближайшие три месяца прохождения буткемпа, вы сможете задавать ему любые вопросы касательно обучения и проходимых тем, совместно с ним строить план своего обучения, а самое главное - куратор всегда укажет вам на ошибки и не даст лениться.
Что вы получаете в этом потоке?
— Куратор будет доступен вам в течении трех месяцев с момента старта.
— За это время вы успеете пройти 4 пробных собеседования, одно из которых будет в самом начале, чтобы понять ваш уровень знаний сейчас и выстроить план дальнейшего обучения, а дальше такие собесы будут проходить раз в месяц. Причем каждый из них будет разобран куратором, и вы получите полную обратную связь по нему.
— Защита каждой темы будет проходить в созвоне, а в случае неудачи тему всегда можно будет пересдать. Таким образом вы сами будете уверены, что освоили материал.
— Раз в месяц куратор будет сверять ваш прогресс и корректировать план обучения.
— Группа включает до 20 человек, но работа будет вестись с каждым индивидуально.
— В случае каких либо непредвиденных ситуаций вы сможете взять паузу на месяц, при этом она не будет съедать сроки вашего обучения.
— Два раза в неделю у вас будут групповые созвоны, на одном вы будете разбирать сложные технические темы, а второй будет в формате дейлика.
— Доступ к буткемпу при покупке такого формата останется с вами навсегда.
Набор на первый поток начинается сейчас и продлится до 26 октября 18:59 по МСК, потому что в этот день в 19:00 уже будет старт.
Так же, теперь на буткемпе доступны новые модули по логированию и мониторингу!
Там поднимаем сбор метрик и логов, собираем дашборды, настраиваем алерты в Telegram и многое другое, можно заценить бесплатно:
— Начать мониторинг
— Начать логирование
Новые модули уже доступны в буткемпе, независимо от формата.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥47❤15🤯5🤝3💯2
Знаете, что самое лучшее в создании собственной платформы? — Абсолютная свобода и гибкость в разработке. Вот появилась идея — сделали, выкатили, собрали обратную связь и так по кругу.
Сегодня хотим рассказать, как вы влияете на развитие этой платформы. Думаю, всем очевидно, что основной фокус-группой и самыми активными контрибьюторами в отзывы и пожелания являются участники буткемпа, и вот несколько живых примеров:
1. Когда буткемп только вышел, любую практику в нем можно было пройти только один раз, и некоторые попросили возможность проходить практики заново. На следующий день такая возможность появилась у всех. Позже уже другие ребята сказали, что было круто видеть историю собственных решений. Так появилась страница «как я решил», где можно посмотреть свои прошлые решения, все команды и сравнить с последней попыткой.
2. Один человек просто рассказал в общем чате, что ему было неудобно каждый раз тянуться мышью к кнопке «Проверить» в практике с терминалом, и он навайбкодил себе скрипт, который жмёт эту кнопку при сочетании клавиш
Самое интересное, что у нас было предусмотрено именно это сочетание клавиш, именно для проверки, но терминал отправлял его в консоль обычным Enter. Теперь каждый может нажать
3. Созвоны по обратной связи. Мы время от времени собираем большой созвон с участниками и разгоняем, что хотелось бы добавить или доработать, так например на первом созвоне попросили возможность пропускать обязательные задания после сообщения о баге или нескольких неудачных попыток.
Раньше было так, что если задание не принимается, а оно обязательное - нужно было ждать исправления (если баг), или биться с ней до победного (если просто не получается решить). Теперь, после сообщения о баге или нескольких неудачных попытках, задание можно отложить: оно остаётся в отдельном списке, можно продолжить работу с другими материалами, а потом вернуться к нему.
И это только несколько примеров.
Всего с июля у нас вышло больше 30ти таких доработок, а количество багов снизилось в разы, вот для примера: за август на платформе было 255 баг-репортов, за октябрь их почти в 3 раза меньше, и это при том, что количество пользователей с августа выросло в 2 раза.
А еще мы сделали канал с отзывами о буткемпе - тут можете почитать, что говорят реальные люди.
Мы всегда прислушиваемся к обратной связи ребят, для нас это очень важный элемент в развитии проекта.
🖤 Буткемп
Сегодня хотим рассказать, как вы влияете на развитие этой платформы. Думаю, всем очевидно, что основной фокус-группой и самыми активными контрибьюторами в отзывы и пожелания являются участники буткемпа, и вот несколько живых примеров:
1. Когда буткемп только вышел, любую практику в нем можно было пройти только один раз, и некоторые попросили возможность проходить практики заново. На следующий день такая возможность появилась у всех. Позже уже другие ребята сказали, что было круто видеть историю собственных решений. Так появилась страница «как я решил», где можно посмотреть свои прошлые решения, все команды и сравнить с последней попыткой.
2. Один человек просто рассказал в общем чате, что ему было неудобно каждый раз тянуться мышью к кнопке «Проверить» в практике с терминалом, и он навайбкодил себе скрипт, который жмёт эту кнопку при сочетании клавиш
Ctrl + Enter и возвращает фокус на терминал.Самое интересное, что у нас было предусмотрено именно это сочетание клавиш, именно для проверки, но терминал отправлял его в консоль обычным Enter. Теперь каждый может нажать
Ctrl + Enter, и если задание еще не засчитано — выполнится проверка, а если засчитано — откроется следующее. При этом фокус у вас остается на терминале, и не надо отвлекаться на клики мышкой.3. Созвоны по обратной связи. Мы время от времени собираем большой созвон с участниками и разгоняем, что хотелось бы добавить или доработать, так например на первом созвоне попросили возможность пропускать обязательные задания после сообщения о баге или нескольких неудачных попыток.
Раньше было так, что если задание не принимается, а оно обязательное - нужно было ждать исправления (если баг), или биться с ней до победного (если просто не получается решить). Теперь, после сообщения о баге или нескольких неудачных попытках, задание можно отложить: оно остаётся в отдельном списке, можно продолжить работу с другими материалами, а потом вернуться к нему.
И это только несколько примеров.
Всего с июля у нас вышло больше 30ти таких доработок, а количество багов снизилось в разы, вот для примера: за август на платформе было 255 баг-репортов, за октябрь их почти в 3 раза меньше, и это при том, что количество пользователей с августа выросло в 2 раза.
А еще мы сделали канал с отзывами о буткемпе - тут можете почитать, что говорят реальные люди.
Мы всегда прислушиваемся к обратной связи ребят, для нас это очень важный элемент в развитии проекта.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥60❤18👏9💯3🤯2
Какие редфлаги в резюме девопса?
Как выглядит резюме для HR? - Кучка непонятных названий, которые мы активно где-то использовали. Поэтому HR читают его наискосок. Пробегают по тексту, выделяют для себя нужные паттерны и принимают решение за пару минут, а то и быстрее, звать ли кандидата или нет. Техлиды в резюме вчитываются чаще, но это не значит, что так делают все. Некоторые вообще даже не открывают резюме, а кто то так же, как и hr, читают их наискосок.
Поэтому очень важно, чтобы даже при невнимательном прочтении резюме могло заинтересовать, а для этого нужно избегать ошибок:
Большой список технологий в начале
Docker, Kubernetes, Terraform, Ansible, Prometheus, Grafana, Jenkins, GitLab CI и ещё десяток названий через запятую.
Этот список может действительно соответствовать твоему стеку и ты правда можешь работать с 15 технологиями одновременно, но для hr или лида это выглядит будто человек просто написал полотно технологий из того, что нагуглил за 3 минуты.
Такого в резюме быть не должно.
Технологии, с которыми ты работаешь должны быть описаны в рамках реальных кейсов, а не просто списком по порядку. Техлид не узнает где именно ты применял ту или иную технологию, если ты явно это не укажешь, а гадать тут никто не будет, ведь резюме не вычитывают, а только лишь смотрят.
Но вот в конце резюме перечислить свой стек можно.
Обязанности из должностной инструкции
«Поддержка инфраструктуры», «участие в настройке CI/CD», «мониторинг серверов».
Такие строчки встречаются в 85% резюме и на них уже никто не обращается внимание. У тебя должно быть написано что именно ты поддерживал в инфраструктуре и с какой технологией работал, когда это все поддерживал. Тут нужна конкретика, нельзя просто писать шаблоны, даже больше скажу: простая задача, но расписанная достаточно подробно, гораздо лучше абстрактной сложной.
Простыня на три страницы
Длинное резюме не всегда хорошо. Казалось бы, если написать большое резюме, будет казаться что у соискателя вагон опыта. Но это не так. Если включать в места работы какую-то учебную деятельность, прохождение практик, то с огромной долей вероятности тебя просто отбросят, потому что будут видеть не реальный рабочий опыт, а какой-то мусор, который человек написал для объема.
При беглом осмотре резюме hr и лид посмотрят на места работы, а если они увидят какой-то курс или лабу, то пропустят их, потому что смотреть там нечего, ведь это не продакшен опыт.
Теперь интерактив:
Делитесь с нами своими резюме, вы выберем несколько штук и завтра их разберем. Все резюме на разборе будут обезличены, а названия компаний будут изменены.
Отправляйте их нашему менеджеру в личку @devmoder.
А теперь крутая новость:
Завтра в 17:00 по МСК проведем ЭФИР, на котором:
1. Расскажем, как выглядит буткемп изнутри и том, что дает куратор
2. Поделимся трендами и тем, что сейчас действительно нужно компаниям, каких девопсов они ищут и как стать именно таким
3. Разберем несколько резюме, которые вы пришлете и дадим советы по ним
4. Поотвечаем на ваши вопросы в конце эфира
Площадку для эфира еще не выбрали, о ней напишем завтра, можете в комментах написать предпочтения.
🖤 Буткемп
Как выглядит резюме для HR? - Кучка непонятных названий, которые мы активно где-то использовали. Поэтому HR читают его наискосок. Пробегают по тексту, выделяют для себя нужные паттерны и принимают решение за пару минут, а то и быстрее, звать ли кандидата или нет. Техлиды в резюме вчитываются чаще, но это не значит, что так делают все. Некоторые вообще даже не открывают резюме, а кто то так же, как и hr, читают их наискосок.
Поэтому очень важно, чтобы даже при невнимательном прочтении резюме могло заинтересовать, а для этого нужно избегать ошибок:
Большой список технологий в начале
Docker, Kubernetes, Terraform, Ansible, Prometheus, Grafana, Jenkins, GitLab CI и ещё десяток названий через запятую.
Этот список может действительно соответствовать твоему стеку и ты правда можешь работать с 15 технологиями одновременно, но для hr или лида это выглядит будто человек просто написал полотно технологий из того, что нагуглил за 3 минуты.
Такого в резюме быть не должно.
Технологии, с которыми ты работаешь должны быть описаны в рамках реальных кейсов, а не просто списком по порядку. Техлид не узнает где именно ты применял ту или иную технологию, если ты явно это не укажешь, а гадать тут никто не будет, ведь резюме не вычитывают, а только лишь смотрят.
Но вот в конце резюме перечислить свой стек можно.
Обязанности из должностной инструкции
«Поддержка инфраструктуры», «участие в настройке CI/CD», «мониторинг серверов».
Такие строчки встречаются в 85% резюме и на них уже никто не обращается внимание. У тебя должно быть написано что именно ты поддерживал в инфраструктуре и с какой технологией работал, когда это все поддерживал. Тут нужна конкретика, нельзя просто писать шаблоны, даже больше скажу: простая задача, но расписанная достаточно подробно, гораздо лучше абстрактной сложной.
Простыня на три страницы
Длинное резюме не всегда хорошо. Казалось бы, если написать большое резюме, будет казаться что у соискателя вагон опыта. Но это не так. Если включать в места работы какую-то учебную деятельность, прохождение практик, то с огромной долей вероятности тебя просто отбросят, потому что будут видеть не реальный рабочий опыт, а какой-то мусор, который человек написал для объема.
При беглом осмотре резюме hr и лид посмотрят на места работы, а если они увидят какой-то курс или лабу, то пропустят их, потому что смотреть там нечего, ведь это не продакшен опыт.
Теперь интерактив:
Делитесь с нами своими резюме, вы выберем несколько штук и завтра их разберем. Все резюме на разборе будут обезличены, а названия компаний будут изменены.
Отправляйте их нашему менеджеру в личку @devmoder.
А теперь крутая новость:
Завтра в 17:00 по МСК проведем ЭФИР, на котором:
1. Расскажем, как выглядит буткемп изнутри и том, что дает куратор
2. Поделимся трендами и тем, что сейчас действительно нужно компаниям, каких девопсов они ищут и как стать именно таким
3. Разберем несколько резюме, которые вы пришлете и дадим советы по ним
4. Поотвечаем на ваши вопросы в конце эфира
Площадку для эфира еще не выбрали, о ней напишем завтра, можете в комментах написать предпочтения.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤57🔥18👍7🎉3🤝2
Просто Devops
Какие редфлаги в резюме девопса? Как выглядит резюме для HR? - Кучка непонятных названий, которые мы активно где-то использовали. Поэтому HR читают его наискосок. Пробегают по тексту, выделяют для себя нужные паттерны и принимают решение за пару минут, а…
Решили его провести в телемосте, ссылку направим ко времени.
Запись будет, загрузим на платформу, сюда продублируем ссылку
Спасибо тем, кто присылал резюме, уже отобрали несколько для разбора.
Увидимся со всеми через 3 часа!
Please open Telegram to view this post
VIEW IN TELEGRAM
🤝34👍22❤10💅4👀1
Последний наш ролик по линуксу стал топ-5 по просмотрам на канале, а раз вам так заходит все, что связано с линуксом...
Сегодня в ролике продолжаем тему прошлого ролика и рассказываем про файрвол, его правила и разновидности, так же разбираем нюансы, связанные с
📱 Смотреть по ссылке
Сегодня в ролике продолжаем тему прошлого ролика и рассказываем про файрвол, его правила и разновидности, так же разбираем нюансы, связанные с
NAT, IPv4 и IPv6Please open Telegram to view this post
VIEW IN TELEGRAM
❤118🔥79🏆10🤝7👀2
Как быстро летит время:
В прошлом октябре начался первый поток сопровода, включавший в себя достаточно разрозненные материалы и скудный набор практик/интерактивов.
А сейчас через сопровождение прошло уже несколько сотен человек, у нас появился маленький адронный коллайдер в виде платформы и буткемп, родившийся как результат опыта всех этих людей, тысячи собеседований и даже сложно представить скольких вложенных сил и эмоций.
Тут кстати есть отзывы.
В прошлом октябре начался первый поток сопровода, включавший в себя достаточно разрозненные материалы и скудный набор практик/интерактивов.
А сейчас через сопровождение прошло уже несколько сотен человек, у нас появился маленький адронный коллайдер в виде платформы и буткемп, родившийся как результат опыта всех этих людей, тысячи собеседований и даже сложно представить скольких вложенных сил и эмоций.
Тут кстати есть отзывы.
🔥34❤9👍8🎉4🤝4
А с какими задачами я буду чаще работать, когда стану девопсом?
Абсолютно на каждом нашем созвоне кто-нибудь задает именно этот вопрос. Вот и сегодня не стало исключением: человек хотел понять, насколько ему подходит буткемп и попросил созвониться, один из главных вопросов звонка - тот, который написан в заголовке.
Давайте дадим ответ здесь.
Для начала, надо понимать, что девопс девопсу рознь, для этого рассмотрим несколько примеров:
Большая компания, продуктовая команда - самый понятный сценарий: есть какой-то продукт, допустим это сервис смс-рассылок, у него есть команда разрабов, которые создают функционал, есть бизнес, который этот функционал запрашивает, а есть команда девопсов, которые должны: обеспечить автоматическое обновление сервиса, мониторинг, чтобы минимизировать инциденты, сбор логов, чтобы если что копаться в них, и обеспечивать развитие и поддержку работоспособности продукта.
Сценарий 2 - Большая компания, платформенная команда: у нас есть не только сервис смсок, но и личный кабинет, сервис аналитики, и еще 25 продуктов для бизнеса, но все это существует в одном контуре, и, согласитесь, что было бы удобнее, если бы оно все разрабатывалось примерно одинаково. Инфраструктура - не исключение, с ней тоже в разы удобнее работать, когда она не отличается (или отличается слабо) от проекта к проекту. Тогда появляется платформенная команда девопсов - они выстраивают инфру для всех продуктов: вот нужен кубер-кластер новому сервису, и продуктовая команда не изобретает его сама, а заказывает у платформенной команды: вот нам надо столько-то нод, прогнозируем такую-то нагрузку, столько дисков и тд, а платформенные ребята собирают это дело и отдают в пользование. Помимо этого, они так же могут заниматься глобальными инфраструктурными задачами компании, например собрать файрволл для всех контуров.
Ну или такой вариант: компания маленькая, команды девопсов нет, сами не понимают че именно нужно - тут девопс будет и разрабом и девопсом и вообще стек у него будет меняться каждую неделю.
На самом деле, мы хорошо это описали во введении в девопс, которое абсолютно бесплатно можно пройти и понять, что это за сфера, и с чем там можно столкнуться.
Кратко: весь стек пригодится в любом случае, просто где-то вы будете 90% работать, например с CI/CD, а где-то крутить куберы и сервера. Проблема только в том, что наверняка вы это узнаете только на собеседовании
Абсолютно на каждом нашем созвоне кто-нибудь задает именно этот вопрос. Вот и сегодня не стало исключением: человек хотел понять, насколько ему подходит буткемп и попросил созвониться, один из главных вопросов звонка - тот, который написан в заголовке.
Давайте дадим ответ здесь.
Для начала, надо понимать, что девопс девопсу рознь, для этого рассмотрим несколько примеров:
Большая компания, продуктовая команда - самый понятный сценарий: есть какой-то продукт, допустим это сервис смс-рассылок, у него есть команда разрабов, которые создают функционал, есть бизнес, который этот функционал запрашивает, а есть команда девопсов, которые должны: обеспечить автоматическое обновление сервиса, мониторинг, чтобы минимизировать инциденты, сбор логов, чтобы если что копаться в них, и обеспечивать развитие и поддержку работоспособности продукта.
Сценарий 2 - Большая компания, платформенная команда: у нас есть не только сервис смсок, но и личный кабинет, сервис аналитики, и еще 25 продуктов для бизнеса, но все это существует в одном контуре, и, согласитесь, что было бы удобнее, если бы оно все разрабатывалось примерно одинаково. Инфраструктура - не исключение, с ней тоже в разы удобнее работать, когда она не отличается (или отличается слабо) от проекта к проекту. Тогда появляется платформенная команда девопсов - они выстраивают инфру для всех продуктов: вот нужен кубер-кластер новому сервису, и продуктовая команда не изобретает его сама, а заказывает у платформенной команды: вот нам надо столько-то нод, прогнозируем такую-то нагрузку, столько дисков и тд, а платформенные ребята собирают это дело и отдают в пользование. Помимо этого, они так же могут заниматься глобальными инфраструктурными задачами компании, например собрать файрволл для всех контуров.
Ну или такой вариант: компания маленькая, команды девопсов нет, сами не понимают че именно нужно - тут девопс будет и разрабом и девопсом и вообще стек у него будет меняться каждую неделю.
На самом деле, мы хорошо это описали во введении в девопс, которое абсолютно бесплатно можно пройти и понять, что это за сфера, и с чем там можно столкнуться.
Кратко: весь стек пригодится в любом случае, просто где-то вы будете 90% работать, например с CI/CD, а где-то крутить куберы и сервера. Проблема только в том, что наверняка вы это узнаете только на собеседовании
🔥45👍18❤9💯4🎉2
Все же в курсе уже про Binance?
Что сказать, вот если бы он прошел наш буткемп, то ничего такого бы не было...
А если серьезно, в интересное время мы живем:
- Сейчас взлом бинанса (вроде как благодаря нейронкам)
- Так же сегодня новость о том, что Claude взломал ядро линукс за 53 минуты
- Буквально недавно тем же клодом заэксплойтили PHP.
Нам это о чем говорит? Нейронки становятся (по сути уже стали) неотъемлемой частью жизни и работы, а те, кто их не использует и не разбирается - уже проигрывают.
Насколько большая это проблема и что будет в будущем? - Никто не знает, ясно одно - если пользуешься нейронками, то шансов быть востребованным и оставаться на плаву больше. В девопсе они помогают ничуть не хуже, чем в той же разработке, а вот заменить девопс-инженера гораздо сложнее, чем разработчика (по крайней мере пока).
Мы поэтому сейчас готовим много материалов по ИИ в девопсе, благо информации и кейсов для этого скопилось огромное количество.
А пока, как сказал один из выпускников сопровождения:
Цифровой рубль 1 — Binance 0
По данным СМИ, злоумышленники проникли во внутренние системы биржи через ноутбук DevOps-инженера Binance и получили возможность проводить несанкционированные транзакции.
Что сказать, вот если бы он прошел наш буткемп, то ничего такого бы не было...
А если серьезно, в интересное время мы живем:
- Сейчас взлом бинанса (вроде как благодаря нейронкам)
- Так же сегодня новость о том, что Claude взломал ядро линукс за 53 минуты
- Буквально недавно тем же клодом заэксплойтили PHP.
Нам это о чем говорит? Нейронки становятся (по сути уже стали) неотъемлемой частью жизни и работы, а те, кто их не использует и не разбирается - уже проигрывают.
Насколько большая это проблема и что будет в будущем? - Никто не знает, ясно одно - если пользуешься нейронками, то шансов быть востребованным и оставаться на плаву больше. В девопсе они помогают ничуть не хуже, чем в той же разработке, а вот заменить девопс-инженера гораздо сложнее, чем разработчика (по крайней мере пока).
Мы поэтому сейчас готовим много материалов по ИИ в девопсе, благо информации и кейсов для этого скопилось огромное количество.
А пока, как сказал один из выпускников сопровождения:
Цифровой рубль 1 — Binance 0
❤131🔥41🤯9👀9🤩5
Пока в других IT-направлениях идут сокращения и происходит отток вакансий, мы продолжаем стабильно трудоустраивать людей в девопс на вилку плюс-минус 300.000 рублей. И делаем это больше года!
Как устроено?
Работаем с техническими вопросами и инфраструктурными задачами: Linux и сети, Nginx и Git, Docker, CI/CD, Ansible, Terraform и Kubernetes. Разбираем работу PostgreSQL и Redis, мониторинг на Prometheus и Grafana, сбор и анализ логов.
Практикующие девопсы обсуждают с вами решения, отвечают на вопросы и дают обратную связь на групповых и индивидуальных созвонах.
Помогаем составить резюме и на собеседованиях, сопровождаем по откликам и разбираем пройденные собесы.
Все желающие могут записаться на созвон, где расскажем о формате и условиях сопровождения, а так же ответим на вопросы.
Удобнее всего это сделать в миниаппке в нашем боте. А если не хотите в боте, то то же самое можно сделать на нашем сайте.
Дополнительно прочитать про сопровод можно здесь.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥37👍11💯5🎉2😍2
Фан-факт: число поисковых запросов vpn/впн за последние 5 лет выросло в 10 раз (интересно почему)
И если раньше это была технология для организации доступа в корпоративные сети, с которой работали сетевики, то теперь все совсем иначе.
Мы решили сделать ролик, в котором ответим на вопрос: "Как работает VPN?"
Разбираем, как он появился и как развивался, какие есть протоколы, и почему это такая важная часть корпоративного мира.
📱 Смотреть на YouTube
И если раньше это была технология для организации доступа в корпоративные сети, с которой работали сетевики, то теперь все совсем иначе.
Мы решили сделать ролик, в котором ответим на вопрос: "Как работает VPN?"
Разбираем, как он появился и как развивался, какие есть протоколы, и почему это такая важная часть корпоративного мира.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥97❤22👍22💯6👀4
«Третий раз подряд попадаю под сокращение. Хочу уже во что-то стабильное».
Это из анкеты, которую нам прислал фронтендерс семью годами опыта. И таких анкет от разработчиков стало в 2 раза больше по сравнению с прошлым набором. (Я давно читал новости, что в разработке сейчас все печально, но сейчас прям своими глазами вижу, насколько). Пишут примерно одно и то же: команду сократили, часть задач отдали нейронкам, а новую работу найти сложнее, чем год, а уже тем более чем пару лет назад. Особенно грустно за тех, кто год учил Go и понял, что вакансий под него нет.
Но есть и вторая большая группа - сисадмины и техподдержка. Они и так работают с Linux, сетью и серверами, кто-то пишет скрипты и работает с Docker. А получают при этом немного, просто потому, что так устроена их должность. И при этом в девопс им перейти чуть ли не проще всех, потому что многое из того, что они уже делали, будет полезно в девопсе. Остается добрать недостающее и правильно упаковать свой опыт.
Узнали себя - приходите на созвон. Расскажем, как за 4 месяца перейти в девопс и апнуться по зарплате.
Запись на созвон: https://prostodevops.ru/l/pro-razrabov
Это из анкеты, которую нам прислал фронтендер
Но есть и вторая большая группа - сисадмины и техподдержка. Они и так работают с Linux, сетью и серверами, кто-то пишет скрипты и работает с Docker. А получают при этом немного, просто потому, что так устроена их должность. И при этом в девопс им перейти чуть ли не проще всех, потому что многое из того, что они уже делали, будет полезно в девопсе. Остается добрать недостающее и правильно упаковать свой опыт.
Узнали себя - приходите на созвон. Расскажем, как за 4 месяца перейти в девопс и апнуться по зарплате.
Запись на созвон: https://prostodevops.ru/l/pro-razrabov
🔥33💯25❤9👏5🎉3
Просто Devops
Важный факт про 8 поток
Это последний поток сопровождения на прежних условиях. Мы приняли решение со следующего потока поднимать итоговую оплату 120% → 130%.
Так что уже через 4 дня сопровод станет дороже.
Запись на поток здесь: https://prostodevops.ru/l/posledniy-potok
Сейчас даже есть 5 минут, чтобы успеть на записаться на созвон в 19:00
Это последний поток сопровождения на прежних условиях. Мы приняли решение со следующего потока поднимать итоговую оплату 120% → 130%.
Так что уже через 4 дня сопровод станет дороже.
Запись на поток здесь: https://prostodevops.ru/l/posledniy-potok
Сейчас даже есть 5 минут, чтобы успеть на записаться на созвон в 19:00
👎58👍28👀10🤝9💅8
Знаете, что чаще всего оказывается самым сложным в понимании, когда люди изучают девопс?
Первая догадка - кубер, потому что он, во-первых, требует уверенного бэкграунда линукса, во-вторых, в нем достаточно замороченные сети, в третьих там огромное количество конфигов, параметров и возможностей. Но сам по себе он остается конкретным инструментом для асболютно ясной задачи: обеспечить отказоустойчивую и масштабируемую работу сервисов, так еще и с возможностью бесшовного обновления этих сервисов.
Так еще и изучать вы его начинаете, когда уже имеете хорошую базу по вещам, перечисленным выше.
А сложнее всего дается CI/CD. Почему? Да как минимум потому что вариантов его реализаций огромное количество, хотя есть стандартные подходы, типа gitflow или gitlab flow. Но при этом в каждом проекте к этим стандартным подходам прикручивают свои условия, добавляют разные окружения, а эти разные окружения нужны для разных этапов, при этом этапы наступают по условиям и так можно продолжать бесконечно.
Начинает кипеть мозг, но главное здесь - идти по порядку:
Для чего вообще нужен CI/CD процесс?
Чтобы максимально автоматизировать процесс выкатки новых фич из локальной разработки в прод.
Какой CI/CD считается хорошим?
Тот, который не дает возможности (или снижает до минимума) выкатывать багованый код. Плюс задает четкую структуру того, как ведется разработка.
И дальше уже в зависимости от:
- сложности проекта
- размера инфраструктуры
- количества сервисов
- языка
- требований к безопасности
- требований к доступности
- требований к скорости релизов
и на самом деле любых специфичных требований проекта - обрастает дополнительными сущностями, этапами и усложнениями.
В целом CI/CD может выглядеть как build -> deploy (и для маленького проекта на старте это будет лучший выбор), так и как адронный коллайдер из разных условий, шаблонов, библиотек и стендов, если того требует проект.
При этом начинается все с малого, кстати хорошо разобрали эту тему в ролике про инфраструктуру
А дополнительно почитать и углубиться в CI/CD можно здесь
Первая догадка - кубер, потому что он, во-первых, требует уверенного бэкграунда линукса, во-вторых, в нем достаточно замороченные сети, в третьих там огромное количество конфигов, параметров и возможностей. Но сам по себе он остается конкретным инструментом для асболютно ясной задачи: обеспечить отказоустойчивую и масштабируемую работу сервисов, так еще и с возможностью бесшовного обновления этих сервисов.
Так еще и изучать вы его начинаете, когда уже имеете хорошую базу по вещам, перечисленным выше.
А сложнее всего дается CI/CD. Почему? Да как минимум потому что вариантов его реализаций огромное количество, хотя есть стандартные подходы, типа gitflow или gitlab flow. Но при этом в каждом проекте к этим стандартным подходам прикручивают свои условия, добавляют разные окружения, а эти разные окружения нужны для разных этапов, при этом этапы наступают по условиям и так можно продолжать бесконечно.
Начинает кипеть мозг, но главное здесь - идти по порядку:
Для чего вообще нужен CI/CD процесс?
Чтобы максимально автоматизировать процесс выкатки новых фич из локальной разработки в прод.
Какой CI/CD считается хорошим?
Тот, который не дает возможности (или снижает до минимума) выкатывать багованый код. Плюс задает четкую структуру того, как ведется разработка.
И дальше уже в зависимости от:
- сложности проекта
- размера инфраструктуры
- количества сервисов
- языка
- требований к безопасности
- требований к доступности
- требований к скорости релизов
и на самом деле любых специфичных требований проекта - обрастает дополнительными сущностями, этапами и усложнениями.
В целом CI/CD может выглядеть как build -> deploy (и для маленького проекта на старте это будет лучший выбор), так и как адронный коллайдер из разных условий, шаблонов, библиотек и стендов, если того требует проект.
При этом начинается все с малого, кстати хорошо разобрали эту тему в ролике про инфраструктуру
А дополнительно почитать и углубиться в CI/CD можно здесь
👍58🔥26❤18💯12🤝4
Зачем нужен Git?
Мы можем уверенно сказать, что это один из основных инструментов любого разработчика, тут все логично: надо вести разработку, комитить изменения и так далее.
Но ведь девопс не пишет код, а значит ему Git не нужен, получается так? На самом деле нет, потому что девопс просто находится с другой стороны гита, если можно так сказать)
Потому что на основе именно этого инструмента выстраивается CI/CD, а это уже ключевая задача девопса.
Именно об этом наш сегодняшний ролик:
- что такое Git
- как он участвует в CI/CD
- и как его учить
📱 Смотреть на YouTube
Мы можем уверенно сказать, что это один из основных инструментов любого разработчика, тут все логично: надо вести разработку, комитить изменения и так далее.
Но ведь девопс не пишет код, а значит ему Git не нужен, получается так? На самом деле нет, потому что девопс просто находится с другой стороны гита, если можно так сказать)
Потому что на основе именно этого инструмента выстраивается CI/CD, а это уже ключевая задача девопса.
Именно об этом наш сегодняшний ролик:
- что такое Git
- как он участвует в CI/CD
- и как его учить
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥68❤21🤩11💯5👀3