diff --git a/avito-developer-practice.md b/avito-developer-practice.md index da2ca42..600090b 100644 --- a/avito-developer-practice.md +++ b/avito-developer-practice.md @@ -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. Закрываем тикет и дополняем базу знаний. Простые и понятные проблемы мы разбираем внутри команд или в слак-чатиках. А кросс-командные встречи проводим для серьёзных и бизнес-критичных проблем: инфраструктурных, процессных и тех, которые затронули сразу несколько команд. Встречи открытые, их анонс мы публикуем в отдельном канале, и прийти на них может любой человек в компании. diff --git a/neighborhood-agreement.md b/neighborhood-agreement.md index c28625c..f965bfa 100644 --- a/neighborhood-agreement.md +++ b/neighborhood-agreement.md @@ -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, напиши тест, который его проверяет и скажет, что это затронуло ваш юнит. Команда — оунер результата. Всегда мониторим зависимости, которые могут поломать сервис. | +| Владеешь кодом – отвечаешь за его тесты и метрики | Оунишь репозиторий — покрой тестами, метриками и необходимым логированием. | + *** ## Правила внесения изменений в чужой функционал diff --git a/analytics-management.md b/profiles/analytics-managers.md similarity index 100% rename from analytics-management.md rename to profiles/analytics-managers.md diff --git a/analytics-levels.md b/profiles/analytics-skills.md similarity index 100% rename from analytics-levels.md rename to profiles/analytics-skills.md diff --git a/design-management.md b/profiles/design-managers.md similarity index 100% rename from design-management.md rename to profiles/design-managers.md diff --git a/design-levels.md b/profiles/design-skills.md similarity index 100% rename from design-levels.md rename to profiles/design-skills.md diff --git a/developer-profile.md b/profiles/developer-skills.md similarity index 100% rename from developer-profile.md rename to profiles/developer-skills.md diff --git a/ds-managers-profiles.md b/profiles/ds-managers.md similarity index 100% rename from ds-managers-profiles.md rename to profiles/ds-managers.md diff --git a/ds-skills.md b/profiles/ds-skills.md similarity index 100% rename from ds-skills.md rename to profiles/ds-skills.md diff --git a/QA-profile.md b/profiles/qa-skills.md similarity index 100% rename from QA-profile.md rename to profiles/qa-skills.md diff --git a/techlead-profile.md b/profiles/tech-managers.md similarity index 100% rename from techlead-profile.md rename to profiles/tech-managers.md diff --git a/readme.md b/readme.md index 9f84be9..3794a41 100644 --- a/readme.md +++ b/readme.md @@ -18,22 +18,21 @@ # Авито в цифрах -| `Показатель` | `Значение` | -|:---|:---| -Всего сотрудников Авито | 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) diff --git a/recruitment-and-office.md b/recruitment-and-office.md index 5821ad1..7eae10a 100644 --- a/recruitment-and-office.md +++ b/recruitment-and-office.md @@ -30,14 +30,11 @@ В секции мы даём кандидату практическую задачу. Это может быть как абстрактная задача «давай спроектируем Авито», так и задача с условиями, специфичными для команды. Например, «давай спроектируем платформу виджетов используя фреймворк Vue JS», «давай спроектируем PaaS». ### Секции для QA-инженеров - **Секция 1. Тестирование.** На этой секции мы проверяем ключевые навыки кандидата в обеспечении качества: составлении тестов и организации процесса тестирования. Даём две простых задачи на тест-дизайн и одну развёрнутую на тестирование новой фичи. Здесь мы смотрим, как кандидат комплексно подходит к тестированию новой функциональности. - **Секция 2. Автоматизация.** На этой секции проверяем знания кандидата по автоматизации тестирования: когда и что нужно автоматизировать, как разрабатывать тесты, просто написание кода. Секция содержит небольшую часть теоретических вопросов. Большая часть времени отводится на решение практических задач. ## Этап 3. Финальное интервью - - Формат: 1 час в Zoom. - Участники: кандидат, нанимающий менеджер, рекрутер. - Оцениваются: мотивация, soft skills, culture fit. @@ -73,15 +70,12 @@ - Корпоративная библиотека. ## Обстановка -

- ![](https://github.com/lapkoa/Images/blob/6df140573355a495736ff00c38153b8e55704eb4/Photo_002.jpg) ![](https://github.com/lapkoa/Images/blob/6df140573355a495736ff00c38153b8e55704eb4/Photo_246.jpg) ![](https://github.com/lapkoa/Images/blob/6df140573355a495736ff00c38153b8e55704eb4/Photo_391.jpg) ![](https://github.com/lapkoa/Images/blob/b0bf6e6802fa53936ec9dfba95a4ba99f14e4496/Photo_345.jpg) ![](https://github.com/lapkoa/Images/blob/3c12e9e02ef2d1ef875ffc14e2b771a053879fbd/Photo_349.jpg) ![](https://github.com/lapkoa/Images/blob/3c12e9e02ef2d1ef875ffc14e2b771a053879fbd/Photo_372.jpg) -

[На нашем Хабре](https://habr.com/company/avito/blog/335896/) можно посмотреть большой фоторепортаж из офиса Авито. diff --git a/spt.md b/spt.md index 2fbab95..fd99ed5 100644 --- a/spt.md +++ b/spt.md @@ -6,11 +6,11 @@ ## Типы задач Обращения пользователей приходят из HelpDesk, соцсетей, магазинов приложений, от клиентских менеджеров и других каналов. Обращения мы делим на три типа задач: -Тип задачи | Описание -------------- | ------------- -| Bug (баг) | Ошибка из-за которой Авито работает не так, как должен. Например, пользователь не может опубликовать объявление или оплатить услугу. -| Crash (крэш) | Непредвиденное завершение работы приложения Авито на iOS или Android. -| Feature (фичареквест) | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги.

К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет. +| Тип задачи | Описание | +|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| Bug (баг) | Ошибка из-за которой Авито работает не так, как должен. Например, пользователь не может опубликовать объявление или оплатить услугу. | +| Crash (крэш) | Непредвиденное завершение работы приложения Авито на iOS или Android. | +| Feature (фичареквест) | Просьба пользователя добавить новую функциональность на сайт или в приложение. Например, пожелание добавить в фильтры породу вельш-корги.

К этому же типу задач относятся багофичи. Это когда мы изначально завели обращение с типом «баг», но на деле ошибки нет. | ## Задача из HelpDesk @@ -30,11 +30,11 @@ Приоритет задаче в Jira выставляется в соответствии с нашей политикой обработки ошибок. Мы используем матрицу, которая объединяет в себе серьёзность бага и вероятность/частоту его возникновения. Вот она в упрощённом виде: -Частота возникновения/
серьёзность | Crash | Failure | Flaw | Annoyance -------------- | ------------- | ------------- | ------------- | ------------- -| Всегда | P0 | P0 | P2 | P3 -| Иногда | P1 | P1 | P3 | P4 -| Редко | P2 | P2 | P4 | P4 +| Частота возникновения/
серьёзность | Crash | Failure | Flaw | Annoyance | +|----------------------------------------|-------|---------|------|-----------| +| Всегда | P0 | P0 | P2 | P3 | +| Иногда | P1 | P1 | P3 | P4 | +| Редко | P2 | P2 | P4 | P4 | Для багов SPT дополнительно обращаем внимание на: - Общее количество обращений пользователей по этой проблеме.