Недавно мы открылись для внешних пользователей Яндекс.
Трекер — наша система управления задачами и процессами.
В Яндексе его используют не только для создания сервисов, но даже для покупки печенья для кухни.
Как известно, чем меньше компания, тем более простые инструменты она может использовать.
Если с утра вы сможете поздороваться с каждым сотрудником лично, то для работы вам будет достаточно даже чата в Telegram. Когда появляются отдельные команды, не только невозможно поприветствовать каждого лично, но и статусы задач могут сбивать с толку.
Облако слов в названиях билетов во внутреннем Яндекс.
Трекере На этом этапе важно сохранять прозрачность процессов: все стороны должны иметь возможность в любой момент узнать о ходе работы над задачей или, например, оставить комментарий, который не потеряется в потоке рабочего чата.
.
Для небольших команд трекер — это своего рода новостная лента с последними новостями из жизни их компании.
Сегодня мы расскажем читателям Хабрахабра, почему Яндекс решил создать свой трекер, как он работает внутри и с какими трудностями нам пришлось столкнуться при открытии его наружу.
В «Яндексе» сейчас работают более шести тысяч человек.
Несмотря на то, что многие его части структурированы как независимые стартапы со своими командами разного размера, всегда необходимо понимать, что происходит с людьми на следующем этаже — их работа может пересекаться с вашей, их улучшения могут помочь.
вы и некоторые процессы могут действовать наоборот. может негативно повлиять на вас.
В такой ситуации сложно, например, позвонить коллеге из другого рабочего пространства в Slack. Особенно, когда прозрачность задач важна для многих людей разных направлений.
В какой-то момент мы начали использовать всем известную Jira. Это хороший инструмент, функционал которого в принципе устраивал всех, но его было сложно интегрировать с нашими внутренними сервисами.
Кроме того, в масштабах тысяч людей, которым нужно единое пространство, где каждый сможет ориентироваться без фонарика, Jira уже было недостаточно.
Бывало и так, что он вылетал под нагрузкой, хотя на наших серверах работал.
Яндекс рос, количество тикетов тоже увеличивалось, а обновления новых версий занимали все больше времени (последнее обновление заняло полгода).
Что-то нужно было изменить.
В конце 2011 года у нас было несколько вариантов решения проблемы:
- Увеличение производительности старого трекера.
Идею отбросили, потому что.
самому перепроектировать архитектуру чужого продукта — это плохо.
Это означало бы, как минимум, прекращение обновлений.
- Разделите трекер на несколько независимых копий (экземпляров), чтобы снизить нагрузку на каждую.
Идея не нова; крупные компании используют его в подобных случаях.
В результате не будут работать сквозные отчеты, фильтрация, связывание и перенос задач между копиями.
Все это было критично для компании.
- Купите другой инструмент. Мы рассмотрели возможные варианты трекеров.
Большинство из них не позволяют легко масштабироваться, то есть стоимость доработок инфраструктуры и последующих изменений под наши нужды будет выше, чем стоимость собственной разработки.
- Напишите свой трекер.
Рискованный вариант. Дает максимальную свободу и возможности в случае успеха.
В случае неудачи у нас возникнут проблемы с одним из ключевых инструментов разработки и планирования.
Как вы уже догадались, мы рискнули и выбрали этот вариант. Ожидаемые преимущества перевешивали недостатки и риски.
Сама команда трекера первой передала свои задачи новому сервису через несколько месяцев после начала работы над проектом.
Затем начался процесс перемещения остальных команд. Каждая команда выдвигала свои требования к функционалу, они прорабатывались, трекер приобретал новые возможности, а потом команду развозили.
Чтобы полностью переместить все команды и закрыть Gira, потребовалось два года.
Но вернемся немного назад и посмотрим на список требований, который был составлен к новому сервису:
- Отказоустойчивость.
Как ты можешь слышал Компания регулярно проводит учения по отключению одного из РЦ.
Служба должна беспрепятственно выполнять их как для пользователя, так и для команды, без необходимости выполнять действия вручную при запуске упражнения.
- Масштабируемость.
Задания в трекере не имеют срока давности.
Разработчику или менеджеру может потребоваться взглянуть как на сегодняшнюю проблему, так и на ту, которая была закрыта 7 лет назад. Это означает, что мы не можем удалить или заархивировать старые данные.
- Интеграция с внутренними сервисами компании.
Тесная интеграция с нашими многочисленными сервисами требовалась большинству команд Яндекса: интеграция с сервисами долгосрочного планирования, системами контроля версий, каталогом сотрудников и т. д.
- Java 7 (теперь 8) для серверной части.
- Node.js + BEMHTML + i-bem для фронтенда.
- MongoDB как основное хранилище данных: автоматический отказоустойчивость, хорошая скорость и возможность легко включить шардирование, бессхемность (удобно для настраиваемых полей в задачах).
- Elasticsearch для быстрого поиска и агрегирования по настраиваемому полю.
Свою роль в выборе сыграли и гибкие возможности настройки анализаторов дайджестов, перколятора и прочих эластичных вкусностей.
- ZooKeeper для обнаружения серверных частей служб.
Бэкэнды взаимодействуют друг с другом, чтобы аннулировать кеши, распределять задачи и собирать собственные метрики.
С помощью ZooKeeper и его клиента открытие можно организовать очень легко.
- Хранение файлов как услуга, которая избавляет нас от головной боли по репликации и резервному копированию при хранении пользовательских вложений.
- Hystrix для связи с внешними сервисами.
Чтобы предотвратить каскадные сбои, не загружайте соседние службы, если у них возникли проблемы.
- Nginx для терминации https и ограничений скорости.
Как показала практика, терминировать https внутри java — не лучшая идея с точки зрения производительности, поэтому мы перенесли эту задачу на nginx. Также безопаснее организовать ограничитель скорости на его стороне.
Пример для понимания ситуации.
Когда мы начинали проектировать систему, у нас было около 1 миллиона задач и 3 тысячи пользователей.
На сегодняшний день у сервиса почти 9 миллионов задач и более 6 тысяч пользователей.
Кстати, несмотря на довольно приличное количество пользователей внутреннего Трекера, большая часть запросов поступает на трекер через API от интегрированных с ним сервисов Яндекса.
Именно они создают основную нагрузку: 
Ниже вы можете увидеть процентили ответов в середине рабочего дня: 
Мы стараемся регулярно оценивать будущую нагрузку на сервис.
Строим прогноз на 1-2 года, затем с помощью Лунапарк проверяем, что сервис это выдержит: 
На этом графике видно, что API поиска задач начинает выдавать заметное количество ошибок только после 500-600 об/с.
Это позволило подсчитать, что с учетом растущей нагрузки со стороны внутренних клиентов и роста объема данных мы выдержим нагрузку через 2 года.
Помимо высокой нагрузки, с сервисом могут случиться и другие неприятные ситуации, с которыми нужно уметь справиться, чтобы пользователи этого не заметили.
Перечислим некоторые из них.
- Сбой дата-центра.
Очень неприятная ситуация, которая, тем не менее, благодаря упражнениям возникает регулярно.
Что происходит, когда это происходит? Худший случай — когда мастер монги находился в отключенном DC. Но даже в этом случае вмешательство разработчика или администратора не требуется благодаря автоматическому переключению при отказе.
В эластике ситуация немного другая: часть данных оказалась в единственном экземпляре, т.к.
наш коэффициент репликации равен 1. Поэтому он создает новые шарды на уцелевших узлах, чтобы все шарды снова имели резервную копию.
При этом балансировщик над бэкендом получает таймаут соединения в тех запросах, которые были выполнены на инстансах в отключенном DC, или ошибку от работающего бэкенда, запрос которого ушёл на отсутствующий DC и не вернулся.
В зависимости от обстоятельств балансировщик может попытаться повторить запрос или вернуть пользователю ошибку.
Но в итоге балансировщик поймет, что инстансы с отключенного DC ему недоступны и перестанет отправлять туда запросы, проверяя в фоновом режиме, работоспособен ли DC и не пора ли вернуть туда нагрузку.
- Потеря соединения между серверной частью и базой данных/индексом из-за проблем с сетью.
Несколько более простая ситуация на первый взгляд. Поскольку балансировщик над бэкендом регулярно проверяет его статус, то ситуация, когда бэкенд не может связаться с базой данных, возникает очень быстро.
И балансировщик снова снимает нагрузку с этого бэкенда.
Существует опасность, что если все бэкенды потеряют связь с базой данных, они все закроются, что в конечном итоге затронет 100% запросов.
- Высокая загрузка запросов в поиске трекера.
Поиск задач, их фильтрация, сортировка и агрегирование — очень трудоемкие операции.
Поэтому именно эта часть API имеет самые строгие ограничения по нагрузке.
Раньше мы вручную находили тех, кто завалил нас обращениями, и просили снизить нагрузку.
Сейчас такое происходит все чаще, поэтому включение лимитов скорости позволило не заметить слишком активный API-клиент.
Яндекс.
Трекер – для всех Нашим сервисом не раз интересовались и другие компании — о нашем внутреннем инструменте они узнали от тех, кто ушел из Яндекса, но забыть Трекер не смогли.
А в прошлом году мы внутри компании решили подготовить Трекер к выпуску в мир — превратить его в продукт для других компаний.
Мы сразу приступили к работе над архитектурой.
Перед нами стояла большая задача масштабирования сервиса на сотни тысяч организаций.
До этого сервис годами разрабатывался для одной из наших компаний с учетом только ее потребностей и нюансов.
Стало ясно, что нынешняя архитектура потребует серьезных доработок.
В результате у нас было два решения.
| Отдельные экземпляры для каждой организации | Экземпляр, в котором могут размещаться тысячи организаций |
Плюсы:
|
Плюсы:
|
Это значительно усложняло поддержку первого варианта — было много точек отказа.
Поэтому мы выбрали второй вариант как окончательный.
Переписывание основной части проекта заняло у нас два месяца, что стало рекордным сроком для такой задачи.
Однако, чтобы не ждать, мы установили несколько копий трекера на выделенное оборудование, чтобы было на чем протестировать фронтенд и взаимодействие со смежными сервисами.
Отдельно стоит отметить, что еще на этапе проектирования мы приняли принципиальное решение поддерживать одну кодовую базу для обоих Трекеров: внутреннего и внешнего.
Это позволяет нам не копировать код из одного проекта в другой, не замедлять скорость релизов и выпускать фичи практически сразу после их появления в нашем внутреннем Трекере.
Но, как оказалось, добавить ко всем методам приложения еще один параметр недостаточно; мы также столкнулись со следующими проблемами:
- Нерезиновая монга и эластичная.
Объединить данные в один экземпляр было невозможно, Elastic не обрабатывает большое количество индексов, Monga также не смогла вместить все организации.
Поэтому бэкенд был разделен на несколько крупных экземпляров, каждый из которых может обслуживать закрепленные за ним организации.
Каждый экземпляр отказоустойчив.
В этом случае между ними можно перетащить организацию.
- Необходимость выполнения задач cron для каждой организации.
Здесь пришлось решать вопрос с каждой проблемой индивидуально.
Где-то они заменили pull data на push. Где-то одна задача cron генерировала отдельную задачу для каждой организации.
- В каждой организации разный набор полей задач.
Из-за наличия оптимизаций для работы с ними пришлось написать для них отдельный кеш.
- Обновление сопоставления индексов.
Довольно распространенная операция, возникающая при обновлении трекера до новой версии.
Добавлен механизм пошагового обновления карт.
- Открытие API для внешних пользователей.
Пришлось добавить ограничитель скорости и заблокировать доступ к API сервиса.
- Наличие службы поддержки для редких действий.
Наши сотрудники службы поддержки и разработчики не имеют права просматривать пользовательские данные организаций, а это значит, что все действия должны выполняться администраторами компании.
Мы добавили для них в интерфейс ряд админ-панелей.
Из-за множества изменений необходимо было оценить скорость работы, количество организаций, которые могли поместиться в инстансе, а также поддерживаемые rps. Поэтому мы проводили регулярные съемки, предварительно заполнив наш тестовый трекер большим количеством организаций.
По результатам мы определили лимит нагрузки, после которого новые организации необходимо будет размещать в новом инстансе.
Мы создали еще один специальный экземпляр Tracker для размещения демо версия .
Чтобы войти в него, вам достаточно иметь аккаунт на Яндекс.
Он блокирует некоторые функции (например, загрузку файлов), но вы можете ознакомиться с реальным интерфейсом Трекера.
Теги: #Управление разработкой #Управление проектами #Управление продуктом #управление задачами #Яндекс.
трекер #трекер задач
-
Насос - Мобильный Автозаправщик
19 Oct, 24 -
Мфкаст №45. Андроид Снова
19 Oct, 24 -
«Сенорранет» — Интересно Для Дизайнера
19 Oct, 24 -
Asterisk 12 Выйдет В 2013 Году.
19 Oct, 24 -
Режимы И Состояния В Scss
19 Oct, 24 -
Новое В Haiku (Svn)
19 Oct, 24
