‼️Стартуем! Розыгрыш! Бесплатное обучение от GigaDevOps — шанс войти в IT на 200к+!

Мы разыгрываем:

💥1 место: БЕСПЛАТНОЕ ОБУЧЕНИЕ (базовый блок)
🛍2 место: скидка 50%
🛍3 место: скидка 30%

Как участвовать?

👉 Быть подписанными на наш телеграм-канал;

👉 Оставить комментарий под этим постом. Подойдёт крутой стикер, слово "участвую" или ваш рассказ, почему выиграть хотите именно Вы!

👉 Поставить реакции на 3 предыдущих поста;

ВСЁ — вы в деле!

P.S. А если хотите точно начать карьеру в DevOps - у нас есть бесплатная консультация, на которой Вам обо всём расскажут. Для записи на неё заполните короткую форму.

Победитель будет определён рандомным образом в воскресенье - 29 июня.

☀️Всем желаем удачи! Вперёд к знаниям и крутой карьере вместе с GigaDevOps!

‼️ Провели ресёрч по митапам, встречам и видео про DevOps, чтобы вы могли полезно провести свои выходные!

Что нашли:

Техническое собеседование DevOps 2025 во Вконтакте

-Тонкости, вопросы, запись самого собеса

Программист vs DevOps: кто за что отвечает

- Вечная битва: какой список обязанностей за кем закреплён, и что делать, чтобы процессы были выстроены грамотно

Как практиковаться Junior DevOps-инженеру

- Боль тех, кто видит на HH только мидл-сеньор позиции. Автор грамотно и по пунктам разбирает, где искать и как начать.

Все, что нужно знать о деплое, DOCKER, CI/CD, если ты новичок

- Интересно и мемно смонтированное видео, где на собственном опыте автор рассказывает о своём пути.

DevOps Mock Interview #2 (Junior DevOps)

- Ребята запустили интересую рубрику, где интервьюируют подписчиков своего канала, проводят очень развёрнутые мок-собеседования.

🛍 Ну, а мы напоминаем, что до завтра вы еще можете поучаствовать в розыгрыше бесплатного обучения и скидок в предыдущем посте!

⁉️.dockerignore — как ускорить сборку Docker-образов и не засорить их

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

✔️ Помогает .dockerignore.

❓ Что такое .dockerignore
Файл, который говорит Docker:
«Эти файлы не нужно включать в контекст сборки»

Аналог .gitignore, но для docker build.

Пример: зачем это нужно

# Без .dockerignore
Sending build context to Docker daemon  514.3MB

# С .dockerignore
Sending build context to Docker daemon  23.6MB

Меньше файлов = быстрее сборка и меньше шанс случайно протечь данными

🧹 Что почти всегда стоит игнорировать

node_modules/
venv/
__pycache__/
.git
.gitignore
*.log
*.swp
*.tmp
.DS_Store
.env

.env особенно важно — чтобы не утекли секреты

👎 Пример плохого .dockerignore

*.log

Только логи, всё остальное (включая node_modules) идёт в образ 😬

✔️Пример хорошего .dockerignore для Node.js проекта

node_modules/
npm-debug.log
Dockerfile
.dockerignore
.git
.gitignore
.env
coverage/
*.swp

❗️ Когда использовать .dockerignore
📍 Нужно ускорить docker build
📍 Не хочешь тянуть в образ мусор
📍 Нужно исключить секретные/локальные файлы из контекста

Важно помнить
.dockerignore влияет на то, какие файлы попадут в контекст сборки (docker build).
Если файл исключён, он будет недоступен Dockerfile — COPY и ADD с ним не сработают.

Пс, что делаешь сегодня в 19:00? 📞

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

Сегодня, например, в 19:00 по МСК пройдёт смол-ток. Подключайся на него здесь: https://meet.google.com/wmt-esyb-qcs

А как узнать, когда и во сколько будет новый? Ответ: наше комьюнити!

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

⬆️ Вышла новая версия GitLab 18.1 — в релизе более 110 улучшений и новых функций для DevOps-команд.

В числе ключевых изменений:

