Об весенние конференции 2025

В апреле 2025 я делал два доклада на конференциях примерно на одну и ту же тему.

1. «Компетенции и уровни развития инженера инфраструктуры. Системный взгляд» на конференции DevOpsConf 2025.
Я рассказывал про то, как расти инженеру – во многом на базе материалов, которые я публиковал здесь на канале.
Я сам недоволен тем какой доклад получился, поэтому видео не выкладываю. При должном желании вы его найдете, или увидите его когда доклад опубликуют организаторы конференции.

2. «Бизнес-ориентированные модели компетенций: инженерный подход к построению» на конференции MergeConf 2025.
Доклад на базе той же модели, но без адаптации под конкретный профиль сотрудника, и чуть расширенная для того чтобы захватить не только направление devops.

В докладе я разбираю как деятельность любой организации разворачивается в проекты, в наборы компетенций проектных команд (более точное название – capability), знание предметных областей, и наконец, в набор элементарных навыков.
Модель может задать систему координат в построении моделей компетенций конкретно под вашу компанию.

Слайды доклада: https://mergeconf2025.timurb.ru/
Видео: https://youtu.be/iJl4kQq1YcY

Краткое содержание:

- Попытаемся рассмотреть модель компетенций как продукт, опишем сценарии ее использования, и через нее построим ее содержательно
- 5 основных сценариев, в которых пытаются использовать модель компетенций
- Уровень в организации определяется ответственностью за результат
- Декомпозиция результатов на составляющие и во времени
- Предметные области и шкала владения ей
- Жизненный цикл системы задает набор навыков необходимых команде
- Middle-минус работают не по результатам, а по задачам
- Типовая задача devops-инженера, которая встретится на любом проекте
- Построение карьерных путей — навигация по пространству ответственности
- Построение обучения внутри уровня — описание предметной области

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

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

Пример: Если ты знаешь не одну вендорскую коробку, а а две или три — это кажется и не рост вовсе. (Например, если ты помимо ELK изучил еще fluentbit, loki, vector и otel).

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

Святослав Котусев небезызвестный в кругах Enterprise Architecture своими исследованиями EA, выпустил новую версию своего легковесного фреймворка по Enterprise Architecture:
https://eaonapage.com/
4 больших одностраничных карты вместо 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):

Из изменений:
- Добавилась модель зрелости EA
- Добавились полтора десятка вариантов функциональной оргструктуры архитектуры (в зависимости от размера и типа организации), в т.ч. небольшой бенчмарк по количеству архитекторов в организации
- Расширилась карта практик EA (добавились связи с артефактами ЕА, появились примеры, карта стала более практической)
- Уточнены формулировке на карте артефактов

Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:
- Lifecycle объектов уровня солюшена и масштабнее
- Опермодель архитектурной функции и взаимодействие между отделами и проектами
- Виды архитектурной документации (обоснования, governance, портфолио и архрепозитории)

The Kubernetes design is based on choreography, but can incorporate orchestration benefits.

Пояснительная бригада: choreography и orchestration это два подхода композиции микросервисов (паттерна saga).
В случае orchestration есть отдельный микросервис, который оркестрирует процесс, проходящий через несколько микросервисов.
В случае choreography микросервисы обмениваются событиями напрямую.

Так вот, операторы в Kubernetes в общем случае работают в соответствии с подходом Choreography, а не Orchestration как мы могли бы подумать.

Что с этим делать? Ничего, просто забавное наблюдение 😃

Страница команды Github по продуктовым исследованиям (во многом на базе LLM).
В разных стадиях — от «набросок на салфетке» до «работающий продукт»

https://githubnext.com/

Интересный взгляд от Github на Platform Engineering в эпоху AI:
https://githubnext.com/projects/continuous-ai/

«Классические» платформы всегда event-driven, они предоставляют сервис в ответ на некий API-запрос, будь то вызов REST API или push в репозиторий.

С появлением понятия «агент» платформа может выполнять некоторую активность постоянно — переход от вызовов API к постоянному сервису. Робот-пылесос убирающий квартиру постоянно, а не только по запросу.

Промежуточным шагом к этому были операторы и шедулеры — условный cert-manager не просто выписывает тебе сертификат LetsEncrypt, а поддерживает его в актуальном состоянии.
Auto-scaling group или HPA не просто масштабирует нагрузки, а поддерживает оптимальное количество мощностей для них.
И то и другое — это по сути классическая работа operations. Написание автоматизации и ее конфигурирование — классическая работа разработки.

Если рассматривать результат работы agentic AI как некую активность над вверенным ему ресурсами (или шире — объектами), платформенную инженерию можно осмыслить по новому.
Не доставка товаров курьером по кнопке, а непрерывная доставка JIT.
Не сканирование кода на уязвимости по созданию PR, а непрерывное сканирование и их устранение. Раньше мы рассматривали dependabot и vulnerabot как ботов. Кажется теперь можно рассматривать их как first class citizen в платформах

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

В обычном цикле работы «гипотеза - реализация - оценка» напрочь ломается последний шаг, если его явно не выносить за рамки чата с LLM.
При этом, не важно занимаешься ли ты оценкой своей работы по факту — ты так или иначе ее получаешь в любом случае, и она в любом случае будет носить некоторый объективный характер.
В случае с LLM положительное подкрепление получаешь сразу же, при этом независимо от того что вы оба написали — если не развита саморефлексия, получится «я герой, и гитхаб не пустой, но время потрачено, а результата нет»