Помогаем исследовать и повышать продуктивность инженерных команд в технологических компаниях

Мы проводили аудит процессов и практик эксплуатации в компании, развивающей B2B SaaS платформу, с целью повышения стабильности платформы, масштабирования сервисов, развития процессов поставки и эксплуатации. Запрос был связан с ростом нагрузки на платформу, усложнением архитектуры и необходимостью выстроить более предсказуемую и устойчивую модель эксплуатации.

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

По результатам аудита были подготовлены рекомендации по следующим направлениям:

• Реорганизация команды эксплуатации, разделение ответственности между платформенной командой и SRE командой, а также улучшение взаимодействия с командами разработки;
• Развитие SRE практик, включая организацию дежурств, управление инцидентами, проведение пост мортемов, управление техническим долгом и техническими миграциями;
• Развитие Observability практик, включая мониторинг, логирование и трейсинг как основу для управляемой эксплуатации и диагностики проблем;
• Развитие и применение практик Infrastructure as Code и CI/CD для стабилизации и синхронизации окружений, а также автоматизации процессов поставки и развертывания.

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

Мы консультировали CTO и SRE команду в технологической компании с фокусом на развитие и масштабирование SRE процессов и практик в условиях роста бизнеса и увеличения количества команд. Управленческий запрос был связан с ростом нагрузки на SRE команду, необходимостью сохранить стабильность платформы и выстроить устойчивое взаимодействие между SRE и командами разработки на этапах разработки, тестирования и поставки.

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

По результатам работы были подготовлены рекомендации по следующим направлениям:

• Масштабирование дежурств SRE команды за счет улучшения передачи смен, учета пиков нагрузки и введения показателей фактической нагрузки на дежурных, включая количество алертов, инцидентов и задач;
• Построение дежурств в командах разработки без введения отдельной роли, с масштабированием уже работающей модели SRE дежурств на продуктовые команды;
• Развитие процессов управления инцидентами, обновление и расширение схемы инцидент менеджмента, дополнение чеклистов и постмортемов задачами по обновлению ранбуков;
• Формирование и использование бюджета ошибок (Error Budget) как управленческого инструмента для баланса между качеством и скоростью, на основе согласованных SLI, SLO и SLA и общего понимания надежности сервисов со стороны бизнеса и команд разработки;
• Запуск регулярных End-to-end тестов в Production окружении для более раннего выявления проблем, снижения количества алертов и повышения наблюдаемости;

Результаты консультации стали основой для масштабирования SRE культуры и практик.

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

В рамках проекта мы применили паттерны из подхода Team Topologies на уровне Reliability трайба. Провели анализ текущей структуры трайба, определили оптимальный состав и типы команд. Разделили направления Reliability Engineering, Release Engineering и Quality Engineering на платформенные и экспертные Enabling команды, что позволило снизить количество зависимостей, уточнить зоны ответственности и уменьшить операционную нагрузку, определить внутренние и внешние способы взаимодействия трайба и команд.

По результатам работы:

• Спроектирована целевая структура Reliability трайба и типы команд с учетом подхода Team Topologies, выполнено разделение направлений Reliability Engineering, Release Engineering и Quality Engineering на платформенные и экспертные Enabling команды;
• Устранены ключевые зависимости между командами внутри трайба, уточнены зоны ответственности, определены владельцы процессов и согласованы способы взаимодействия между платформенными и экспертными командами;
• Подготовлен Engineering playbook с паттернами, процессами и практиками для Reliability трайба и команд;
• Разработаны и проведены тренинги по Reliability Engineering на основе подходов Google SRE для тимлидов, техлидов и инженеров;
• Проработаны и внедрены практики Monitoring, Alerting, Incident Management, Troubleshooting, On-Call, Postmortems, SLI, SLO, SLA и Error Budget, а также подход к снижению toil как источника операционной перегрузки.

Проект заложил основу для системного развития культуры и практик надежности в компании.

