Какие практики бывают в разработке и эксплуатации, и как их внедрять? И как масштабировать практики и оценивать их с помощью метрик? Какие сложности можно встретить на пути?

Привет, Хабр! Меня зовут Евгений Харченко. Моя роль в Райффайзен Банке — руководитель отдела по развитию практик в разработке и эксплуатации. А еще уже пять лет я — Senior Community Lead DevOps, хотя начинал с роли инженера тех. поддержки ServiceDesk. Еще я — член программного комитета DevOpsConf.

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

Контекст

В Райффайзен Банке работать интересно. Мы постоянно совершенствуем цикл разработки и эксплуатации с помощью разных технических решений. У нас 11 крупных профессиональных сообществ и 10 рабочих доменов, где каждый посвящен каким-то бизнес-функциям. В доменах есть команды — всего 262. А еще есть комьюнити по разным технологиям. Люди из доменов и комьюнити объединяются, делают совместные инженерные решения, выдвигают инициативы. Я работаю в домене инфраструктуры, развиваю свои команды и представляю одно из сообществ.

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

Чтобы договариваться, нужны практики, метрики и стандарты. Они позволяют объединять людей и делать что-то унифицированное. Это, в нашем случае, жизненная необходимость.

В Райфе люди работают под объединением бизнес доменов, которые состоят из команд, а команды создают различные продукты. С какими же проблемами мы сталкивались чаще всего:

• Скорость разработки. Темпы разработки не позволяют оперативно адаптироваться к изменениям. Мы хотим делать быстрее. Причем ускорение измеримо конкретными цифрами.

• Качество кода. Отсутствие минимально необходимого уровня качества разработки взращивает ошибки и дефекты. Качество кода влияет на стабильность.

• Разнообразие подходов и инструментов. Увеличивает риски дублирования усилий и снижает стандартизацию.

Pain Index

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

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

Путь состоял из трех этапов:

• Первые три года (2019 – 2021). IT стандарты, внедрение новых практик и критериев оценки.

• 2022-2023 года. Внедрение DORA метрик, трансформация стандартов к лучшим практикам, исследования инженерной культуры.

• 2024. Новые подходы и платформа практик.

IT-Стандарты. Ретроспектива 2019-2021

В 2019 году у нас появилась инициатива по цифровой трансформации компании.

На тот момент был отдел объединения команд Acceleration Team. Суть была в том, чтобы внедрять DevOps практики, проводить цифровую трансформацию. Отдел в коллаборации с CTO доменов строили расчеты DORA метрик эффективности. На тот момент в компании в качестве CI/CD-платформы использовались Bamboo и Bitbucket.

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

Три ключевых идеи IT-стандартов:

1. Повышение технической зрелости команд.

2. Повышение качества и стабильности продуктов.

3. Упрощение внутреннего найма разработчиков.

Нам хотелось среди инструментов технологического ландшафта, а у нас были, Java, Python, .NET и другие разнородные решения. В 2019 году было принято решение внедрить 4 практики:

1. Continuous Integration​.

2. Auto Tests.

3. Code Review​.

4. Trunk Based Development​.

Критерии оценки в 2019 году

Trunk Based Development (TBD)

На trunkbaseddevelopment.com пишут: «От флагирования до развертывания определенным способом модели ветвления». Но в 2019 году мы фокусировались на следующих критериях:

• Единственная долгоживущая default ветка — master/main.

• Прямые коммиты в master/main запрещены.

• Следование стандарту именования веток (имена веток начинаются с одного из префиксов bugfix/ feature/ hotfix/ release/), 90% соблюдение.

• Все ветки срезаются с master и мержатся в master за рассматриваемый период.

• Merge в master выполняется только через pull request.

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

Auto Tests

В автотестах три критерия:

• Наличие тестов в Sonar.

• Наличие дашбордов в Grafana со статистикой по автотестам.

• Написание тестов включено в DoD команды.

