Как показать, что шаришь за Docker 🐳 ?

#вопросы_собеседований

Чтобы быть готовым к вопросам со звездочкой и лучше понимать как устроен Docker.

1) Узнай когда лучше подходит VM, вместо контейнера.

Если кратко:
- Тяжелые приложения/Монолит
- Устаревшие приложения, для которых нет образа с поддерживаемой ОС
- Когда приложение не умеет работать внутри контейнера. Например, всё что написано на Java ниже версии 1.8u191, не умело нормально работать внутри контейнера, пока не добавили флаги типа -XX:+UseContainerSupport или -XX:+UseCGroupMemoryLimitForHeap и другие. Хотя даже эта версия еще не очень-то любит контейнера и я бы смотрел на всё что выше Java 10.
- Когда нужно и Linux и Windows, а контейнер ограничен ядром ОС. Поэтому на Linux не запустить Windows контейнер (да, уже и такие есть) и наоборот.
- Нужно больше гибкости в управлении ресурсами
- Не хочется усложнять жизнь дополнительными нюансами безопасности в контейнерах

Материал:
- https://www.youtube.com/watch?v=vuRgqnBsvCg

2) Как устроена файловая система контейнеров.

Она состоит из слоёв. И ситуёвина в том, что если на нижнем слое есть какой-то файл, а на верхнем слое сделали rm, то отображаться файл не будет в запущенном контейнере, НО физическое место он всё равно будет занимать, так как уже записан в нижнем слое.

❗️Поэтому обязательно подчищайте все кеши после RUN apt update

Материал:
- https://habr.com/ru/companies/slurm/articles/701950/

3) Виды сетевых драйверов в Docker и область их применения.

Знаешь только про дефолтный Bridge? Посмотри ссылки, там рассказано про None, Bridge, Host, Overlay, Macvlan, IPvlan.

Например, Overlay используется в Docker Swarm.

Материалы:
- https://www.youtube.com/watch?app=desktop&v=fBRgw5dyBd4
- https://habr.com/ru/articles/790212/

4) Не используй Docker-in-Docker (DIND)

Это небезопасно. Для сборки образов обрати внимание на Kaniko или Buildah. А для запуска контейнеров настрой rootless режим для Docker демона, если это возможно в конкретном случае. Ещё можно глянуть в сторону Podman, как rootless вариант докера по умолчанию. А ещё LXC контейнера есть, помните такие?

Материалы:
- https://habr.com/ru/articles/563040/
- https://habr.com/ru/articles/529814/

5) Как создать образ с нуля, не используя другой образ за основу.

- FROM scratch — чисто ядро Linux, подойдет запускать бинари или накидать своё виденье минимального образа.
- Debootstrap для образов на базе Debian
- А тут скрипты для сборки некоторых ОС с нуля от разрабов Docker.

Материалы:
- https://docs.docker.com/build/building/base-images/#create-a-minimal-base-image-using-scratch
- https://wiki.debian.org/Debootstrap
- https://github.com/moby/moby/tree/master/contrib

6) Лучшие практики при создании Dockerfile.

Основные я бы выделил:
- Multistage (этот пункт имеет нюанс, знаете какой? Из-за этого я его не использую обычно)
- Минимальный образ
- Устанавливать в образ только то, что нужно
- Один процесс - один контейнер
- Использовать кеш при сборке
- Не использовать версию тега :latest
- Комбинировать установку пакетов в один RUN, но при этом не надо вообще всё пихать в один RUN! Подумайте о кеше.
- Используйте CMD в режиме exec

Материал:
- https://docs.docker.com/build/building/best-practices/

7) Отличие между COPY↔ADD, ARG↔ENV и ENTRYPOINT↔CMD.

📚А это вам ДЗ - найдите ответ сами 😉

Cетевая архитектура Kubernetes 💻 Часть 1 из 3
#вопросы_собеседований

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

Архитектура сети Kubernetes состоит:

• CNI (Conteiner Network Interface) — для настройки сети Pod’ов между Nodes и сети Pod’ов на каждом узле. Так же CNI активирует Network Policy.

• kube-proxy — для обслуживания Services.
Его функционал может быть заменён на CNI, который поддерживает eBPF (Cilium, Calico) или BGP (kube-router).

• CoreDNS — для сетевых имён Services.
Ранее использовался kube-dns, но с версии 1.13 заменен на CoreDNS.

• Ingress — для роутинга доменных имён снаружи кластера на Services.

