AB
1
О проектеМодель зрелости: как оценивать и растить инженерные команды
2
3
Информационная безопасность
4
5
1. Моделирование угроз безопасности при разработке новой функциональности
6
Ожидание от командыВ команде проводится моделирование угроз безопасности для всех продуктовых изменений, есть выделенный человек для поддержания процессов ИБ в команде.

или

Осознанно выбран подход к безопасности в команде после консультации с Security Unit.
7
Пример
8
Зачем эта практикаДля поддержания безопасности продукта необходимо заранее продумать, как новая фича может на ней отразиться. Это позволит учесть при разработке дополнительные проверки, механизмы и т.д.

Выделенный человек, осознанно занимающийся вопросами безопасности в команде, становится точкой security-экспертизы. Это помогает команде не забывать про безопасность и держать её под контролем.
9
Уровень 0Про необходимость такого процесса неизвестно. Вопросы безопасности никогда не поднимаются, никем не обсуждаются.
10
Как перейти— Ознакомиться с процессом моделирования угроз.
— Определиться с ответственным: оставить всё на TUL'е или выбрать Security Champion'a, заонбордить его в роль и процессы безопасности.
11
Уровень 1Подход к безопасности сводится к эпизодическим обращениям в Security. Выделенный человек в команде есть, а внутренних процессов, касающихся безопасности, — нет. Вопросы безопасности обсуждаются несистемно, если в них есть очевидная потребность.
12
Как перейти— Хотя бы одному члену команды пройти курс по Threat Modeling.
— Нативно интегрировать моделирование угроз в планирования/груминги/DoR/DoD-чеклисты.
— Ответственный ознакомлен с процессами безопасности, драйвит их выполнение.
13
Уровень 2 (Бейзлайн)Хотя бы один член команды прошёл курс по Threat Modeling.
Команда имеет подход к управлению безопасностью: есть выделенный человек или иной выбран подход, который поддерживает процесс.
Команда внедрила TM в свои процессы — есть регулярное обсуждение на груминге, пункт в DoR/DoD для задач, и т.д.
14
Как перейтиФиксировать процесс и результаты моделирования угроз при помощи инструментов, рекомендованных Security.
15
Уровень 3Командные процессы TM используют инструменты, рекомендованные Security.
Каждая итерация процесса оставляет артефакт: команда пользуется TM-шаблоном.
16
17
2. Управление рисками безопасности
18
Ожидание от командыЮнитам и командам необходимо регулярно проводить оценку рисков безопасности. Оценка рисков — это глобальный взгляд на продуктовую функциональность и технические решения команды. Процесс помогает ответить на вопрос «откуда и как может прилететь», на выходе получается обновляемая карта рисков юнита.
19
Пример
20
Зачем эта практикаКарта рисков позволяет:
— повысить осведомленность и прозрачность об актуальных для конкретной команды угрозах безопасности
— качественнее и быстрее моделировать угрозы для новой функциональности
— планировать улучшения безопасности своей части продукта (метрики, мониторинг, процессы реагирования, доп.проверки), плюс приоритизация
21
Уровень 0Про необходимость такого процесса неизвестно, карта рисков не составлялась.
22
Как перейтиДля первого проведения такой оценки необходимо организовать встречу с Security. После проведения получится документ с рисками, их оценкой и action item'ами для команды.
23
Уровень 1Карта рисков актуализировалась более полугода назад. Ни один из action item'ов с прошлой оценки рисков не выполнен командой.
24
Как перейтиКоманда актуализировала карту рисков по прошествии полугода и позвала экспертов её провалидировать. Выполнила хотя бы один action item' с предыдущей актуализации.
25
Уровень 2 (Бейзлайн)Карта рисков актуализировалась в течение полугода. Часть action item’ов с прошлой оценки выполнена юнитом.
26
Как перейтиПроводить работы по роадмапу инициатив, разработанных после оценки.
27
Уровень 3Карта рисков актуализировалась в течение полугода. На команде нет открытых action item’ов.
28
29
3. Устранение уязвимостей
30
Ожидание от командыМы ожидаем, что каждая команда будет устранять уязвимости безопасности в рамках договоренностей.
31
Пример
32
Зачем эта практикаМинимизируем риски безопасности продукта. Не накапливаем уязвимости низких критичностей, которые иногда могут комбинироваться в более опасные уязвимости.
33
Уровень 0— Команда не знает про SLA.

