💻Где работать. Часть первая(аутсорс, аутстаф, финтех)?💻

#базазнаний

Аутсорс

Плюсы:
* Прокачка идет быстро — тебя закидывают на разные проекты, как картошку в кипяток, и ты вынужден учиться на лету, иначе утонешь. Реальный опыт в куче разных областей.
* Стабильная работа — проектов много, так что без дела не сидишь, если только компания не помрет.

Минусы:
* Платят ниже рынка — да, ты работаешь как конь, но ценник как у пони. Компании экономят, продавая твой труд дороже, чем платят тебе.
* Выгоришь — постоянная смена проектов и заказчиков выжимает тебя, как лимон. Мало где успеваешь по-настоящему вникнуть.
* Чужие проекты — не жди, что будешь делать что-то крутое и *свое*. Ты здесь лишь прокладка между заказчиком и кодом.

Аутстафф

Плюсы:
* Зарплата выше — компании вроде как платят больше, потому что арендуют тебя как ресурс. Ну а что, ты ресурс и есть, так что бери бабки, пока дают.
* Иногда хороший проект — если повезет, можно попасть на что-то стоящее, чем можно хвастаться в резюме.

Минусы:
* Много собесов — сначала с компанией-аутстаффером, потом с клиентом. И если не пройдешь одно из интервью — вылетел в трубу.
* Технически "никто" — ты вроде работаешь в компании, но ты не их сотрудник. Даже кружку с логотипом не дадут. Начальник есть, но он твой "арендодатель".

Финтех

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

Минусы
* Бюрократия — та же причина, что и плюс, но в плохом смысле. На каждый чих надо пять подписей и одобрение сверху. Даже за то, чтобы исправить баг, придется пройти круги ада.
* Ответственность — ошибся на пару цифр — и вот тебе многомиллионные убытки.

Практика

💻Как происходит найм?💻

#базазнаний

Окей, давай разберём, как это работает. Представим, ты решился на подвиг — пойти искать работу. Но тут есть подвох — работу-то ты нашёл (например, на том же hh.ru, все его знают), а что дальше? Сейчас расскажу.

HR — твой первый босс

Да-да, это та самая встреча, где тебя будут сканировать на адекватность. Всё начинается со скрининга: разговор ни о чём, где HR решает, стоит ли тратить на тебя ещё чьи-то нервы.

Техсобес: Приготовься к пыткам

Если HR не сбежал после общения с тобой, поздравляю, тебя ждет техсобес! Тут тебя начнут раскручивать на знания, проверять код, заставлять решать задачки, а потом ещё и вопросы не по теме сыпать. Один этап — это просто мечта. Обычно их два, три, а то и больше. Готовься морально.

Тестовое: мини-задание, макси-напряг

Иногда тебе предложат тестовое задание. Это что-то вроде "покажи нам своё мастерство, и мы скажем, верим ли тебе". Хитрый ход, но никуда не деться — сделай хорошо, и шансы увеличатся.

Этап "ждать и страдать"

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

Офер: Дождался офера!

PROFIT! Если ты выжил, тебя не слили и никто не забыл, то получаешь офер. Теперь ты на коне — можешь торговаться, принимать или радоваться первой работе.

Практика

💻Как пройти performance review?💻

#базазнаний

Собери свой чекап

Знаешь, как машины проходят техосмотр? Вот тебе примерно туда же. Возьми свою работу за последние полгода-год и проведи ревизию. Вспомни все проекты, задачи, правки, какие ты там "перетягивал лямку". Ловко вытягивай все, что пошло не так, и трансформируй это в "ценные уроки". Но только не начинай ныть, как будто тебе пятерку по физре не поставили.

Конкретика — твой друг

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

Тоже человек!

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

Проси и предложи

Забавный момент, но большинство людей боится предложить свои идеи на performance review. А вот тут ты можешь поймать шанс! Предложи что-то, что улучшит процессы в компании или команде. Сразу увидят, что ты не только о себе думаешь, но и о том, как всем станет лучше.

Фидбек — это не атака

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

Цели и перспективы

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

Практика

💻Как делать минимум работы?💻

#базазнаний

Сеньор? А вот джуны пускай возятся.

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

Не накосячь — и никто не полезет.

Логика простая: чем меньше косяков, тем меньше вопросов к твоей персоне. Куда меньше рефакторинга и багфиксов. Качество кода? Да кому это нужно! Главное — не писать бред, которую потом заметят. И не вляпывайся в эпические фейлы. Один косяк — и тебя на ближайший месяц погрузят в баг-трекинговое болото.

Проактивность? Спасибо, не надо.

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

Устраивайся в конторы, где можно расслабиться.

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

Практика

💻Как крутить опыт и говорить за него?💻

#базазнаний

Ищешь любую компанию

