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

Предположим, некий "devops-инженер" пишет разнообразную автоматизацию пайплайна SDLC для своей команды разработки.
- Его видимая работа состоит в написании различных автоматизаций на YAML. Эти задачи можно положить в таск-трекер и проконтролировать их выполнение.
- Следующий слой работы состоит в интеграции отдельных шагов пайплайна так, чтобы артефакты между ними передавались правильно и без ошибок. Эти задачи в таск трекер положить можно, но только либо в виде самого описания или definition of done задачи по реализации шага пайплайна, либо в виде багов — когда один шаг вроде бы интегрирован с другим, но дает неверные результаты. Причем, технически эту задачу отделить от первого шага вполне реально — я часто советую ребятам сделать два эти шага по отдельности, когда они буксуют над подобной составной задачей
- Слоем глубже находится построение поведения пайплайна, состоящего из нескольких шагов. Например, мы сперва публикуем контейнер в хранилище, дальше этот контейнер сканируем на уязвимости и подписываем ключом, и в конце разрешаем запуск контейнеров на средах только если они подписаны. Эту задачу можно положить в таск-трекер как набор отдельных задач, но для того чтобы реализовалась именно функциональность "разрешить запуск только контейнеров просканированных на уязвимости" нужно эти задачи или объединить в какой-нибудь эпик, или тщательно описать что должно происходить для каждой из задач, или описать весь процесс отдельным документом и прикрепить его к каждой из задач. Создание такого описания и декомпозиция его на тикеты может быть отдельной задачей перед собственно написанием автоматизации на YAML, и задачей окажется довольно немаленькой.
Ну или можно завести одну большую задачу "реализовать проверку подписи контейнеров", подразумевая всю эту цепочку, и отдать выяснять детали самому инженеру. Но тогда как состояние выполнения этой довольно немаленькой задачи, так и собственно способ ее реализации становятся плохо верифицируемыми для стороннего наблюдателя. Иными словами, если мы ставим такие достаточно большие составные задачи (или мини-проекты) мы должны быть уверены в том, что сотрудник умеет их решать, и решает их хорошо.
- Если идти еще глубже, мы приходим к построению принципов и стандартов работы пайплайна самого по себе, и как они будут интегрироваться с рабочим процессом команд разработки. Из этих принципов у нас появляются задачи на реализацию элементов функциональности пайплайна — т.е. задачи предыдущего слоя. Такой вид задач требует как знания предметной области ("как правильно строить пайплайны") с одной стороны, так и совершенно нетехнических компетенций с другой стороны — навыков анализа систем, планирования процессов и декомпозиции решений на элементарные задачи.

Все это хорошо, но какая здесь связь с DevOps?

Дело в том, что ориентация на результат, анализ сложных систем и планирование их реализации — это набор необходимых характеристик любого технического руководителя. Декомпозиция целевого решения на отдельные задачи тоже.
Вся суть "методологии DevOps" состоит в том, чтобы включать в активности по проектированию целевой системы не только функциональные и нефункциональные требования заказчика, но также и части системы связанные с Инфраструктурой и SDLC. Это не столько "методология" или "философия", сколько домен знания наподобие "проектирования интерфейсов" или "построения даталейков".
Скорее всего будучи руководителем, реализацию различных частей системы ты отдашь сотрудникам с соответствующей квалификацией.
В этот момент и возникает потребность в devops-инженерах, которые на деле являются такими же разработчиками как фронтендеры, тестировщики или разработчики на Java.

Друзья из Флант недавно попросили меня поделиться видением того, куда движется DevOps и индустрия, и что с ней станет лет через 10.
После того как они опубликовали свою статью я понял, что хочу немного развернуть свои ответы.

В телеграм такой длинный пост не влезает, прочитать его можно у меня на сайте:
https://timurb.ru/kb/kuda-idet-devops/
https://timurbatyrshin.medium.com/ed8c5fd01b02

Если хочется обсудить — пишите в канале, здесь обсуждение получится скорее всего лучше

20 апреля, в субботу через две недели, выступаю на онлайн-конференции «Systems Design» по проектированию ИТ-систем с докладом «Построение модели грейдов через моделирование цепочек добавленной ценности».

Расскажу о том, как построение Value Stream можно использовать не только для построения CI/CD-пайплайнов, но и для быстрого построения модели предметной области любого процесса, и для разворачивание этой модели в набор требований — в данном случае, например, в требования к грейдам в компании.

Кому конференция будет особенно полезна?
— Разработчикам
— Архитекторам
— Системным аналитикам
— ИТ-специалистам, которые интересуются вопросами проектирования