• Service mesh (опционально) — для настройки сети Pods на каждом узле, добавляя mTLS шифрование внутри кластера.
Service Mesh способен заменить kube-proxy, если достаточно управления трафиком на L7 уровне, вместо L3/L4.

——

[CNI]

CNI устанавливается на каждой Node кластера и автоматически выдает IP-адрес каждому Pod’у и создает сеть между всеми Pod’ами.

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

ℹ️ Сеть Pods предоставляет возможность взаимодействовать с другими Pod'ами напрямую по их IP, но так как IP пересоздаются при пересоздании Pod’а, то обычно используют для этого Services.

👮 CNI поддерживает Network Policies для контроля доступа между Pod'ами на L3/L4 уровне сети. Это своего рода фаерволы, которые ограничивают или разрешают трафик на основе их Labels и Namespace.

- Ingress Policy: Ограничивает входящий трафик.
- Egress Policy: Ограничивает исходящий трафик.

По умолчанию, без Network Policy, все Pod’ы могут общаться с любыми Pod’ами:

The cluster network is completely open, by design. Any Pod can communicate to any other Pod.

Source

Поддерживаемые сетевые плагины:

- Flannel: Лёгкий сетевой плагин, который строит Overlay-сеть между узлами с помощью VXLAN. Не поддерживает Network Policy.
- Weave: Использует инкапсуляцию трафика для создания распределённой сети.
- Calico: Предоставляет как L3-роутинг, так и сетевые политики безопасности. Поддерживает маршрутизацию без использования Overlay-сетей.
- Cilium: Использует eBPF для высокоэффективной маршрутизации и управления безопасностью.
- kube-router: Обеспечивает маршрутизацию, сетевые политики и балансировку нагрузки в кластере. Заменяет kube-proxy (не работают вместе) для балансировки нагрузки, позволяя использовать маршрутизацию на уровне IP.

——

[kube-proxy]

kube-proxy — это сетевой прокси, который работает на каждом узле кластера. Его основная задача — маршрутизация и балансировка трафика между Pod'ами, используя Services.

kube-proxy наблюдает за изменениями Services и правил и обновляет правила iptables или IPVS для направления трафика на нужные поды.

kube-proxy реализует 3 (4) метода маршрутизации:

- User Space: Устаревший механизм, когда kube-proxy создает балансировщики в user-space для управления трафиком. Удален в версии 1.26
- iptables: Режим по умолчанию. Использует правила iptables для перенаправления трафика, что улучшает производительность и снижает нагрузку на узлы.
- nftables: альтернатива iptables, которая стабильно работает даже при большом количестве правил. Поддерживается Linux ядром начиная с 5.13. Относительно новый и может быть ещё не совместим с сетевыми плагинами.
- IPVS: Использует IP Virtual Server для высокопроизводительной балансировки на уровне ядра. По производительности сопоставим с CNI-плагином, если использовать его вместо kube-proxy — Source.


ℹ️ Может быть заменён на CNI, который поддерживает eBPF (Cilium, Calico) или BGP (kube-router).

[Продолжение👇]

Cетевая архитектура Kubernetes 💻 Часть 2 из 3
#вопросы_собеседований

[CoreDNS]

CoreDNS — это модульный DNS-сервер, который используется в Kubernetes для резолвинга DNS-запросов внутри кластера.

Возможности CoreDNS:

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

Например, kubernetes-плагин позволяет:
- Резолвить домены внутри кластера (ClusterIP).
- Использовать headless-services
- Кастомизировать доменные зоны для различных Namespaces или Services.
- Настраивать фильтры и правила резолвинга.

🔌 Список плагинов

2. Гибкая конфигурация через ConfigMap
В котором определяется, какие плагины должны использоваться и в каком порядке они будут обрабатывать запрос.

3. Поддержка DNS over TLS и DNS over HTTPS
Поддерживает зашифрованные протоколы DNS-over-TLS и DNS-over-HTTPS, для безопасности при резолвинге DNS-запросов.

ℹ️ В отличие от mTLS, который можно получить, используя Service Mesh, TLS поддерживает лишь проверку сертификата сервера, тогда как mTLS поддерживает взаимную аутентификацию, проверяя также сертификат клиента.

4. Кэширование и балансировка нагрузки
CoreDNS может кэшировать DNS-запросы для уменьшения задержек и оптимизации работы, а плагин loadbalance распределяет трафик, что может быть полезно для распределённых систем и отказоустойчивости.

——

[Ingress]

