Комментарии

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

Платформу для онлайн-магазина выбрал: DST Store, в нем есть весь нужный мне функционал. Опыта по разработке сайтов не было, поэтому нанял специалиста, который все сделал за меня.

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

Процедура оформления покупки у нас, как и в других похожих онлайн-магазинах: клиент формирует заказ, выбирает подходящий платежный способ и оплачивает счет. После этого мы печатаем холст и организовываем доставку.

Выход на зарубежный рынок был достаточно закономерным решением — хотелось увеличить платежеспособную аудиторию и, соответственно, выручку. Сначала вывел продажи в Казахстан, Киргизию, Узбекистан, но понял, что нужно двигаться еще дальше, поэтому стал засматриваться на США, Канаду, Австралию, Великобританию и страны Европы. Все они англоговорящие — не было необходимости переводить сайт на миллион языков.

Решая все вопросы про масштабирование бизнеса, не мог обойти стороной вопрос приема платежей. Чтобы получать средства из-за границы российские сервисы не всегда удобны, поэтому стал искать варианты.

Наименее бюрократичным и сложным вариантом мне показалась аренда имеющегося аккаунта Stripe. Он регистрируется на граждан или компании в других странах, потом сдается в аренду. Способ показался рабочим — проблем не возникло, платежи доходили быстро. Как вариант, можно еще арендовать аккаунт PayPal, GoCardless, Adyen.

Выбрал Stripe еще и потому, что у них была готовая интеграция для сайтов на WooCommerce (а у нас как раз такой). К сожалению, долго так работать не получилось, аккаунт заблокировали, а деньги на нем заморозили. Вывести их смог только через 3 месяца.

Лишившись возможности принимать средства из-за рубежа, стал срочно искать другое решение, потому что продажи застыли на несколько дней. Сначала подумал создать такой же аккаунт Stripe, только уже на друга, который живет за рубежом. Но решил, что это будет слишком рискованно для него, тем более придется разбираться в налогах еще одной страны.

Был еще вариант подключить платежку из СНГ. Я рассматривал наиболее популярные: Ckassa, Cent.app, Unitpay, Prodamus. Но у всех было ограничение по доступным странам и высокие комиссии.

Рисковать блокировкой больше не хотелось, платить высокие комиссии — тоже, поэтому продолжил поиск дальше. На форумах прочитал, что можно зарегистрировать компанию за рубежом и уже на нее подключить платежную систему (в нашем случае это все тот же Stripe). С выбором страны все оказалось легко — США, поскольку хотел позже охватить Amazon и Etsy.

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

Мой процесс открытия компании в этом штате занял всего неделю, плюс еще неделя ушла на подключение платежной системы Stripe. Чтобы выводить с него деньги, открыл счет в банке Payoneer на свою иностранную компанию.

Криптовалюта в бизнесе — это законно?

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

Подумал — а почему бы и нет. Крипта становилась все популярнее, так сказать, обстоятельства располагали. Очевидные плюсы для бизнеса:

— Низкие комиссии. Обычно сервисы берут около 1% + комиссия блокчейна.

— Доступность. Клиенты могут платить из любой страны — из тех же Штатов или Австралии. Но при этом не нужно тратить время на открытие всех этих счетов, выбор платежек и т.д.

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

— Простой процесс внедрения. В среднем интеграция платежки на сайт занимает пару минут.

— Безопасность. Блокчейн шифрует данные, хранятся они децентрализовано. Взломать сеть достаточно сложно.

— Отсутствие чарджбеков (мошенничества с банковскими картами).

— Отсутствие регулирования со стороны государств. Заморозить или заблокировать счета практически невозможно.

Другой вопрос: разрешено ли это со стороны законодательства? В России есть закон «О цифровых финансовых активах», который регулирует вопросы, связанные с криптовалютой. Ее можно хранить, покупать и продавать (уплачивая налог с дохода), использовать в качестве инвестиции.

А вот использовать в качестве платы налоговым резидентам (тем, кто проживает в РФ 183+ дней в году) за товары и услуги нельзя. Но ответственность за нарушение закона не предусмотрена.

Такие законопроекты обсуждались, рассмотрение планировалось на апрель 2023 года. Но проект еще не внесен в Госдуму. То же касается и вопросов криптобирж — их статус тоже в стадии обсуждения.

В целом, Центробанк допускает оплату криптовалютой товаров от иностранных продавцов. Глава ЦБ Эльвира Набиуллина выступает в поддержку трансграничных операций в криптовалюте. Их возможное введение обсуждается уже 2 месяца. Пилотный проект уже запущен — летом Росбанк начал проводить тестовые международные криптооперации.