или

— Менее 30% задач за период исправлено в рамках SLA.
34
Как перейти
35
Уровень 1От 30% до 60% задач за период исправлено в рамках в SLA.
36
Как перейти
37
Уровень 2 (Бейзлайн)Более 60% задач за период исправлено в рамках SLA.
38
Как перейти
39
Уровень 3Устранять уязвимости за период не приходилось.

или

100% задач за период исправлено без нарушений SLA.
40
41
42
QA
43
44
1. Мониторинги функциональности
45
Ожидание от командыМы ожидаем, что у каждой команды Авито будет мониторинг своей функциональности и что команда будет реагировать на аномалии.
46
ПримерОдин или несколько дашбордов в Grafana.
47
Зачем эта практикаАвито состоит из многих компонентов. Когда что-то ломается, мы хотим очень быстро об этом узнать и починить. Если у нас нет информации по компоненту, то мы не понимаем, работает он или нет, и любую проблему решаем дольше.
48
Уровень 0Мониторинга функциональности нет.
49
Как перейти— Ознакомиться с системами мониторинга в Авито.
— Cделать дашборд с бизнес-критичными и техническими метриками по своему функционалу.
50
Уровень 1Мониторинг функциональности есть, и он ничего не показывает.
51
Как перейтиДобавить или скорректировать дашборды и алерты по ним. При взгляде на дашборд должно быть однозначно понятно, работает сейчас сервис в нормальном режиме в каждом из дата-центров или нет. Если нет, то должно быть понятно, проблема в самом сервисе или в окружении/источниках данных.

