DevOps Upgrade: что изменится в 11 потоке

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

➡️ Длительность потока — 9 месяцев, вместо привычных 6.

Мы добавили вводный модуль для плавного погружения в процесс обучения. Посмотрим путь развития DevOps-инженера, подтянем базу Docker, Git и Linux, научимся совмещать жизнь, работу и обучение.

➡️ Неделя 1. Знакомство и вводная встреча с ментором и куратором, входное тестирование, roadmap DevOps.

Открываем вводные курсы на выбор: большой видеокурс по Linux, введение в Ansible и Docker, подготовительный курс по Git. Для тех, кому не надо ничего подтягивать — пробный проект на стенде.

➡️ Неделя 2. Изучение вводных курсов, тренинг по тайм-менеджменту и самообучению.

➡️ Неделя 3-4. Прохождение вводных курсов Самостоятельный трек + поддержка от куратора и ментора.

➡️ Неделя 5. Плавный вход в модуль Ansible с увеличенным временем прохождения.

Старт потока — 30 июня.

Цену мы тоже снизили — до 31 мая присоединиться к потоку можно за 135 000 ₽ (вместо привычных 150-160).

⭐️ Узнать подробности и забронировать раннюю цену — на странице курса.

#devops_upgrade

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

На этой неделе, вместо привычного теста с выбором варианта ответа у нас было обсуждение, где лучше хранить Terraform state.

Я, как и большинство из вас, чаще использую S3 или Gitlab. На видео подробно рассказал, почему, и в каком случае предпочтителен тот или иной вариант ⬆️

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

Поделитесь в комментариях ⬇️

Blameless ≠ Безответственность: почему это ключ к надежности ваших систем

Blameless culture — это не просто модный термин. Это фундаментальный принцип построения устойчивых, надежных и постоянно улучшающихся систем.

Почему Blameless — это критически важно:

➡️ Фокус на проблеме, а не на людях
Когда случается инцидент, наша главная цель — понять, что пошло не так и почему система позволила этому случиться, а не кто нажал «ту самую кнопку». Поиск виноватых мгновенно создает атмосферу страха.

➡️ Честность и прозрачность
Люди боятся сообщать об ошибках или неочевидных рисках, если знают, что их накажут. Blameless поощряет открытое обсуждение факторов, приведших к сбою (включая дизайн системы, процессы, документацию, давление сроков), что абсолютно необходимо для настоящего постмортема.

➡️ Учимся на реальности
Самые ценные уроки извлекаются из провалов. Если люди скрывают детали из-за страха, мы теряем возможность по-настоящему понять слабые места и исправить системные причины.

➡️ Скорость восстановления и улучшения
Энергия, потраченная на поиск виноватого — это энергия, отнятая у анализа первопричин и внедрения исправлений. Blameless ускоряет процесс реального устранения проблем.

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

Но есть важный нюанс, который обязательно нужно понимать: Blameless — это НЕ отсутствие ответственности!

Ответственность присутствует, но она смещается от наказания инженера за конкретное действие/ошибку к ответственности команды в целом за:

➡️ Активное и открытое участие в разборе инцидентов
➡️ Усердный поиск корневых причин, глубже «человеческой ошибки» (почему процесс не предотвратил ее? почему мониторинг не сработал? почему документация была неясной?)
➡️ Внедрение улучшений, выявленных в постмортеме, чтобы предотвратить повтор инцидента
➡️ Совершенствование систем и процессов
➡️ Понимание, что люди — часть системы, и наша задача — строить системы, устойчивые к неизбежным человеческим ошибкам (через автоматизацию, проверки, четкие процедуры, улучшенный мониторинг и алертинг).

Проще говоря:

🍀 Blameless
Эта ошибка произошла. Давайте поймем причины, включая то, как система/процесс не защитили нас от нее, и исправим это так, чтобы это больше не повторилось.
🍀 Безответственность
Человеский фактор, ну ошибся человек, бывает. Ничего страшного, ничего делать не будем.

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

DevOps Upgrade: рассказываю про помодульную оплату (на самом деле все просто)

В 11 потоке мы решили иначе подойти к формату рассрочки и сделали возможность оплаты равными частями перед началом каждого модуля.

