Devops Bootcamp с Федосеевым

Привет! На связи Аниса 🤓

— Расскажите о себе, — топ-1 вопрос, недооцененный по сложности 🙅‍♂️

Начинаем говорить и понимаем: рассказ путается, цифры забылись, иными словами — мысль растекается по древу. Как итог — впечатление не то, в голове сумбур, а внутри ощущение, что могло быть и лучше.

Всё так! И правда, могло бы!)

Причина в том, что сильные примеры из практики требуют подготовки. Их сложно просто вспомнить, особенно про стрессе на интервью. Их нужно собрать.
Что это дает?


😎 Конкретика вместо общих фраз.

Вместо «у меня есть опыт управления проектами» можно сказать: «Когда в проекте X возникла проблема Y, я сделал(а) A, B и C. В итоге получилось сделать Q, что дало результат N».
Готовый шаблончик!

😉 Спокойствие и структура

Когда в голове есть четкие схемы для ответа, нервов меньше. Мы управляем разговором, а не пытаемся безуспешно на ходу составить связный текст.

😏 Мы показываем свой способ мыслить

Через то, как мы описываем ситуацию, виден наш подход: уходим ли мы в детали, можем ли выделить главное, умеем ли связать действие с результатом. Это правда важно, на это всегда обращается больше внимание!

Риски, если «забить» на подготовку описания опыта:

🚩 Наш опыт останется абстрактным. Мы много раз произнесем «у меня есть опыт, правда!», но не сможем его продемонстрировать.

🚩 Потеря возможности выделиться. Другой кандидат с такими же обязанностями в резюме, но с четкими историями, будет выглядеть убедительнее.

#карьера@devopsupgrade

Коллеги, всем привет!
У нас на курсе DevOps Upgrade студенты закончили тему про мониторинг 🔥

Интересно проверить и ваши знания, поэтому, вопрос из мониторинга ниже ⬇

Приветы! На связи Аниса 🤓

Продолжаю череду постов об увольнении — уж очень эта тема соблазнительная и порой коварная, брр!

Сегодня о том, чего и врагу не пожелаешь: об увольнении друга из компании, с кем вместе работали. Точнее даже так:

Как не уволиться «за компанию», если уволился друг?

Когда из компании уходит ✨друг✨, с которым вы вместе проживали и приятные, и не очень моменты — всё вокруг становится хуже: и митинги ещё тупее, шутки несмешные, а мысль «может, и я уже пойду?» мелькает чаще обычного.
И всё это может быть не про работу, а про лишение привычной надежной опоры (и это тоже непросто).

Карьерные шаги нужно делать всегда обдуманно и аккуратно. Выдыхаем и рассуждаем, что может обезопасить от поспешных решений:

• Никаких решений на 1 месяц

За это время тоска постепенно сходит на нет, уступая место рабочим задачам. Если спустя месяц желания работать дальше нет — уже можно думать (пока только думать!) о смене компании.

• Друг ≠ работа

Пишу этот пункт немного через силу, так как сама очень привязываюсь к команде. Команда/человек — это вполне себе фактор удержания сотрудника. Однако, это ни в коем случае не должно быть фактором увольнения. Каждый из нас живет свою жизнь, а существование настоящей дружбы не зависит от совместной работы.
Важно отделить, что конкретно поменялось с уходом друга — вполне возможно, что список будет небольшим или даже не наберется.

• Открытие в себе новой роли

Когда уходит друг, пропадает привычная модель общения, пусть и внутри работы: кто-то из нас брал инициативу, кто-то чаще исполнял, кто-то разряжал обстановку. И кажется, что вместе с человеком ушла часть нашей силы.
Но! Это также может освобождаться пространство, которое мы раньше не занимали. Новые навыки, модели поведения, новые роли. И постепенно начинается самопроявление: начинаешь чаще говорить на встречах, брать инициативу, выстраивать контакты, жёстче защищать границы — классно же)

Если же уход 🐁друганчика🐁 лишил последнего, что удерживало оставаться в компании — это уже другое дело, тут можно постепенно готовиться и к своему уходу. А если запутались — я тут, приходите консультироваться + распутываться)

А если хочется порассуждать на тему дружбы на работе — пишите в комментариях. Такое мы любим!