Ingress — управляет доступом к Services из внешних сетей. Предоставляет SSL терминацию и виртуальный хостинг.

Компоненты:
- Ingress Controller: Управляет Ingress-объектами для настройки маршрутизации трафика.
- Ingress Rules: Правила для маршрутизации трафика на основе хоста или пути.

Примеры: NGINX, Traefik, HAProxy.

[Продолжение👇]

Cетевая архитектура Kubernetes 💻 Часть 3 из 3
#вопросы_собеседований

[Service Mesh] (опционально)

Service Mesh — это инфраструктурный слой, который управляет коммуникацией между микросервисами.

Обеспечивает маршрутизацию запросов, безопасность, мониторинг, балансировку нагрузки, а также управление отказами в сети (timeout запроса, перегруз сети, недоступность сервиса, потеря пакетов).

ℹ️ Service Mesh способен заменить kube-proxy, если достаточно управления трафиком на L7 уровне, вместо L3/L4:

A service mesh decouples traffic management from Kubernetes, eliminating the need for a kube-proxy component to support traffic within service mesh; and managing inter-service traffic, security and observability by providing an abstraction closer to the microservice application layer.

Source

Реализуется с помощью прокси, которые запускаются рядом с каждым приложением в Pod’е. Эти прокси обеспечивают взаимодействие между Services, а также между Services и внешними ресурсами, в случаях запросов от Pod наружу кластера.

Примеры реализации: Istio, Linkerd, Consul Connect, Kuma.

Основные задачи Service Mesh

1. Обеспечение сетевой безопасности:
- Автоматически настроит шифрование (mTLS) для всех коммуникаций между сервисами.
- Контроллирует доступ между сервисами с использованием политики безопасности (например, на основе ролей и аутентификации).

2. Маршрутизация и управление трафиком:
- Поддерживает сложную маршрутизацию и распределяет нагрузки между версиями микросервисов, что применяется в Canary Deployment.
- Автоматически распределяет запросы между сервисами на основе Labels.

3. Имеет механизмы управления отказами:
- Retry: Автоматически повторит попытку отправки запроса через определённый промежуток времени. Это особенно полезно при временных сбоях сети.
- Timeout: Если сервис не отвечает в течение указанного времени, запрос будет автоматически прерван. Это предотвращает зависание запросов при слишком долгом ожидании.
- Circuit Breaker: Отключает запросы к сервису, если количество ошибок превышает допустимый порог. Это предотвращает перегрузку сервисов, которые уже испытывают проблемы, и снижает общий трафик, направляемый на сбойные компоненты.

4. Мониторинг и трассировка:
- Автоматически собирает сетевые метрики и логи.
- Поддерживает трассировку запросов (Jaeger, Zipkin).

5. Трансформация трафика и управление запросами:
- Редактирует запросы и ответы для изменения заголовков, фильтрации данных или преобразования форматов.

Преимущества Service Mesh:
1. Микросервисы могут сосредоточиться на бизнес-логике, а все задачи, связанные с сетью делегируются.
2. Централизованное управление и мониторинг
3. Легко добавлять или изменять сервисы, не меняя логику приложения.

ℹ️ Service Mesh разграничивает доступы на уровне приложений (L7: HTTP, gRPC), тогда как CNI разграничивает доступы на уровне сети (L3-L4) с помощью Network Policy.

——

Доп. материал по теме:
🟥 Устройство сети в Kubernetes
📝 За кулисами сети в Kubernetes
📝 Kubernetes для сетевых инженеров
📝 Продираемся сквозь сети в Kubernetes: Load-Balance, BGP, IPVS и все такое прочее

📝 Эксперименты с kube-proxy и недоступностью узла в Kubernetes
📝 What is Kube-Proxy and why move from iptables to eBPF?

📝 Container Networking Interface (CNI) — сетевой интерфейс и стандарт для Linux-контейнеров
📝 Kube-proxy Vs. CNI
🟥 Calico для сети в Kubernetes
🟥 Сетевые политики Kubernetes

📝 Service Mesh: что нужно знать каждому Software Engineer о самой хайповой технологии
📝 Why do I need a Service Mesh as well as a CNI?
📝 Service mesh vs. Kubernetes Ingress — what is the difference?

DevOps: быть или не быть? Вот в чём вопрос

Полную версию статьи + мемы читай в
📱 Notion (без VPN) или 📱 LinkedIn

——

На прошлой неделе обратился парень с запросом на повышение зп. Он работает уже почти год в роли DevOps-инженера.

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

