2021-08-03 19:49:11
Когда количество команд в компании, использующих схожую инфраструктуру для разработки, начинает расти, появляется идея построения единой инфраструктурной платформы. Для этого многие строят специальные инфраструктурные команды с фокусом на разработку платформы. Идея в целом неплохая, но есть несколько опасных ловушек, о которых нужно знать перед стартом реализации.
Первая ловушка называется «платформа ради платформы». В неё можно легко попасть на этапе построения отдельной команды. Платформа строится ради обеспечения нужд продуктовых команд и облегчения их работы. Если платформенная команда не вовлечена в продуктовую разработку, а приоритеты в бэклоге задач выставляет лидер этой команды, то фокус может легко уйти в сторону разработки крутой платформы или использования интересных технологий.
Чинится это как минимум двумя способами. Можно раздать представителей инфраструктурной команды в продуктовые команды на 30-50% времени, чтобы они в полях глубже проникались проблемами и понимали что реально нужно командам. Это также будет полезно в рамках развития DevOps культуры в компании. Альтернативным вариантом, или дополняющим, является управление приоритетами в бэклоге задач представителями продуктовых команд (лучше всего для данной роли подходят техлиды). Для этого они собираются на регулярные встречи, где обсуждают самые горячие проблемы и расставляют приоритеты на ближайшее время в разработке платформы.
Вторая ловушка называется «убивающая поддержка». Чем больше начинают использовать платформу, тем больше времени начинает забирать ее поддержка. Дефекты, мелкие улучшения, инциденты и другие виды запросов начинают сильно перегружать платформенную команду. Без четко организованных процессов и SLA недовольство продуктовых команд растёт и начинается противостояние «мы - они», которое к добру не приводит.
Лечится снова таки как минимум двумя способами. Во-первых, все компоненты платформы должны быть максимально задизайнены на самообслуживание (self-service). То есть, любые типовые задачи как выделение ресурсов, модификация конфигурации и т.д. должны быть доступны для выполнения продуктовыми командами. Для общих задач поддержки четко поставленный процесс и SLA. Во-вторых, на старте использования платформы каждая команда должна найти выделенного инфраструктурного инженера на одну или несколько команд, который закрывает для них все вопросы платформенной поддержки. Это может быть инженер из платформенной команды на % времени.
Третья ловушка называется «а нам этого не говорили». Любая платформа предполагает определённые правила использования и стиль работы. Если он никак не формализован, то люди начинают работать как им кажется правильным, со всеми вытекающими проблемами. Ситуация усугубляется, если на платформу загоняют насильно, без мотивации ее использовать, знаний и опыта в используемом технологическом стеке.
Лечится традиционно двумя способами. Во-первых, формализацией гайдлайнов по использованию всех компонентов платформы. Чем большее количество вопросов они покрывают, тем меньше граблей и шишек будут собирать продуктовые команды. Во-вторых, программы обучения, онбординга и менторства для начинающих работу на платформе команд. Это позволит им получить не только начальные теоретические знания, но и поддержку на время адаптации.
Ну и напоследок, самый главный совет: постоянно собирайте детальную обратную связь с продуктовых команд об их опыте работы на платформе. Это лучший источник для понимания текущей ситуации и потенциальных проблем.
318 views16:49
L
