⌨️ Если профессия DevOps умрёт к 2030 году

#AI

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

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

Цель этого поста состоит в том, чтобы успокоить и вас, и себя несколькими аргументами на случай совсем уж печального исхода. Это мои прогнозы и советы общего характера. Вернётесь к ним, если к 2030 году такая профессия, как DevOps, и все смежные с ней профессии перестанут существовать.

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

У нас есть время. Конечно, дата в заголовке выбрана условно: пока даже самые смелые прогнозы адептов нейрозамещения не указывают на более близкие сроки. В мире нет ничего, что нельзя было бы освоить за 4–5 лет на уровне, достаточном для того, чтобы за это платили деньги.

Поскольку большинство из нас претендует занять место именно на отечественном рынке, мы имеем пару скрытых преимуществ. Некоторые ограничения на приобретение технологий и оборудования, а также невероятные успехи в импортозамещении обеспечивают дополнительную фору, которая позволит нам, бросив взгляд через океан или, возможно, на большого красного соседа, сгруппироваться и войти в новую реальность с минимальными потерями. Если совсем страшно, советую получить должность в госсекторе (довольно иронично звучит от меня) . До него прогресс докатывается ещё медленнее и входит обычно куда мягче, чем в сектор коммерческий.

Итак, предсказания сделал, теперь хочу выслушать ваше мнение. Под этим постом разыгрывается подписка Telegram Premium на три месяца. Чтобы принять участие, оставь комментарий, начинающийся с «AI», в течение 24 часов после публикации (+ требуется твоя реакция под постом и подписка на канал). Напиши что-нибудь по теме поста: чем ты собираешься заняться, когда AI подомнёт под себя весь IT-сектор, что останется человеку в эпоху технологической сингулярности или просто как планируешь провести вечер пятницы.

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

На следующей неделе выпущу большой пост про Load Average. Возможно, в нём будет даже то, чего вы не знали. Как минимум за шпаргалку он сойдёт. Кроме того, хочу написать пару постов о том, как AI применяется в DevOps-сфере уже сейчас, об одной перспективной нейросетевой концепции, которая уже меняет, а скоро до неузнаваемости преобразит ландшафт рынка труда, и о профессии (близкой к нашей), которая кажется мне наиболее перспективной в контексте всеобщего нейрозамещения. Формат больших постов-карточек с базовыми технологиями и красочными схемами тоже никуда не уедет. Кстати ставь реакцию если рад возвращению милого маскота HHD.

РОЗЫГРЫШ ЗАВЕРШЁН, РЕЗУЛЬТАТЫ В КОММЕНТАРИЯХ, ВСЕМ БОЛЬШОЕ СПАСИБО (так как желающих было немного по подписке выиграл каждый участник)

Подписывайся на канал DevOps // Human Help

⌨️ Модель жизненного цикла процесса в Linux

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

⌨️  Как они размножаются? fork() / clone() / exec()
⌨️  Родился, потерпел и умер: Жизненный цикл процесса
⌨️  Биография. Вспоминаем и делимся
⌨️  STAT: жди, работай, спи
и прочие по тегу #process_management

Под этим постом разыгрывается подписка Telegram Premium на три месяца. Чтобы принять участие, оставь комментарий, начинающийся с <process>, в течение 24 часов после публикации. Не забудь также поставить реакцию под постом и быть подписанным на канал.

Насколько важны подобного типа знания (в частности о process management) для современного DevOps-инженера? Низкоуровневая теория которая потребуется только на сертификации и собеседовании или база без которой никак? Пишите своё мнение в комментариях.

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

Ну и конечно, пост про Load Average все ещё с меня.

РОЗЫГРЫШ ЗАВЕРШЁН, РЕЗУЛЬТАТ В КОММЕНТАРИЯХ, ВСЕМ БОЛЬШОЕ СПАСИБО

Подписывайся на канал DevOps // Human Help

⌨️ Только хорошие новости 2

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

Настало время итогов и цифр.

Во-первых, нас больше 1000. Это веха, это нужно отметить. Каналу не больше 10 месяцев. Не то чтобы это феноменальные темпы роста, но лично меня они вполне устраивают. А по-настоящему радует статистика:
77% подписчиков читают посты канала
42% читают посты в первые 24 часа после публикации
другие показатели тут.

Во-вторых, вот уже почти полтора года я реализуюсь как ментор и IT-репетитор. Счётчик на моей странице на сайте GetMentor утверждает, что за это время мне удалось пообщаться с более чем 80 замечательными людьми. По этому показателю я нахожусь на 4-м месте из 135 среди всех менторов с тегом DevOps/SRE и также на 4-м месте из 16, где к профессиональному тегу добавляется «Цена: Бесплатно». Кроме того, я являюсь счастливым обладателем более чем 60 отзывов на этой платформе. Можете глянуть, я ими очень горжусь.