Мы развивали процессы и практики надежности в EdTech компании среднего масштаба (около 250 инженеров). Управленческий запрос был связан с резким ростом нагрузки на платформу, увеличением количества продуктовых команд и необходимостью сохранить стабильность сервисов при кратном росте бизнеса. За короткий период нагрузка на системы выросла в 8 раз, а количество команд — примерно в 2 раза.

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

По результатам работы:

• Поддержан запуск платформенной команды, а также SRE и DevSecOps команд в формате Enabling команд;
• Определены границы ответственности и оптимальные способы взаимодействия между продуктовыми, платформенными и экспертными командами;
• Оформлены Team API для платформенных и Enabling команд как явное описание ожиданий, обязанностей и точек взаимодействия;
• Сформированы и реализованы рекомендации по масштабированию эксплуатации и надежности с учетом роста нагрузки и числа команд;
• Развиты и внедрены SRE практики, включая Observability, On-Call, Incident Management, Postmortems и Runbooks.

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

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

Исследование проводилось в форматах интервью и опросов с участием представителей 150 команд из 12 доменов. Для проведения исследования мы разработали все необходимые инструменты и использовали адаптированную модель DORA, дополненную практиками и метриками, применяемыми в компании. В качестве основы для анализа характеристик культуры использовалась типология Рона Веструма. В рамках исследования оценивались такие характеристики культуры, как обмен информацией, сотрудничество, общая ответственность, отношение к ошибкам и работа с улучшениями, с фокусом на выявление системных проблем и точек развития.

По результатам исследования:

• Создана модель оценки инженерной культуры в командах, включающая 6 ключевых характеристик, и сформированы гипотезы для дальнейшей проверки;
• Подготовлен опросник для оценки инженерной культуры с примерами проявления каждой характеристики, проведена оценка инженерной культуры в 150 командах из 12 доменов (охват 60%) в формате опросов и интервью;
• Рассчитан индекс инженерной культуры по компании в целом, доменам и командам, подготовлен интерактивный отчет с аналитикой по характеристикам, практикам и метрикам;
• Определены характеристики культуры в командах и связаны с уровнем зрелости технических практик;
• Определены практики и характеристики требующие приоритетного внимания и включены в инженерную стратегию для развития;
• На основе модели и аналитики разработано внутреннее платформенное решение для регулярной оценки инженерной культуры и практик.

Этот проект стал основой для системного управления инженерной культурой на уровне всей организации.

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

Для оценки соответствия использовались технические практики из модели Accelerate (DORA Core) и подхода Trunk-Based Development. В рамках анализа были изучены ключевые документы и материалы: стратегия развития платформы, архитектура, сервисы, процессы, практики, метрики, роли, шаблоны и интерфейсы.

По результатам анализа:

• Выделены категории процессов и стадии, которые структурируют жизненный цикл платформы и разделяют его на логические этапы;
• Подготовлен каталог процессов и практик с описанием, примерами, метриками и моделью зрелости;
• Построен радар практик и проработан жизненный цикл практик;
• Детально проработаны практики: Версионирование и ветвление, Непрерывная интеграция, Управление зависимостями, Качество кода и ревью кода, Управление окружениями, Автоматизация тестирования, Непрерывная поставка и управление релизами, Инфраструктура как код;
• Подготовлены рекомендации по развитию процессов и практик, а также по формированию собственной методологии.

Результаты проекта стали основой для системного развития платформенных сервисов и принятия инженерных и архитектурных решений.

Мы привлекались в рабочую группу по развитию и масштабированию практики Infrastructure as Code в платформенных и инфраструктурных командах крупной технологической компании. Запрос был связан с ростом и усложнением инфраструктуры и необходимостью унифицировать подходы и практики управления инфраструктурным кодом.

В рамках проекта была сформирована временная рабочая группа и проведен аудит текущих подходов и практик. Мы проанализировали используемые инструменты, провели сравнение и выбор решений (Puppet, Ansible, Chef, Salt), а также собрали сложные кейсы применения практики Infrastructure as Code в инфраструктурных и платформенных командах крупных технологических компаний. Отдельным направлением работы стало развитие экспертизы и практического применения подхода в командах.

По результатам работы:

