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

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...

Reading time: 3 minutes

Из всех тем, рассматриваемых в Team Topologies наиболее непонятная тема — это Enabling team, “модифицирующая” или “преобразующая” команда. Я буду использовать слово Модифицирующая Команда, потому что такой же перевод используется в Platen.

В самой книге про нее говорится многих общих слов типа:

Enabling teams have a strongly collaborative nature; they thrive to understand the problems and shortcomings of stream-aligned teams in order to provide effective guidance

или

The mission of enabling teams is to help stream-aligned teams acquire missing capabilities, usually around a specific technical or product management area

Read more...

Reading time: 1 minutes

Если сравнивать “просто стикеры” в миро и Archimate, то Archimate удобнее тем, что мы в нем получаем “встроенную” валидацию типов, которую в случае стикеров приходится выполнять более явно.

Скорее всего это применимо и для других формальных языков описаний (BPMN, UML и т.д.) в сравнении со “свободными” рассуждениями.

С другой стороны, если понимания типов у человека нет все нотации мгновенно становятся бессмысленными. А для коммуникации нужны именно типы, пространство понятий, а не нотация.

Read more...

Reading time: 3 minutes

В начале 20 века английский экономист Рональд Коуз изучал причину появления фирм на свободном рынке, и в своей статье Природа фирм он пришел к следующему:

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

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

Read more...