А так, криптовалюта — имущество, и если она приносит доход, то, конечно, нужно платить налог. Это распространяется на покупку-продажу криптовалюты и обычно ставка составляет 13% (стандартный НДФЛ). В любом случае советую поискать актуальную информацию.

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

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

Способы приема оплаты в криптовалюте

Дальше я начал думать, как добавить криптовалюту в способы оплаты. Нашел два основных подхода: перевод на криптокошелек и подключение криптопроцессинга.

— Перевод на кошелек. Основное преимущество — простота использования, потому что ничего подключать не надо. Тем не менее требуется полностью все делать вручную: выставлять счета, переводить сумму в нужную валюту, рассчитывать комиссию, подтверждать оплату. Тем более покупатель может ошибиться в адресе кошелька и не сможет вернуть деньги.
— Процессинг криптовалют. Этот способ показался более интересным, ведь за небольшую комиссию (в среднем 1%) мы получали полную автоматизацию процесса оплаты. Транзакции обрабатываются посредническим сервисом, который отслеживает и сортирует платежи.

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

Мне не хотелось тратить время на ручную обработку оплат, поэтому остановился на криптопроцессинге. Теперь оставалось только выбрать сервис, их сейчас много, поэтому подобрать подходящий не так сложно.

Выбор криптопроцессинга

На какие критерии я опирался при подборе крипто эквайринга:
— Комиссия. Конечно, чем меньше — тем лучше, тут все понятно.
— Надежность. Было важно, чтобы средства платформа хранила на холодных кошельках. Так ниже вероятность того, что в случае взлома сервиса прпадут деньги.
— Вывод средств. Не хотелось бы ждать перевода средств на наш счет по несколько дней.
— Чекаут. В том числе от него зависит конверсия. Поэтому я искал сервисы с понятными интерфейсами, где не нужно тратить время на то, чтобы разобраться что и куда.
— Техподдержка. Нужно быстрое решение любых возникающих проблем.

Так я подобрал для себя три сервиса:
1. BitPay;
2. CryptoCloud;
3. CoinPayments.

Подробно останавливаться на каждом не буду, всю информацию можно найти в интернете. Я пообщался с поддержкой сервисов, сравнил их по пунктам выше. Основные сомнения вызывал размер комиссии: менеджеры второй платформы предложили мне его снизить, поэтому остановились на ней.

На подключение ушло около часа: за это время прошел регистрацию, создал проект в личном кабинете и протестировал интеграцию. С DST Store особых проблем тоже не возникло.

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

Выводы

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

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

Я сильно далека от крипты, но в чем преимущества процессинга?
Почему я не могу просто выложить адрес моего кошелька и QRcode к нему?

Что дает подключение к сервису процессинга криптовалютных платежей дополнительного, чтобы я платила 3%?

В большинстве случаев ключевыми инструментами для планирования выступают системы отчетности, в частности системы бизнес-аналитики (BI), а CRM и BPM — это «поставщики» данных для их дальнейшей обработки и анализа. При этом можно выделить два уровня планирования и наиболее подходящие инструменты для каждого из них.

— Стратегическое планирование. Как правило, для стратегического планирования кроме специализированных решений используются BPM-системы. Например, в рамках сотрудничества с одной крупной транспортной компанией мы реализовали проект по внедрению системы планирования железнодорожных перевозок. Система позволяет учитывать множество факторов: емкость составов, расписание, задачи по сокращению простоев и минимизацию перевозок пустыми вагонами. На базе BPM-системы были созданы математические модели для оптимизации маршрутов, что сократило время планирования с недели до 1–2 дней. Это пример сложного, но высокоэффективного подхода к планированию.
— Оперативное планирование. Для этого предпочтительны CRM-системы. С их помощью можно автоматизировать управление отделами продаж и маркетинга, контролировать выполнение KPI, прогнозировать доходы, бюджет и загрузку ресурсов. Так, в CRM-системе фиксируются плановые даты окончания текущих проектов, что помогает отделу продаж мониторить ситуацию, соблюдать дедлайны и избегать простоев.

При этом следует отметить, что в настоящее время растет спрос на универсальные решения. Все больше компаний предпочитают low-code/no-code BPM-платформы. Это позволяет быстро и с минимальными затратами автоматизировать бизнес-процессы. Например, в одном из проектов с компанией, выпускающей автомобильные шины, BPM-система использовалась для автоматизации управления рецептурами производства — управления R&D-лабораторией. Получая данные из систем управления процессом сборки готовой продукции и информацию для последующего проведения тестирования специфичных характеристик продукта, BPM способствует созданию централизованного хранилища данных, исключая их дублирование, и автоматизации повторяющихся задач. Интеграция с ERP-системами, базами данных отдела качества и системами управления мастер-данными обеспечивает точность информации.

