Об DevOps и архитектуру

Об вайбкодинг текстов

Примерно с октября я довольно плотно занимаюсь работой с текстом при помощи LLM + FPF.
Сперва Google AI Studio (бесплатный, хорош для быстрого старта), теперь ChatGPT Plus.

Из недавних открытий (и мне почему-то не встречались статьи про это) — работа с текстом не через WebUI, а через IDE+coding agent.

Проблематика следующая:
Примерно от 1-2 страниц текста, у тебя в нем появляется заметное количество взаимозависимых объектов.
Когда какой-то меняется, их неплохо бы обновлять и «пересчитывать» — примерно как в случае с Openspec, Spec-Kit, которые описаны выше.
А если текст структурирован, доработок много, то в чате начинаешь быстро теряться, забывать скопипастить какие-то строки, соглашения, терять диффы и т.д.
Иными словами, поболтать с моделью в UI легко и приятно, но непродуктивно если что-то нужно получить на выходе — выгребать ценное из гор слопа сложно и муторно.

Но когда разговариваешь с LLM в IDE, агент сам фиксирует и типизирует все объекты, фиксирует принятые решения и вообще ведет подробный лог изменения документов.
Скорее всего на старте разговора нужно настроить AGENTS.md и структуру репозитория, но если опыт с этим есть проблем с настройкой не должно быть.

Вот пример моей настройки: https://github.com/timurb/fpf-workbench.
Для использования клонируем+копируем репозиторий, открываем в любой IDE с подключенным агентом, подробно описываем свою ситуацию и просим сохранить как вводные данные. Дальше просим дать такие или иные ответы, или сделать корректировки, и они появляются прямо на диске.

В следующем посте о том, что я собираю с помощью LLM.

Как я написал в прошлом посте, меня как и во многих других вещах, в контексте LLM интересует в первую очередь методологический аспект: как работать с ними эффективно?
При этом я намеренно не задаю определение слова «эффективно», чтобы можно было применять этот подход в разных контекстах.

В этот раз я не буду писать долго и много, и просто порекомендую посмотреть на https://github.com/Fission-AI/OpenSpec/
Это одновременно метод и инструмент для построения coding workflow вида «планируем фичу -> проектируем архитектуру -> пишем тесты -> пишем код».

На базе него эту эффективность собрать кажется достаточно несложно независимо от того что вы понимаете под «эффективностью»:
- если вам дела нет до документации можно ее оставить только как опору для агентов
- если вам техническая документации нужна, здесь уже есть готовый каркас на базе которого можно строить и не выдумывать его самому
- каркас довольно легковесный, при этом его можно дорабатывать (например корректировать какая именно документация вам нужна)

(уточнение: я пока не могу сказать насколько он сочетается с полностью автономными coding agents)

Похожие инструменты/подходы, но менее удобные для старта по тем или иным причинам:
- https://promptdriven.ai/ — кажется, один из первых подходов «спеки -> доки», который так и не выстрелил, да и помер. Смотреть на него не рекомендую.
- https://github.com/github/spec-kit — более детальный по сравнению с OpenSpec и кажется более тяжеловесный подход от Microsoft
- https://github.com/bmad-code-org/BMAD-METHOD — на мой взгляд чрезмерно формализованный
- Plan & Act — самый простой, но и наименее мощный из всех

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

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

С этими LLM одни проблемы — количество идей увеличилось в несколько раз. Когда их воплощать то?

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

У меня получилась такая эвристика: «если после разговора с LLM ты не почуствовал себя дураком, или не ушел из разговора с вооот такенным списком задач — ты поговорил зря» — знай эти задачи как-то приоритезируй и разгребай. Но в разгребании радости гораздо меньше чем собственно в поиске решения.

Навык «разбивать большую задачу на много маленьких, каждая из которых приносит пользу» становится еще более актуальным чем во времена пост-ватерфола: сейчас становится супер легко попасть в ловушку over-engeneering, причем сразу на множестве уровней одновременно: уровне описания проблемы, уровне описания концепции решения, уровне постановки задач, уровне проработки архитектуры решения, уровне определения и проработки границ между компонентами, уровне определения качества этих компонентов. Чуть промахнулся — получил тонны нейрослопа, который еще не сразу заметишь.
На уровне реализации все наоборот, хорошо — написал задание, модель тебе написала ответ. Но попутно тут же наплодила долга на всех перечисленных уровнях (и нескольких не перечисленных).

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

