Pull to refresh
5
0

Редактор

== Так вы не авторизуете платежи, а просто шлюзуете их на банки?

ЮKassa – точка входа в эквайринг нескольких банков России, в том числе, использует и собственный эквайринг ЮMoney. Такой подход позволяет обеспечить балансировку нагрузки, лучшие ставки для магазинов, и, конечно же, отказоустойчивость за счет «резервирования».

==Там стоят модули шифрования/дешифрования, они создают узкие места. По сути на банках 20-30TPS на один такой модуль это уже предельная нагрузка.

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

==В случае шлюза это большая проблема, держать 200TPS?

Как и с какой нагрузкой справляется каждый отдельный банк-эквайер зависит от особенностей его внутренней реализации. Например, для собственного эквайринга ЮMoney показатели в 200 tps – не предельные.

Спасибо, проверим этот момент. Отправьте, пожалуйста, номер кошелька нам в лс — поблагодарим за тестирование. ;)

Мы рекомендуем сначала обратить внимание на п.1, это оптимальный стартовый подход в случае, если вопрос про "какое кол-во юзеров выдержит сервис". А дальше уже проводить точечную оптимизацию по отдельным важным (медленным, ценным, значимым) методам.


У нас это хорошо описано в этих двух статьях, все можно прочитать по ссылкам:
https://habr.com/ru/companies/yoomoney/articles/433436/
https://habr.com/ru/companies/yoomoney/articles/437416/

Надеемся, помогли вам) Если будут ещё вопросы - задавайте!

Здравствуйте! Спасибо за ваш комментарий) Уже передали его автору, скоро ответим.

Здравствуйте! Мы выпустили статью с краткими резюме докладов, видеороликами и таймкодами. Приглашаем почитать и посмотреть) Вот ссылка на этот материал: Что общего у Rolls Royce, покрытия автотестами и PgBouncer / Хабр (habr.com)

Здравствуйте! Да, конечно. Мы уже готовим статью по мотивам докладов для Хабра, в ней будут записи и таймкоды, чтобы было удобнее смотреть. Но если выложим пораньше ролики, то пришлём вам ссылку на них. =)

Вы подняли очень больную тему. И правда, Microsoft создала прекрасный инструмент для проверки кода, но тот способ, которым они предлагают распространять библиотеку, абсолютно не приемлем. Первое что приходит на ум — анализатор Roslyn. Этот пример нас очень вдохновил, и мы решили попробовать поступить схожим образом. Давайте попробуем разобраться вместе.

Библиотека с нашими правилами проверки ищется в той же папке (C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\150), где лежит библиотека Microsoft.Data.Tools.Schema.Tasks.Sql.dll. В документации предлагают подкладывать наш dll в эту папку. Но, как вы сказали, это сильно не удобно. Если посмотреть C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VisualStudio\v16.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets, то можно обнаружить, откуда берётся задание SqlStaticCodeAnalysisTask:

  <UsingTask TaskName="SqlStaticCodeAnalysisTask" AssemblyFile="$(SqlServerRedistPath)\Microsoft.Data.Tools.Schema.Tasks.Sql.dll" />

Параметр $(SqlServerRedistPath) задается несколькими строками выше (через параметр $(SSDTPath)):

  <PropertyGroup>

    <ReferencePath Condition="$(SSDTPath) != ''">$(ReferencePath);$(SSDTPath)</ReferencePath>

    <DacPacRootPath>$(VsIdePath)</DacPacRootPath>

    <SqlServerRedistPath Condition="'$(SSDTPath)' != ''">$(SSDTPath)</SqlServerRedistPath>

    <SqlServerRedistPath Condition="'$(SqlServerRedistPath)' == ''">$(VsIdePath)\Extensions\Microsoft\SQLDB\Dac\150</SqlServerRedistPath>

  </PropertyGroup>

Соответственно параметр $(SSDTPath) можно указать прямо в sqlproj.

Возвращаясь к анализатору Roslyn: он представляет из себя NuGet-пакет. Что нам мешает сделать то же самое? Создадим NuGet-пакет, в котором будут все dll из папки C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\150 + библиотека с нашими проверками. После того, как опубликовали библиотеку, необходимо руками добавить наименование этого пакета в sqlproj (VS не поддерживает NuGet в проектах sql). Для этого в проект добавляем несколько строк:

<ItemGroup>

  <PackageReference Include="OurCompany.OurValidations" Version="1.13.0" GeneratePathProperty="true">

    <PrivateAssets>all</PrivateAssets>

    <IncludeAssets>build</IncludeAssets>

  </PackageReference>

</ItemGroup>

Присваиваем значения для параметра $(SSDTPath):

<PropertyGroup>

  <SSDTPath>$(PkgOurCompany_OurValidations)\lib\net472</SSDTPath>

</PropertyGroup>

Изначально восстанавливаем NuGet-пакет:

msbuil MyProjectName.sqlproj /t:Restore

Собираем проект:

msbuil MyProjectName.sqlproj /t:Build

Правда, такое решение работает только при построении из консоли, так как Visual Studio, насколько я понимаю, смотрит на оригинальные dll. Но нам ничего не мешает добавить Target, который будет вызывать MSBuildTask c Target=StaticCodeAnalys.

Уже сейчас в [SDK-Style](https://github.com/microsoft/DacFx/blob/main/src/Microsoft.Build.Sql/sdk/Sdk.targets#L51) проекте можно обнаружить, что БД [master](https://www.nuget.org/packages/Microsoft.SqlServer.Dacpacs.Master) подтягивается из NuGet. 

Что касается Extension в Visual Studio: действительно, таким способом распространять правила проверки куда удобнее. Но а как вы проверите код при сборке в CI (continuous integration)?

Спасибо за ваш комментарий и мнение!

Вот передаем ответ Оли, автора статьи:

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

В статье упоминается, что у нас есть отдельный отдел аналитики, и именно системные аналитики описывают технические решения в общем случае. Но если нам нужно внести изменения в какой-то API-метод, мы в команде как правило опишем в документации это самостоятельно – это не сложно. ПМ как аналитик отвечает за достаточность документации в команде, и когда нужно, привлекает аналитика.

Роль инцидент-менеджера: у нас унифицирована часть этой функции. Конечно, ПМ не занимается первой или второй линией поддержки. Есть первая линия с их инструкциями, если не получается решить на первой – подключается вторая линия, там уже люди могут посмотреть логи и ответить на большинство вопросов. Но есть вопросы не стандартные или очень срочные, в таких случаях менеджеру в рамках своей ответственности нужно уметь быстро ответить. Иногда самому логи посмотреть быстрее и проще, чем привлекать разработчика.

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

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

Во-первых, мы смотрели на интересы и бэкграунд кандидата — прохождение продуктовых курсов было одним из критериев, который мы оценили как must have — просто, чтобы убедиться в том, что кандидату действительно важно и интересно это направление
Во-вторых, важным для нас триггером в принятии решения стало то, что наш стажёр имел опыт в роли sales manager — для нас это был как маркер того, что он умеет в переговоры, а, значит, сможет проводить без какого-то внутреннего страха и сопротивления проблемные и решенческие интервью среди наших пользователей, то есть будет полезен при проведении cusdev вместе с UX-командой.

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

Опыт найма стажёра был полезным не только для новичка, но и для нас — мы выявили небольшие проблемы с онбордингом и интеграцией новичка во все процессы — потребовалось больше времени на то, чтобы коллега стал самостоятельным, чем мы могли себе представить изначально. Но тут объективно повлияло отсутствие у него опыта работы в крупной компании, где более 1000 человек занимается развитием сервиса.

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

Наш видеоконтент пока находится на доработке. В ближайшее время видео снова станет доступным.

Спасибо за такой подробный комментарий и разбор выступлений. Мы постарались подобрать спикеров разного уровня и с разными темами, чтобы каждый мог почерпнуть для себя что-то новое. Комментарии к видео открыли, можете оставить свой отзыв под видео. если еще есть такое желание — спикерам будет очень приятно.

Спасибо и вам за комментарий! Приятно, что наши темы попали в цель и нашли отклик!

Добрый день! Рады, что вам понравился кейс :) Презентацию можно посмотреть по ссылке.

В кейсе «Прозрачное планирование. Путь самурая» мы поделились нашим опытом развития через боль. В дедлайн менеджер как бы умирает и возрождается уже более опытным и эффективным.

Здравствуйте! Таймкоды во всех видео с митапа добавили вчера, обновили описание роликов сразу после публикации видео. Вопросы спикерам по теме выступлений вы можете задать здесь, в комментариях на Хабре.

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Works in
Registered
Activity