Золотое правило: не парься сильно. Выбирай компанию, которая существует, желательно без черных списков в сети. Лучше, если это малый бизнес или стартап — их сложно пробить. Есть еще те, которые умерли, но память о них жива. Можно и в резюме оживить.

Как раздуть опыт, чтобы не спалиться?

Ловкость рук — и никакого мошенничества. Придумывай задачи, которые ты мог бы делать, но будь реалистом. Писать, что ты кодил искусственный интеллект, не надо. Но если, например, ты в теории мог бы пилить базы данных — пиши, что "поддерживал SQL". Главное — чтобы звучало убедительно и жизнеспособно.

Искусство красиво приврать в резюме

Да, это критично. Легкий налет сказочности — это нормально, но не надо указывать, что ты создал приложение, которым пользуется миллиард человек, если кроме твоей мамы его никто не видел. Метафорически говоря: соври так, чтобы самому было не стыдно, если на собеседовании начнут копать. Тебя могут проверить.

Про теги не забудь

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

Рассказывай так, будто тебя уже взяли

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

Практика

💻Кем работать(sre, devops, mlops, devsecops)?💻

#базазнаний

Ну что, начнём с краткого погружения в эти роли, чтобы ты понял, кем ты станешь: тушилой, клоуном, магом или параноиком.

SRE — Тушит пожары и несет воду

Site Reliability Engineer (да-да, те самые люди, которые на шее всей компании сидят). Их главная задача — чтобы всё работало. И это "всё" обычно стремится не работать именно тогда, когда тебе бы хотелось просто балдёжно жить. Мониторы пиликают, прод отваливается, а ты — должен всё это отслеживать и чинить. Бэкапы, мониторинг, автоматизация — это твои лучшие друзья. Если любишь, когда вся ответственность за uptime и благополучие компании висит на твоих плечах, — велкам в SRE.

DevOps — Клоун с перфоратором

Знаешь, как это — быть человеком, который вроде должен всё связать воедино, но при этом больше напоминает циркового жонглера, чем инженера? Вот это и есть DevOps. В теории — ты интегрируешь разработку и эксплуатацию, автоматизируешь процессы, ускоряешь релизы и прочие красивые слова. На практике — твоя жизнь напоминает хаос, потому что ты одновременно настраиваешь пайплайны, конфигурации и пытаешься объяснить разработчикам, почему их код опять всё сломал. Ты — человек-оркестр, у которого всегда чего-то не хватает: времени, терпения, серверов. Но зато в резюме красиво выглядит.

MLOps — Звучит так, как будто ты умный

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

DevSecOps — Параноик с блокнотом

Если ты думаешь, что обычный DevOps — это весело, то с добавлением приставки "Sec" всё становится серьёзнее. DevSecOps — это те, кто сидят в углу, проверяют каждый файл на бэкторы и SSL-сертификаты, помешаны на безопасности и видят уязвимости даже в себе. Эти ребята боятся всего — начиная от кодовых багов и заканчивая SQL-инъекциями. Но платят им за это хорошо, потому что компании любят людей, которые могут защитить их данные от кулхацкеров и не развалить инфраструктуру в процессе.

Что в итоге

- Хочешь геройствовать и работать под давлением 24/7? SRE — твой выбор.
- Не боишься, что кто-то будет считать тебя ходячей шуткой? DevOps.
- Любишь искусственный интеллект, но не хочешь объяснять, что ты делаешь? MLOps.
- Ну и для тех, кто хочет спать по ночам спокойно (а все остальные пусть нервничают) — DevSecOps.

Решай сам, кем быть, но помни: в каждой роли свои плюсы и минусы.

Практика

💻Что такое дежурство в DevOps и как с ним справляться?💻

Представь: ты наслаждаешься выходным, а тут — бац! — система падает, клиенты не могут оплатить заказы, а в чате горят красные сообщения. Вот тут-то и начинается дежурство DevOps-инженера. 👨💻

Что это такое?
Дежурство в DevOps — это как быть «скорой помощью» для цифрового мира. Ты следишь, чтобы приложения работали 24/7, ловишь баги, устраняешь сбои и не даешь системе уснуть. Всё ради того, чтобы пользователи даже не заметили проблем. Например, если упал сервер или зависла оплата, ты быстро всё чинишь — как супергерой в мире кода! 🦸

Как справиться?
Автоматизируй рутину. Настрой мониторинг (типа Zabbix или Prometheus), чтобы система сама кричала «SOS» при проблемах. Не нужно сидеть и смотреть в экран — пусть роботы работают за тебя! 🤖

Учись у практиков. Например, на Boosty.to/devboxops есть задачи, которые учат не паниковать при авариях и прокачивают навыки через реальные кейсы. Там даже можно потренироваться «дежурить» на учебных проектах — как тренажёр для DevOps! 🚀

Работай в команде.
Дежурство — не solo-выступление. Обсуждай инциденты с коллегами, делитесь лайфхаками. Так и стресс меньше, и решения находишь быстрее. 👥