Кстати, у каждого из вас есть возможность помочь мне доковылять до бронзы в этом зачёте. У меня действительно есть возможность совершенно безвозмездно (разве что за отзыв) уделить вам час своего времени и ответить (по возможности) на все ваши вопросы, связанные с DevOps-карьерой и обучением.

В-третьих, и это самое важное. Human Help скоро перестанет быть просто Telegram-каналом. Это значит, что в ближайшее время мы зарелизим нечто супер классное. Я говорю «мы», потому что мне повезло, и вокруг моего проекта собралась команда невероятно талантливых ребят. То, что мы вам покажем, возможно, не снесёт вам голову сразу, но станет крепким фундаментом, на котором планируется возвести нечто грандиозное (всё как обычно со стартапами).

Под этим постом разыгрываются подписки Telegram Premium на три месяца. Чтобы принять участие, оставьте комментарий, начинающийся с фразы «Только хорошие новости», в течение 24 часов после публикации (также требуется ваша реакция под постом и подписка на канал). Напишите пожелания удачи нашей команде, выразите поддержку, предложите помощь или сотрудничество. Кроме того, если действительно нужно, запишитесь ко мне на консультацию через GetMentor.

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

РОЗЫГРЫШ ЗАВЕРШЁН, РЕЗУЛЬТАТ В КОММЕНТАРИЯХ, ВСЕМ БОЛЬШОЕ СПАСИБО

Подписывайся на канал DevOps // Human Help

⌨️ Load Average (1/3)

#Linux

Самая важная метрика в мониторинге  на техническом собеседовании

Введение

Попытаюсь кратко порефлексировать на тему, то что за вопросом про LA, среди админов и девопсов закрепилась репутация самого популярного не для кого не секрет.

Репутация заслуженная, но причины почему каждому новому ‘поколению’ сисадминов/девопсов задают один и тот же вопрос уже на протяжении лет 15, если не больше, мне понятны не до конца, возможно дело в универсальности самой метрики, она показывает всё не показывая ничего конкретного. Идеальный триггер для мониторинга, threshold превышен, что-то идет не так - разбирайтесь.

Возможно дело в инерции и самовоспроизводимости партеров, много лет вопросы о LA выполняли роль системы опознавания «свой - чужой» среди админов. Чего стоит лишь дополнительный вопрос:
«В чем измеряется LA?»

Но подобная популярность губительна, этот вопрос разбирался в десятке видео/статей, призванных подготовить зрителя/читателя к тех. собесу. Сейчас эффективность этого вопроса сродни самым известным тюремным загадкам, около-нулевая. Все знают ответ, если не знают, то готовясь к определённым обстоятельствам, стараются узнать его в первую очередь.

Но то, что все знают ответ, не означает, что лично вам его не зададут и тем более не означает, что это знание не поверхностно. LA, то что вы знаете и (возможно) не знали.

Что такое Load Average и как она рассчитывается?

LA - это показатель средней загрузки системы, он отражает количество процессов, конкурирующих за ресурсы системы (в основном CPU) за определённые интервалы времени. Load Average показывает среднее число активных задач, которые либо выполняются, либо готовы к выполнению, либо находятся в ожидании ресурсов I/O.

В Linux ядро обновляет Load Average каждые 5 секунд, вычисляя экспоненциально сглаженное среднее (EWMA, Exponentially Weighted Moving Average) на основе количества задач в очереди исполнения и задач в ожидании I/O.

Load Average в Linux не просто арифметическое среднее за 1, 5 или 15 минут. LA использует EWMA.

Каждое новое измерение нагрузки (раз в 5 секунд ядро считает, сколько процессов в очереди) влияет на итоговый Load Average больше, чем более старые измерения.
Старые значения тоже учитываются, но с каждым новым обновлением их вклад становится всё меньше.

Я не буду приводить формулы расчета, для них мало места, лишь скажу что подобный подход позволяет эффективно убирать влияние пиков на итоговое значение LA. Если нагрузка мимолетна и не подтверждается последующим измерением, то график очень быстро сглаживается, чем дальше тем сильнее потому что вес пика становится всё все меньше. И напротив чем дольше держится нагрузка, тем ближе Load Average к реальному числу процессов в очереди. А когда нагрузка уходит, значение затухает экспоненциально, а не падает сразу.

Небольшое послесловие и стандартный розыгрыш

Я хотел создать классический пост в 10 карточек, но тема как будто бы оказалась слегка объемнее чем я предполагал, да и как передать через инфографику некоторые вещи я просто не додумался. Поэтому чтобы не заставлять вас читать полотно текста решил разделить пост на несколько частей.

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