Например, в дашборде могут быть такие метрики: RPS по сервису (сейчас, вчера и неделю назад); RPS по потребителям (от кого прилетают запросы); Response time: параметризовать перцентиль (75, 99, 999, 98); в разбивке по подам/инстансам; Response codes: 2xx,4xx,5xx, другие; Response time и количество открытых сессий к БД, если есть; Размер и время жизни кеша (если есть); Response time и Response codes сервисов-источников данных (что нам отвечают те, кого мы вызываем) — по одному графику на источник, CPU utilisation per node, Memory consumption (per node) — с трешхолдом лимита, network utilisation, disk io utilisation, отбивки деплоя сервиса, отбивки деплоя монолита, переключение между prod/staging/dev/perf окружениями для сервисов очередей, consume по топикам в единицу времени; produce по топикам в единицу времени, время обработки одного события события (по топикам) для сервисов на go, метрики goruntime, gc pause, goroutines, сколько реальных тредов работает.
52
Уровень 2 (Бейзлайн)От 50% — P0-P1 проблем видим на мониторинге. Есть разбиение основных метрик по кластерам.
53
Как перейти— Cобрать и рассмотреть случаи за последний спринт, когда проблема была, но её не было видно на мониторинге.
— Добавить по каждому случаю метрики.
— Проделывать это в каждом спринте.
— Сделать метрики 3 дата-цетров, если их нет.
54
Уровень 3100% P0-P1 проблем видим. Если мониторинг зелёный, то уверены, что все работает. Есть метрики 3 дата-центров.
55
56
2. Команда умеет быстро откатываться
57
Ожидание от командыНовые фичи в критичной функционьности команда может быстро откатить или отключить. Для этого можно использовать feature toggling или любой другой механизм быстрого отката. Команда использует Canary при большинстве релизов. Внимание: A/B тест -— не механизм для быстрого отката!
58
ПримерВыкатываем новую йункциональность черновиков в продакшен. Мы долго тестировали, но, так как фича объёмная, не досмотрели, что у некоторых пользователей отдаётся 500-ая ошибка. Ничего страшного, потому что мы выкатили этот релиз Canary-деплоем, а в приложениях закрыли функцию фичатоглами. Мы выключили тоглы и откатили канареечный релиз, работа у пользователей восстановлена в самый короткий срок.
59
Зачем эта практикаДля того, чтобы вовремя заметить проблемы в новой версии сервиса и при этом уменьшить потери компании, имеет смысл выкатывать новые сервисы сначала на небольшой процент трафика. Только убедившись, что всё работает как надо, постепенно увеличивать процент трафика до 100. Также для любой функциональности должна быть возможность быстро откатить или отключить использование новой фичи в случае проблем.
60
Уровень 0Несколько раз выкатывали Canary Deploy, есть несколько фичей под фичатоглами.
61
Как перейтиРазобраться, как работает feature toggling и как реализован быстрый откат в CI. Использовать feature toggling и Canary Deployment. Проверить, что работает. Провести учения по Canary-релизам.
62
Уровень 1Иногда используем feature toggling или быстрый откат для новой или зарефаченной функциональности.
63
Как перейтиПонять, что мешает всегда использовать feature toggling и Canary Deployment для безопасной выкатки новых изменений. Начать регулярно пользоваться этими инструментами. Если не хватает времени, учесть при планировании. Добавить релиз Canary и закрытие Feature Toggle-ом в Definiton of Done к задачам.
64
Уровень 2 (Бейзлайн)Мы всегда можем быстро откатить или выключить сломанную фичу для новой или зарефаченной функциональности.
65
Как перейтиНекоторые функциональные поверки можно сократить и проверить эффективней на небольшом трафике, чем самостоятельно тратить время на то, чтобы воспроизвести кейс на тестовой среде. Подход Shift-Right позволяет тестировать сложные кейсы в продакшене, но только при условии небольшого процента трафика и полностю прозрачных метрик всего бизнес-процесса.
66
Уровень 3Освоили технику Shift-Right, имеем полную картину происходящего в метриках и умеем сокращать скоуп тестирования, осознанно передвигая тестирование «вправо».
67
68
3. В команде есть роль тестировщика и тестирование не является бутылочным горлышком
69
Ожидание от командыВ команде может не быть выделенного тестировщика, но роль тестировщика должна сохраняться. «Шапку» тестировщика может носить кто-то один, но лучше получается, если её носят все поочередно.
70
ПримерВ команде может быть выделенный QA или кто-то выполняет его роль. Есть человек, который может рассказать про качество того, что делает команда и какими методами оно обеспечивается. Этот человек развивает и улучшает направления тестирования и QA.
71
Зачем эта практикаМы хотим выпускать качественный продукт. Мы понимаем, что в команде может быть мало тестировщиков или не быть вообще, но при этом тестирование всё равно должно быть.
72
Уровень 0Иногда очень быстро катим фичи, тестировать некогда даже если есть тестировщик.
73
Как перейтиНачать планировать время на тестирование. Лучше всего при груминге задач отдельно обговаривать этап тестирования, а также кто и когда будет его проводить.
74
Уровень 1Нет тестировщика — катимся без тестирования.
75
Как перейтиТому, кто лучше всех знает продукт, попробовать надеть «шапку» тестировщика на один спринт. Если всё получится хорошо, «шапку» тестировщика можно передавать другим членам команды. Или попросить помощи у QA -юнита, если что-то пошло не так.
76
Уровень 2 (Бейзлайн)Хоть кто-то может подменить тестировщика/просим помощь кластера, когда нужно потестировать.
77
Как перейтиВсем по очереди надевать «шапку» тестировщика на спринт.
78
Уровень 3Вся команда может взять на себя роль тестировщика.
79
80
4. Тестирование включено в процессы на ранних этапах
81
Ожидание от командыКто-то из команды надевает «шапку» тестировщика при проработке требований и инициирует обсуждения того какие есть корнер-кейсы, нет ли противоречащих требований, что и как можно будет проверить.
82
ПримерНа этапе проработки требований обсуждаются вопросы о том:
— Как должен деградировать сервис, если источник данных сломался?
— Что делать, если пользователь ввёл телефон из 50 цифр?
— Как мы будем тестировать эту фичу?
— Может нам надо RM докрутить?
83
Зачем эта практикаЧем раньше мы замечаем проблему, тем дешевле её исправить. И для того, чтобы увидеть проблему в требованиях или нестыковку в постановке задачи, нужно посмотреть на неё с точки зрения тестировщика. А заодно и подумать про подготовку к тестированию там, где она нужна.
84
Уровень 0Тестирования нет или тестируем редко/случайно.
85
Как перейтиНачать планировать и выделять время на тестирование.
86
Уровень 1Тестирование подключается только после разработки.
87
Как перейтиПривлекать тестировщиков на этапе груминга. Если тестировщика нет, надевать «шапку» тестировщика и привлекаться.
88
Уровень 2 (Бейзлайн)Команда прорабатывает часть требований в том числе и в разрезе тестирования.
89
Как перейтиПо каждой задаче при груминге:
— Подумать что ещё нужно проверить (безопасность, удобство использования и т.д.).
— Понять, какая нагрузка ожидается на сервис и придумать как сделать нагрузочное тестирование, если оно применимо.