Таким образом, выбор инструментов для планирования зависит от потребностей бизнеса: для стратегического планирования применяются BI- и BPM-платформы, для оперативного — CRM-системы, а для гибкой автоматизации подходят low-code/no-code инструменты.

Найти баланс: быстрая замена системы или долгосрочные цели?

Изменение отношения бизнеса к проектам по внедрению CRM и BPM связано с несколькими ключевыми тенденциями. Прежде всего, уход с рынка многих известных зарубежных решений вынуждает компании искать отечественные аналоги и переходить на них. Этот процесс продолжается, что, в свою очередь, стимулирует развитие универсальных платформ. Так, BPM-системы становятся более востребованными, поскольку компании нуждаются в решениях, которые выходят за рамки стандартной функциональности CRM, трансформируясь в ExRM (Extended Relationship Management).

Кроме того, в условиях ухода иностранных вендоров с российского рынка компании сталкиваются с необходимостью оперативной замены критически важных систем. В подобных ситуациях часто приоритет отдается внедрению MVP (Minimum Viable Product, минимально жизнеспособного продукта), чтобы обеспечить работоспособность бизнеса и организовать перенос накопленных данных в новую систему. Конечно, это временное решение, однако оно позволяет избежать остановки бизнес-процессов.

В данной ситуации компании стараются соблюдать баланс между оперативными и долгосрочными целями. Бизнес, как правило, сначала решает текущие проблемы, а уже затем возвращается к вопросам долгосрочного планирования. Компании осознают важность минимизации рисков в будущем, что делает, например, переход на отечественное ПО стратегической задачей, особенно в госсекторе. Использование западных решений в этом контексте сопряжено с высокими рисками и уже не рассматривается.

Также некоторые крупные компании создают уникальные программные продукты «под себя». Это позволяет максимально адаптировать ИТ-решения под свои задачи, но одновременно связано с некоторыми рисками. Ключевые из них — нехватка специалистов, способных поддерживать систему. Поэтому бизнес, имеющий возможность для планомерного импортозамещения систем, предпочитает тщательно подходить к выбору новых продуктов, учитывая их долгосрочную перспективу и возможность интеграции с существующими ИТ-решениями.

В целом можно отметить рост интереса со стороны бизнеса к BPM-системам, которые помогают объединить и автоматизировать бизнес-процессы в рамках единой платформы. Такие системы упрощают работу с данными и снижают риски, связанные с интеграцией при большом количестве систем. Более того, мы видим тенденцию, когда к существующей CRM-платформе добавляют BPM-систему для автоматизации процессов, которые не может закрыть классическая CRM. Это говорит о том, что многие компании делают акцент на стратегическое планирование и выбирают инструменты, позволяющие работать с долгосрочными бизнес-стратегиями.

Программное обеспечение (ПО) для автоматизированных систем поддержки бизнеса активно развивается, начиная с двух последних десятилетий предыдущего века. Первые наработки касались системы автоматизации производственных процессов и бухгалтерского учета (пример – программа 1С), далее реальность потребовала перехода к автоматизации сервиса, продаж товаров и услуг, маркетинговых операций. Затем потребовалось учитывать и автоматизировать задачи перекрестных процессов, охватывающих работу множества подразделений, разветвленной цепи поставок и огромного количества клиентов (для оптимизации работы с клиентской сетью – ПО CRM-система). И, наконец, насущной необходимостью стала автоматизация стратегии управления бизнесом корпоративных компаний, для которой был создан специальный класс ПО — BPM-система.

Что такое CRM- и BPM-системы и области их применения

CRM (Customer Relationship Management) система была разработана для регулирования и управления взаимоотношениями с клиентами. Ее основные задачи — организация контактов, взаимоотношений и сделок с клиентурой, формирование базы контрагентов, создание удобных инструментов обработки информации. Система управления взаимодействия с клиентами (CRM) успешно функционирует в мире со второй половины 95-годов и продолжает развиваться. На Западе почти все крупные корпорации и средние компании применяют CRM-системы, позволяющие в определенной степени влиять на успешность бизнеса предприятия. Однако, выстроить и успешно управлять стратегией бизнеса способен лишь новый класс ПО — BPM-система, разработка и внедрение которой осуществляется с начала 2000-ых.