Что любопытно, практики Devops описанные отцами-основателнями и далее превратившиеся в DX, Evolutionary Architecture, и частично Platform Engineering на концептуально-методическом уровне вполне неплохо помогут справиться с возросшей сложностью.
У тебя внезапно продуктивность команды разработки становится такой, что может делать десятки коммитов в день (хотя до этого хорошо если коммит в неделю).
Как вы думаете, станет ли после этого команда High Performer по DORA? Увеличится ли частота релизов, снизится ли Lead Time, снизится ли CFR?
Чем будут заниматься разработчики, которые внезапно «стали суперпроизводительными»?

Мне кажется, количество работы возрастет для всех:
- для разработчиков — нужно будет научиться разбираться не только в легаси-коде, но и в нейрослопе, и срочно учиться становиться техлидами
- для техлидов — появится головная боль как обеспечивать поддерживаемость и качество кода, которые до этого держались на их авторитете, опыте и peer review
- для девопс-инженеров — вариантов не интегрировать проверки (все какие можно) в пайплайны больше не осталось. Ну и запросов от команд разработки будет больше (если только не реализован self-service для них)
- для операционных менеджеров/менеджеров бэклога — количество технических задач без которых delivery не поедет значительно возрастет, и им придется научиться въезжать в технические вещи
- для руководителей в целом — кратно вырастет количество решений, которые им нужно будет принимать

Ну либо еще пока можно оставаться в древнем начале 21в, когда все писали код руками — кстати, тоже очень неплохой вариант, пока не появились подходы коллективной работы с участием LLM.

Всех с новым годом!

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

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

Интересный взгляд от 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 в платформах

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

https://githubnext.com/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Об ведение базы знаний
(копия моего поста в одном из чатов)

При ведении базы знаний у тебя есть несколько сценариев работы с информацией (по сути, жизненный цикл объекта информации-знания):
- Поиск внешний
- Сбор и учет материала, фиксация ссылок, выгрузка контента
- Осмысление материала, фиксация мыслей
- Анализ взаимосвязей между темами
- Корректировка и переработка материала
- Поиск материала в своей БЗ
- Обмен материалами с другими людьми / встраивание материалов в повседневную работу
Ключевое в ведении базы знаний — это то, чтобы эти сценарии происходили хоть как-то.
Ты лично должен их осуществлять — за тебя никакой инструмент не запишет твои мысли после прочтения статьи.
Но может помочь с этим (предоставив удобную локацию для записи и удобный интерфейс), или помешать (заставив тебя задумываться куда именно записывать).

Ну и инструменты обычно помогают только с какими-то небольшим набором сценариев.
К примеру, OneNote хорошо помогает фиксировать ссылки ко встречам в аутлуке, выгружать с них контент (мой основной юзкейс для него), но не помогает со всем остальным.
А Obsidian/Logseq из коробки с этим никак не помогают и здесь у нас разрыв в деятельности (если кто-то может рассказать как быстро и просто из календаря в аутлуке попадать в страницу в obsidian, и из нее обратно в календарь — я буду очень благодарен).
Хорошие инструменты помогают с большим количеством сценариев — по сути удобны для всех этих сценариев кроме разве что поиска внешнего (и поиск это отдельная большая важная тема) и обмена материалами с другими.

Часто возникает и куча смежных задач для инструмента, типа работы с задачами, рисования и т.д. — это часто реализуется через плагины, здесь Obsidian на высоте.
А с поиском внешним (в интернете, в корпоративном поиске или других системах) никак не помогают.

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