Как это работает:
➡️ финальная стоимость делится на 6 равных платежей, которые вносятся перед началом каждого нового модуля, кроме финального задания
➡️ выйти из процесса обучения можно после любого модуля — оплачивать непройденные модули не нужно
➡️ программа курса построена в формате сквозного проекта, поэтому пропустить модуль и вернуться на следующий нельзя
➡️ если вы не успеваете учиться, можно бесплатно перевестись на следующий поток

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

Сейчас занять место можно за 195 000 ₽ 155 000 ₽, или 25 833 ₽/модуль.

⭐️ Узнать подробности и забронировать цену — на странице курса.

#devops_upgrade

Вторник — день, когда мы традиционно решаем простые (или не очень) задачи ⭐️
#задача

Выберите правильный ответ в опросе ниже ⬇️

Сказки DevSecOps: вебинар уже через час ⌛️

🪩 Как перестать тушить пожары и встроить безопасность в процессы без потери скорости
🪩 Time-to-market и безопасность: можно ли совместить?
🪩 Где безопасность реально помогает бизнесу, а где — тормозит?
🪩 Как избежать простоя на миллионы?
🪩 Почему компании с системным DevSecOps теряют в 5 раз меньше данных?
🪩 Как перестать «докупать сканеры» и начать действовать?

Спикеры:

➡️ Андрей Сухоруков, Team Lead DevOps/SRE/DevSecOps (нужное подчеркнуть), Лаборатория Касперского

➡️ Артем Кармазин, ведущий эксперт внедрения процессов
безопасной разработки, Positive Technologies

➡️ Мария Шеховцова, руководитель направления архитектуры и анализа направления безопасной разработки, Positive Technologies

Ссылка на вебинар придет в бота перед началом трансляции. Подключайтесь!

Признайтесь, кто закрывает время в календаре на «пообедать»?

Уверен, что каждый из вас хотя бы раз так делал. А что, если я скажу, что такие «защищенные часы» могут помочь вам расти в карьере?

Когда операционка съедает все ваше время, вы не успеваете думать и, как следствие, расти. Загвоздка в том, что операционка съест время в любом случае — на то она и операционка. У вас всегда будут незавершенные задачи, проекты, созвоны и т.д. Чтобы у вас было время на рост, его нужно выделить.

➡️ Что такое «защищенные часы»?

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

➡️ Как внедрить?

Выделите час в неделю и создайте встречу с самим собой в рабочем календаре. Пропишите повестку, поставьте напоминалку и предупредите команду, что в этот час вы недоступны. Не двигайте, чтобы «доделать еще одну задачу» или «помочь, а то как же они без меня». Отменить или перенести «защищенный час» можно только в крайнем, критическом случае (уровень «апокалипсис», не меньше).

➡️ Чем заполнить защищенный час?
Читать. Апдейтить карьерный план. Разбирать итоги (что сработало, а что нет).
Важно! Это не час для отдыха. Это час для осознанного планирования и рефлексии.

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

Кроме того, у вас появятся темы для разговоров с руководством — когда вы понимаете ценность своей работы, «продать» ее становится проще.

И третье — отсутствие стагнации. Если регулярно анализировать свою работу, застоя не будет.

Ну что, кто будет пробовать? А кто уже пробовал? Делитесь в комментариях

🔥, если нужно больше подобных постов

Вы точно знаете, сколько денег съедают ваши облачные сервисы?

Слёрм запускает серию бесплатных встреч, на которых будут разбирать решения в области FinOps:

🪩 неверное использование облачных ресурсов из-за непонимания их специфики;
🪩 избыточную надёжность (SRE);
🪩 оverengineering — избыточное усложнение инструментов, пайплайнов, процессов.

➡️ Первый вебинар «Облачные решения: как снизить затраты и повысить эффективность?» — уже на следующей неделе.

Программа вебинара:
➡️ Типичные ошибки при работе с облачными сервисами и их влияние на бизнес.
➡️ Настройка сетевых сервисов и контроль доступа.
➡️ Как неправильный выбор ресурсов может привести к сбоям.
➡️ Почему резервное копирование — обязательная часть стратегии.

Когда: 11 июня в 17:00 мск

Занять место на вебинаре — через бота.

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

Сегодня пятница, а значит, можно поделиться тем, что произошло за неделю. Так что ловите сказ о том, что меня сильнее всего выбесило ⬆️

Почему в документациях никто не пишет, как на самом деле все должно работать? А ошибки в документациях — это вообще отдельная боль.

А что вас бесило на этой неделе? Поделитесь, чтобы уйти на выходные с легким сердцем⬇️