Более подробно про конференцию, воркшопы и доклады Вы можете узнать в отдельном TG-канале и на сайте конференции

Об менеджерское и инженерное рассмотрение процесса разработки [1/2]

Если продолжать обсуждать переход от документо-ориентированных (document-centric) процессов управления к программно-задаваемым (software-defined) (предыдущие посты: раз, два, три), легко упустить одно обстоятельство, которое одновременно наиболее ярко покажет совершившуюся революцию (и возможно окажется, что это революция консервативная).

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

Менеджера в общем мало интересует содержание отдельных работ, его интересует выполнение взятых на себя обязательств исполнителями: чтобы разработчики в срок разработали код фичи и передали его тестировщикам, чтобы тестировщики протестировали фичу и передали его для деплоя на продакшн и т.п. Одна из основных задач менеджера - контроль таких обязательств. Если тот, кому передали результаты некоторой работы подписал акт приемки, менеджеру в целом не важно, работает ли фича на самом деле, закрывает ли она потребности клиента, т.к. обязательства прописанные в контракте выполняются. Ошибка на продакшне это всего лишь повод либо добавить в контракт "гарантийный срок на поставляемый результат" (как обязательство устранять дефекты в течение этого срока), либо открыть отдельный контракт на поддержку. И это все совершенно нормально и правильно, т.к. контракт за выполнением которого он следит - это интерфейс через который взаимодействуют организации. Если контракт плохо организован, начнет сбоить само взаимодействие.

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

Об менеджерское и инженерное рассмотрение процесса разработки [2/2]

Такое неоднородное вовлечение в процесс хорошо показано на "Горбатой диаграмме" из RUP (см выше).
Слева на право происходят фазы процесса разработки (можно провести параллель с состояниями тикета на доске или шагами пайплайна). Сверху вниз показаны роли, которые участвуют в каждой из фаз, и условный уровень их вовлечения в течение времени работы над проектом или фичей.

Итак, если рассмотреть особенности этих двух ролевые позиций - менеджера и инженера, то сразу становится ясна причина по которой звучат разные фантастические призывы вокруг DevOps, что мол "devops-инженер должен наладить взаимодействие между разными командами"  —  если смотреть на вещи как и прежде, с позиции менеджера, вполне закономерно будет казаться именно это. При этом, первый более-менее внятный ответ на вопрос в чем именно будет состоять «налаживание взаимодействия» кажется было дано лишь в подходе Team Topologies, и именно в нем снова начали говорить о «контрактах» между командами, до этого были достаточно пространные (с т.з. менеджера) слова про «коллаборацию» и «работу на общую цель», т.е. опять таки решение инженерное. UPD: скорее следующее будет не так, см обсуждение: Но раз у нас происходит разворот от менеджмента к инженерии, это налаживание взаимодействия (с т.з. корректировки обязанностей и контроля их выполнения) скорее становится новой задачей как раз таки менеджера (и это уже будет какой-то другой вид менеджера, например, scrum-мастер или менеджер потока). Инженерной же задачей здесь будет организация собственно технологического процесса, и этот технологический процесс будет затрагивать не только собственно конвеер CI/CD, но и фазы архитектурного проектирования и анализа. Как я писал чуть раньше, эту самую инженерную задачу скорее всего будет формулировать руководитель разработки. Devops-инженер же будет реализовывать по этому заданию конкретные компоненты сквозного процесса - подобно тому как разработчики реализуют бизнес-функциональность приложения по спеке/набору user stories от владельца продукта.

И еще один момент. Глядя на это же самое обстоятельство нельзя ставить знак "равно" между ITIL и DevOps. ITIL - дисциплина для менеджеров, даже несмотря на то, что в 4й версии его авторы изо всех сил постарались сделать его инженерным. Глядя же, например, на DevOps-топологии мы явно видим, что все топологии где идет речь о разграничении ответственности (т.е. о менеджерском взгляде на вещи) считаются антипаттерном для DevOps.

There is no “i” in IaC

Об платформенных инженеров [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 до производительности дисковой подсистемы и сопровождения в продакшне.

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

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

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

Об платформенных инженеров [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” дает людям хороший ориентир куда развиваться и к чему стремиться.
И одновременно закладывает в понятийное пространство нанимателей организационный паттерн “технологическая платформа”

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

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

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

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

Об 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 как справочная таблица, которую ты при необходимости можешь чуть-чуть доработать, но которой можно и пользоваться как есть

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

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

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

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

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

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

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

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

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

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

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

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

https://devopsconf2025.timurb.ru/

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

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

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

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

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

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

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

Об весенние конференции 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, портфолио и архрепозитории)