1️⃣ Виртуальные реестры Maven (бета)
Управление зависимостями Maven стало проще: теперь несколько внешних репозиториев объединяются в единую точку доступа через виртуальный реестр. Умное кэширование ускоряет сборки, а аудит безопасности и настройка интеграций упрощаются. Доступна настройка через API, есть ограничения на количество реестров и источников, но функционал будет расширяться по мере выхода из беты.

2️⃣ Duo Code Review — в общем доступе
ИИ-ассистент Duo Code Review теперь доступен для всех пользователей Premium и Ultimate. Он автоматически анализирует изменения кода в merge request, выявляет баги и уязвимости, предлагает улучшения и лучшие практики. Можно запрашивать фидбек через тег @GitLabDuo. Многие рекомендации доступны для мгновенного применения прямо в браузере.

3️⃣Проверка скомпрометированных паролей
GitLab.com теперь проверяет, не был ли ваш пароль замечен в утечках. В случае обнаружения — уведомление и инструкция по смене пароля. Рекомендуется использовать уникальные пароли и включать двухфакторную аутентификацию.

4️⃣Компоненты CI/CD для SLSA 1
Появились новые модули для CI/CD, которые позволяют достичь соответствия требованиям SLSA Level 1: автоматическая подпись и проверка происхождения артефактов через Sigstore Cosign. Интеграция максимально простая.

Дополнительные обновления:

➖ Продвинутый поиск кода: несколько совпадений для одного файла теперь объединяются для лучшей навигации и понимания контекста.
➖ Улучшенная проверка CODEOWNERS: теперь автоматически проверяются не только синтаксис, но и права доступа всех участников, что помогает избежать ошибок в процессе ревью.
➖ Логи нижестоящих конвейеров доступны прямо в VS Code через расширение GitLab Workflow.
➖ Фильтр пользователей в админпанели self-managed GitLab: можно разделять ботов и людей для быстрого управления и аудита.
➖ Поддержка ORCID-идентификаторов в профилях пользователей — важно для исследователей и академического сообщества.
➖ Новые настройки email-уведомлений для конвейеров сервисных аккаунтов.
➖ Просмотр неактивных персональных токенов доступа теперь доступен для повышения прозрачности и безопасности.
➖ Виртуальные эпики теперь поддерживаются в GitLab Query Language.
➖ Новый интерфейс панели ревью в merge request — все черновые комментарии собраны в одном месте для удобного завершения ревью.
➖ В GraphQL API появился аргумент accessLevels для фильтрации участников проекта по правам доступа.

🎉Реферальная система теперь в GigaDevOps!

Приглашай друзей и знакомых и получай реальные деньги – 10% от стоимости их обучения!

❓ Как это работает:

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

2. Ты делишься этой ссылкой со знакомыми и друзьями.

3. Каждый пользователь, перешедший по вашей ссылке, закрепляется за тобой на 90 дней.

4. Если в течение этого срока пользователь купит любой курс школы, ты получаешь 10% от фактической стоимости его покупки.


Твой доход = 10% от стоимости обучения.

Ты получаешь 10% от фактической стоимости купленного твоим рефералом обучения. Настоящие деньги на той карте или счету, который укажешь!


Пример 1: Привлеченный тобой студент купил курс за 25 000 рублей. Твой доход = 2 500 рублей.

Пример 2: Привлеченный тобой студент выбрал курс за 70 000 рублей. Твой доход = 7 000 рублей.

Чем дороже курс – тем выше твоя комиссия!


🔤 Как зарегистрироваться?

1. Заполни форму регистрации партнера здесь (если вы еще не заполняли ее ранее).

2. Перейди в Личный кабинет. В левом боковом меню выбери раздел "Покупки".

3. Нажми "Партнерская программа". Там ты сразу увидишь уникальную партнерскую ссылку и сможешь отслеживать статистику переходов и начислений!


💲 Как получить выплаты?

1. Выплаты производятся с 1 по 10 число каждого месяца за покупки, совершенные в предыдущем календарном месяце.

2. Менеджер партнерской программы свяжется с тобой в этот период (с 1 по 10 число) для уточнения реквизитов для перевода (банковская карта/счет или другие удобные вам способы).

