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

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

Проблема была серьезной

  • В прошлом году процент сеансов без сбоев (процент сеансов без сбоев пользовательского интерфейса) временами составлял всего ~50%.
  • Иногда в среднем происходило около 7000 сбоев в час. Большинство из них были ложными предупреждениями, которые повлияли на MTTD реальных проблем.
  • MTTA (среднее время подтверждения) инцидентов составляло более 2 часов.
  • Не было надлежащих проверок конвейеров сборки и развертывания.

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

Решение было сложным

Это было довольно трудно решить.

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

Мы любим вызовы

Мы нашли идеальное решение для этого. При этом мы:

  • Уменьшено количество сбоев в 350 раз до 20 в час (первоначально было 7000 в час)
  • Количество сеансов без сбоев увеличилось до ~99,9X% (первоначально было ~50%).
  • Предотвращены неудачные развертывания, в которых критические изменения вносились более чем в 10 раз из примерно 100 развертываний за последние 3 месяца.
  • Сокращено MTTA (среднее время подтверждения инцидента командой инженеров) до ~2–3 минут (первоначально оно составляло ~2–3 часа). Снижение MTTA помогло снизить MTTR (среднее время решения).
  • Добавлены более сильные проверки во время сборки. Мы обнаружили, что 10–15% PR содержат критические изменения на уровне сборки, и мы заблокировали объединение этих изменений с мастером на уровне PR.

Как мы это сделали

Давайте шаг за шагом посмотрим, как мы подошли к проблеме и нашли идеальное решение. Вот шаги, которые мы предприняли для решения проблем:

  1. Сузили ошибки до правильного владельца
  2. Выявлены и устранены проблемы
  3. Добавлены проверки, чтобы избежать новых проблем
  4. Сокращение числа инцидентов иMTTA
  5. Более быстрые откаты в случае инцидентов

1. Сузили ошибки до нужного владельца 🕵️‍♂️

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

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

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

Это помогло пометить правильную команду для инцидентов, а также помогло создать нашу панель мониторинга для мониторинга предупреждений.

2. Выявлены и устранены проблемы 🔨

Эта задача была не менее сложной, так как более 16 команд с более чем 40 инженерами внесли свой вклад в кодовую базу более чем 12000 файлов.

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

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

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

Мы сократили количество ошибок с 7000 ошибок в час до примерно 28 ошибок в час в среднем!

До (12 мая 2021 г.)

После (16 января 2022 г.)

3. Добавлены проверки, чтобы избежать новых проблем 🛡️

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

3.1 Проверки перед фиксацией

Добавлены перехватчики коммитов для анализа кода с помощью auto prettify, tsc и eslint.

3.2 Проверки после фиксации

Добавлено больше проверок 🛡️перед слиянием кода с основной веткой.

  1. проверка размера PR
  2. Конфиденциальные файлы будут просматриваться только определенными людьми
  3. ESLint проверяет
  4. Проверка машинописного текста
  5. Разница в размере пакета для обозревателей, чтобы увидеть влияние PR на размер пакета
  6. Модульные и интеграционные тесты
  7. Проверка порога покрытия кода
  8. Владельцы кода. Гарантированные проверки PR разрешены только от группы владельцев кода.

3.3 Проверки при развертывании

Мы добавили еще несколько проверок перед развертыванием релиза в рабочей среде.

  1. Добавлен набор сквозных тестов для среды автоматизации.
  2. Добавлен набор сквозных тестов в производственной среде с нулевым трафиком.

Развертывание было остановлено из-за сбоя комплексного пакета в среде автоматизации.

Развертывание было остановлено из-за сбоя тестовых случаев в рабочей среде с нулевым трафиком.

3.4 Оптимизация конвейера сборки, рекламы и развертывания

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

Пиар-канал:

Конвейер развертывания:

Мыдобавили проверки гигиены перед фиксацией, сборкой, PR и развертыванием. Это позволило предотвратить более 10 неудачных развертываний, в которых за последние 3 месяца были критические изменения.

4. Уменьшено количество инцидентов и MTTA 📞

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

Каждую неделю мы вели журналы обзора действий с заинтересованными сторонами, чтобы уменьшить количество инцидентов и MTTA.

Количество инцидентов за последние 3 месяца:

5. Более быстрые откаты в случае инцидентов ⏪

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

Мы создали новый простой конвейер возврата, который представляет собой процесс запуска и утверждения одним нажатием. Весь процесс возврата занимает 2–3 минуты для восстановления более старой стабильной версии панели инструментов (первоначально это занимало ~30 минут!).

Что ждет впереди 🤔

  • Проверьте каждый PR, чтобы убедиться в наличии сквозных тестов для новых потоков.
  • Запустите комплексные наборы тестов с разными ролями пользователей (например, владелец, менеджер, финансы, операции и т. д.).
  • Добавьте больше интеграционных тестов и увеличьте покрытие кода.

Фронтенд-инжиниринг в Razorpay

Если вам интересно узнать больше о FE в Razorpay, читайте другие наши блоги:

https://engineering.razorpay.com/laying-the-frontend-foundations-with-a-platform-team-62c21c37bf9c



Надежный выпуск функций в мобильном приложении
При написании тестов для кода вы выполняете агрессивные, а не регрессивные итерации.engineering.razorpay.com





Создание адаптивных интерфейсов в неадаптивном приложении
История создания и запуска мобильного первого входа и регистрации в настольном приложении.engineering.razorpay .com



Работа в Разорпей

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