BPMS (Business Process Management System), как определяется самим названием программного продукта, управляет бизнес-процессами организации через разработку стратегии ее развития, моделирование, внедрение и отслеживание эффективности на примере каждого экземпляра бизнес-процесса. Благодаря включенным программным компонентам система осуществляет одновременное моделирование бизнес процессов, содержит инструменты для формирования и управления бизнес правилами, а также модули для создания ИТ инфраструктуры и встраивания ее в существующий бизнес процесс. Через постоянный мониторинг и выявление слабых мест с помощью этой системы осуществляется совершенствование всех производственных и маркетинговых процессов компании. В целом, BPM-система управляет потоком работ, информацией и взаимодействиями между всеми подразделениями компании и людьми, участвующими в процессах бизнеса.

CRM-система, в исходном варианте предназначена была осуществлять оптимальное взаимодействие с клиентской базой по выстроенным алгоритмам, повышая тем самым качество продаж и сервиса. Все ее дальнейшие модификации и усовершенствования не имеют такого всеобъемлющего влияния на стратегическое управление бизнесом, в отличие от BPM-систем.

BPM-система объединяет в себе преимущества предшествующих информационных систем управления бизнесом, в том числе наработки CRM-системы, и с каждым годом функционал системы расширяется. Фактически, в ней интегрированы и получили дальнейшее развитие три класса корпоративного ПО: система управления документацией, система управления ресурсами и инструментарий для отображения смоделированных бизнес-процессов в графике и таблицах. Схема документооборота в системе BPMтакже может быть представлена в графическом виде, и это позволяет увидеть связь документов с процессами организации. Кроме того, в BPM-системах используется архитектура SOA, удобно и легко интегрирующая модели бизнес-процессов в различные приложения.

Очевидно, что для компаний крупного бизнеса и корпорации в отличие от небольших предприятий управление с помощью CRM явно недостаточно и требуется BPMS.

А в чем собственно различие между системами CRM и BPM?

Есть еще способы, например ленивая загрузка или загрузка по требованию на клиентской части

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

Реализуется ленивая загрузка при помощи AJAX и инициируется событиями, отслеживаемыми при помощи JavaScript. То есть для работы методики необходима поддержка JS браузером, то есть перед тем, как применить ленивую загрузку, стоит знать, что пользователи без JS воспользоваться функцией не смогут, а поисковые роботы скрытый таким образом контент скорее всего не увидят (или увидят отдельные страницы, с которых этот контент браться будет).

Разновидности ленивой загрузки:

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

— Загрузка «при скроллинге» — загрузка следующей партии материалов в тот момент, когда пользователь уже почти ознакомился с изначально загруженным содержанием. Этот способ ленивой загрузки используется в социальных сетях («бесконечные» ленты новостей), но также применим для интернет-магазинов, каталогов и сайтов СМИ. В случае «бесконечных» лент стоит помнить о доступности навигации: нужна либо фиксированная панель меню, либо кнопка «наверх».

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

Все верно Афанасий, чаще всего на стороне браузера кешируются файлы изображений, JS и CSS файлы. Чуть реже имеет смысл кешировать страницы и бинарные файлы (медиа-файлы, PDF, скачиваемые документы и архивы и т.д.).

Статические ресурсы должны иметь хотя бы недельное время жизни кеша, а лучше кешировать их сразу на год. Таким образом, эти ресурсы будут только один раз скачиваться с сервера, а затем браузер будет либо сразу использовать локальную копию (если указан заголовок Expires или Cache-Control), либо после проверки на неизменность (если указан заголовок Last-Modifed или ETag).

Заголовки Expires и Cache-Control: max-age

В качестве значения у этих заголовков используется дата. До тех пор, пока она не настала, браузер будет без каких‑либо дополнительных проверок использовать закешированную версию ресурса. Expires поддерживается чуть шире, чем Cache-Control: max-age, поэтому лучше использовать именно его.

Заголовки Last-Modifed и ETag

В качестве значения заголовка Last-Modifed используется дата, а для заголовка ETag — произвольная строка. Если используются эти заголовки, то браузер, прежде чем использовать закешированный ресурс, получит с сервера текущее значение заголовка и сравнит его с заголовком закешированной версии — если данные совпадут, то будет использоваться локальная версия, а если нет — произойдёт повторная загрузка. Запросы проверки происходят быстрее, чем полная загрузка ресурсов, что даёт прирост производительности сайта при повторном использовании ресурсов.

Оптимальная стратегия клиентского кеширования

Для редко меняющихся файлов стоит поставить Expires на дату, которая наступит через год, а в момент изменения этих ресурсов использовать метод «отпечатков пальцев» (fingerprinting) — добавлять к имени файла небольшую часть хеша, которая фомируется на основе его содержания. Таким образом, вся статика всегда закеширована на клиенте, а при изменении этой самой статики меняются имена файлов и они автоматически перезагружаются браузером.