Затем рассказал ему про план совместной работы и тогда он мимолетом вкинул, что ещё думает о переходе в разработку на Go, но сомневается.

👣 Аргумент следующий: в Go значительно больше зарплаты и уже через год уже можно лутать 300к на позиции Middle или типа того. И потому в раздумьях, ведь перспективы в Go выглядят куда более впечатляющими.

Мой ответ (точнее вопрос) был прост — а что тебе нравится больше всего?

Ещё года 4 назад я впервые услышал сколько получают разрабы на Go. Я думал, что DevOps самая высокооплачиваемая позиция, ведь об этом говорят иностранные рейтинги и сайты типа levels.fyi. А на деле с опытом в 3 года я получал 160к, тогда как с одним годом в Go уже тогда были зп в 300к.

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

👩‍💻 Здесь можно поспорить и рассказать про доход в Manual QA, но я скажу, что не знаю больше нигде так много случаев, когда люди работают на 2-4 работах и получают 600к-1.200к, работая 8 часов в день. Это самая подходящая работа для совмещения, так как самая не затратная по времени. И выйти на нужный уровень для совмещения можно за 1-2 года. Вакансий на 300к немного, но ведь люди как-то находят 2-4 таких.

А если брать разрабов и DevOps - то у них одинаковые потолки зарплат. И там и там в РФ рынке почти одинаковое количество вакансий, по крайней мере на сегодняшний день. Например, DevOps позиций от 435к - 10 штук, а на Go от 455к - 9 по данным из HH.Разница если и есть, то в рамках погрешности.

🖥 Почему бы тогда не перейти в Java? Тут от 440к - 18 и от 550к - 7. Выбор очевиден же.

Вернёмся к вопросу: «Чем тебе нравится заниматься?». Он ключевой, потому что от этого зависит стабильность и скорость роста дохода, пока есть интерес. А если выгорел - то иди в саббатикал и переосмысливай свой выбор по жизни.

И в DevOps и в разработке есть позиции на 600к или вот пример на 800к в РФ. А за границей есть и 11к и 15к в $ и это только открыто публикуемые вакансии. Ну да, минус налоги, относительно резидентства ИП. В Грузии 1% до 200к долларов в год, если больше, то можно с 20% снизить до 5%.

В закрытом найме в качестве проектной работы на GO можно лутать 10-20к долларов, и я думаю, что и DevOps тоже может найти позиции до 20к, если иметь достаточно широкий опыт и грамотно оформить LinkedIn. Понятно, что это должен быть человек руки-ножницы: Тестер, Безопасник, DevOps, SRE, но и на Go за 20к нифига не только код писать. Или идти в FAANG и ждать реализацию опционов.

🖥 Даже DBA на РФ рынке получают предложения на 500к или на 600к в рублях. Но я пока не слышал, чтобы кто-то размышлял перейти в DBA.

В общем суть ясна, да?

Если в ИТ за деньгами, то какая вообще разница? Везде нормальные зарплаты. А если говорить о сложности, то это штука пипец какая относительная: что нравится делать - то и будет проще.

🏦 Чтобы получать 50-100 миллионов ₽ в год — иди в банковскую сферу покупать/создавать деривативы.

🏡 Или иди в риелторскую компанию и без опыта лутай 300-500к через 3 месяца и затем создавай свою команду из 10 человек, которая на пассиве тебе будет приносить ещё сверху 300-600к.

🖥 Если уткнулся в рынок по PHP, то переобулся в Go и пошёл дальше. При этом в PHP влететь в разы проще, чем в Python или Go, так как мало желающих, а рынок вакансий большой. 2 месяца обучения и добро пожаловать. Неважно на чем ты пишешь, если ты выбрал быть разработчиком, то переучиться не составит огромного труда.

Также и в DevOps - видишь больше денег в SRE компетенциях - качай их. Ну и экстраполируй принцип на остальные ИТ профессии.

Или искать валютную удалёнку.

❓Такие мысли. А вы что думаете?

Привет-привет! Контент на подходе, а пока делюсь новостями.

😷 Переболел полторы недели неизвестным, что выбило из графика.

📊 Готовлю анализ Junior DevOps рынка. Данных в анализе много, дел тоже, поэтому долго пишется. Надеюсь до конца октября успеть.

▶️ 9 ноября в 18:00 (GMT+3) меня пригласили принять участие в митапе для студентов ИТМО, которые обучаются по DevOps профилю. Тема «Портфолио начинающего DevOps-инженера».