Главное, чтобы тесты были и отображались — проверили интеграцию, связались по API — отлично!

Code Review​

• Запрет на push в master/main.

• В PR есть минимум два согласующих за рассматриваемый период.

• В рамках репозитория настроен статический анализатор SonarQube через подключение плагина.

В код-ревью мы проверяли отсутствие прямого пуша в основную ветвь разработки, наличие pull-requests и согласующих в них.

Continuous Integration

• Для Pull Request (PR) есть сборка — 75% всех PR имеют сборку за рассматриваемый период.

• PR не может быть смержен, если build на PR завершился с ошибкой.

Это о том, что у каждого PR (или же Merge Requests в терминологии GitLab) должны быть успешные сборки, которые проходят и рассматриваются за определенный период.

Основные инструменты на тот момент были в Atlassian Bitbucket, сейчас вместо него Bamboo, SonarQube, Bitbucket, Grafana.

Результаты оценки в 2019 году

К чему привел первый год внедрения этих практик:

58% команд на тот момент были в статусе unknown. Это значит, что мы не знаем, внедряли они это или нет. Мы просто не могли добраться до этих цифр.

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

Состав практик в 2019 году:

1. Continuous Integration.​

2. Auto Tests.

3. Code Review​.

4. Trunk Based Development​.

Критерии оценки в 2020 году

В 2020 году появилось три новых практики:

5. Continuous Delivery​.

6. Logging.

7. Monitoring.

Те четыре, что были, проверялись точно также. Расскажу про новые.

В CD проверяли, что:

• У команды есть deployment project.

• В deployment project присутствует environment, определяющий продакшн среду, в начале названия такой среды идет метка (Prod).

• На продакшн среду был хотя бы один успешный деплой за исследуемый период.

• Для GitLab засчитывается автоматически.

В CD проверялось наличие Deployment Project, потому что на тот момент уже был Bamboo. Но было неудобно делать автоматизированные проверки для Continuous Delivery. В GitLab удобнее, поэтому в 2020 году мы начали массовый переход на него. Те, кто уже перешел на GitLab до этого, были рады, ставили зачеты автоматически.

В логировании проверяли:

• Наличие у команды индекса в платформе логирования.

• Наличие идентификаторов команды среди полей team_name.

• Наличие контакта для связи team_contact.

• Наличие team_id команды в соответствии с внутренним home-порталом.

• Наличие хотя бы одной записи за исследуемый период в указанных индексах.

В мониторинге проверяли два критерия:

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

• Наличие записей в агрегированном измерении sre_metrics_aggregation в БД команды в InfluxDB.

Результаты оценки в 2020 году

В 2019 году было 5% тех, кто выполнял все четыре практики. В 2020 году практик стало семь, но уже 11% команд их выполняли. Это было сложнее с точки зрения долгосрочного внедрения, потому что некоторые команды только появлялись, а некоторые подходы были еще не развиты и до конца не определены.

47% — это наша оценка AA, которую мы получили по полным внедрениям. Это хороший результат — стало лучше, но все еще не идеально.

Инструменты 2021 года

В финальном по внедрению стандартов и практик 2021 году, критерии оценки остались теми же. Но появилось нечто новое — внутренняя платформа разработки, которая уже начала строиться. Мы называем ее Internal Developer Platform или просто DevPlatform.

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

Результаты оценки практик в 2021 году

Постепенно становилось все больше команд, покрытие и выполнение практик увеличилось. Для нас это было сигналом, что adoption происходит и компания развивается.

Результаты

Если посмотреть агрегированно, увидим рост команд за три года, причем достаточно большой. И желтая зона AA увеличивалась. Команды все больше внедряли технические практики.

Нам удалось этого добиться благодаря переходу на новые инструменты. GitLab давал возможность улучшенной автоматизации и переиспользования подходов. В Bamboo требовались права на просмотр чужих развертываний, что неудобно. А команда Acceleration Team приходила на помощь другим. Сейчас вместо того, что было, у нас есть DevOps Enabling Team, по следам из Team Topologies. Еще были индивидуальные контрибьюторы в командах. Все вместе дало результат.

