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

Reading time: 1 minutes

Святослав Котусев небезызвестный в кругах Enterprise Architecture своими исследованиями EA, выпустил новую версию своего легковесного фреймворка по Enterprise Architecture: https://eaonapage.com/

4 больших одностраничных карты против 1.5 тыс страниц TOGAF (в прошлой версии было 2 одностраничника):

Из изменений по сравнению с версией 1.0:

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

Рекомендую как минимум полистать всем, кто так или иначе сталкивается со следующими темами или интересуется ими:

Read more...

Reading time: 2 minutes

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

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

   Read more...

Reading time: 3 minutes

При ведении базы знаний у тебя есть несколько сценариев работы с информацией (по сути, жизненный цикл объекта информации-знания):

• Поиск внешний
• Сбор и учет материала, фиксация ссылок, выгрузка контента
• Осмысление материала, фиксация мыслей
• Анализ взаимосвязей между темами
• Корректировка и переработка материала
• Поиск материала в своей БЗ
• Обмен материалами с другими людьми / встраивание материалов в повседневную работу

Ключевое в ведении базы знаний — это то, чтобы эти сценарии происходили хоть как-то.

Read more...

Reading time: 4 minutes

Последний год или чуть больше достаточно большая часть моих задач на работе – организация пула devops-инженеров:

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

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

Read more...

Reading time: 4 minutes

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

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

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

Read more...

Reading time: 4 minutes

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

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

Read more...

Reading time: 6 minutes

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

Kubernetes

• Будет ли он ещё популярен через 5-10 лет?
• Какие технологии могут прийти ему на смену?
• Какие вызовы ему придётся решать?

Kubernetes никуда не исчезнет, он стал таким же стандартом, каким стал Docker для упаковки и передачи приложений. Пока что это стандарт на описание и композицию приложений и инфраструктуры. Но он сейчас достаточно быстро становится базой для стандартов, например, для комплаенса или интеграции с телеметрией, одним словом при помощи Kubernetes API уже значимое время описывают объекты, которые не всегда связаны с инфраструктурой напрямую:

Read more...

Reading time: 3 minutes

Меня очень вдохновляет язык моделирования Archimate при всех его недостатках. Я не особенно задумывался почему — на нем удобно отображать связи и взаимодействие между людьми, процессами, приложениями, технологиями, но кажется этого недостаточно чтобы служить вдохновением. Сегодня я понял в чем дело: за счет его метамодели у нас в рассуждениях появляется интерфейс, связывающий между собой понятия из самых разных областей.

Метамодель Archimate очень простая, это формула “cубъект — выполняет действия — с объектом”, и в дополнение представление ее же во внешний мир в виде сервисов и интерфейсов.

Read more...

Reading time: 2 minutes

(из неопубликованных архивов)

Некоторое время назад нашел простое и потрясающее объяснение того, когда нужно выбирать waterfall, когда scrum, а когда еще что-то другое.

Цитата (отсюда https://sebokwiki.org/wiki/System_Lifecycle_Models):

There are a large number of potential life cycle process models. They fall into three major categories:

  1. primarily pre-specified and sequential processes (e.g. the single-step waterfall model)

  2. primarily evolutionary and concurrent processes (e.g. lean development, the agile unified process, and various forms of the vee and spiral models)

Read more...

Reading time: 5 minutes

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

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

Read more...