Записаться на очное посещение или онлайн можно всем, даже если никогда не учился в ИТМО. Главное в анкете указать, что нужен пропуск, если очно.

Я продублирую анонс сюда следующим сообщением. И спасибо Никите Самохину за приглашение!

▶️ 14 ноября в 19:00 (GMT+3) проведу онлайн лекцию для сообщества Mentor In Tech (это те же ребята, что и Women In Tech) по теме «Что нужно знать/уметь, чтобы стать DevOps». Точное название темы я не помню какое указал в заявке, но примерно так 😁. Будет пересекается с темой, что в ИТМО, но в другом формате и только онлайн.

Анонс пока не присылали, но как появится — опубликую.

Анализ РФ рынка для Junior DevOps (Октябрь 2024)
#анализ_рынка

📱Ссылка
📱 Ссылка

Время на чтение - 10 минут.

Рассказываю:
- Сколько вакансий в сравнении с другими позициями
- Сколько получают Junior DevOps
- Какие навыки требуются и как получить лучшее предложение

Прошу поддержать пост лайком в LinkedIn, так как публикуюсь в неудачное время для просмотров, а ваша активность поможет ему остаться на плаву после выходных (я надеюсь ❤️).

Следующим будет для Middle и Senior.

#devops #junior #зарплаты

Привет! В субботу был митап в ИТМО и если хочешь посмотреть в записи, то вот ссылка на пост ребят.

Также собрал короткие ответы на прозвучавшие вопросы.

—

❓ Какие ключевые навыки, наиболее важны для начинающего DevOps-инженера?

В первую очередь: Linux+Bash, Network, Опыт в написании ПО, Git.
Во вторую: Docker, CI/CD.
В третью: Ansible, Terraform, Kubernetes (Helm).

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

Для составления приоритета использовал свой анализ рынка для Стажёров.

❓ Какие ресурсы советуете для развития навыков? Сообщества, Форумы, сайтики и т.п.

Я думаю будет нормально, если я посоветую свою DevOps Roadmap. В ней же, но здесь есть ссылки на другие подобные ресурсы.

❓ Как продемонстрировать/описать свои навыки в работе с технологиями?

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

❓ Можно ли DevOps’у сделать пет-проект, как это делают разработчики? Из чего он должен состоять?

Можно начать с самого начала и даже написать приложение, например, чат бота на Python/Golang. А можно взять уже готовое приложение, состоящее из Фронта, Бека и БД и сделать для него:
- Контейнеризацию всех компонентов
- Сборку, упаковку и деплой CI/CD на GitLab или GitHub
- Если это облако, то с помощью Terraform создать VMs на сборки и деплоя
- Деплоить можно c помощью Ansible или Docker-compose. В случае первого добавляется еще одно важное ключевое слово, что плюс.
Если усложнить:
- Поднять Kubernetes в облаке или локально
- Написать манифесты для деплоя, лучше всего в Helm, но подойдет и в базовом ямле, если Helm не понятен сейчас.
- Добавить мониторинг за приложением и инфрой

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

❓ Как перекатиться в данную область, если ты разработчик/системный администратор?

Смотри ответ на первый вопрос. Опыт в ИТ будет хорошим плюсом. Чаще всего в DevOps идут из сисадминов, потому что область очень родственна базой в виде Linux и Network.

❓ Как подготовиться к собеседованиям на позиции DevOps-инженера? Какие типичные вопросы могут задавать работодатели?

На стажёра нужно готовиться к базовым вопросам прежде всего, типа:
- Что такое DevOps?
- Что такое контейнеризация? Чем отличается от виртуализации?
- Что такое DNS и как устроен?
- Что такое IP?
- TCP vs UPD
- Для чего нужен IaC?

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

Подобных сборников есть ещё некоторое количество. Если найдёшь конкретно для Стажёра/Junior вопросы, то пиши!

📱 Как стать DevOps с нуля в 2025 году | ПОШАГОВЫЙ ГАЙД 💣

Время на чтение: 30 минут.

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

Гайд составлен на основе кусочка знаний из моей закрытой базы по вопросам с собеседований, которую выдаю после мок-интервью — думаю, это точно лайк-репост ❤️

Рассказываю:
- Кто такие DevOps и Айтишники;
- Что и где учить — самым подробнейшим образом;
- Дотошный чек-лист для проверки знаний на Junior DevOps;
- На какие суммы рассчитывать (спойлер: 150к).

Как такое перенести в LinkedIn пока ума не приложу. Может и не стоит вовсе.