Собственно техника fingerprinting активно используется для статичных ресурсов (стилей и скриптов) во многих фреймворках (в частности, в Ruby on Rails). А массовую простановку для всех типов статичных файлов заголовка Expires можно реализовать на стороне веб‑сервера (в nginx, например).

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

Быстродействие сайта или веб‑приложения — это комплексная метрика, которая характеризует скорость обработки запроса пользователя от инициации этого запроса до момента предоставления результата. Этот параметр напрямую влияет на пользовательский опыт, конверсию и SEO‑позиции ресурса.

Быстродействие зависит как от производительности серверного оборудования, так и от качества кодовой базы клиентской и серверной частей приложения. Качество бэкенд‑разработки и используемого хостинга определяет скорость обработки запроса пользователя и время до предоставления ответа. Качество фронтенд-разработки определяет скорость загрузки интерфейса и время, необходимое для перехода веб‑интерфейса к готовности для взаимодействия.

Быстродействие бэкенда и хостинга

Основной показатель производительности бэкенда и хостинга — это время генерации страницы: интервал времени, который необходим, чтобы сервер принял запрос, обработал его и сформировал ответ. Ключевой метрикой тут является Time to First Byte (TTFB) — время от запроса до получения первого байта данных.

В плане используемых платформ наиболее высокие показатели демонстрируют сайты, написанные на базе фреймворков, а сайты на базе CMS обычно чуть более медленные. Однако, во многом скорость работы сайта зависит еще и от уровня квалификации разработчика.

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

Для повышения быстродействия на уровне бэкенда и хостинга производится оптимизация программного кода (ускорение и упрощение обработки данных, оптимизация алгоритмов), настройка кеширования («запоминание» результатов вычислений и их многократное использование) и смена серверного оборудования на более производительное.

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

Быстродействие фронтенда

Основные метрики — объём передаваемых данных и среднее требуемое время до возможности взаимодействия с интерфейсом.

На уровне фронтенда определяется необходимый объём данных, который требуется загрузить в браузер, чтобы приложением можно было полноценно пользоваться. Здесь важна целесообразность загрузки ресурсов, их минификация и оптимизация, а также настройка клиентского кеширования. Положительно на скорость загрузки влияет использование современных форматов изображений (WebP, AVIF), декомпозиция приложений с помощью модулей JS и применение tree-shaking для JavaScript-бандлов. Также полезен переход на серверный рендеринг (SSR) для приложений, которые используют клиентский рендеринг (CSR) — SSR + регидрация на клиенте обеспечивает более быструю отрисовку, а также сокращает время до интерактивности (Time To Interactive, TTI).

На время до интерактивности влияет как требуемый объём загрузки ресурсов, описанный выше, так и сложность DOM‑дерева для отрисовки и ресурсоёмкость клиентских подпрограмм на JavaScript. Упрощение процесса отрисовки и оптимизация JS‑скриптов в сочетании с возможностями ленивой загрузки компонентов (или загрузки по требованию) позволяет сократить время, требуемое для готовности клиентской части веб‑приложения к взаимодействию с пользователем.

Рекомендации по быстродействию

Относительно нормальным показателем времени генерации сложной страницы сайта является 0.1-0.5 секунд — это показатель вполне достижим на любой коробочной CMS. Если страницы сайта генерируются более 0.5 секунды, то это может вызывать дискомфорт пользователей и вам стоит рассмотреть варианты оптимизации производительности серверной части.

Если вы только создаёте сайт или новое веб‑приложение, то перед стартом проекта сформулируйте перед разработчиками требования к быстродействию системы — для достижения высоких показателей (генерация страниц менее чем за 0.1 секунды) обычно требуется использовать подходящие платформы и особые подходы к архитектуре приложения.

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

Оптимальное время полной загрузки страницы на сегодняшний день — 2-3 секунды. Для сложных веб‑приложений допустимо ≤ 5 секунд, но только при условии визуальной индикации процесса загрузки. Помните, что воспринимаемое быстродействие — это субъективный показатель: если пользователь получает обратную связь от интерфейса в процессе обновления, то он значительно позитивнее воспринимет даже относительно длительные интервалы загрузки.

Быстродействие — это важно

Воспринимаемая пользователями скорость работы — это всегда сумма скоростей работы бэкенда и фронтенда. Необходимо работать как над повышением скорости генерации страниц, так и над сокращением объёма загружаемых данных и над ускорением отрисовки интерфейса. А работа над UI/UX позволяет улучшить клиентский опыт даже в тех случаях, когда пользователям приходится немного подождать.

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