Основные проблемы подхода

• Ручные оценки. Около 30 % оценок приходилось делать силами экспертов.

• Обязательность. Не всегда практики подходили всем командам одинаково эффективно. Были обязательные практики, которые стояли в целях у команд. Были коробочные решения, где делать оценку не получалось. Из-за этого страдало общее покрытие.

• Инженерная зрелость. При имеющихся условиях было сложно внедрять стандарты. Были люди с разной культурой, не все понимали одинаково, что и зачем нужно внедрять.

Лучшие практики IT-стандартов 2022-2023 года

Рассмотрим следующие блоки: 

• Best Practices 2022-2023

• DR Tests

• R&R

• DORA Metrics

• Technical Excellence

От IT-Стандартов к лучшим практикам

Ключевые и важные изменения:

• Изменение курса. Приняли решение, что практики должны стать гигиеной.

• Культура. Постановка нового фокуса на развитие инженерной культуры.

• Изменения и цели. Реализация практик в командах теперь добровольная, добавление в годовые цели — не обязательно.

Мы перешли к лучшим практикам, чтобы IT стандарты стали обязательными. Но это нехорошо с точки зрения гигиены — как странно заставлять человека чистить зубы по утрам, также странно и заставлять следовать стандартам. Если же ориентироваться в работе на инженерную культуру и техническую зрелость, то необходимость этих практик чувствуется естественно. Но для этого нужно накопить опыт и понимание. Поэтому компания приняла решение, что реализация практик не обязательна. Изменились цели и фокус сместился на инженерную культуру. Так стали смотреть на это направление под другим углом.

Что такое лучшие практики?

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

IT-Стандарты 

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

Лучшие практики

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

Да, практики те же самые:

1. Trunk Based Development​

2. Auto Tests

3. Code Review​

4. Continuous Integration​

5. Continuous Delivery​

6. Logging

7. Monitoring

Но есть и кое-что новое:

8. Disaster Recovery, работающий с помощью DRP (Disaster Recovery plan). Для этой практики есть разные инструменты. Обсудим их подробнее.

Disaster Recovery:

• Позволяет подтвердить готовность команд и инфраструктуры к восстановлению IT-системы в случае технических сбоев.

• Проверяет в промышленной среде один или несколько сценариев восстановления IT-системы согласно DRP, Disaster Recovery Plan.

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

Мы также следили за следующими метриками и артефактами DR:

• Тестируемый сценарий DRP.

• Фактические значения RTO, RPO (при тесте RPO=0).

• Команда DR-тестирования.

• Состав функциональных проверок во время теста.

• Результат тестирования: успешно, неуспешно, с замечаниями.

• Комментарий: обязателен при нештатных ситуациях во время теста.

• Ответственный за тестирование.

То есть проверяли, что есть тестируемый DR, что он описан, заполнены все необходимые поля  в JIRA и команды следуют определенным ITSM  процессам. Проверяли также исполнение DR в соответствии с «тирностью» системы команды. От tier — определение, сколько времени система может лежать, восстанавливаться и так далее.

Критерии выполнения Disaster Recovery:

• Зафиксированные значения метрик RTO или RPO соответствуют классу критичности IT-системы (Tier).

• Функциональные проверки IT-системы по результатам DR-теста пройдены успешно.

• По результатам DR-теста не найдены замечания по сценариям восстановления и инструкциям.

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

Процесс Disaster Recovery выглядел так:

1. Применение классического ITSM — создание CRQ процесса.

2. Заполнение задач в JIRA.

3. Выполнение DR-теста не реже раза в год и при изменениях инфраструктуры.

Результаты по лучшим практикам на конец 2023 ⎼ начало 2024

Результаты лучших практик агрегировали в таблицу:

Проанализировав таблицу, я сделал интересные выводы:

Ручная оценка упала. Раньше было 30%, а теперь в среднем 13%.

Практики стали автоматизироваться и все больше выполняться, несмотря на то, что перестали быть обязательными.

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

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

21% не выполнили всех практик, а самая невыполняемая была DR, потому что самая новая.

Общий процент выполнения составил 63% по автоматизации и внедрению — это означало принятие практик в командах. Самые выполняемые — CI и Code Review. Ура!

А теперь внезапно…

Culture of Engineering

В 2023 году предложили цель Culture of Engineering в категории Technical Excellence. Culture of Engineering мы понимали как четыре цели для команд:

1. TTM (Time-to-Market).

2. R&R (Reliability & Resilience).

3. Legacy.

4. SLA, Incident Management.

Дальше подробней поговорим про Reliability & Resilience и Time-to-Market.

Time to Market 

Time to Market — известная метрика в мире разработки. Главная цель — это снижение TTM. Изначально мы понимали это как время от создания задачи до деплоя на прод, а в индустрии — как время от идеи до прода. Но как можно измерить Time to Market от идеи, когда у тебя 270 команд, ведущих работу по-разному и с разными flow в JIRA. Получался налог на консистентность ведения проектов. Поэтому мы рассчитали эту метрику немного по-другому и занялись ее внутренней адаптацией.

TTM разбивался на две подметрики — Lead Time (время производства) и Deployment Frequency (частота успешных развертываний). Кстати, Change Lead Time и Lead Time — это разные метрики. В результате у команд были метрики, практики и расчеты в  интерфейсе внутреннего портала платформы разработки.

По ним можно было отследить, как команда перформит, выполняет подходы и оценивает себя.

R&R (Reliability и Resilience)

В индустрии все двигались к устойчивости и надежности. Нас это тоже зацепило. И R&R — ответ на этот вызов.

Для нас R&R был связан с тремя метриками:

1. Availability.

2. MTTR (Mean Time to Restore).

3. Performance или Latency — скорость ответа сервиса.

Мы понимали R&R так:

• Reliability (надежность) — способность работать стабильно в течение длительного времени, соответствуя ожиданиям и требованиям.

• Resilience (устойчивость) — способность продолжать функционировать надежно и стабильно в условиях сбоев, нагрузок или других непредвиденных событий.

То есть R&R — это когда система работает стабильно и выполняет то, что должна в ожидаемое время в соответствии с контрактами и SLA.

Суть в том, чтобы проверять availability (доступность сервиса). Availability рассчитывается по незамысловатой формуле, но сложность в том, чтобы собирать эти данные по всем сервисам. На большом масштабе это тяжело.

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

MTTR

Суть метрики MTTR в том, чтобы измерять среднее время восстановления системы. Проблема больших компаний — добыть все метрики, которые касаются системы, продукта и всего, что с этим связано. Это производилось на наших ITSM сервисах, JIRA и других системах, участвовавших в ITSM и просматривающих количество инцидентов. Время восстановления считалось за рассматриваемый период.

Performance

Performance еще называют Response Time или Latency. Это одна из RED-метрик. Суть в том, как быстро функция отвечает на запрос — какое время ждали получения ответа. Именно это мы оценивали.

В результате получили такое видение:

Так ключевые метрики Availability, MTTR и Performance позволяют оценить систему с точки зрения стабильности. Это был большой первый шаг навстречу тому, чтобы все сделать.

Исследование инженерной культуры

Помимо технических практик, мы исследовали инженерную культуру. Ведь она помогает всему.

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

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

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

Это хорошо ложится в DORA Core Model:

Мы взяли ее за основу и адаптировали под себя. Блок культуры находится в Generative Organization Culture. Лучшие практики в этой модели находятся в блоке Technical Capabilities. Там также есть Test Automation, метрики эффективности и Data Management в более расширенной версии.

В результате построили свою адаптированную модель, которая выглядела примерно так:

В этой модели подсвечиваются наши практики и метрики. Но так как у нас свой опыт, мы залезли еще глубже — добавили метрики инцидент-менеджмента, связали частоту развертываний и падение систем с культурным индексом и скоростью прохождения информации в командах. В результате работали с Big Data, большими дашбордами, применяли шкалы Лайкерта, где люди оценивают ответы на вопросы в баллах от 1 до 5, где 1 — точно нет, 5 — точно да.

Тогда не было единого инструмента, чтобы на все посмотреть. Мы строили отчеты в Google Looker Studio и видели, что все практики выполнены, какой показатель Test Coverage, какие DORA-метрики собираются, какая культура.

Когда мы это сделали, то поняли, что можно составить культурный индекс по результатам суммы категории вопросов об инженерной культуре. Оказалось, что у команд с индексом культуры от 4,3 на 30% меньше нереализованных технических практик. Опросив 150-200 команд мы убедились, что это действительно работает.

А теперь вернемся к Pain Index. Он снижался за 2021, 2022, 2023 годы на фоне внедрения культуры, практик, метрик, расчетов, автоматизации, экспертов, контрибьюторов и большого массива информации.

У нас в компании есть движение Technical Excellence. Оно делится на цель, лучшие практики и инженерную культуру. В Culture of Engineering есть подцель — Time To Market, SLA, инцидент менеджмент, legacy, R&R со своими подметриками и т.д.

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

Основные проблемы подхода:

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

• Уровни зрелости. Практики — не бинарные, и двумя проверками, чаще всего, не ограничиться. В каждой практике от двух до пяти критериев. А деплой не сразу становится автоматизированным, и CI — не сразу Continuous Integration. Все это нужно как-то оценивать.

• Опыт и навыки. Нехватка экспертизы и методологической базы для построения глубокой аналитики и объединения опыта. Мы хотели, чтобы люди, внедряя технические практики, мотивировались, им становилось интересно. Для этого у нас была внутренняя система развития и комьюнити.

• Ручные действия. Осталось множество ручных действий, которые не исчезли полностью, в разных интерфейсах. Опрос надо заполнять вручную, а в остальном мы хотели полную автоматизацию. Сейчас для этого появляются технические возможности — Technical Capabilities от DORA.

Технические возможности. Новое начало

Культура ест стратегию на завтрак!

Питер Друкер

Питер Друкер говорил, что если в компании культура неэффективна, то и сотрудники в этой компании не смогут сделать execution, выполнить стратегию.

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

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

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

Если вы попробуете поговорить с бизнесом о внедрении глобальных подходов вас спросят про эффективность. Обычно с точки зрения бизнеса, эффективность понимают как коммерческую. То есть для компании важен коммерческий успех. За ним стоят достижения компании в цифровой индустрии. Он складывается из эффективности работы команд. А ее можно достичь, когда люди чувствуют себя хорошо. Это называется well-being.

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

Эту неочевидную цепочку бывает очень сложно объяснить, особенно кому-то не из мира IT. Но обо всем этом еще в 2013 рассказывала DORA Core Model. Конечно, система не идеальна, и есть, возможно, другие подходы, но ничего лучше на тот момент, для нас, мы не нашли.

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

Разработка фреймворка для создания практик

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

1. Статус практики.

2. Описание.

3. Какую проблему решает практика.

4. Риски: что будет, если не применить практику.

5. Как реализовать — примеры или технологии для реализации.

6. Какие навыки дает практика.

7. Способы измерения практики.

8. Уровни зрелости практики.

Привело это к таким интерфейсам:

Теперь у нас не Continuous Integration, а Integration and Build (сборка), в результате у нас появились уровни зрелости, критерии проверки и многое другое. А еще теперь даем большой массив информации для команд, как расти внутри, какие навыки развивать, что считать хорошей практикой. Мы подумали и над тем, какие практики вообще в компании можно внедрять, как они должны строиться и верифицироваться.