#карьера@devopsupgrade

Коллеги, привет!

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

Кстати, почему после длинных праздников всегда так много дел? Мне кажется, все из-за того, что в праздники не хочется много работать, и задачи просто копятся. И вот, будние наступают, и все алерты с низким приоритетом догоняют разом. Думаю, каждый столкнулся с подобным в начале года.

Из более приятного и интересного, Яндекс запустили сертификацию. Формат для нашего сегмента довольно новый, по крайней мере я раньше такого не встречал. Было действительно интересно поучаствовать 🔥

⏩Делитесь, что у вас что накопилось из категории давайте уже после Нового года?

Коллеги, приветствую 👋🏻
На прошлой неделе здесь была задача про DevSecOps‑подход и падающие чекеры. Обсудим ее.

Варианты ответов были следующие:
❌Отключать все security-чекеры.
Неверно, этот вариант ломает саму идею и риски бизнеса растут.

❌Блокировать релизы при падении пайплайна.
Выглядит проще всего, но можно блокировать разработку и вообще потерять доверие.

❌Скрывать отчеты.
Не подойдет, потому что безопасноть должна быть видна разработчикам.

✅Отправлять все срабатывания в бэклог и брать в работу только critical.
Это правильный ответ. Но есть ряд важных уточнений и дополнительных шагов, которые многим из вас могут показаться очевидными (и это круто).

⏩Как выглядит корректный DevSecOps-подход
1. Ввести базовый baseline и не блокировать по старым проблемам
• Фиксируем текущее состояние: все существующие SAST/SCA-находки объявляем baseline
• Пайплайн не должен падать из-за уже известных старых уязвимостей
• Новые проблемы, появившиеся в конкретном PR или коммите, — вот их уже можно блокировать или жёстко контролировать

2. Приоритизировать по критичности и риску
Всё найденное уходит в бэклог, но работа ведётся по severity:
• Critical / High — обязательны к исправлению в разумные сроки (SLA)
• Medium / Low — либо откладываются, либо помечаются как неактуальные / ложные срабатывания

3. Уменьшать шум и ложные срабатывания
• Правила и сигнатуры SAST/SCA должны быть настроены так, чтобы реже цеплять несущественные находки
• Часть правил имеет смысл перевести в режим информирования, а не фейла

4. Ужесточать политики постепенно
• Сначала пайплайн падает только по критическим уязвимостям
• Потом добавляются high
• И только после расчистки старой базы — важные средние

DevSecOps — это не про «сломать разработку ради безопасности», а про управляемые риски и эволюцию процессов, которые команды реально готовы поддерживать 📌

Привет! На связи Аниса 🤓

Тут мы определяли, хотим ли уволиться, или это постпраздничный мираж.

Допустим, всё, баста. Увольняемся!

Не секрет, что на it-рынке сейчас неспокойно: специалистов много, ИИ-фильтры всех достали, а зарплаты на многих позициях перестали расти, как это было в ковидные времена (а ведь прошло уже как 6 лет...👨‍🦳)


Как подготовиться к увольнению?


• Формируем финансовую базу

Формула такова: ежемесячные обязательные расходы умножить на 3-5 месяцев — да, именно столько в среднем сейчас занимает активный поиск работы, чтобы дождаться наиболее приятного оффера.
Пугаю, но лучше так, чем ожидать смены работы за пару недель.

• Утром оффер — вечером увольнение

Уходить в никуда — big nononono. Уходить в никуда с финансовой подушкой — сомнительно, ну ок.
Однако, я бы не стала, если на работе всё в рамках разумности.
Отличный вариант — собеседуемся, получаем оффер, уходим.

• Освежаем резюме + linkedIn и только после этого начинаем откликаться

У рекрутеров в компаниях есть база резюме. Бывают системы, которые автоматически добавляют резюме в базу из откликов на красном работном сайте. Будет не очень круто, если ваше черновое резюме, с которого были сделаны отклики в формате «а вдруг возьмут, прикольная вакансия», сохранится в базе или получит отказ.
Лучше сначала привести резюме в порядок и только после этого начинать откликательную деятельность 🤓

• Рабочие задачи — всё ещё важны