3. После подтверждения реквизитов деньги будут переведены в кратчайшие сроки.

P.S. Поставь огонёк, если тебе нравится эта функция!

🧱 Как правильно организовать Terraform-конфигурацию для разных окружений (dev / stage / prod)

Когда инфраструктура начинает расти, появляется вопрос:
Как не сломать прод, когда выкатываешь dev?

✅ Помогает правильная архитектура Terraform-проектов.
С изоляцией, чистыми модулями и state-файлами, которые не мешают друг другу.

❗️ Почему нельзя писать всё в одном месте
Если держать всё в одном каталоге — легко случайно сделать terraform apply и задеть не то окружение.

Workspaces? В теории красиво, на практике — почти никто не использует. Ломаются в CI, сложно дебажить, нельзя подключать разные провайдеры.

✅ Как делают в проде
Чёткое разделение по окружениям:

terraform/
├── envs/
│   ├── dev/
│   ├── stage/
│   └── prod/
├── modules/

- отдельная папка

- отдельный terraform.tfvars

- отдельный backend (S3 state-файл)

- один и тот же набор модулей
Такой подход масштабируется, безопасен и легко поддерживается.

📄 Пример: envs/dev/main.tf

terraform {
  backend "s3" {
    bucket = "infra-terraform"
    key    = "dev/terraform.tfstate"
    region = "us-east-1"
    dynamodb_table = "tf-locks"
  }
}

Это значит:
🔹 state для dev живёт отдельно
🔹 никакой apply не затронет stage/prod
🔹 есть блокировка от одновременного запуска

🧰 Общая логика — в модулях

modules/
├── vpc/
├── s3/
└── ec2/

Каждое окружение просто подставляет свои переменные:

module "vpc" {
  source = "../../modules/vpc"
  cidr_block = "10.0.0.0/16"
  env        = "dev"
}

🧩 Где держать переменные?
В terraform.tfvars для каждого окружения:

region        = "us-east-1"
instance_type = "t3.micro"
domain        = "dev.example.com"

Файл variables.tf общий — он описывает, что можно настраивать, а не как.

🛡Почему это безопасно

📍 У каждого окружения — свой state → никакой гонки
📍 Все конфигурации разделены → проще ревью
📍 Модули переиспользуются → меньше копипасты
📍 У тебя контроль → apply работает в контексте среды

✅ Когда использовать такую структуру

✔️ У тебя хотя бы два окружения (dev/prod)
✔️ Ты хочешь стабильный CI/CD
✔️ Работаешь в команде или на проекте, где "прод ломать нельзя"

👀А что делать, если нужна стажировка/первый проект, а везде ищут минимум мидлов?

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

Что искали:

➖DevOps
➖без опыта
➖удалёнка

Конечно, вакансий для сеньора с опытом от 6 лет в офис на окраине Екатеринбурга за 20 000 рублей больше, чем то, что нам интересно, но всё же некоторые предложения нашли:


1️⃣ DevOps без опыта от 150к с графиком 5/2

2️⃣ Джун DevOps с полной удалёнкой

3️⃣Оплачиваемая стажировка в Aston с бесплатным обучением и последующим трудоустройством

4️⃣Джуниор DevOps в IT-компанию

5️⃣Оплачиваемая стажировка для Junior с трудоустройством по ТК

Также вот, что нашли на Habr:

➖ Ищут джуна, которого готовы растить внутри команды с интересными требованиями по заявке, но с ЗП до 175к

➖ Расширяют команду, ищут DevOps, требования к опыту не указаны, зп 236к.

Cвежак на LinkedIn:

➖ Junior DevOps

➖ Junior DevOps

➖ Junior DevOps

➖Junior DevOps на фриланс

➖ Junior DevOps

Да уж! Было тяжело. В сравнении с Middle - и ЗП другая, и количество несопоставимо.

‼️ Хочешь стать Middle за несколько месяцев? Это возможно. Дисклеймер: учиться придётся. Но результат того стоит однозначно.

Залетай на бесплатную консультацию и присоединяйся к GigaDevOps.

🌐 Dual Stack — зачем нужен IPv6 и как его включить правильно