Первое, что стоит сделать, если скорость работы базы данных не удовлетворяет требованиям, это проверить адекватность настройки СУБД относительно имеющихся ресурсов, а также убедиться, что при проектировании БД были учтены используемые запросы. Если, например, для СУБД работает с настройками «из коробки», а при обработке запросов не используются индексы, то надо не масштабировать СУБД, достаточно просто откорректировать конфигурацию работы сервера баз данных и обновить схему используемой базы данных под профиль нагрузки. Иногда также проще увеличить выделение ресурсов под сервер баз данных — количество оперативной памяти и скорость работы дисковой подсистемы оказывают существенное воздействие на скорость работы СУБД. Нередко даже небольшое увеличение RAM и переход на SSD увеличивает производительность в разы или даже на порядок.

Масштабирование через партиционирование, репликацию и шардинг (SQL и NoSQL)

В момент, когда даже корректно настроенный сервер баз данных на достаточно мощном железе уже недостаточно хорошо справляется с нагрузками, производится масштабирование при помощи партиционирования, репликации и шардинга. Далее рассмотрим эти способы увеличения производительности СУБД.

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

Репликация (replication)

Репликация — это синхронное или асинхронное копирование данных между несколькими серверами. Ведущие серверы часто называют мастерами (master), а ведомые серверы — слэйвами (slaves), иногда используются и другие названия — лидер и фолловеры (leader & followers), праймари и реплики (primary & replicas). Один ведущий узел (мастер, лидер, праймари) принимает запросы как на запись, так и на чтение, а ведомые (реплики, слейвы или фолловеры) синхронизируются с ним и обслуживают только запросы на чтение.

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

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

С практической точки зрения, создание нескольких дополнительных slave‑серверов позволяет снять с основного сервера нагрузку по запросам на чтение и повысить общую производительность системы, а также можно организовать слэйвы под конкретные ресурсоёмкие задачи и таким образом, например, упростить составление серьёзных аналитических отчётов — используемый для этих целей slave может быть нагружен на 100%, но на работу других пользователей приложения это не повлияет. Если нужна максимальная надёжность и сохранность данных при адекватной производительности, то обычно достаточно реализовать синхронную репликацию на 1-2 слэйва при большем их количестве в общем.

Партиционирование (partitioning)

Партиционирование — это разбиение таблиц, содержащих большое количество записей, на логические части по неким выбранным администратором критериям. Партиционирование таблиц делит весь объем операций по обработке данных на несколько независимых и параллельно выполняющихся потоков, что существенно ускоряет работу СУБД. По сути, это разделение таблицы на логические части (партиции) для ускорения запросов и управления большими объемами данных. Партиционировать таблицы можно горизонтально (на уровне строк, например, через разделение на партиции по диапазонам значений) и вертикально (на уровне столбцов, например, через вынесение редко используемых полей в отдельную таблицу). В результате будет ускорение запросов за счет работы с меньшими объемами данных и упрощения управления информацией (в частности, при архивации старых партиций или при разделении данных на «горячие» и «холодные»).

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

Шардинг (sharding)

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

Стратегии шардинга могут отличаться в зависимости от задач. Ключевой шардинг (Key-Based) — данные распределяются по шардам посредством хэш‑функции или через остаток от деления (например, user_id % N). Диапазонный шардинг (Range-Based) — шарды хранят данные из определенных диапазонов (например, пользователи A–M, N–Z). Географический шардинг — данные хранятся ближе к пользователям (шард для РФ, шард для ЕС, шард для США).

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

Использование репликации, шардинга и партиционирования

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

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

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

Стоит помнить, что репликация и шардинг (как вместе, так и по отдельности) превращают систему в распределённую, поэтому при разработке надо учитывать ограничения по теореме CAP: нельзя одновременно гарантировать согласованность данных (C — consistency), доступность (A — availability) и устойчивость к фрагментации (P — partition tolerance). В лучшем случае можно получить только два свойства из трёх перечисленных. В финтехе, например, обычный выбор — C+P, а в системах с менее значимой информацией — A+P.

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

Последняя поговорка о том, что новое масло — это новое масло, верна, и, как и обычное топливо, его становится все труднее найти.

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

Но что именно синтетические данные? Как бизнес может генерировать эти данные, преодолевать трудности и использовать свои преимущества?

Что такое синтетические данные?

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

Синтетические данные искусственно генерируется с помощью алгоритмов или компьютерного моделирования, которые статистически или математически отражают данные реального мира.

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

Тенденции отрасли?

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