• Проведен аудит практики Infrastructure as Code и выявлены ключевые ограничения и точки роста;
• Выполнено сравнение и обоснованный выбор инструментов с учетом масштабов и требований компании;
• Собраны и систематизированы сложные кейсы применения Infrastructure as Code в крупных инженерных организациях;
• Подготовлена и проведена серия мастер классов по практическому применению выбранных инструментов;
• Запущен пилотный R&D проект по переходу на новую версию инструмента;
• Разработан внутренний Development Kit, упростивший работу со структурой инфраструктурных репозиториев, зависимостями и шаблонами, а также улучшивший документацию и тестирование инфраструктурного кода.

Проект заложил основу для масштабируемого и управляемого развития практики Infrastructure as Code в компании.

Мы проводили исследование и развитие инженерной культуры и практик в крупном банке (2500 инженеров). Работа велась с центром компетенций DevOps, продуктовыми и платформенными командами. Запрос был связан с необходимостью системно развивать инженерные практики, выстроить единый подход к DevOps на уровне компании и повысить эффективность внутренних платформ.

В рамках проекта мы провели исследование текущего состояния инженерных практик, оценили зрелость команд и подготовили рекомендации по развитию внутренней платформы как продукта и сервиса. На базе подходов DORA была создана модель инженерных практик, применимая для регулярной оценки и развития инженерной культуры в командах. Для проведения оценки были разработаны инструменты опросов и аналитики, проведены исследования и анализ результатов. Процесс развития DevOps практик был адаптирован под текущие процессы банка и стандарты индустрии, включая технический ассессмент команд, материалы ЦК Agile и DevOps, радары по технологиям, каталоги практик и метрик.

По результатам работы:

• Сформирована внутренняя экспертная команда в формате Enabling команды;
• Разработан фреймворк и процессы развития DevOps на уровне компании и команд;
• Составлен каталог инженерных практик и метрик, подготовлены модели зрелости;
• Созданы инструменты для опросов и анализа состояния практик в командах;
• Подготовлены отчеты по результатам оценки, анкеты команд и рекомендации по применению;
• Сформирован бэклог и роадмап подключения команд к внутренней платформе и реализации конвейера CI/CD.

Результаты работы заложили основу для системного и управляемого развития инженерной культуры и DevOps практик в организации.

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

В рамках проекта было проведено исследование продуктовых и платформенных кластеров, включающих более 30 команд. Исследование проводилось в формате интервью с техническими руководителями и тимлидами, анализа задач в Jira, документации в Confluence, рабочих материалов в Miro, а также анализа OKR, моделей зрелости команд, внутренних платформ, дашбордов и метрик. Целью исследования было выявить системные ограничения, мешающие росту инженерной эффективности, и определить, какие практики и подходы могут быть масштабированы на всю компанию.

По результатам работы:

• Выявлены проблемы взаимодействия между кластерами и командами, а также ограничения, связанные с загрузкой и capacity продуктовых и платформенных команд;
• Определены сильные стороны инженерной организации и практики, которые целесообразно масштабировать;
• Подготовлены рекомендации по обновлению инженерных практик и метрик в Team Maturity Model;
• Сформированы варианты запуска и развития акселератора с учетом текущих ограничений и целей компании;
• Подготовлен отчет с рекомендациями, визуальные схемы и проведена презентация для руководства.

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

Мы привлекались как внешние эксперты в рабочую группу по исследованию проблем взаимодействия разработчиков с внутренней платформой в крупной технологической компании. Запрос был связан со сложностями использования платформы, большим количеством повторяющихся обращений от команд и отсутствием системного шаринга знаний о возможностях и правилах работы с платформой. В результате это негативно влияло на Developer Experience и замедляло онбординг команд.

В рамках работы мы начали с анализа уже существующей аналитики запросов от разработчиков и последовательно разобрали, почему у команд возникают проблемы при работе с платформой. Мы собрали и систематизировали информацию о текущем состоянии платформы: какие сервисы она предоставляет, где находится документация, какие существуют точки входа, как устроен онбординг, какие продуктовые метрики используются и как выстроено взаимодействие между командами и платформенной командой. Анализ проводился через призму Developer Journey, от первого знакомства с платформой до повседневного использования сервисов. Дополнительно был изучен релевантный опыт индустрии по решению схожих проблем, чтобы сопоставить текущее состояние платформы с лучшими практиками.