Ты поднял сервис — всё работает. Но тут клиент говорит:
🔈 «Нам нужен IPv6».
И ты такой: «Так ведь работает и без него…»
✔️ Но современная инфраструктура требует Dual Stack — когда сервис работает и по IPv4, и по IPv6 одновременно.

❓ Почему появился IPv6
IPv4 даёт ~4.3 млрд адресов (32 бита).
С ростом интернета их стало не хватать — всё уже распределено между провайдерами и организациями.

Чтобы решить проблему, в 1998 году придумали IPv6:
🔢 128 бит адресации → ~3.4×10³⁸ адресов
Хватает всем — на много лет вперёд.

❓ Что такое Dual Stack
Это режим, когда:
- сервис слушает и IPv4, и IPv6
- DNS возвращает и A, и AAAA записи
- клиент сам выбирает, как подключиться

Пример записей DNS:

A     → 192.0.2.10  
AAAA  → 2a01:4f8:c17:4b1::1

Пример использования curl

curl -4 example.com   # IPv4
curl -6 example.com   # IPv6

Как использовать?
Сначала провайдер (или облако) должен выдать IPv6-адрес.
Далее необходимо зарегистрировать AAAA-запись, указывающую на IPv6-адрес.
Интерфейс сервера должен иметь IPv6-адрес.
Маршруты на сервере должны быть настроены.

⚙️ Nginx: как слушать оба IP-протокола

server {
    listen 80;
    listen [::]:80;
    server_name example.com;
    ...
}

⚠️Без строки listen [::]:80; IPv6 не будет обслуживаться

🔥 Когда включать Dual Stack
✔️ У тебя публичный сервис или API
✔️ Мобильные пользователи (часто идут через IPv6)
✔️ Хостинг/облако требует IPv6
✔️ Клиенты из других стран (Китай, Индия, Германия — активно используют IPv6)
✔️ Аудит / безопасность / заказчики с жесткими требованиями

❕ Вывод
IPv6 — это не «технология будущего». Он уже активно используется и становится обязательным для публичных сервисов.

Но он не включается сам по себе — настройку нужно делать осознанно: от облака до DNS и firewall.

❓ Не пов, а рил: ты наконец нашёл себе первую работу в DevOps, а это оказался небольшой стартап.

Вопрос: зачем таким маленьким проектам этот специалист, и чем предстоит заниматься?

Да, вот так оказалось. Это не гигантский банк и не техно-корпорация, а небольшой стартап. В команде 5–7 человек, никаких миллионных бюджетов. Всё быстро, лампово и по-своему хаотично. И вот ты смотришь вокруг и ловишь себя на мысли: А зачем вообще тут DevOps? Неужели нельзя просто “на лету” всё выкатывать?

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

🔎 Почему стартапу не хватает “ручного режима”?
Вроде бы, когда команда небольшая, можно же договориться в чате, быстро что-то залить на сервер, прописать пару скриптов… Но чем дольше команда работает “по старинке”, тем больше возникает:

➖ Ручных багов — где-то забыли команду, где-то не прописали переменную, где-то “задеплоили не ту версию”.
➖ Потерянного времени — релиз превращается в квест с дедлайнами, а не в рутинную задачу.
➖Тестов “на авось” — кто-то помнит про них, кто-то нет.
Огня в проде — потому что всё тестировалось “на глаз”, и никто не может быстро откатиться.
➖DevOps — это не про “нанять отдельного девопса с зарплатой как у лида”, а про культуру, которая помогает даже маленьким командам работать как взрослые.

✨ В чём реальная польза DevOps для маленькой команды?
➖ Быстрые и безопасные релизы.
Даже если у вас мало сервисов, автоматизация означает, что “выкатить на прод” — это одна кнопка, а не марафон по SSH.

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

➖ Обратная связь и мониторинг.
Даже в маленькой команде важно знать, что приложение работает, а не “лежит” уже второй час.

➖ Легче масштабировать бизнес.
Когда команда растёт, DevOps-процессы не тормозят, а только ускоряют разработку и внедрение новых фич.

💲 А что по затратам?
Сразу вопрос: “А если денег мало?”
Всё честно — на старте хватит бесплатных (или почти бесплатных) инструментов:

➖ Git + GitHub/GitLab — для контроля версий и пайплайнов.
➖ Docker — для упаковки приложений.
➖ CI/CD (GitHub Actions, GitLab CI) — чтобы не деплоить руками.
➖ Мониторинг — Prometheus, Grafana, или даже простые алерты в Telegram.
➖ Cloud-тарифы для стартапов — у многих платформ есть бесплатные опции для новых команд.

Главное: DevOps — это не про покупку дорогущих решений, а про то, чтобы команда не тратила время на то, что можно автоматизировать.

⚙️ С чего начать, если ты первый devops в стартапе?

1️⃣ Посмотри, где “горит”.
Где чаще всего случаются ошибки? Что делают вручную? Где теряется время?

2️⃣ Автоматизируй мелочи.
Пусть даже это будет “маленький” пайплайн или скрипт для тестов — но это уже шаг вперёд.

3️⃣ Объясняй команде, зачем это нужно.
Иногда люди боятся автоматизации (“а вдруг я потеряю работу?”), но твоя задача — показать, что DevOps = меньше рутины и больше времени на творческие задачи.

4️⃣ Не пытайся внедрить всё и сразу.
В стартапе важно не перегореть. Двигайся маленькими шагами, показывай пользу — и команда сама подтянется.

☀️ Вам тоже жарко? Это всё ЛЕТНЯЯ РАСПРОДАЖА в GigaDevOps!

‼️ Только до 30 июля. Только 10 акционных мест.

➖ Тариф "Всё включено": 65 000
➖ Тариф "1-2-1": 85 000.

❓ Как успеть обучиться выгодно?

До 30.07 включительно написать нашему менеджеру @ratushnov "Я С ВАМИ" + выбрать тариф. Оплатить обучение необходимо до конца месяца.


GigaDevOps — это обучение, практика, поддержка, мок-собеседования, помощь с резюме и многое другое. Не упускай эту возможность: присоединяйся к нам уже сейчас.

⚡️ Напоминаем Вам!

Уже 00:00 скидки превратятся в тыкву, а возможность обучиться выгоднее испарится так же быстро, как и хорошие вакансии DevOps на HH.

Осталось 2 места на обучение по ценам в посте выше. Для того, чтобы присоединиться - просто напишите @ratushnov в ЛС 💬

Когда шумиха вокруг ИИ немного улеглась, давайте с холодной головой обсудим, где ИИ в DevOps — это хорошо, а где без человеческого контроля станет только хуже.

1️⃣ Упрощение автоматизации
ИИ автоматизирует рутинные задачи, такие как CI/CD и мониторинг. Алгоритмы машинного обучения могут анализировать результаты развертывания и предсказывать сбои, что значительно ускоряет процессы.

2️⃣ Проактивная безопасность
Интеграция ИИ в DevSecOps позволяет выявлять уязвимости в коде. Инструменты, такие как Snyk, помогают анализировать код на наличие аномалий, что делает системы более защищенными.

3️⃣ Автономные DevOps
Автономные системы могут принимать решения в реальном времени. Например, GitHub Actions автоматически развертывает приложения на основе заданных метрик, минимизируя вмешательство человека в рутинные процессы.

4️⃣ Оптимизация конфигурации
ИИ динамически настраивает среды, как в Kubernetes, чтобы избежать простоев и оптимизировать использование ресурсов. Это повышает общую производительность систем.

5️⃣ Адаптивные ИИ-системы
Адаптивные системы предсказывают нагрузки и оптимизируют ресурсы на основе текущих данных, позволяя избежать пиковых нагрузок и обеспечивая стабильность.

6️⃣ Оптимизация кода
Инструменты, такие как DeepCode, помогают улучшать код, предлагая рекомендации и автоматизируя рефакторинг, что делает разработку более эффективной.

7️⃣ Интеграция с облаком
ИИ автоматизирует масштабирование в облачных сервисах, например, с помощью AWS Auto Scaling, что позволяет обеспечивать высокую доступность приложений.

8️⃣ ИИ и IoT
Интеграция ИИ с IoT улучшает мониторинг устройств, позволяя предсказывать сбои и минимизировать время простоя.