#devops #гайд #junior #стажёр #intern

👨‍🔬 Зачем мне Computer Science?

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

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

🔄 Если идёшь по гайду, то дважды нажми на обновить страницу, чтобы сбросить кеш — там немало обновлений.

Началось всё вообще с размышлений о необходимости разбираться в ОС и устройстве компьютера. Я хоть и узнал в вузе основы ЭВМ, но так и не смог вспомнить или придумать примера как это помогло мне в 2017 стать DevOps. Зачем мне сейчас, например, понимать особенности работы с оперативной памятью я знаю, но зачем это начинающему специалисту?

Сам я джуном изучал так называемый Computer Since практически никак. Учим команду awk, вот так можно использовать, агааааа. Учим top, вот так, оооооо.

А что такое ядро и системные вызовы к нему? Вот оно мне как поможет написать systemd unit?

Я виртуалку развернул по гайду из интернета и в неё автоматом коннект с интернетом прокинулся, что ещё тут нужно знать про виртуализацию и сети?

Да вроде и не нужно, получается. При вкате в профессию наоборот дольше учишься: пока со всем этим разберёшься.

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

Зачем тогда я добавил материалы из области Computer Science? Потому что на собесе могут ожидать понимание и спрашивать напрямую или косвенно. Потому что это логичный путь изучения. Но вот увлекательный ли? И да и нет. Чем меньше времени и желания разбираться, тем менее увлекательный.

Окей, Эд, а пруфы у тебя есть, что это спрашивают? Нет, только моё предположение. Надо сходить стажёром-джуном на собесы, разведать обстановку. Где бы только найти ещё 24 часа в сутках.

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

❓ Как думаете, может начинать лучше с изучения команд в Linux и потом сразу в Docker, GitLab, Kubernetes и т.п.? И только когда-нибудь потом возвращаться, условно, к книгам Таненбаума.
Или стоит изучить эволюцию процессоров, что такое ОС, что такое виртуализация, как устроены сети, что такое программа и как её написать, что такое БД и только потом всё остальное?

Middle DevOps | Честный анализ РФ рынка (Ноябрь 2024)
#анализ_рынка

📱Ссылка
📱 Ссылка

Время на чтение — 15 минут.

TL;DR:
❤️Средняя — 268.700₽;
❤️Медиана — 272.500₽;
❤️Минимальная — 140.000₽;
❤️Максимальная — 450.000₽;
❤️Работа из дома — 77% вакансий;

Если хочешь узнать:
❤️Как проходил отбор вакансий;
❤️Какие навыки требуются;
❤️Способ узнать вилку, если она не опубликована на hh.ru;
❤️Где больше денег: в офисе или на уделёнке;
❤️И что обо всём этом думает безукоризненный профессионал JSON Statham, то переходи по ссылке.

Посмотреть на бомбическую таблицу с вакансиями и самому её фильтрануть по навыкам или отсортировать по зарплате можешь в самом конце статьи.

—

Уже прочитал? Ну как, огнище же? 🔥 30 часов труда вложены не зря, я считаю.

Буду очень рад твоим лайкам на посте в LinkedIn в понедельник. Это стоит того, чтобы его увидело как можно больше людей, а лайки и просмотры этому способствуют. Я напомню через сторис 🤝

Следующий анализ для Senior.

Пиши что думаешь об анализе в комментариях!

#devops #middle #зарплаты

Senior DevOps | Честный анализ РФ рынка 🚀 (Декабрь 2024)
#анализ_рынка

📱Ссылка
📱Ссылка

Время на чтение — 20 минут.

TL;DR:
❤️Средняя — 361.394₽;
❤️Медиана — 350.000₽;
❤️Минимальная — 200.000₽;
❤️Максимальная — 800.000₽;
❤️Работа из дома — 82% вакансий;
❤️Удалёнка по миру— 21% вакансий.

В анализе ты узнаешь:
❤️Какие навыки требуются, чтобы получать 800к;
❤️Где искать удалёнку по миру;
❤️Топ вакансий, оформленных левой пяткой;
❤️Почему важно правильно оформить резюме, чтобы найти работу;
❤️Какие вакансии не попали в анализ.

Таблицу с вакансиями можешь посмотреть и самостоятельно отфильтровать в самом конце статьи.

—

Ну что, друзья, ещё 30 часов своего труда после работы дарю вам. Буду рад, если и вы подарите его другим людям ❤️

#devops #senior #зарплаты