Обожаю этот канал.
Теперь они ещё и выпустили update по devops
https://youtu.be/rXPpkzdS-q4?si=j3GV73Pf10EqY2Es

Всем привет!

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

Немного о себе:

🟠 DevOps Culture First.
Начём с того, что изначально мой путь виделся мне, как путь "Linux engineer"! Я копался в Linux, разбирался в сетях, бился головой, изучая, как работает инфраструктурный софт типа nginx или MySQL.
Больше всего мне нравилась автоматизация... Bash-скрипты, cron, немного Python, сама мысль, что с помощью автоматизации можно строить по-настоящему крутые и автономные системы.
При этом, мне нравилось и программировать, я разбирался в том, как работают бекенды, базы данных, как устроена большая разработка.
Пока рос я и мои компетенции, развивалась и сама индустрия. У нас появились контейнеры, Infrastructure as Code инструменты, и целая культура, которая призвана объеденить все то, что мне так нравится. DevOps!
Когда я услышал о DevOps впервые, кажется, я сразу же почувствовал, что это резонирует с тем, что мне искренне нравится.

Я всегда оставался сторонником мнения, что культура и процессы первичны, и только потом идут конкретные паттерны или инструменты. Я всегда старался быть get in touch с командами разработки, хоть рынок старательно пытался выделить DevOps в отдельную роль.

🟠 Kubernetes Enjoyer.
Признаюсь честно — я большой фанат Kubernetes :)
Иногда, когда ко мне приходят с проблемой X, я шучу: "Просто поставь Kubernetes — и всё будет!" Конечно, это сильное преувеличение. Но правда в том, что Kubernetes — технология, которую я искренне люблю. Видно, как она стала стандартом в индустрии. Она закрывает массу задач "из коробки", а возможности по расширению...

Немного о топиках и о том, какого рода контент здесь будет.

🟧: Разбор культурного аспекта работы DevOps и взаимодействия с командой(беки, фронты, QA, PM).
🟧: Практические кейсы из разряда: "Ко мне пришли с проблемой Х и я хочу поделиться решением со всеми"
🟧: Мои эксперименты и отражение моего пути обучения новым технологиям

Я рад видеть всех пристутствующих на моем канале!

Один из культурных аспектов DevOps — это мотивация, с которой инженеры совершают те или иные изменения.
Продвигая data-driven decisions, мы всё чаще смотрим на цифры, а не на ощущения.
Я бы хотел рассказать о четырёх основных метриках, которые двигают DevOps.
О четырёх метриках, из-за которых у вас опять перепиливаются пайплайны снова и снова.

Речь идёт о DORA метриках.
DORA – DevOps Research and Assessment
Это исследовательская группа, которая вывела 4 метрики по которым можно понять "девопсовость" команды.

Вот эти 4 метрики:
1. Deployment Frequency
Частота деплоев в прод. Больше лучше.
2. Lead Time for Changes
Время от момента, когда задача получила статус "В работе", до момента когда задача оказалась на проде. Меньше лучше.
3. Change Failure Rate
Процент деплоев на прод, которые привели к ошибкам(С какой частотой у нас падает прод после релиза). Меньше лучше.
4. Time to Restore Service.
Время, которое требуется, чтобы упавший сервис, снова начал работать. Менньше Лучше.

Именно на эти показатели ориентируются devops в своей работе.

Deployment Frequency

Девопс: У нас stage вообще не соответствует проду. Давайте за неделю стабилизируем stage.
И все изменения сначала будут попадать туда.

Стабилизация stage может повлиять на количество доставленных фич, но на самом деле
Стабильный прод -> тестирование на актуальном stage -> меньше страха -> чаще катимся в прод, быстрее доставляем фичи.

Lead Time for Changes

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

Данный пример показывает, как изменение, которое кажется наоборот замедляющим(автозакрытие MR)
Может спровоцировать ускорение ревью.

Change Failure Rate(CFR)
Процент деплоев на прод, которые завершились ошибкой.

Девопс: Нам нужно добавить endpoint /healthz
Который будет отдавать 200 OK если сервис работает корректно.

Казалось бы это не несёт никакого value, и опять какое-то странное требование, но на самом деле мониторинг этого эндпоинта напрямую влияет на CFR

Time to Restore Service

Девопс: Нам нужно добавить smoke-тесты
В случае провала которых мы будем откатывать прод автоматически

По-сути, это изменение, которое может очень сильно сократить время которое требуется, на восстановление сервиса.

Когда DevOps приходит с идеей:
- Давайте настроим stage
- Давайте добавим smoke-тесты
- Давайте перепишем пайпы
Это не прихоть и не абстрактное желание "сделать красиво".
Почти каждое такое изменение призвано улучшить одну из DORA метрик.
И такие предложения являются ответом на проблемы, которые появляются в общем процессе доставки и эксплуатации кода.

А у вас отслеживаются DORA метрики?
Как вы считаете пайпланы должны постоянно меняться/улучшаться?
Или работает и не трогаем?

Знание DevOps = рост в ЗП? Окупится ли обучение?

Количество вакансий, где требуется DevOps‑компетенция, выросло почти в  2,5  раза за последние пять  лет.
Даже чайка‑менеджеров теперь просят понимать, как выкатывать сервисы в  продакшен…

Однако это не те знания, которые легко получить. Бытует мнение будто бы Девопс инженерам платят много - намного больше чем разработчикам - но их знания это рокет сайнс и вкатываться туда тяжело и долго.

Антон - Senior DevOps, построивший с 0 инфраструктуру и CI/CD процессы в нескольких компаниях. Он ведет канал о популяризации девопс технологий и знает, какие навыки необходимы для заработка от 500к+ в этой сфере.

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

❗️Оставь свой вопрос в форме под анонсом стрима -мы обязательно на него ответим. Подписка на стрим поможет не упустить разбор конкретно твоего кейса.

Дата стрима - 31.07 в 18:00

Ужe через 30 минуток начинаем совместный стрим c JAVA GYM RAT !!!

Обменяемся взглядами на DevOps и разработку, поговорим вкате, ответим на ваши вопросики!!!🐳

Ссылка!!!