Не забывайте про производительность и на клиенте. Команда Performance Unit может помочь придумать какие технические и продуктовые метрики нужно добавить при разработке,
продумать деградации и включить их в описание задачи.
90
Уровень 3Команда продумывает то, как будет тестировать на этапе проработки требований: риски, corner cases, как технически тестировать.
91
92
5. Команда придерживается пирамиды тестирования
93
Ожидание от командыОжидаем, что у команды есть юнит-, интреграционные и end-to-end тесты. И что они составляют пирамиду тестирования: юнитов больше, интеграционных меньше, end-to-end ещё меньше.
94
ПримерКоманда при разработке новой фичи обсуждает проверки и старается перенести их как можно ниже по уровню пирамиды тестирования. Команда знает, как выглядит её тестовая модель по уровням и может показать свою пирамиду, а также регулярно проводит ревью пирамиды и контролирует, что е2е-сценарии не разрастаются.
95
Зачем эта практикаЮнит-тесты самые дешевые в разработке и поддержке, поэтому большую часть функционала хочется покрывать ими. Но полностью обеспечить приемлемый уровень качества используя только юнит тесты, к сожалению, нельзя. Поэтому интеграционных и end-to-end тесты тоже должны быть.
96
Уровень 0Команда не знает, что такое пирамида тестирования, и не знает, какая она сейчас.
97
Как перейтиРазобраться, что такое пирамида тестирования. Проанализировать её на визуализации тестовых моделей.
98
Уровень 1Команда знает, в каком состоянии сейчас их пирамида тестирования, но она далека от целевого состояния.
99
Как перейтиКоманда понимает в каком состоянии текущая пирамида тестирования. Автотестов e2e-уровня и ручных проверок не более 30% от всего объёма функциональных проверок. Если для вас e2e-тесты не применимы, то остальные тесты должны быть разбиты на слои и соответствовать пирамиде с погрешностью не более 30%. Есть конкретные планы по улучшению пирамиды тестирования. Для новых задач автотесты разрабатываются на разных слоях, подходящих под конкретные проверки.
100
Уровень 2 (Бейзлайн)Команда имеет бэклог и сроки когда просто пирамида станет пирамидой тестирования. Автотесты на новые фичи разбиваются на разные слои пирамиды до их разработки.