Под этим постом разыгрывается подписка Telegram Premium на три месяца. Чтобы принять участие, оставь комментарий, начинающийся с «LA», в течение 24 часов после публикации (+ требуется твоя реакция под постом и подписка на канал). Напиши что-нибудь по теме поста: узнал ли ты из него что-то новое, задавали ли тебе вопросы про LA на собесах, ну или что что тебя больше всего раздражает (или наоборот радует) в ТГ каналах/постах посвященных Linux / DevOps (моих или чьих-то еще). Ну и давайте от СЕМИ СЛОВ включая «LA».

РОЗЫГРЫШ ЗАВЕРШЁН, РЕЗУЛЬТАТ В КОММЕНТАРИЯХ, ВСЕМ БОЛЬШОЕ СПАСИБО

Подписывайтесь на канал DevOps // Human Help
Записывайтесь ко мне на консультацию через GetMentor

⌨️ Load Average (2/3)

#Linux

Интерпретация Load Average. Какое значение LA считать нормальным?

LA - величина относительная. Оценивать её надо относительно количества ядер CPU (под ядрами в этом контексте понимают логические процессоры).

Стандартный пример с сервером на 4 ядра:
LA = 4 означает, что в среднем каждое ядро занято обработкой какого-то процесса.
LA = 8, процессы образуют очередь, так как для них недостаточно процессорного времени.
LA = 1 означает, что нагрузка ниже возможностей системы.

Из этого выводится простое правило:
LA ≈ числу ядер → процессорное время утилизировано, но очередей, а значит, задержек, нет.
LA выше числа ядер → CPU не справляется, накапливаются очереди.
LA ниже → ресурсы простаивают.

Кажется, что всё просто, но LA часто фиксирует не только проблемы с CPU, но и с I/O.
Если процесс отрабатывает медленно из-за чтения с медленного диска, это тоже увеличит LA.

Оцените следующие метрики:
- загруженность CPU
- время ожидания I/O
- количество процессов в состоянии D (uninterruptible sleep)

Если LA высокий, но CPU свободен, это, скорее всего, I/O-задержки.
Под этим постом разыгрывается подписка Telegram Premium на три месяца. Чтобы принять участие, оставь комментарий, начинающийся с «LA», а после этого напиши, что, бы ты ответишь, если на собеседовании тебя спросят:
“LA 900 900 900, это ок? Когда мы можем такое увидеть?” (вопрос реальный).
Предложение действительно только в течение 24 часов после публикации (+ требуется твоя реакция под постом и подписка на канал).

Подписывайтесь на канал DevOps // Human Help
Записывайтесь ко мне на консультацию через GetMentor

⌨️ Софт скилы на собеседовании.

#рекрутинг #собеседования

Почему «говорить правду» на собеседовании не всегда рационально (в 95% случаев)?
И почему от тебя, на самом деле, её никто не ждёт?

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

“Почему ты ушёл с предыдущего места работы / решил сменить компанию?”

Что на самом деле хотят услышать? Важно понимать, что люди по ту сторону стола не наивны. Руководитель, тимлид или HR прекрасно понимают, что вы пришли на собеседование не для того, чтобы рассказывать о внутренних конфликтах и своих ошибках/провалах/карьерных неудачах.

Этот вопрос задается не для того, чтобы выслушать ваши исповеди или жалобы. Он нужен для того, чтобы понять, как вы ведете себя под давлением, как формулируете мысли.

Какие причины озвучивать не стоит? После таких признаний ваши шансы на оффер резко падают:

“Конфликт с начальником / командой”
“Результаты моей работы не устроили руководство”
“Не справился с задачей”
“Контроль и отчетность были слишком жесткими”
“Не прошел испытательный срок”

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

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

Как воспринимать вопрос о причине смены работы? Это вопрос не о прошлом, а о том, как ты видишь себя сейчас, в моменте, на этом собеседовании. Твои собеседники оценивают, на самом деле, не содержание твоего ответа, а тон и логику. Логику, которая должна приводить к твоей цели.

А какая цель считается легитимной? Как ответить на вопрос и остаться в рамках делового этикета? Есть множество вещей, на которых можно сфокусировать причину смены работы, для позиции от junior+ до midle это фокус на развитии. Самая безопасная и универсальная. Вы хотите показать, что не бежите от чего-то, а идете к чему-то, к новым задачам, технологиям, зонам ответственности.

Например, можно ответить следующим образом:

“Работая в текущей команде, я многому научился. Теперь хочу применить этот опыт в проекте с более широкими задачами и современным стеком”

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

Под этим постом разыгрывается подписка Telegram Premium на три месяца. Чтобы принять участие, оставь комментарий, начинающийся с «ATQ», а после этого напиши, что ты ответишь, если на собеседовании тебя спросят:

“Почему ты ушел с предыдущего места работы?”

Предложение действительно только в течение 24 часов после публикации (+ требуется твоя реакция под постом и подписка на канал).

Подписывайтесь на канал DevOps // Human Help
Записывайтесь ко мне на консультацию через GetMentor