Я могу описать несколько принципов, которым стараюсь следовать:
- Не держу миллион вкладок в броузере, ссылки сохраняю в БЗ и в двух словах пишу что это и зачем (например, «Сравнение инсталляторов Kubernetes https:///ссылка»)
- Если прочитал статью и нашел ее интересной — выгружаю ее снимок в Zotero, т.к. через год-другой ее в интернете уже не найдешь. Кстати, можно попробовать вести таким образом библиотеку контента из интернета расшаренную на компанию. Плюс линкую в БЗ в виде отдельной страницы (происходит автоматом в виде плагина)
- Если нужно письменно о чем-то порассуждать — делаю это в БЗ, и сразу проставляю [[ссылки]] на другие страницы, чтобы через полгода при поиске информации можно было найти свои старые мысли через обратные ссылки/backlinks. Конкретно в этом пункте в Obsidian будет некоторое ограничение, т.к. в нем (в отличие от Logseq) по-моему нет ленты/журнала в который я пишу мысли не задумываясь «в какое место их положить», и обратных ссылок в Obsidian тоже по-моему нормальных не было
- Предыдущий пункт мне позволяет «автоматически» создавать страницы про концепты и делать связи между не связанными на первый взгляд темами. Пример в скрине ниже — я не писал ничего про Engineering, но в 5 страницах ссылался на термин, плюс Logseq мне нашел еще 117 страниц, где слово встречается в тексте
- Если где-то написал что-то что захочу сохранить (например, этот пост) — копирую к себе в БЗ.
- Ну и все вообще записи (кроме проектных) веду в Logseq — поэтому он останется приватным
- Вся проектная активность — вокруг корпоративного стека MS Office (Outlook, OneNote) и проектных Gitlab/Wiki/и т.п.

Вот по сути вся моя методология ведения базы знаний. Поделитесь своей?

Во вторник, 8 апреля, на конференции DevOpsConf буду рассказывать о том, как и куда можно расти инженерам.

https://devopsconf2025.timurb.ru/

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

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

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

Итак, компания собирает команду под некую бизнес-задачу, и я считаю, что к команде можно применить обычные методы проектирования систем.
Сперва рассмотрим команду как черный ящик — пока не будем заглядывать внутрь и опишем какие задачи нужно выполнять команде.
Это может быть в зависимости от степени непрозрачности этого ящика, например:
- Автоматизация неких существующих бизнес-процессов
- Не просто автоматизация, но и реинженеринг таких процессов
- Создание и реализация пользовательского пути
- Создание новой функциональности
- Создание новой системы (или приложения) с нуля
- Доработка функциональности существующей системы
- Поддержка существующей системы.с минимальными доработками
- и т.д.

Сейчас это все звучит немного абстрактно и непонятно, поэтому давайте опишем более конкретно, например:
- Создание масштабируемой системы логирования
- Перестройка пачки ямлов в платформы разработки

Или если отойти в сторону от инфраструктуры и devops, это может быть например:
- Создание электронного кошелька
- Развитие системы управления складом

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

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

Навскидку у меня получаются следующие сценарии использования:
- Стаффинг на проекты — определение состава проектной команды
- Оценка кандидатов при собеседованиях и промо
- Построение путей развития сотрудников
- Внепроектный поиск компетенций в компании для консультаций

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

Какие еще сценарии использования использования моделей компетенций я пропустил?

Об IT-компетенции [2/2]

Помимо всего прочего за это время я изучил модели компетенций SFIA и iCD и хочу поделиться мнением об их сходствах и различиях (см. также сравнение от самих SFIA):
- И то и другое — модели компетенций с библиотекой, которая описывает собственно компетенции необходимые для профессий в IT
- SFIA – результат деятельности рабочей группы, которая его разрабатывают уже более 20 лет на базе того как работают компании в мире
- iCD начинался так же (в рамках Японии), но сейчас основан в большей степени на большом количестве стандартов и BoK (BABOK, SWEBOK, PMBOK, ITIL 2011, DMBOK, COBIT 5, CRISP-DM, японские внутренние стандарты), что на мой взгляд хорошо, т.к. не приходится переизобретать велосипед
- В iCD нет аналогов SFIA View (например, SFIA DevOps View или SFIA Cyber security View). Про SFIA DevOps View есть доклад Евгения Харченко.
- В SFIA описываются только “навыки”, в iCD описываются как “задачи” для той или иной роли (по факту, примерно то же что навыки SFIA), так и навыки, которые им соответствуют. Подробнее об этом можно почитать либо в сравнении от SFIA (ссылка выше по тексту), либо прямо в самих моделях.
- К примеру, в iCD задаче “Preparation for development environment” соответствуют навыки “Architecture design methods”, “Application architecture design methods”, “IT infrastructure building process”, “Systems Interoperability technology”, “Development process and methods”, “Development environment management”, “Standardization (software)”
- В iCD супер детально прописаны как классы задач (которые как я уже сказал, в целом примерно то же самое что компетенции SFIA), так и навыки необходимые для выполнения этих задач. Против ~100 навыков SFIA в iCD ~200 видов задач, которые детализируются в ~600 уточненных задач и в ~2500 элементарных операций. Плюс к этому ~500 навыков, которые разворачиваются в ~10 тысяч детальных объектов знания. Они группируются в дерево из 4 уровней, т.е. в них навигация довольно простая. В итоге можно брать и прям по рубрикатору выписывать все необходимые пункты. При необходимости можно расширить своими собственными пунктами, или чуть поменять формулировки в словаре
- Дополнительно в iCD благодаря Task Dictionary Chart можно посмотреть на ЖЦ некоей инициативы в организации, приложить к ней возможную ролевку и сразу есть ориентир какие из навыков нужны
- Вместо этого в SFIA детально вольным образом прописано для каждого навыка что именно требуется на каком уровне. К примеру, для “Release management” прописано (мой вольный перевод с сокращениями), что сначала специалист помогает с релизами, затем начинает принимать участие в их планировании, потом начинает разрабатывать подходы и автоматизацию, и самый высокий уровень – разрабатывает стратегии и стандарты. Для данного навыка описаны 5 уровней из 7, применение навыка на оставшихся двух не характерно.
- Уровни довольно сильно отличаются: в SFIA довольно детально прописана детализация для каждого из 7 уровней, причем каждый из них рассматривается в нескольких аспектах и детально прописывается под каждый навык. В iCD такой детализации нет, для всех задач и навыков есть 5 уровней (без опыта -> учебный опыт -> работа под руководством -> самостоятельная работа -> обучение других), плюс сверх этого для навыков есть еще 3 уровня “общественного признания”. Мне такой подход кажется более простым для понимания, применения и гармонизации с другими моделями.
- В целом SFIA мне показался больше подходящим для творческого осмысления и переработки под себя, а iCD как справочная таблица, которую ты при необходимости можешь чуть-чуть доработать, но которой можно и пользоваться как есть

Об IT-компетенции [1/2]

Последний год или чуть больше достаточно большая часть моих задач на работе – организация пула devops-инженеров:
- построение найма (в т.ч. делегирование найма самим ребятам) и работы HR-специалистов
- уточнение критериев к грейдам
- описание типовых задач, которые команды devops закрывают на проектах
- классификация разношерстных проектных запросов на нашу грейдовую сетку (чтобы проекты перестали запрашивать лидов на “развертывание софта по инструкции”)

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

Я расскажу про онтологию получившуюся в результате всего этого движа своем докладе на конференции DevOpsConf 2025, которая пройдет 7 и 8 апреля. Цена билета будет расти в течение всего времени до начала конференции, есть вероятность что за пару недель до ее начала билеты закончатся.

Об платформенных инженеров [2/2]

В свете вышесказанного видится, что “платформенный инженер” как отдельная специальность/должность скорее всего будет актуальной исключительно для компаний, для которых сверхбыстрое и сверхпредсказуемое ИТ является важным конкурентным преимуществом, а не просто способом снизить стоимость реализации проектов. При этом компания будет достаточно большой (от нескольких десятков команд), чтобы IDP выделять как отдельную сущность. Т.е. в первую очередь “платформенные инженеры” будут существовать только в бигтехе и scale-ups в высококонкурентных областях. Либо в высокорегламентированных областях типа медицины, но там их задача будет не ускорение разработки, а обеспечение повторяемого качества релизов любых команд и соответствию регуляторке, и такие платформы вероятно будут достаточно сильно отличаться от платформ в компаниях, работающих в “экономики скорости”. Во всех остальных случаях термин «платформенный инженер» кажется не будет иметь смысла.

При этом “платформенная инженерия” вполне может и будет оставаться актуальным доменом проектирования систем, примерно таким же как “проектирование СЭД” или “проектирование WMS”, именно потому что автоматизация работы команд разработки так или иначе нужна всем, только работать в этих командах будут работать не Platform Engineer, а классические Software Engineer либо Devops Engineer.

Но тем не менее я поддержу термин “платформенный инженер” по одной простой причине. До сих пор не было хорошего способа способом самоидентификации для “devops-инженеров”, “automation engineer”, “build & release engineer”, и всех тех, кто попал в зазор между “developers” и “operations”. Были попытки в виде SRE и Cloud Engineer, но они захватили только часть всей профессии “devops-инженер”, поэтому проблема самоидентификации никуда не исчезла.

Теперь этот способ самоидентификации появился, и при всех его приведенных выше недостатках он выглядит достаточно неплохо: термин “Platform Engineer” дает людям хороший ориентир куда развиваться и к чему стремиться.
И одновременно закладывает в понятийное пространство нанимателей организационный паттерн “технологическая платформа”

Об платформенных инженеров [1/2]

Некоторое время назад я озвучивал свое мнение о том, что такое “devops-инженер” (спойлер: определенный вид разработчика), однако на днях было указание на термин “платформенный инженер” (спасибо, Антон!).

Несмотря на то, что термин “platform engineer” постепенно распространяется, я не считаю его верным. Но вместе с тем он может оказаться полезным.

Platform Engineering это домен проектирования, предметная область, такая же как, например “трансграничные переводы” или “автоматизация склада”, или шире “финтех” и “ретейл”.

Platform team разрабатывает Технологическую Платформу (вариант: Инфраструктурную Платформу, Internal Developer Platform, IDP)  —  систему, автоматизирующую деятельность сотрудников организации, только в данном случае не финансистов или кладовщиков, а программистов. Для автоматизация работы склада это может быть как коробочное решение (например, 1С Управление складом), так и полностью самописное решение. То же самое с Технологической Платформой  — есть вендоры, которые предлагают готовые решения, но чаще всего их собирают некие-инженеры из опенсорсных компонентов самостоятельно.

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

К примеру, платформенная команда занимающаяся компонентами платформы на базе Backstage будет состоять из typescript-разработчика, devops-инженера и DX-чемпиона (в России его скорее всего назвали бы не чемпионом, а аналитиком). Платформенная команда занимающаяся DBaaS будет состоять из Postgres DBA, Golang-программиста, фронтендера и архитектора. А платформенная команда занимающаяся мониторингом будет состоять из спеца по тюнингу прометеуса, девопс-инженера, голанг разработчика и DX-чемпиона.

Если проект маленький, все эти роли могут быть совмещены в одном человеке  —  в этом случае его можно будет назвать Platform Engineer. Но с большой вероятностью он тогда будет заниматься и задачами команд и ИТ за пределами собственно платформы. Иными словами, попробуйте в этом случае найти три отличия от “devops-инженера”, кроме названия.

Если проект большой – команда будет естественным образом больше. В кроссфункциональной команде возникнет либо разделение работ, либо разделение труда.

Разделение работ (“артель”) - это когда несколько взаимозаменяемых T-shape специалистов с примерно общими для всех компетенциями работают над общим проектом. В этом случае, наверное, термин platform engineer будет вполне корректным. T-shaped платформенные инженеры закрывают все задачи в создании Платформы от проектирования UI и API до производительности дисковой подсистемы и сопровождения в продакшне.

Разделение труда (“производство”) - это команда в которой каждый выполняет свою часть функциональных задач: фронтендер пишет фронтенд, голангер пишет голанг, а девопс настраивает интеграции.

В первом случае (“артель”) команда будет эффективнее с т.з. результативности и проще в управлении, но сложнее в подборе и дороже по стоимости, т.к. будет требовать сеньорных разносторонних экспертов, либо будет требовать развитого и хорошо поставленного процесса онбординга, либо будет необходимо наличие большого количества таких “разносторонних экспертов на рынке” (чего не случится никогда).

Во втором случае (“производство”) команда будет менее гибкая, скорее всего сложнее в эффективном управлении, но проще в подборе и масштабировании.

There is no “i” in IaC