Как насчет обстоятельного разговора про управление кластерами?🤔

Мы с Виталием Лихачевым, спикером курсов Слёрма по k8s, решили провести совместный вебинар. Будем обсуждать Rancher в продакшене, а именно:

⭐️ централизованное управление кластерами через единый интерфейс;
⭐️ автоматизированные бэкапы и восстановление;
⭐️ настройку доступа для команд и интеграцию внешней аутентификации;
⭐️ встроенные мониторинг и использование магазина приложений.

Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой, поделимся собственным опытом и best practices.

Когда: 16 июня в 19:00 мск

Занять место на вебинаре ➡️ через бота.

DevOps Upgrade: летние гранты на обучение! 🍉

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

На летнем потоке их будет 10 для тарифа «Комфорт»:

⭐️ 2 места — скидка 100%
⭐️ 3 места — скидка 50%
⭐️ 5 мест — скидка 35%

Как получить грант:

➡️ Заполнить входную анкету
➡️ Пройти тестирование до 20 июня 2025 года
➡️ Дождаться результатов — их я объявлю на канале 23 июня

Тест состоит из 42 вопросов и помогает проверить вашу готовность к обучению — от знания Linux и Docker до мотивации. На прохождение дается 45 минут. Удачи!

#devops_upgrade

Вы неправильно готовите Rancher

Почему? Да потому что я сам его неправильно готовлю.

Сегодня в 19:00 встречаемся на бесплатном вебинаре с Виталием Лихачевым.

Будем разбирать:

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

Подробно покажем и расскажем, как Rancher упрощает эксплуатацию k8s и управление инфраструктурой.

➡️ Подключайтесь и задавайте вопросы, будем рады видеть каждого. Ссылка на трансляцию, как всегда, придет в боте.

⭐️ Стартуем через 15 минут ⭐️

Подключайтесь!

K3s vs RKE2: что использовать, и какая между ними разница

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

В мире Kubernetes развертывание дистрибутивов через kubeadm или полноценных кластеров часто избыточно. На помощь приходят облегченные решения, среди которых есть k3s и RKE2. Хотя оба преследуют цель упрощения, их философия и применение различаются.

Ключевые отличия:

1. Философия и Цель

➡️ k3s: максимальная простота и минимализм. Девиз: «5 секунд до запуска Kubernetes». Удалены все ненужные компоненты, многие заменены облегченными аналогами. Идеален для самых ограниченных сред, локальной разработки.

➡️ RKE2: пытается усидеть на всех стульях без существенного усложнения установки по сравнению с k3s. Сохраняет большую совместимость с «ванильным» K8s. Соответствие стандартам (FIPS 140-2, CIS Benchmark, ACSC Hardening Guide)

2. Архитектура и Компоненты

➡️ k3s:
- Один бинарный файл: весь сервер (control plane + kubelet) упакован в один исполняемый файл.
- SQLite вместо etcd: по умолчанию использует встроенную БД SQLite для хранения состояния (etcd — опция)
- Облегченные компоненты: kine (интерфейс между K8s API и различными бэкендами БД), flannel/wireguard (сеть), traefik (Ingress Controller), local-path-provisioner (Storage)

➡️ RKE2:
- Ближе к «ванильному» K8s: использует стандартные компоненты Control Plane (kube-apiserver, kube-scheduler, kube-controller-manager, etcd) из официальных образов CNCF, но упакованные в один бинарник rke2 для простоты управления.
- etcd по умолчанию
- Безопасные компоненты: Cilium (сеть с eBPF и улучшенной безопасностью) или Calico, CoreDNS, Metrics Server. Интегрированный rke2-ingress-nginx (на основе NGINX)

3. Что выбрать?

➡️ Выбирайте k3s, если вам нужен самый простой и быстрый способ запустить Kubernetes на маломощном устройстве или для локальной разработки, тестирования или CI/CD. Приоритет — минимальный ресурсный след и мгновенный старт.

➡️ Выбирайте RKE2, если вам нужен удобный в развертывании Kubernetes с соответствием стандартам (FIPS, CIS), или вы мигрируете с «ванильного» кластера и хотите максимальной совместимости. А может наоборот планируете в дальнейшем перейти на «ванильный». Приоритет — безопасность и соответствие без чрезмерной сложности управления.

В таблице привел сравнительную характеристику для удобства ⬇️