Да, душой и кошельком, возможно, мы уже в другом месте пьём джюс. 🍻
Однако финальные месяцы на работе не менее важны, чем предыдущие.
Главное — сохранить прекрасные отношения с коллегами, руководителями, а также показать себя в задачах. Вспомним, как на концертах всегда выбирают лучших артистов на начало и на конец — так работает память, не иначе)

• Прощаемся красиво

Как много в этом слове... Не каждый поймет, далеко не каждый сможет!
Статусы проектов, уточнения, ответственные лица, контакты, инструкции «что делать, если…».
Уважительное отношение к работе (даже если всё достало, понимаю) вернется в виде положительных рекомендаций

• Уходя — уходи

Мой личный пункт, на котором хочу акцентировать внимание. Повышения з/п (размер повышения без изменения должности внутри компании не будет сильно ощутим из-за специфики штатного расписания, 1.5х от з/п внутри роли ожидать не стоит), обещания об изменениях в процессах или изменении роли без дедлайна — лишь отложат ваш поиск, а могут даже добавить чувства долга перед руководителем.
Это ни к чему.

Всё точно будет хорошо. Да, сейчас и правда сложнее искать работу, но работа всё равно есть.
Главное — не суетимся, улыбаемся и машем собеседуемся со всеми для прокачки навыка.

Нужна помощь — пишите, консультацию организуем. Всё нестрашно 👏

Кто уже в поиске? Как впечатления от it-рынка сейчас? Поворчать/похвалиться — в комментариях

#карьера@devopsupgrade

Быстрый старт в DevOps 🔥

Самый частый вопрос у тех, кто решил сменить сферу: С чего вообще начинать? Если коротко: не с инструментов, большинство именно так и делает, а потом теряется.

На мой взгляд, хорошее решение вопроса — бесплатный курс «Быстрый старт в DevOps» от Слерма.

🔴Внутри отличное наполнение для тех, кто хочет разобраться, а не учить всё подряд:
· Короткая и понятная выжимка, что такое DevOps на практике, а не в вакансиях
· Какие инструменты действительно базовые, а какие можно не трогать на старте
· Понимание, чем DevOps-инженер реально занимается в компании и подходит ли вам это направление
Курс небольшой и без философии. Посмотрели и сразу поняли, ваше или нет.

⏩Оформляйте курс, пока он открыт. Мы пока добрые, но кто знает, какие изменения нас ждут :)

Три переоцененных инструмента 📌

Хочу поднять тему, которая периодически всплывает в разговорах про best practices. Есть решения, которые принято считать универсальными и почти обязательными. Но на практике они часто оказываются переоценёнными. Разбираемся почему 👇🏼

🔴Ansible: иллюзия простоты
От Ansible зачастую ожидают простой YAML, который решит все проблемы конфигурации. Но на деле можно получить лавину неподдерживаемого YAML, который со временем превращается в инфраструктурные спагетти.

Частые ошибки:
· Писать гигантские плейбуки вместо модульных ролей
· Игнорировать идемпотентность и получают скрипты, которые ломаются при повторном запуске
· Не задумываться о производительности при работе с сотнями нод
· Использовать Jinja2 там, где уже нужен полноценный язык программирования

В действительности Ansible отлично подойдет для конфигурации ОС, ad-hoc задач, деплоя приложений на существующие сервера.

🔴Kubernetes: молоток для всех гвоздей
От него ждут золотой стандарт оркестрации, который автоматически сделает инфраструктуру масштабируемой и отказоустойчивой. На практике, оказывается что Kubernetes имеет высокую сложность эксплуатации, особенно в маленьких командах, где значительная часть времени уходит не на бизнес-логику, а на поддержку.

Частые ошибки:
· Разворачивать production-кластер «для трёх микросервисов»
· Не считать стоимость владения (инженеры, мониторинг, безопасность)
· Не понимать, что Kubernetes — это платформа, а не продукт
· Забывать, что managed-сервисы всё равно требуют экспертизы

Kubernetes правда нужен для хорошо написанных микросервисов, сложной networking-политики, real-time scaling.

🔴ArgoCD: GitOps-комбайн
Многие думают, что в таком случае получат магическую синхронизацию, где Git — единственный источник истины. В реальности же это сложная распределённая система, которую непросто диагностировать и отлаживать.

