Мы отреагировали на сообщение на площадке Bugbounty сразу как его получили. Согласно статье, 2 месяца исследователь искал нашу Bugbounty программу. Она вот здесь, на первой странице поиска: https://yandex.ru/search/?text=юмани+bugbounty
Кроме того, автор ошибся с оценкой критичности, мы оценили ее как medium, угрозы средствам клиентов не было. Уязвимость была закрыта в нормативные сроки.
Автор получил ответ и от нас, и от администрации Bugbounty. Но в своих публикациях автор не приводит ответ площадки о том, что мы предоставили документальные подтверждения, что баг был найден до обращения, и подает информацию однобоко.
С автором уже была переписка на площадке Bugbounty, мы предоставили наши доводы площадке, наша позиция подтверждена, но автор это повторно игнорирует и подает информацию неполностью. Наша позиция довольно четкая — за дубли мы не платим.
Обращение является дублирующим, это подтверждается нашими внутренними документами. Мы предоставили все необходимые подтверждения дубля репортинга площадке. По правилам программы, вознаграждение за дубли не выплачивается.
Площадка подтвердила, что мы ей предоставили доказательства, что баг был зафиксирован раньше обращения.
== Так вы не авторизуете платежи, а просто шлюзуете их на банки?
Ю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 человек занимается развитием сервиса.
Ну, и то, что финтех имеет свои особенности, завязанные на регуляторику ЦБ и других надзорных органов, тоже повлияли на сроки адаптации нового коллеги.
Спасибо за такой подробный комментарий и разбор выступлений. Мы постарались подобрать спикеров разного уровня и с разными темами, чтобы каждый мог почерпнуть для себя что-то новое. Комментарии к видео открыли, можете оставить свой отзыв под видео. если еще есть такое желание — спикерам будет очень приятно.
Мы отреагировали на сообщение на площадке Bugbounty сразу как его получили. Согласно статье, 2 месяца исследователь искал нашу Bugbounty программу. Она вот здесь, на первой странице поиска: https://yandex.ru/search/?text=юмани+bugbounty
Кроме того, автор ошибся с оценкой критичности, мы оценили ее как medium, угрозы средствам клиентов не было. Уязвимость была закрыта в нормативные сроки.
Автор получил ответ и от нас, и от администрации Bugbounty. Но в своих публикациях автор не приводит ответ площадки о том, что мы предоставили документальные подтверждения, что баг был найден до обращения, и подает информацию однобоко.
С автором уже была переписка на площадке Bugbounty, мы предоставили наши доводы площадке, наша позиция подтверждена, но автор это повторно игнорирует и подает информацию неполностью. Наша позиция довольно четкая — за дубли мы не платим.
Обращение является дублирующим, это подтверждается нашими внутренними документами. Мы предоставили все необходимые подтверждения дубля репортинга площадке. По правилам программы, вознаграждение за дубли не выплачивается.
Площадка подтвердила, что мы ей предоставили доказательства, что баг был зафиксирован раньше обращения.
Ну пока не до такой степени))
== Так вы не авторизуете платежи, а просто шлюзуете их на банки?
Ю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 человек занимается развитием сервиса.
Ну, и то, что финтех имеет свои особенности, завязанные на регуляторику ЦБ и других надзорных органов, тоже повлияли на сроки адаптации нового коллеги.
Наш видеоконтент пока находится на доработке. В ближайшее время видео снова станет доступным.
Спасибо за такой подробный комментарий и разбор выступлений. Мы постарались подобрать спикеров разного уровня и с разными темами, чтобы каждый мог почерпнуть для себя что-то новое. Комментарии к видео открыли, можете оставить свой отзыв под видео. если еще есть такое желание — спикерам будет очень приятно.
Спасибо и вам за комментарий! Приятно, что наши темы попали в цель и нашли отклик!
Добрый день! Рады, что вам понравился кейс :) Презентацию можно посмотреть по ссылке.