mirror of
https://github.com/avito-tech/playbook.git
synced 2026-03-13 21:53:21 +03:00
- вынес профили в отдельный каталог (#110)
- исправил ошибки разметки во всех документах
This commit is contained in:
Aleksandr
@@ -21,13 +21,13 @@
|
||||
|
||||
Работу с LSR в Авито начали в 2017 году. Процесс несколько раз менялся, и сейчас выглядит так:
|
||||
1. Когда возникает проблема, дежурные видят её в системе мониторинга.
|
||||
1. Дежурные сами чинят проблему или привлекают ответственных от команд.
|
||||
1. Автоматика фиксирует в Jira продолжительность инцидента, затронутую функциональность и недополученную прибыль. Это называется Auto LSR.
|
||||
1. Автоматика же отмечает критичность инцидента в случае больших финансовых потерь или большого количества жалоб от пользователей.
|
||||
1. Мы заводим постмортем тикет в Jira c описанием проблемы, которая вызвала инцидент, если такого еще нет. К нему линкуются Auto LSR.
|
||||
1. Проводим встречу с командой и экспертами и детально разбираем проблему.
|
||||
1. Выполняем все нужные действия по предотвращению подобных инцидентов в будущем.
|
||||
1. Закрываем тикет и дополняем базу знаний.
|
||||
2. Дежурные сами чинят проблему или привлекают ответственных от команд.
|
||||
3. Автоматика фиксирует в Jira продолжительность инцидента, затронутую функциональность и недополученную прибыль. Это называется Auto LSR.
|
||||
4. Автоматика же отмечает критичность инцидента в случае больших финансовых потерь или большого количества жалоб от пользователей.
|
||||
5. Мы заводим постмортем тикет в Jira c описанием проблемы, которая вызвала инцидент, если такого еще нет. К нему линкуются Auto LSR.
|
||||
6. Проводим встречу с командой и экспертами и детально разбираем проблему.
|
||||
7. Выполняем все нужные действия по предотвращению подобных инцидентов в будущем.
|
||||
8. Закрываем тикет и дополняем базу знаний.
|
||||
|
||||
Простые и понятные проблемы мы разбираем внутри команд или в слак-чатиках. А кросс-командные встречи проводим для серьёзных и бизнес-критичных проблем: инфраструктурных, процессных и тех, которые затронули сразу несколько команд. Встречи открытые, их анонс мы публикуем в отдельном канале, и прийти на них может любой человек в компании.
|
||||
|
||||
|
||||
@@ -14,19 +14,20 @@
|
||||
## Краткое руководство
|
||||
|
||||
|
||||
Правило | Руководство к действию
|
||||
------------- | -------------
|
||||
Правило бойскаута | Оставь код репозитория лучше, чем он был до твоего прихода.
|
||||
Куда хочешь, туда и пушь | Делать PR можно в любой репозиторий, если это не запрещено внутренними политиками безопасности или соответствиями внешним стандартам.
|
||||
В чужой код со своим уставом не лезь | У команд есть Coding Standard и политика Code Review. Нужно использовать Coding Standard команды, которая владеет кодом. Если Code Standard в команде отсутствует — подсвети проблему оунеру.
|
||||
Запушил в чужой код, не мёржь без согласия владельца | Следуем политике Code Review команды, которая владеет кодом.
|
||||
Написал новый код, напиши и тесты | Тесты качественные и являются частью документации.
|
||||
Написал новый код, а тесты не упали? Проверь и исправь тесты | Покрываем тестами так, что баг ломает тесты. Если логику поломали, а тесты «зеленые», значит их надо исправлять. Исправляет CODE OWNER, который владеет этим функционалом.
|
||||
Кто сломал, тот и чинит | Кто сломал автотесты, уронил метрики или удалил логирование, тот их и исправляет.
|
||||
Отклоняешь на ревью, аргументируй | Оунер репозитория не может отклонить пулл-реквест без четкого объяснения причин с аргументами.
|
||||
Пришел тикет на ревью? Проведи его сегодня, не откладывай на завтра | Code Review должно проходить не позже, чем на следующий день.
|
||||
Если сломали твой код, а ты не узнал – сам виноват | Используешь соседнее API, напиши тест, который его проверяет и скажет, что это затронуло ваш юнит. Команда — оунер результата. Всегда мониторим зависимости, которые могут поломать сервис.
|
||||
Владеешь кодом – отвечаешь за его тесты и метрики | Оунишь репозиторий — покрой тестами, метриками и необходимым логированием.
|
||||
| Правило | Руководство к действию |
|
||||
|---------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Правило бойскаута | Оставь код репозитория лучше, чем он был до твоего прихода. |
|
||||
| Куда хочешь, туда и пушь | Делать PR можно в любой репозиторий, если это не запрещено внутренними политиками безопасности или соответствиями внешним стандартам. |
|
||||
| В чужой код со своим уставом не лезь | У команд есть Coding Standard и политика Code Review. Нужно использовать Coding Standard команды, которая владеет кодом. Если Code Standard в команде отсутствует — подсвети проблему оунеру. |
|
||||
| Запушил в чужой код, не мёржь без согласия владельца | Следуем политике Code Review команды, которая владеет кодом. |
|
||||
| Написал новый код, напиши и тесты | Тесты качественные и являются частью документации. |
|
||||
| Написал новый код, а тесты не упали? Проверь и исправь тесты | Покрываем тестами так, что баг ломает тесты. Если логику поломали, а тесты «зеленые», значит их надо исправлять. Исправляет CODE OWNER, который владеет этим функционалом. |
|
||||
| Кто сломал, тот и чинит | Кто сломал автотесты, уронил метрики или удалил логирование, тот их и исправляет. |
|
||||
| Отклоняешь на ревью, аргументируй | Оунер репозитория не может отклонить пулл-реквест без четкого объяснения причин с аргументами. |
|
||||
| Пришел тикет на ревью? Проведи его сегодня, не откладывай на завтра | Code Review должно проходить не позже, чем на следующий день. |
|
||||
| Если сломали твой код, а ты не узнал – сам виноват | Используешь соседнее API, напиши тест, который его проверяет и скажет, что это затронуло ваш юнит. Команда — оунер результата. Всегда мониторим зависимости, которые могут поломать сервис. |
|
||||
| Владеешь кодом – отвечаешь за его тесты и метрики | Оунишь репозиторий — покрой тестами, метриками и необходимым логированием. |
|
||||
|
||||
***
|
||||
|
||||
## Правила внесения изменений в чужой функционал
|
||||
|
||||
45
readme.md
45
readme.md
@@ -19,21 +19,20 @@
|
||||
|
||||
# Авито в цифрах
|
||||
| `Показатель` | `Значение` |
|
||||
|:---|:---|
|
||||
Всего сотрудников Авито | 11000+ человек
|
||||
Команда разработки | 2700+ человек
|
||||
Средний возраст сотрудников | 30 лет
|
||||
Количество серверов | 2500+
|
||||
RPS к бэкенду | 96 000
|
||||
MAU | 50 миллионов человек
|
||||
Доля пользователей приложений | 78%
|
||||
Релизов изменений | 200-250 в день
|
||||
Команд разработки | 200+
|
||||
Активных объявлений | 237 миллионов
|
||||
Модерация | 15 миллионов версий объявлений в день
|
||||
Сделок в секунду | 10
|
||||
Картинок в хранилище | 32 миллиарда
|
||||
|
||||
|:------------------------------|:--------------------------------------|
|
||||
| Всего сотрудников Авито | 11000+ человек |
|
||||
| Команда разработки | 2700+ человек |
|
||||
| Средний возраст сотрудников | 30 лет |
|
||||
| Количество серверов | 2500+ |
|
||||
| RPS к бэкенду | 96 000 |
|
||||
| MAU | 50 миллионов человек |
|
||||
| Доля пользователей приложений | 78% |
|
||||
| Релизов изменений | 200-250 в день |
|
||||
| Команд разработки | 200+ |
|
||||
| Активных объявлений | 237 миллионов |
|
||||
| Модерация | 15 миллионов версий объявлений в день |
|
||||
| Сделок в секунду | 10 |
|
||||
| Картинок в хранилище | 32 миллиарда |
|
||||
|
||||
# Состав репозитория Авито playbook
|
||||
|
||||
@@ -71,16 +70,16 @@ MAU | 50 миллионов человек
|
||||
|
||||
### Экспертный трек
|
||||
|
||||
- [Инженеры](developer-profile.md)
|
||||
- [Аналитики](analytics-levels.md)
|
||||
- [QA-инженеры](QA-profile.md)
|
||||
- [DS-инженеры](ds-skills.md)
|
||||
- [Инженеры](profiles/developer-skills.md)
|
||||
- [Аналитики](profiles/analytics-skills.md)
|
||||
- [QA-инженеры](profiles/qa-skills.md)
|
||||
- [DS-инженеры](profiles/ds-skills.md)
|
||||
|
||||
### Менеджерский трек
|
||||
|
||||
- [Технические менеджеры (лиды)](techlead-profile.md)
|
||||
- [Аналитики](analytics-management.md)
|
||||
- [Технические менеджеры (лиды)](profiles/tech-managers.md)
|
||||
- [Аналитики](profiles/analytics-managers.md)
|
||||
- [Продакт менеджеры](product-levels.md)
|
||||
- [Руководители дизайна](design-management.md)
|
||||
- [DS-менеджеры](ds-managers-profiles.md)
|
||||
- [Руководители дизайна](profiles/design-managers.md)
|
||||
- [DS-менеджеры](profiles/ds-managers.md)
|
||||
|
||||
|
||||
@@ -30,14 +30,11 @@
|
||||
В секции мы даём кандидату практическую задачу. Это может быть как абстрактная задача «давай спроектируем Авито», так и задача с условиями, специфичными для команды. Например, «давай спроектируем платформу виджетов используя фреймворк Vue JS», «давай спроектируем PaaS».
|
||||
|
||||
### Секции для QA-инженеров
|
||||
|
||||
**Секция 1. Тестирование.** На этой секции мы проверяем ключевые навыки кандидата в обеспечении качества: составлении тестов и организации процесса тестирования.
|
||||
Даём две простых задачи на тест-дизайн и одну развёрнутую на тестирование новой фичи. Здесь мы смотрим, как кандидат комплексно подходит к тестированию новой функциональности.
|
||||
|
||||
**Секция 2. Автоматизация.** На этой секции проверяем знания кандидата по автоматизации тестирования: когда и что нужно автоматизировать, как разрабатывать тесты, просто написание кода. Секция содержит небольшую часть теоретических вопросов. Большая часть времени отводится на решение практических задач.
|
||||
|
||||
## Этап 3. Финальное интервью
|
||||
|
||||
- Формат: 1 час в Zoom.
|
||||
- Участники: кандидат, нанимающий менеджер, рекрутер.
|
||||
- Оцениваются: мотивация, soft skills, culture fit.
|
||||
@@ -73,15 +70,12 @@
|
||||
- Корпоративная библиотека.
|
||||
|
||||
## Обстановка
|
||||
<p align="center">
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
</p>
|
||||
|
||||
[На нашем Хабре](https://habr.com/company/avito/blog/335896/) можно посмотреть большой фоторепортаж из офиса Авито.
|
||||
|
||||
|
||||
20
spt.md
20
spt.md
@@ -6,11 +6,11 @@
|
||||
## Типы задач
|
||||
Обращения пользователей приходят из HelpDesk, соцсетей, магазинов приложений, от клиентских менеджеров и других каналов. Обращения мы делим на три типа задач:
|
||||
|
||||
Тип задачи | Описание
|
||||
------------- | -------------
|
||||
| Bug (баг) | Ошибка из-за которой Авито работает не так, как должен. Например, пользователь не может опубликовать объявление или оплатить услугу.
|
||||
| Crash (крэш) | Непредвиденное завершение работы приложения Авито на iOS или Android.
|
||||
| Feature (фичареквест) | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги. </br> </br>К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет.
|
||||
| Тип задачи | Описание |
|
||||
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| Bug (баг) | Ошибка из-за которой Авито работает не так, как должен. Например, пользователь не может опубликовать объявление или оплатить услугу. |
|
||||
| Crash (крэш) | Непредвиденное завершение работы приложения Авито на iOS или Android. |
|
||||
| Feature (фичареквест) | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги. </br> </br>К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет. |
|
||||
|
||||
## Задача из HelpDesk
|
||||
|
||||
@@ -30,11 +30,11 @@
|
||||
|
||||
Приоритет задаче в Jira выставляется в соответствии с нашей политикой обработки ошибок. Мы используем матрицу, которая объединяет в себе серьёзность бага и вероятность/частоту его возникновения. Вот она в упрощённом виде:
|
||||
|
||||
Частота возникновения/</br>серьёзность | Crash | Failure | Flaw | Annoyance
|
||||
------------- | ------------- | ------------- | ------------- | -------------
|
||||
| Всегда | P0 | P0 | P2 | P3
|
||||
| Иногда | P1 | P1 | P3 | P4
|
||||
| Редко | P2 | P2 | P4 | P4
|
||||
| Частота возникновения/</br>серьёзность | Crash | Failure | Flaw | Annoyance |
|
||||
|----------------------------------------|-------|---------|------|-----------|
|
||||
| Всегда | P0 | P0 | P2 | P3 |
|
||||
| Иногда | P1 | P1 | P3 | P4 |
|
||||
| Редко | P2 | P2 | P4 | P4 |
|
||||
|
||||
Для багов SPT дополнительно обращаем внимание на:
|
||||
- Общее количество обращений пользователей по этой проблеме.
|
||||
|
||||
Reference in New Issue
Block a user