Частые ошибки:
· Внедрять GitOps до того, как научились делать стабильные пайплайны
· Не понимать reconciliation loop и удивляются «автоматическим» деплоям
· Строить хрупкие цепочки зависимостей между приложениями.

ArgoCD действительно необходим только крупным распределённым командам, где у вас сотни сервисов и динамические окружения.

⏩Мой вывод: проблема не в инструментах, а в ожиданиях и контексте их применения.
Интересно, какие из этих граблей вы уже успели собрать — и какие инструменты, на ваш взгляд, переоценены сегодня?

Коллеги, привет!
Предлагаю начать эту неделю с небольшой задачи из реальной практики DevSecOps.

🔴Условие:
Команда получает негативные результаты SAST/SCA. Пайплайн стал «красным всегда». Релизы начинают тормозиться, а доверие к security-чекерам постепенно падает.

🔴Вопрос:
Какой DevSecOps-подход в такой ситуации выглядит наиболее корректным?

Голосуйте за правильный вариант ниже⬇
И напишите в комментариях, как вы решали похожие ситуации на практике

Привет! На связи Аниса ⚪️

научилась читать ваши мысли, и вот она — первая постпраздничная

Я хочу уволиться... или не хочу?

Возвращение в рабочий (или хотя бы похожий на него) ритм после новогодних праздников — это жестко.
И, самое главное, это ощущение — норм!
Ну, честно, даже самая любимая работа не перебьёт всё великолепие из салатов, подарков, крепкого сна и свободного графика 🥱

А как понять, я реально хочу уволиться или просто стрессую после праздников?

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

Если речь о таких чувствах, то выдыхаем. Это классическое вхождение в ритм: мозг привык накапливать и экономить энергию, поэтому всеми силами сопротивляется — и я понимаю его абсолютно...


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

То в таком случае стоит и правда задуматься о карьерных изменениях, а лучше — постепенно готовиться к ним. Как это сделать — напишу в следующем посте, далеко не уходите

Что поможет восстановиться (мне помогло):

🟢выход из офиса / дома в середине рабочего дня на 15 минут.
Смена картинки быстро возвращает живость и чуть-чуть подзаряжает
🟢в первые 1-3 рабочие недели минимум соцсетей.
Инфошум усиливает усталость, а замедление вне работы поможет плавно вернуться к рабочему темпу без перегрузки
🟢устроить себе ⚪️рабочий комфорт+⚪️ — уютная чашка / удобный блокнот / чистый экран и клавиатура — всё это добавляет организованного вайба для работы. Мелочь, а приятно!

И ещё — многое решает наше восприятие. Согласитесь, ведь круто, что мы умеем работать, зарабатывать, а порой даже и повышать свой доход!) Так что ценим и хвалим себя за такие штуки 👸

А какие способы вернуться к работе после длительного отдыха у вас? Расскажите, будем пробовать!

#карьера@devopsupgrade

Коллеги, привет!

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

Конечно, всё ещё хочется отдыха, надеюсь, что на каникулах получится немного выдохнуть. В работе тоже всё довольно ожидаемо: постепенно догоняют задачи, которые откладывались «на после Нового года».

Зато совсем скоро можно будет переключиться и заниматься важными и интересными задачами, которые запланировал на 2026 год 🔥

Конец года и рабочие итоги 🌟

Коллеги, приветствую!
Давно у нас не было таких кружочков. Ну что сказать, год подходит к концу. Остались уже, наверное, последние дни. Я могу только пожелать всем держаться из последних сил, у кого они еще остались. Скоро мы подойдём к тому моменту, когда закроем все рабочие вопросы и, наконец-то, начнём готовиться к самому празднику.

Из интересного, пожалуй, расскажу только то, что на прошлой неделе я присутствовал на нашей внутренней конференции и наблюдал очень классные доклады. Рад, что коллеги рассказывают такие интересные вещи. Мне кажется, уровень действительно высокий. Очень надеюсь, что мы сможем транслировать эти доклады и вовне. Я, по крайней мере, этого очень жду.

С наступающим! 🔥

Привет! На связи Аниса ✨

Конец 2025 года пришёл… Пришли и они — посты с итогами года и планами на следующий.

