== Так вы не авторизуете платежи, а просто шлюзуете их на банки?
ЮKassa – точка входа в эквайринг нескольких банков России, в том числе, использует и собственный эквайринг ЮMoney. Такой подход позволяет обеспечить балансировку нагрузки, лучшие ставки для магазинов, и, конечно же, отказоустойчивость за счет «резервирования».
==Там стоят модули шифрования/дешифрования, они создают узкие места. По сути на банках 20-30TPS на один такой модуль это уже предельная нагрузка.
В каждом банке в обязательном порядке на выходе из системы в сторону МПС стоят модули шифрования. По нашему опыту, сообщения имеют небольшой размер, а модули – существенные запасы мощности, и мы ни разу не упирались в их производительность.
==В случае шлюза это большая проблема, держать 200TPS?
Как и с какой нагрузкой справляется каждый отдельный банк-эквайер зависит от особенностей его внутренней реализации. Например, для собственного эквайринга ЮMoney показатели в 200 tps – не предельные.
Мы рекомендуем сначала обратить внимание на п.1, это оптимальный стартовый подход в случае, если вопрос про "какое кол-во юзеров выдержит сервис". А дальше уже проводить точечную оптимизацию по отдельным важным (медленным, ценным, значимым) методам.
Здравствуйте! Да, конечно. Мы уже готовим статью по мотивам докладов для Хабра, в ней будут записи и таймкоды, чтобы было удобнее смотреть. Но если выложим пораньше ролики, то пришлём вам ссылку на них. =)
Вы подняли очень больную тему. И правда, 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:
Соответственно параметр $(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). Для этого в проект добавляем несколько строк:
Правда, такое решение работает только при построении из консоли, так как 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
Санкт-Петербург, Санкт-Петербург и область, Россия
Ну пока не до такой степени))
== Так вы не авторизуете платежи, а просто шлюзуете их на банки?
Ю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)
Здравствуйте! Да, конечно. Мы уже готовим статью по мотивам докладов для Хабра, в ней будут записи и таймкоды, чтобы было удобнее смотреть. Но если выложим пораньше ролики, то пришлём вам ссылку на них. =)
Спасибо, мы передали ваше пожелание команде ЮKassa. =)
Вы подняли очень больную тему. И правда, 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 человек занимается развитием сервиса.
Ну, и то, что финтех имеет свои особенности, завязанные на регуляторику ЦБ и других надзорных органов, тоже повлияли на сроки адаптации нового коллеги.
Наш видеоконтент пока находится на доработке. В ближайшее время видео снова станет доступным.
Спасибо за такой подробный комментарий и разбор выступлений. Мы постарались подобрать спикеров разного уровня и с разными темами, чтобы каждый мог почерпнуть для себя что-то новое. Комментарии к видео открыли, можете оставить свой отзыв под видео. если еще есть такое желание — спикерам будет очень приятно.
Спасибо и вам за комментарий! Приятно, что наши темы попали в цель и нашли отклик!
Добрый день! Рады, что вам понравился кейс :) Презентацию можно посмотреть по ссылке.
В кейсе «Прозрачное планирование. Путь самурая» мы поделились нашим опытом развития через боль. В дедлайн менеджер как бы умирает и возрождается уже более опытным и эффективным.