В отчете о синтетических данных прогнозируется, что к 2030 году большая часть данных, используемых для модель машинного обучения в целях обучения будут использоваться синтетические данные, полученные с помощью компьютерного моделирования, алгоритмов, статистических моделей и т. д. Однако на синтетические данные в настоящее время приходится менее 1% рыночных данных, однако к 2024 ожидается, что на него будет приходиться более 60% всех генерируемых данных.

Зачем использовать синтетические данные?

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

Но зачем использовать синтетические данные?

Время, необходимое для генерировать синтетические данные намного меньше, чем получение данных из реальных событий или объектов. Компании могут получать синтетические данные и разрабатывать индивидуальные наборы данных для своего проекта быстрее, чем зависимые наборы данных из реального мира. Таким образом, в сжатые сроки компании могут получить аннотированные и помеченные данные о качестве.

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

Дополненные и анонимные данные против синтетических

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

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

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

Типы синтетических данных

Разработчики используют синтетические данные, поскольку это позволяет им использовать высококачественные данные, которые маскируют личную конфиденциальную информацию, сохраняя при этом статистические качества реальных данных. Синтетические данные обычно делятся на три основные категории:

1. Полностью синтетический

Он не содержит информации из исходных данных. Вместо этого компьютерная программа, генерирующая данные, использует определенные параметры из исходных данных, например плотность признаков. Затем, используя такую ​​реальную характеристику, он случайным образом генерирует предполагаемую плотность признаков на основе генеративных методов, что обеспечивает полную конфиденциальность данных за счет их актуальности.
2. Частично синтетический

Он заменяет определенные значения синтетических данных реальными данными. Кроме того, частично синтетические данные заменяют некоторые пробелы, присутствующие в исходных данных, и специалисты по данным используют методологии на основе моделей для создания этих данных.
3. Гибридный

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

Синтетика заменяет крауд-разметку и во множестве кейсов делает это лучше и дешевле. Так что, еще один барьер на пути к AGI теперь снят.

Удивили. Оказывается данных мало. )))) Я думал их столько что за всю жизнь не прочитать.

Современные технологии искусственного интеллекта (ИИ) нуждаются в огромных объемах данных для тренировки, и эти данные стали “новой нефтью” цифрового мира. Согласно прогнозам исследовательской группы Epoch AI, к 2032 году разработчики могут столкнуться с нехваткой данных для обучения новых генеративных моделей ИИ. В условиях дефицита появляется альтернатива — синтетические данные, и к 2030 году их рынок может достигнуть $2,34 млрд.

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

Основное назначение синтетических данных — восполнить недостаток реальных данных, особенно в случаях, когда их сбор осложнен из-за вопросов конфиденциальности, высокой стоимости или соображений безопасности. Например, в таких сферах, как:

• Беспилотные автомобили: чтобы обучить ИИ, отвечающий за автономное вождение, необходимо множество сценариев дорожного движения. В реальной жизни собрать такой объем данных сложно, а вот синтетические данные могут смоделировать нужные ситуации.

• Финансовая аналитика: создание моделей ИИ, анализирующих и предсказывающих изменения в финансах, требует больших массивов данных, которые зачастую защищены законодательством или коммерческой тайной.

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

Кроме того, синтетические данные могут помочь снизить предвзятость, часто присутствующую в реальных датасетах, что улучшает качество и объективность моделей ИИ. Они создаются по запросу, быстро и практически без ограничений по объему, обеспечивая нужное разнообразие для более точной работы ИИ.
Кто использует синтетические данные?

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

• Meta: новая языковая модель Llama 3.1 использует синтетические данные для решения задач, связанных с программированием и математикой.

• Toyota и Waymo: используют синтетические данные для тренировки и тестирования своих моделей в области автономного вождения.

• Amazon: применяет синтетические данные в анализе и разработке своих продуктов.

• Microsoft и Google: малые языковые модели, такие как Phi (Microsoft) и Gemma (Google), частично обучены на синтетических данных, что позволяет этим ИИ-системам решать широкий спектр задач.

• Nvidia: недавно выпустила модель Nemotron-4 340B Instruct, которая генерирует синтетические данные, имитируя реальные характеристики, что делает ее универсальной для различных исследований и задач.
Риски и вызовы использования синтетических данных

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

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

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

Давайте разберем организацию доставки на собственном маркетплейсе более серьезно и детально

1. Складская логистика:
— Централизованный склад: Все товары хранятся в одном месте. Этот способ удобен для контроля запаса, но может увеличивать время доставки, особенно если заказ оформлен в удалённом регионе.
— Региональные склады: Распределение товаров по нескольким складам в разных регионах может значительно сократить время доставки и снизить транспортные расходы.

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