Обещаю не душнить количеством прочитанных книг, реализованных проектов, выученных языков и вот этим всем. В 2025 году без геройства 🚪

А потом наступает январь — и наступает момент, когда все эти планы надо начать делать. Первые две недели ещё как-то держимся на мотивации и драйве, а дальше всё сложнее и сложнее сохранять дисциплину. В марте-апреле от неё обычно уже ничего не остаётся, кроме чувства вины. Ну, база.

А что, если попробовать поставить только одну цель?

В чём прикол польза:

• Кратное снижение тревоги «мне нужно успеть всё». И, кстати, кому нужно? Думаем.
• Без чувства вины и стыда перед самим собой.
• Выше шанс результата: один конкретный фокус воспринимается спокойнее и реалистичнее, чем попытка тянуть на себе сразу всё.

Цели спокойно можно добавлять. Но только тогда, когда мы понимаем, что с первой (самой горящей для нас) уже справились.

Цель может быть любой: от «хочу вылечить все зубы» или «записать первое видео про готовку любимой яичницы» до «найти работу с доходом от 400 тысяч». И неизвестно, что больше принесёт профита, знаете ли!)

— А чем отличается постановка сразу нескольких целей от одной цели с последующим добавлением новых?

При регулярном невыполнении целей/обещаний самому себе возникает инфляция доверия к себе. Это когда с каждым новым обещанием внутренней веры в себя становится меньше, а риск не сдержать обещание перед самим собой растёт.
Чтобы укрепить цену своего обещания, нужно хотя бы раз, разочек пройти полный цикл достижения цели:

✨решил — приложил усилия — смог✨

— А как понять, что цели мне вообще нужны? Что это моё желание, а не что-то, навязанное обществом?

Спрашивать себя, например: зачем мне это? Для чего? Нужно? А кому нужно? А для чего мне нужно? Ну, дальше понятно)

В общем, да! Надеюсь, не загрузила перед Новым годом 🤓
Цель у меня в другом — снизить градус важности и тревоги в медиа-пространстве достигаторов перед уютным праздником.

А вообще — с Наступающим, ребята!

И да, не забудьте поделиться в комментариях своим самым главным планом на следующий год — будет классно вдохновиться и узнать друг друга с других сторон

#карьера@devopsupgrade

Всем привет!
Ранее писал о нашем эфире с коллегами, на котором обсуждали самые актуальные темы DevOps.

⏩Понимаю, трансляция была в рабочее время, поэтому для тех, кто не смог присутствовать, прикрепляю запись.
Обязательно посмотрите, получилось интересно и местами жарко 🔥

Обзор Helm 4

Некоторое время назад вышел Helm 4, и хотелось бы про это сказать. Это первый мажорный релиз за последние шесть лет, и он скорее про эволюцию и расчистку накопленного техдолга, чем про явные изменения для пользователей.
Helm 4 стал логичным продолжением Helm 3: архитектура обновлена, но базовая модель осталась прежней.

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

📌 Что принципиально нового
Главное изменение — переход на Server-Side Apply вместо старого 3-Way Merge. Это должно снизить количество конфликтов и ситуаций в духе «всё прошло успешно, но есть нюансы». Есть надежда, что в подобных случаях система будет выдавать более явные и понятные ошибки.

Также обновлён плагинный движок и добавлены некоторые приятные мелочи.

📌 Насколько легко перейти с Helm 3
В целом переход выглядит достаточно простым. Формат чартов и релизов совместим, и подавляющее большинство существующих чартов должно работать без переписывания.

Отдельно стоит обратить внимание на то, что часть флагов CLI была переименована. Старые варианты пока продолжают работать, но это стоит учитывать, особенно если активно используются плагины и автоматизация.

Кто-то уже попробовал? Делитесь, как вам? ⬇️

Коллеги, привет!

Иногда прикольно посмотреть на айтишников не в привычном контексте митингов, дедлайнов и алертов, а в ситуациях, где решают совсем другие навыки. Как раз в таком формате мне недавно довелось поучаствовать.
И сразу спойлер: повезло не всем, и я оказался в их числе.

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

Первый выпуск уже доступен
⏩в VK
⏩на YouTube

Интересно будет услышать ваше мнение: в подобных форматах чаще решает стратегия или всё-таки удача? ⬇