🔥 Совет новичкам: Не бойся дежурств! Они — лучший способ понять, как устроены системы изнутри. А если хочешь потренироваться, загляни на Boosty — там ждут реальные задачи, которые превратят тебя из «чайника» в профи. 😉

P.S. Помни: даже супергерои иногда спят. Есть ротация дежурств и не забывай про отдых! 💤

💻Резюме. Общий гайд.💻

Пост доступен на бусти.

💻CI/CD за 5 минут: самый базовый гайд💻

Привет, будущие DevOps-гуру! Сегодня разберем, что такое CI/CD, зачем это нужно и как это работает.

Ну начнем с простого, что такое CI/CD?

CI (Continuous Integration) — это автоматическая сборка и тестирование кода при каждом изменении.
CD (Continuous Delivery/Deployment) — автоматическая доставка кода на тестовые или продакшен-серверы.

Такс... Хорошо, но как это работает?

1. Пишешь код.
2. Пушишь в Git.
3. CI-система (GitLab CI, GitHub Actions, Jenkins, ...) ловит изменения, запускает тесты.
4. Если тесты пройдены → CD-пайплайн разворачивает код на сервере.
5. Profit! Пользователи получают фичи быстрее, а баги — реже.

Круто, но зачем это DevOps?

⚡️ Скорость: Нет ручных проверок — релизы каждую неделю (или даже день!).
🛡 Надежность: Автотесты ловят 90% багов до прода.
🤖 Автоматизация: Освобождаешь время для крутых задач, а не для рутины.

Не учись методом тыка — делай как профи!

#DevOps #CI_CD #Automation #Автоматизация #DevBoxOps

💻 Разбор реальных кейсов: как забытые сикреты едва не убили наш API 💻

Привет, всем! 👋

⚡️ У нас вышла эксклюзивная статья на Boosty!

В ней вы найдёте:
• Подробную хронологию инцидента — от первых алертов до экстренного фиса и антипаники
• Причины провала: почему обновление сикретов зашло только наполовину
• Чек-листы и правила на будущее: как не допустить такого снова
• Лайфхаки по хранению конфигураций и построению надёжной коммуникации в команде

🔒 Статья доступна только платным подписчикам Boosty!

👉 Подписывайся на Boosty DevBoxOps и будь в курсе всех реальных кейсов и практических разборов:
https://boosty.to/devboxops

До встречи внутри! 🚀

🔥 Друзья, на Boosty вышел свежий кейс 🔥

💻Как случайно удалить все переменные окружения через Ansible💻

Представьте: обычный деплой, кофе в руках… и тут ваш контейнер «просит прощения» — он просто забыл ВСЕ переменные окружения! 😱

В этой статье мы рассказываем:

1. Как баг в модуле  docker_container превратил простой рестарт в настоящий квест.
2. Почему документация и поиск на GitHub стали нашими спасителями.
3. Как написать собственную логику перезапуска контейнера и не остаться без окружения.

🛠 Плюс три рабочих совета, которые спасут вас от ночных багхантов!

Заценить разбор и получить доступ ко всем материалам можно только в подписке на Boosty:
👉 https://boosty.to/devboxops

Погнали разбирать реальные кейсы и учиться на чужих ошибках! 🚀

💻DevBoxOps в деле: реальные успехи наших подписчиков!💻

💎 Что говорят те, кто уже прокачал свои DevOps‑скиллы с нами?
• 100 % участников отметили, что после выполнения заданий стали увереннее работать с Ansible и Linux.
• 9  из  10 наших подписчиков получили первые приглашения на собеседования ещё во время обучения.
• Стажёры и джуны пишут, что разбор “best practices” сэкономил им недели самостоятельного поиска.
• 💯Процесс обучения оценивается – 10/10
• 💯Готовность рекомендовать  –  10/10
• Качество материалов  –  9/10

🚀 Почему DevBoxOps — это обеспеченный старт вашей DevOps‑карьеры:
1. Практика по реальным кейсам: конфигурация сетей, работа с БД, CI/CD‑конвейеры.
2. Пошаговые инструкции для новичков: от первого урока до первого интервью.
3. Поддержка наставника и закрытое сообщество единомышленников.

👉 Стартуй прямо сегодня:
🔗 https://boosty.to/devboxops/

🚨 ТОЛЬКО В ЭТУ СУББОТУ 🚨

Привет 👋

Мы решили провести бесплатный созвон в эту субботу в 20:00 по МСК, в котором ты можешь принять участие.

На созвоне будет уникальная возможность взглянуть на наши процессы изнутри и задать любой вопрос.

Приходи, будет интересно 🥳

🚨 ВАЖНОЕ НАПОМИНАНИЕ 🚨

Всем привет!
Напоминаю, что созвон пройдет сегодня, в 20:00 по МСК.
Ссылка будет здесь, ближе к созвону.

Ждём именно тебя 🫵