3. Системы управления заказами (OMS):
— Внедрение системы, которая позволяет отслеживать статусы заказов, управлять инвентарем и интегрироваться с курьерскими службами. Это улучшит клиентский опыт и упростит отчетность.

4. Расчет стоимости и сроков доставки:
— Установите адекватные цены на доставку, основываясь на характеристиках региона, весе и размере товаров. Также важно заранее сообщать клиентам сроки доставки, чтобы избежать недовольства.

5. Разнообразие вариантов доставки:
— Предложите своим клиентам разные способы доставки, такие как экспресс-доставка, стандартная доставка и самовывоз. Это даст возможность выбрать наиболее удобный и экономичный вариант.

6. Интеграция с платформой:
— Убедитесь, что система логистики интегрирована с вашими процессами на маркетплейсе. Удобный интерфейс и четкость в отображении всех этапов заказа просто необходимы.

7. Анализ и оптимизация процессов:
— Регулярно анализируйте показатели по доставке, чтобы выявлять проблемы и оптимизировать процессы. Это включает в себя изучение статистики времени доставки, возвратов и отзывов клиентов.

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

Выбор между монолитом и микросервисами — это не просто техническое решение. Это стратегическое решение, которое влияет на всю жизнь проекта. Нет универсального ответа. Лучший подход зависит от конкретных требований проекта, размера команды и доступных ресурсов. Однако, понимание преимуществ и недостатков каждой архитектуры — ключ к принятию правильного решения.

Глубокое погружение: Тестирование монолитных приложений

Преимущества:
— Простота начального этапа: На ранних стадиях разработки монолита тестирование относительно простое. Все находится в одном месте, упрощая отладку и интеграционное тестирование.
— Быстрое сквозное тестирование: Поскольку весь код находится в одном месте, сквозное тестирование (end-to-end testing) может быть выполнено относительно быстро.

Недостатки:
— Сложность с ростом проекта: По мере роста приложения, тестирование становится все более сложным и трудоемким. Изменение одной части кода может привести к неожиданным последствиям в других частях.
— Замедление процесса разработки: Длительное тестирование может существенно замедлить процесс разработки.
— Зависимости и конфликты: Тесное взаимодействие компонентов приводит к множеству зависимостей и потенциальных конфликтов, затрудняющих тестирование и отладку.
— Трудоемкая рефакторинг: Изменение архитектуры или отдельных модулей в большом монолите может потребовать огромных усилий и времени.
— Проблемы с масштабированием: Масштабирование монолита — это масштабирование всего приложения целиком, что может быть неэффективным и дорогим.
Тестирование микросервисной архитектуры

Преимущества:
— Изолированное тестирование: Каждый микросервис может быть протестирован независимо от других. Это ускоряет процесс и упрощает поиск ошибок.
— Параллельное тестирование: Возможность параллельного тестирования значительно ускоряет весь процесс.
— Гибкость и масштабируемость: Можно масштабировать только те сервисы, которые нуждаются в дополнительных ресурсах.
— Более быстрая обратная связь: Быстрое тестирование и развертывание позволяют получать более быструю обратную связь от пользователей.

Недостатки:
— Сложность интеграционного тестирования: Необходимо тщательно тестировать взаимодействие между микросервисами. Это требует дополнительных усилий и инструментов.
— Увеличение сложности инфраструктуры: Микросервисная архитектура требует более сложной инфраструктуры и инструментов для оркестрации, мониторинга и управления.
— Повышенные требования к квалификации: Разработка и тестирование микросервисов требуют от разработчиков более высокой квалификации и опыта.
— Увеличение числа точек отказа: Большее количество сервисов увеличивает потенциальное число точек отказа.
Когда монолит, а когда микросервисы?

Выбор архитектуры зависит от конкретных требований проекта.

Монолит подходит для:
— Простых проектов: Когда функциональность ограничена и масштабируемость не является критическим фактором.
— Быстрой разработки прототипов: Когда нужно быстро создать минимально жизнеспособный продукт (MVP).
— Небольших команд: Когда команда небольшая и обладает ограниченными ресурсами.

Микросервисы подходят для:
— Больших и сложных проектов: Когда функциональность обширна и требуется высокая гибкость и масштабируемость.
— Проектов с высокой частотой изменений: Когда необходимо часто обновлять и развертывать новые функции.
— Больших команд: Когда команда большая и разделена на независимые группы.
Разница в деталях: Монолит vs. Микросервисы

Ключевое отличие — связность. Монолит — это единый блок кода. Микросервисы — это набор независимых, слабо связанных модулей. Это влияет на все аспекты, от разработки до тестирования и развертывания. Изменение в монолите может затронуть всю систему. В микросервисах изменения локализованы.