По результатам работы:

• Подготовлен документ с описанием всех путей входа в платформу, ссылками и комментариями с точки зрения разработчика, впервые изучающего документацию и сервисы платформы;
• Подготовлен документ с классификацией запросов от разработчиков: по сервисам платформы, командам, юнитам и кластерам, с описанием характера проблем, способов их решения и возможных причин возникновения;
• Подготовлен обзор практик и подходов, применяемых для улучшения Developer Experience, включая создание Enabling команд, формирование Community of practice, проведение Dojo и развитие практики InnerSource, с разбором применимости к контексту компании;
• На основе аналитики и опыта индустрии сформирован план выбора решения и запуска пилотной версии на ограниченном количестве команд.

Проект стал основой для системного улучшения Developer Experience и взаимодействия команд с внутренней платформой.

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

В рамках проекта мы провели исследование взаимодействия платформенных и продуктовых кластеров и команд. Работа включала интервью с представителями команд и руководителями, анализ документации в Confluence, задач в Jira, схем в Miro, а также анализ OKR, моделей зрелости, внутренних платформ, дашбордов и метрик. Фокус исследования был направлен на дизайн кластеров и юнитов, типы команд и способы их взаимодействия.

По результатам исследования:

• Построены AS-IS и TO-BE топологии кластеров, юнитов и команд, включая новые типы команды и способы внутреннего и внешнего взаимодействия;
• Выявлены проблемы оргдизайна: избыточное взаимодействие между командами, неясные зоны ответственности платформенных и продуктовых команд, сложный и дублирующийся Discovery и разрывы между Discovery и Delivery;
• Определены типы платформенных команд и их роль: платформенные команды внутри юнитов и на уровне кластера, зоны ответственности за платформы, инфраструктуру, эксплуатацию и общие сервисы;
• Подготовлены рекомендации по переходу к Stream-aligned командам, ограничению количества стримов на команду, снижению когнитивной нагрузки и уменьшению количества вариантов взаимодействия;
• Сформированы рекомендации по выделению Enabling команд для поддержки платформенных и продуктовых команд, с четкими API, интерфейсами и целями;
• Подобраны метрики для оценки состояния команд, способов взаимодействия, зрелости платформенных команд и эффективности масштабирования.

Рекомендации по применению паттернов из Team Topologies были переданы в рабочую группу и использованы как основа для разработки фреймворка масштабирования и планирования пилотных изменений на уровне кластеров и юнитов.

Мы привлекались в рабочую группу крупной технологической компании для обновления платформенного фреймворка и проектирования Internal Developer Platform. Управленческий запрос был связан с необходимостью повысить эффективность внутренних платформ, усилить роль платформенных команд и перейти к более системному и продуктовому подходу в их развитии.

В рамках проекта был проведен анализ топологий, структуры и способов взаимодействия платформенных команд между собой и с продуктовыми командами. Дополнительно мы выполнили детальный анализ существующего платформенного фреймворка, используемых практик и метрик, а также текущих подходов к управлению платформами. Работа велась с опорой на модель зрелости Platform Engineering и паттерны Team Topologies, а также включала анализ реальных сценариев использования платформ через построение Developer Journey Map.

По результатам работы:

• Подготовлены целевые топологии платформенных команд с применением паттернов Team Topologies;
• Построена Developer Journey Map по взаимодействию продуктовых команд с платформами и платформенными командами;
• Спроектирована целевая архитектура Internal Developer Platform;
• Сформированы рекомендации по применению продуктового подхода в платформах и определена роль Platform Product Owner;
• Проведен анализ аналитики и метрик, подготовлены прототипы платформенных дашбордов;
• Подготовлены рекомендации по обновлению платформенного фреймворка;
• Уточнены и обновлены цели и задачи платформенных команд.

Результаты стали основой для системного развития платформенных команд и запуска Internal Developer Platform как внутреннего продукта.