Что считать хорошей практикой

Мы верим, что система контроля версий — необходима, чувствуем, что правильно хранить код в одном месте. То же самое чувствуем в отношении практик и подходов.

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

• Адаптируемость. Практика должна иметь возможность применяться с любой конечной реализацией (технологией) — неважно, Bamboo, GitLab, Bitbucket и так далее. То, что используется, должно работать в любом случае и идеально. Например, у нас есть абстрактные классы, мы не занимаемся конкретной реализацией при переносе в кодовую базу.

• Измеримость. Классика менеджмента: хочешь управлять — умей измерять.

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

• Обучаемость. Практика должна обучать инженеров и мотивировать их развиваться.

Статус практики

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

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

Технические возможности и навыки

Практики внедряются с навыками. У нас есть внутренняя система Skills Flow, которая выглядит так:

Система построена на базе методологии SFIA. Это модель цифровых навыков диджитализированной индустрии. Эти навыки базируются на поведенческих факторах, атрибутах. Люди оценивают сами себя.

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

Подтвердилась гипотеза исследования «Культура влияет на технику». Мы поняли, что важно видеть эти данные в одном месте.

Теперь вместо такой таблицы:

 У нас есть такой интерфейс:

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

Как теперь выглядят практики

Например, есть MR pickup time с источником данных, способами измерения. Мы его глубоко, серьезно прорабатываем, конкретизируем, инвестируем силы.

Карта связи практик выглядит так:

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

Сейчас у нас есть 12 основных практик:

Мы пока не все внедрили, но работаем над тем, чтобы все их адаптировать. Практики, помеченные звездочкой, для нас новые, раньше их в компании не было. Сейчас мы внедряем Inner Source, Code Maintainability, Code Quality, Observability и Quality Assurance. Ведь есть практики, вмещающие подпрактики. Например, Observability складывается из логирования, мониторинга и трейсинга.

Реализация подключения к платформе

Для подключения практик к платформе делаем спецификации, meta-info.yaml-файлы в репозиториях, которые заполняют люди. Для этого устанавливаем связь команды, проекта в GitLab, строим агрегирующие графы, из чего это складывается. Такая реализация позволяет понять, как какой-то проект связан с командой. Вариантов применения есть множество, мы решаем свои задачи.

Решенные проблемы

В результате мы решили ряд проблем:

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

• Уровни зрелости. Теперь на первом уровне зрелости среди всех практик больше 90 показателей, и там не по два критерия в каждом. У нас достаточно большой объем данных. Думаю, мы вырастем до 40 практик и дальше будем расти. Всего может быть более 300-500 показателей о работе команды. Это Big Data, которой мы уже занимаемся.

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

Выводы и советы

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

• Инженерная культура и технические практики влияют на эффективность работы компании, поэтому важно измерять все, что хоть сколько-нибудь поддается измерению.

• Все данные в разработке и эксплуатации дают возможность принимать объективные управленческие решения.

Что и кому со всем этим делать

• Junior. Изучайте существующие практики и подходы в компании. Если их нет, перенимайте опыт у более опытных коллег и изучайте лучшие отраслевые практики.

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

• Lead EM/CTO. Задайте стратегию инженерного развития, поддерживайте внедрение лучших практик и создавайте культуру, способствующую росту и совершенствованию компании.

Развивайте техническое совершенство!

Чтобы дерево выросло, надо его посадить.

К чему это я? К тому, что чтобы что-то начать делать, надо начать делать, а дорогу осилит идущий.

Скрытый текст

А узнать больше по теме вы сможете на ближайшей конференции Saint HighLoad++ в 2026 году в Москве! Программа конференции охватывает такие аспекты веб-разработок, как архитектуры крупных проектов, базы данных и системы хранения, devops и системное администрирование, нагрузочное тестирование, эксплуатацию крупных проектов и другие направления, связанные с большими и высоконагруженными IT-системами.