Роль человека
Несмотря на все преимущества ИИ, человеческий фактор остается критически важным:

✔️ Решение сложных задач: часто организации сообщают, что автоматизация не устраняет необходимость в ручном тестировании.

✔️ Процент невыявленных уязвимостей: по отчётам Gartner, 60% уязвимостей остаются невыявленными даже с использованием ИИ.

✔️ Креативность и интуиция: автоматизация не может заменить человеческое творчество, вы и сами прекрасно знаете, попробуйте без 100 выверенных промтов попросить GPT придумать классную шутку. Спойлер: будет стыдно.

✔️ Проблемы с конфигурацией: В отчете "Cost of a Data Breach Report" утверждается, что 80% проблем требуют человеческого вмешательства для диагностики и решения.


Каков вывод? ИИ — это очень удобно, то, что раньше требовало большой концентрации внимания и рутинной работы, сейчас можно сделать за несколько кликов. Но без контроля даже на момент августа 2025 далеко не уедешь. Поэтому без работы девопсеры точно не останутся. Автоматизируем, что автоматизируется, но очень внимательно проверяем всё, что делали не только мы, но и ИИ — вот и весь секрет🤌

⚡️ RBAC в Kubernetes: как не дать разработчику всё сломать

Работаешь в команде, у всех доступ к кластеру, и один день внезапно:

kubectl delete --all pods --all-namespaces

Да, он случайно забыл, что работает в проде.😲

Чтобы такого не было — в Kubernetes есть RBAC (Role-Based Access Control). Это не просто формальность, а реальный способ ограничить доступ по принципу наименьших привилегий.

Вот как это устроено:

4️⃣ ключевых объекта:
📍 Role — определяет разрешения на действия с ресурсами в пределах одного namespace.
📍 ClusterRole — может применяться глобально ко всему кластеру или локально через RoleBinding.
📍 RoleBinding — связывает пользователя/группу/сервисный аккаунт с Role или ClusterRole в рамках одного namespace.
📍 ClusterRoleBinding — связывает субъекта с ClusterRole, и разрешения применяются ко всему кластеру.

📌 Пример:
Хочешь дать разработчику доступ только к логам своего приложения в dev-namespace?

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: dev-namespace
  name: logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-logs-access
  namespace: dev-namespace
subjects:
- kind: User
  name: "dev-john"
roleRef:
  kind: Role
  name: logs-reader
  apiGroup: rbac.authorization.k8s.io

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

💡 Советы:
➖ Всегда начинай с read-only прав.
➖ Используй ClusterRoleBinding только когда действительно нужно.
➖ Разделяй доступ по ролям и namespace'ам.
➖ Не выдавай права через system:masters, если не хочешь дать всё и сразу.

⚠️RBAC не защищает от ошибок в самом приложении. Только от "лишнего" в kubectl.

📣 А ты уже настраивал RBAC у себя? Или до сих пор все — admin? Напиши 👇

⏰ Подъехали свежие вакансии для вас!

➡️ Junior DevOps инженер в Aston (6 офисов в РФ)

➡️ DevOps Engineer в Лабораторию Касперского с опцией релокации из регионов

➡️ Middle Devops Engineer в МТС, удалённо с мощным соцпакетом

➡️ DevOps в Centicore: офис в Москве либо удаленка

➡️ Middle DevOps Engineer в Mad Devs с зп в $, удаленно

➡️ Администратор баз данных в Контур (10 офисов в РФ и удаленка)

➡️ DevOps-инженер (Кибербезопасность) в Bell Integrator, удаленка

➡️ DevSecOps в Сравни с кайфовым офисом в Москве и удаленкой

➡️ DevOps инженер в Ральф.IT с 9:00 до 18:00 из офиса в Москве или из дома

➡️ DevOps с бэкграундом сисадмина в Nobilis.Team (удаленка и поездки в филиалы)

Позиции в основном мидловые – потому что мы помогаем начать и удержаться сразу на Middle уровне, без стажировок и галер.

👨‍💻 Что требуется и как быстро может получиться с твоими навыками – можешь узнать на бесплатной консультации с нашими менторами.