Как работать с платформой

Чем платформы могут быть полезны вашему продукту

Chief Product Officer маркетплейса «Беру» Алексей Журба на конференции ProductSense рассказал, почему платформы стали популярны и как извлечь из них пользу для своего продукта.

Уже более десяти лет я занимаюсь тем, что строю платформы. Сначала в IBM в области информационной безопасности, потом в Wargaming — для дистрибуции и оперирования MMO-играми, а теперь в маркетплейсе «Беру» компании «Яндекс.Маркет». На базе этого опыта и аккумулированных знаний я расскажу, как получить практическую пользу от платформ, даже если вы сами их не строите.

Три причины подумать о платформах:

1. Платформа — это модная социально-экономическая концепция, которая трансформирует разный бизнес вокруг нас. Лучше знать, как это работает.

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

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

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

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

Отличные примеры платформ — «Яндекс.Такси» и Uber, которые за счёт распространения интернета и мобильных телефонов заменили диспетчерские службы и за короткое время выросли так, как не смогли бы традиционные таксопарки.

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

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

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

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

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

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

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

Помните, что платформа — это коммуникация между участниками сети. Обмен информацией всегда должен происходить на платформе, а вот обмен товарами, услугами и валютами может происходить и вне её. Всё вместе это составляет ключевую транзакцию (core transaction) платформы.

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

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

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

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

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

Теперь поговорим о том, как извлечь из этого пользу.

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

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

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

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

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

В простейшем виде анализ возможностей сводится к нескольким вопросам:

• Какие группы пользователей уже есть у моего продукта или бизнеса? Кто они — supply или demand?
• Какие ещё группы можно добавить или привлечь?
• Чем они могут обмениваться с помощью моего продукта?
• Где в таком обмене возникает ценность?

Допустим, ваш продукт нельзя превратить в платформу. Но вы всё равно можете извлечь пользу: попробуйте придумать, чем ваш продукт или бизнес способен помочь окружающим платформам.

Вот несколько возможностей с реальными примерами.

Побудьте курицей или яйцом.

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

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

Помогите платформе привлечь или удержать аудиторию.

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

Например, Netflix или HBO стараются заполучить эксклюзивные сериалы, чтобы удержать текущую аудиторию и привлечь новую. Интересно, сколько человек не продлили подписку у HBO после окончания «Игры престолов»?

Помогите платформе оптимизировать ключевую транзакцию.

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

Встройтесь в ключевую транзакцию платформы.

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

Вспомните PayPal, который когда-то стал основным способом оплаты сделок между пользователями Ebay.

Создайте дополнительную ценность для участников платформы.

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

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

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

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

Что такое платформенный бизнес? Создание платформы маркетплейса

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

Революция платформ

Платформы-гиганты знают все: Google, Uber, Facebook, AirBnb. Эти компании не создают контент, не имеют своего громадного автопарка, не владеют сетями отелей по всему миру. Но почему-то они лидеры на этих рынках.

Google и Facebook — лучшие рекламные площадки, хотя у них нет своих площадей на билбордах и нет своего ТВ канала.

Uber может держать цены на такси максимально низкими и обслуживать людей по всей планете.

AirBnb имеет самый большой выбор для аренды жилья, при этом не имея ни одного отеля в своей собственности.

Что же такое происходит? Почему какие-то выскочки заняли рынок, не имея крупных ресурсов в виде недвижимости, оборудования или людских ресурсов?

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

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

Есть прекрасная книга Чаудари, Альстайн, Паркер Революция платформ, которая позволит вам глубже вникнуть в понятие Платформа и ее преимущества и отличие от классического бизнеса.

Платформенный бизнес

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

AirBnb организует взаимодействие владельцев недвижимости с теми, кто хочет арендовать дом, квартиру или комнату.

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

Основная ценность Facebook — в создаваемом контенте и взаимодействии с другими пользователями. Но Facebook не создает сам контент, контент создают пользователи. Люди приходят за контентом в социальную сеть, а это привлекает рекламодателей.

Классический бизнес работает по-другому. Он сам создает ценность в своем конвейере и продает ее клиентам. Компания Toyota сама создает машины и сбывает их через сеть дилеров. Объем выручки для Toyota напрямую зависит от количества произведенных машин.

В случае с Uber и другими бизнес-платформами, количество написанного кода не имеет прямой корреляции с выручкой от сайта-платформы.

Что такое платформа

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

Каждая группа пользователей приходит на площадку с определенной целью.

Посетители AirBnb хотят найти подходящее жилье под свои условия.

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

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

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

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

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

Откуда взялись бизнес-платформы?

Платформенный бизнес существует давно.

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

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

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

При этом государство собирает со своих граждан налоги. Эти налоги идут на жизнедеятельность государства.

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

Почему именно сейчас начали активно расти бизнес-платформы?

Все дело в технологическом сдвиге и развитии сети Интернет. Крупные технологические инновации порождают целый веер инноваций в других областях.

Возьмем Google как поисковую систему. Google дает бесплатный доступ к большому количеству информации.

Google не владеет этой информацией. Он — просто диспетчер, который направляет вас на нужный сайт.

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

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

Через интернет все больше людей могут получить доступ к Google поиску, где они могут найти что угодно.

Причем это не только США, но и весь мир. Мог ли Google 16 века добиться такого? Нет, только сейчас технологии позволили обращаться к сервису компании одновременно из множества точек планеты.

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

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

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

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

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

Что дает платформа

Каждый участник платформы получает ту ценность, за которой он пришел на площадку

Потребитель обычно получает много всего, что он не может получить от обычной конвейерной компании:

• большой выбор среди поставщиков на площадке. Широкий выбор ассортимента дает возможность выбрать более привлекательные условия.
• множество инструментов поиска. Различные фильтры, подборки и т.д.
• снижение рисков за счет работы площадки в плане проверки репутации поставщиков. Площадке выгодно, чтобы на ней работали только надежные поставщики. Любой негатив из-за поставщика также сказывается и на платформе.
• бесплатные элементы для потребителя — за счет того, что площадка зарабатывает на других сервисах. Google бесплатно ищет информацию. Facebook бесплатно дает возможность общаться. AliExpress дает возможность бесплатно быстро подобрать нужный товар у проверенного поставщика без необходимости куда-то ехать.

Что получает бизнес от платформы

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

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

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

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

Сама платформа получает множество преимуществ перед конкурентами классического типа:

• Низкие издержки на ресурсы для оказания услуг.
• AirBnb не нужно покупать отели, не нужно вкладываться в ремонт. Они просто приглашают владельцев недвижимости на свою площадку.
• Расширение площадки практически ничего не стоит для самой площадки.

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

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

Возможность быстрого роста

Платформенный бизнес может быстро расти — затраты роста относительно невысоки. При этом есть большие возможности по экспериментированию — менять интерфейс сайта проще, нежели переделывать здание. Цифровой мир — более податливый материал, нежели реальный.

При этом любое действие на площадке оставляет след, который можно анализировать. Это позволяет делать и проверять много гипотез роста.

Диверсификация рисков

Есть множество продавцов на площадке с разных сегментов. Если кто-то из них прогорит, на площадке это никак не скажется. Более того, можно проанализировать его результаты и сделать выводы. Стабильность площадки зависит от стабильности всего рынка.

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

Возможность изучать информацию по взаимодействию участников рынка и принимать решения по оптимизации этих взаимодействий

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

Возможность давать более полный сервис потребителю

Площадке проще построить целую линейку сервисов для покупателя, которая будет закрывать спектр потребностей.

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

Бизнес-модель платформа

Монетизация платформенного бизнеса зависит от участников рынка.

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

Участники платформы приходят на сайт за ценностью. Для одних — это прямая ценность в виде контента, информации. Для других — ценность в наличии других участников (клиентов).

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

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

Если ваша комиссия для аудитории А негативно влияет на ценность, предоставляемую для аудитории Б — это неправильно. Так в итоге все разбегутся с площадки. Например, если бы с пользователей Facebook брали денег за контент, то рекламодателей на Facebook было бы немного.

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

Ищите такую монетизацию, которая не будет убивать основную ценность для участников площадки.

На чем может зарабатывать платформа?

Давайте рассмотрим варианты монетизации площадки:

Реклама

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

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

Платный доступ

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

Данная модель также может включать в себя вариант платного и бесплатного аккаунта. Бесплатный аккаунт имеет ограничения. Платный аккаунт имеет некоторые привилегии.

Пример — fl.ru. Исполнитель может быть на бесплатном аккаунте, но для него тогда будут действовать жесткие ограничения. Либо он может заплатить за аккаунт PRO и полноценно использовать площадку.

Дополнительные сервисные функции платформы. Это похоже на платный аккаунт, но оплата берется не периодически, а за разовую услугу или возможность на сайте. Пример — единоразовое поднятие своего объявления в поиске на Avito.

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

Комиссия со сделок

Если деньги проходят через площадку, то можно брать некий процент с каждой сделки. Комиссию платит либо Исполнитель, либо Заказчик, либо делят ее между собой.

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

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

Как создать торговую площадку

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

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

Первые вопросы, которые вы должны себе задать при создании бизнес-платформы:

1. Какой рынок будет обслуживать платформа?

Для какого рынка вы работаете? Достаточно ли он велик, чтобы на нем можно было заработать? Если это рынок парикмахерских в провинциальном городе, то возможно проект не взлетит по причине малого масштаба.

Достаточно ли рынок узкий? Если рынок будет слишком широк (бытовая техника), то вы будете конкурировать с крупными брендами, которые имеют свои магазины, а также с крупными маркетплейсами (Яндекс Маркет, Windberries).

1. Участники платформы. Кто мои потребители и партнеры?

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

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

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

1. Создание ценности для участников платформы. В чем ценность для каждого участника?

Это самый главный пункт. Без ценности участнику нет смысла работать на платформе.

Необходимо проверить свои гипотезы относительно ценности: сформулировать предложение, найти представителей целевой аудитории и получить обратную связь по предложению. Цепляет ли их это предложение? Готовы ли они подписаться на ранней стадии?

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

Это совершенно не техническая работа. Это задача владельца продукта — сформулировать ценность для всех участников проекта.

1. С какого минимального решения мы можем начать?

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

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

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

1. Какой будет план развития площадки?

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

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

Именно перебор идей в итоге может дать нужное сочетание, которое будет привлекать людей на площадку.

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

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

Возможные стратегии начала работы платформы

Для площадки остро стоит вопрос курицы и яйца. Покупателям нужен большой выбор поставщиков на площадке. А как привлечь поставщиков, если нет покупателей на площадке?

Есть следующие варианты:

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

Исполнители никак не представлены на площадке. Вы берете некий процент от сделки. Ваша работа заключается в привлечении трафика и координации работы по заказам.

По мере успешного выполнения заказов, вы постепенно автоматизируете работу исполнителей:

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

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

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

1. От CRM к платформе. Создание площадки персонала

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

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

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

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

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

Не начинайте сразу с большого географического региона или широкой отрасли. Пробуйте на малом объеме.

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

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

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

Техническая часть платформы — разработка марткетплейса

Мы — разработчики веб-платформы Falcon Space.

У нас есть несколько готовых решений для создания платформы:

Каждое решение можно развивать и видоизменять. Это обязательная опция для любой развивающейся платформы.

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

Узкие моменты на старте создания платформенного бизнеса

В чем добавленная ценность (и УТП для партнеров)?

Если нет ценности, то все остальное не даст результата.

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

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

Первичный состав лояльных поставщиков и покупателей

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

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

Откуда брать трафик

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

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

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

Изучайте основы продвижения и требуйте прозрачный план действий от подрядчиков по продвижению.

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

За что брать деньги с участников системы?

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

Здесь важно найти такое решение, которое и ДЕЙСТВИТЕЛЬНО устроит и подходит вашим партнерам. Не нужно нажимать или уговаривать. Это только повредит дальнейшей конверсии.

Главная задача — выяснить за что готов платить потребитель и на каких условиях.

Какое техническое решение выбрать — готовое или разработанное под себя?

Если вам хватает функций готового решения, то берите готовое решение. Это быстрее, дешевле, надежнее и функциональнее, нежели долгая заказная разработка.

Но есть одно важное условие — решение можно развивать и видоизменять. Без возможности кастомизации, площадка долго не проживет.

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

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

Сколько нужно специалистов для проекта?

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

Чем больше вы тратите в проекте, тем меньше этот отрезок. Если вы тратите мало, то у вас меньше рисков закрыться по причине нехватки средств.

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

В проекте веб-разработки мы пришли к тому, что идеальное число разработчиков на проекте — 2:

• Минимальное количество взаимодействий на проекте (время на разговоры — тоже деньги).
• Платформа и готовые решения позволяют нам создавать функционал быстрее, чем заказчик проработает задачи со своей стороны.
• Один человек может заболеть или уволиться. В этом случае технические знания проекта могут быть частично утеряны (документация — это хорошо, но не решает всех вопросов).
• Дизайн, продвижение, тексты мы не делаем. Мы фокусируемся только на технической части.
• Все люди на проекте одинаково понимают бизнес-логику, и не нужно распространять знания по большой команде.
• Нет размытия ответственности. В большом проекте ответственность размазывается где-то между участниками из-за сложностей взаимодействия. Формально виноват один человек, но на деле у него всегда есть серьезная причина, по которой он не смог выполнить свою задачу. Знакомо?

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

Первые шаги по созданию бизнес-платформы

1. Определить потребителей и ценность для каждой группы потребителей. Создание простой презентации для каждого сегмента целевой аудитории.
2. Получить обратную связь. Улучшить предложение, сгенерировать новые идеи по ценности и добиться положительного отклика по своему предложению.
3. Определить MVP — минимальное решение, которое должно быть запущено в эксплуатацию. Это первая версия платформы. Определите какие кабинеты будут в системе, страницы кабинетов и возможности для пользователей, какие интеграции потребуются. Другими словами, создайте концепцию проекта. Здесь вы можете найти шаблон концепции проекта.
4. Реализуйте свое решение минимальными средствами. Запустите как можно скорее для получения обратной связи от потребителей.
5. Работайте с трафиком — пишите статьи, делайте видеообзоры, вкладывайтесь в рекламу, организуйте PR акции и т.д.
6. Корректируйте свой план развития. У вас появится новая информация по ходу становления вашей платформы. Адаптируйтесь под изменяющиеся реалии. Шлифуйте свою площадку, собирайте обратную связь, пробуйте внедрять различные гипотезы.

Заключение

Хотелось бы предостеречь людей, которые захотят попытать счастья в этой золотой лихорадке под названием «маркетплейс».

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

Есть множество обращений к нам с идеей сделать маркетплейс, при этом люди с трудом понимают, что такое сайт, как он работает и откуда брать трафик (а что такое трафик?).

Своей целью общения с такими людьми считаю отговорить их от идеи создания маркетплейса. Они просто потеряют деньги. Сначала на создании движка. Затем на продвижении (SEO, реклама). Как кончится бюджет, они просто по-тихому свернут проект.

Ключевые ошибки этих людей:

• полное незнание элементов сайтостроения и продвижения;
• нет никакой ценности от площадки для участников платформы;
• есть стойкое убеждение, что они придумали нечто уникальное. Сейчас сделаем, откроем сайт — и как попрут!

Делайте проект только с полным пониманием каждого шага. Если у вас есть где-то белые пятна — прорабатывайте их, ищите материал, задавайте правильные вопросы.

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

Революция платформ уже произошла. Осталось выяснить только один вопрос — вы пользователь платформ или создатель одной из них?

Интернет-платформа: суть, задачи, виды

Что это такое? Интернет-платформа – это инструмент для создания сайтов. CMS, фреймворки, SaaS-решения – все это может быть применено для разработки веб-ресурса, но эти методы нельзя назвать универсальными

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

Суть и виды интернет-платформ

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

Суть и виды интернет-платформ

Фреймворки

Это каркасы, призванные упростить и ускорить создание ресурсов. Если сравнить разработку сайта с возведением здания, роль фундамента и несущих стен отводится фреймворку. Именно он определяет тип будущей постройки – садовый домик или небоскреб.

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

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

У систем управления контентом есть несколько неоспоримых преимуществ:

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

Недостатки, встречающиеся при работе с CMS:

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

SaaS – платформа для сайта

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

Суть технологии понятна из расшифровки аббревиатуры: Software as a Service, то есть программное обеспечение как услуга. Клиентам за арендную плату предоставляется доступ к готовым решениям, при помощи которых они создают собственные веб-ресурсы.

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

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

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

Выбирая SaaS, придется смириться с некоторыми минусами:

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

Требования к интернет-платформе

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

Требования к интернет-платформе

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

В качестве основы для формулирования перечня функций предлагаем следующий список:

• Продуманная структура.
• Поиск по сайту.
• Заказ обратного звонка.
• Личный кабинет пользователя с историей его заказов.
• Корзина.
• Оформления возврата товаров через сайт.
• Программа лояльности с начислением бонусов.
• Интеграция с 1С.
• Интеграция с CRMи автоматическое прохождение заказа.
• Мобильная версия.
• Форма для заказа каталога на вложенных страницах интернет-магазина.
• Виш-лист (раздел для сохранения понравившихся товаров).
• Деление по категориям.
• Форма «C этим товаром покупают».

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

Требования к интернет-платформе

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

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

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

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

Скачивайте и используйте уже сегодня:

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ ресурсов об IT-сфере

Только лучшие телеграм-каналы, каналы Youtube, подкасты, форумы и многое другое для того, чтобы узнавать новое про IT

ТОП 50+ сервисов и приложений от Geekbrains

Безопасные и надежные программы для работы в наши дни

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

Выбор между тремя основными интернет-платформами

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

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

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

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

Топ-3 CMS для сайтов

WordPress

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

• Может служить основой для запуска сайтов всех типов, в том числе визитки, портфолио, новостного портала, платформой для интернет-магазина или блога.
• Веб-мастеру доступно множество уроков и рекомендаций по настройке системы, выбору плагинов и шаблонов, поскольку WordPress используется многими разработчиками во всем мире.
• Специальные модули предназначены для отслеживания статистики, а также есть возможность успешной SEO-оптимизации сайта.

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

• Для реализации масштабных проектов не предназначен. Созданные на базе WPинтернет-магазин с количеством товаров более 10 тыс. единиц или корпоративный сайт компании, где более 1 тыс. сотрудников, со временем начнут притормаживать.
• Широкий выбор плагинов имеет негативную сторону в виде излишней нагрузки на систему.
• Наличие слабых мест в расширениях влечет низкий уровень безопасности.
• Несовместимость отдельных плагинов между собой становится причиной сбоев в работе WP.
• Иногда не обойтись без помощи профессионала, поскольку работа поддержки оставляет желать лучшего, а искать правильное решение самостоятельно долго и неэффективно.

1С-Битрикс

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

Ежегодная плата за право пользования 1С-Битрикс варьируется в зависимости от масштаба бизнеса. Если предполагается создание небольшого сайта, цена стартует с 5 400 рублей. Владельцы предприятий в среднем сегменте заплатят не менее 35 900 рублей, крупные компании – от 72 900 рублей. Разработка версии платформы с учетом индивидуальных запросов заказчика обойдется минимум в 90 000 рублей. Через год лицензия продлевается.

• Рассчитана на масштабные проекты, где востребовано большинство функций этой CMS.
• Поддерживает большое количество интеграций, с продуктами 1C совместима идеально.
• Реализована функция ведения статистики и отслеживания заказов, необходимая интернет-магазинам.

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

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

Joomla!

Для использования этой бесплатной CMS с большим количеством шаблонов и расширений понадобится владение азами программирования и верстки, а именно, знание HTML и CSS.

Некоторые хостинги предлагают установить Joomla! автоматически, вам остается только выбрать тариф и зарегистрировать домен. За дополнительные плагины и шаблоны придется заплатить.

• На базе Joomla! без проблем создается веб-ресурс любого типа, будь то корпоративный сайт, онлайн-магазин или блог.
• Благодаря открытому исходному коду можно увеличивать функционал.
• Исчерпывающие инструкции по работе с CMS размещены на официальном сайте. Еще больше информации легко найти на специализированных форумах, например, на GitHub.
• Платить за использование Joomla! не надо, встроенного функционала достаточно для создания любого сайта.

• Удобное многоуровневое меню, благодаря которому разработка веб-ресурса доступна новичкам.
• Большое количество функций в базовой версии.
• Предусмотрены инструменты для SEO-продвижения.
• Текстовый и графический редактор с готовыми блоками.
• Поиск с фильтрами, позволяющий легко найти нужные материалы.

• Для быстрой работы Joomla! придется следить, чтобы в системе использовались свежие плагины.
• При загрузке расширений со сторонних сайтов безопасность CMS и ваших данных находится под угрозой.
• Если не устраивают однотипные стандартные шаблоны дизайна, придется разработать собственный код или купить подходящий для своего сайта.

Популярные фреймворки для создания сайтов

Django

Веб-приложения и сложные сайты можно разрабатывать на базе этого бесплатного каркаса, написанного на Python и использующего шаблон проектирования MVC-MVT. В основу фреймворка положен принцип DRY (don’t repeat yourself), то есть один и тот же код не придется переписывать раз за разом. Изначально Django создавался для создания новостных порталов, этим объясняется такая особенность его архитектуры, как наличие средств, способствующих быстрой разработке информационных сайтов.

Популярные фреймворки для создания сайтов

• Большое количество библиотек.
• Простое масштабирование сайта благодаря модульной структуре.
• Готовые решения для безопасности ресурса, в том числе система аутентификации и защита от подмены заголовка хоста.
• Встроенная панель управления сайтом – разработчику не придется писать свою админку.

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

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

Flask

Для создания веб-приложений предназначен еще один фреймворк, написанный на Python. Это микроплатформа, поскольку набор базовых функций ограничен. Для добавления нужных придется вручную устанавливать соответствующие расширения. Работа Flask основана на использовании внешней библиотеки WSGI, а также шаблонизатора Jinja2.

Достоинства этой интернет-платформы:

• Масштабируемость, благодаря которой проект можно развивать во всех направлениях.
• Гибкость, то есть способность изменять приложение без негативных последствий.
• Совместимость с Google App Engine и с WSGI 1.0.
• Простота использования, независимость от большого количества расширений.
• Интегрированная поддержка модульного тестирования.
• Подробная документация на официальном сайте.

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

Ruby on Rails

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

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

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

Ruby on Rails нередко используется для проверки бизнес-моделей, когда нужно быстро представить продукт и убедиться в его востребованности. Первая версия приложения, созданная на этом фреймворке, может быть запущена уже через 2–3 месяца.

Лучшие SaaS решения для создания сайтов

InSales

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

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

Лучшие SaaS решения для создания сайтов

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

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

NYiGDE?

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

Маркетплейс с целью отстройки от конкурентов сделал ставку на три бесплатные действия:

• Регистрация.
• Создание сайта.
• Бессрочное использование функционала и обслуживание.

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

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

Для разработки своего ресурса можно выбрать подходящий шаблон из 500, входящих в библиотеку платформы. На ознакомление с возможностями uKit дается 14 дней, дальнейшее использование – после оплаты. Эксперты называют этот конструктор палочкой-выручалочкой для владельцев малого и среднего бизнеса, подчеркивая его эффективность и простоту использования.

Более 100 миллионов пользователей по всему миру – убедительный довод в пользу выбора этого конструктора для создания собственного сайта. Дизайнеры этого проекта не зря получают зарплату: Wix заслуженно считается лучшей платформой с точки зрения качества оформления страниц будущего ресурса.

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

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

Запущенный еще в 2005 году, этот российский конструктор сайтов хорошо известен и на родине, и за ее пределами. Функционал платформы превосходит многие CMS, однако разработчик постоянно предлагает обновления и внедряет дополнительные возможности.

Одна платформа, чтобы править всеми

Привет! Меня зовут Миша, я работаю в Ozon Tech — руковожу направлением базовых сервисов в платформе. Ozon сегодня — это порядка 4000 разработчиков и более 3500 сервисов. Разработка постоянно развивается, количество сервисов увеличивается, и одна из сложных задач — это найти удобный для всех способ управлять тем, что происходит под капотом.

Для этого мы сделали платформу: это внутренние стандарты, сервисы, процессы, инфраструктура для разработки. Можно сказать, что это такой «сервис для продуктовых разработчиков», который предоставляет удобные инструменты во все команды, обеспечивает единообразие подходов в разных командах, помогает внедрять изменения и новые технологии. Для нас платформа теперь — основа для разработки, на ней строятся все информационные системы, и сложно представить Ozon без неё.

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

История: зачем нужна и как появилась платформа

В 2018 году один мой друг и коллега хотел переходить в Ozon. Я его очень сильно отговаривал, говорил: «Серьёзно? Женя, вот это вот всё тебе надо? Вот эта Windows, этот .NET. Ты будешь что-то переписывать. Зачем?». На тот момент в компании было меньше 100 инженеров, на серверах стояла Windows, были огромные монолиты MS SQL Server с тысячами хранимых процедур и десктопные приложения на Delphi.

В это время в компании происходили большие и важные изменения после смены топ-менеджмента. И вот спустя четыре года мы с Женей вместе работаем в Ozon и продолжаем строить большую и классную компанию. Ozon образца 2022 года — это огромный маркетплейс, на котором продают и покупают всё, что душе угодно. Мы выросли почти в 40 раз. У нас несколько дата-центров и тысячи серверов, а наша система из нескольких больших монолитов превратилась в огромную распределённую систему, которая состоит из нескольких тысяч сервисов, обрабатывающих порядка 3 млн запросов в секунду. Больше никакого Delphi — только современные технологии.

Несколько лет назад мы столкнулись с трудностями: из-за масштабов и сложности разработки продуктовые команды зачастую вынуждены были тратить время на решение технических и инфраструктурных задач. Это увеличивало time to market, негативно влияло на мотивацию и усложняло коммуникацию.

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

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

Платформа помогает уменьшать time to market, с ней разработка происходит быстрее и удобнее, а бизнес продолжает эффективно развиваться.

Как устроена платформа: архитектура

Нашу платформу можно представить в виде нескольких слоёв.

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

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

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

Следующий слой — слой библиотек и фреймворков, на основе которых строятся все приложения.

И на самом верху находятся все микросервисы и все компоненты, которые мы строим.

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

Конвенции и стандарты

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

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

Четыре года назад у нас появился один из основных документов, приближающих нас к этому балансу. Он называется «Конвенция по микросервисам». Между собой мы шутим, что это в некотором роде конституция разработчика Ozon. Этот документ описывает то, как нужно писать сервисы, версионировать API в них, как они должны конфигурироваться, используя различные параметры, и взаимодействовать.

Мы используем gRPC для реализации взаимодействия между сервисами. Для внешних пользователей все сервисы предоставляют HTTP интерфейс, некоторые также используют GraphQL. И вся информация о том, что можно использовать в каком случае, содержится в этом документе.

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

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

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

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

Как платформа помогает создавать сервисы

Мы используем пять языков, на которых пишем бэкенд. В основном это Go, C# и Java — на них пишем сервисы, которые обрабатывают пользовательские запросы. JS и Python тоже есть, они используются в некоторых нишевых проектах. Но глобально весь бэкенд Ozon написан на первых трёх языках.

Для Go, C# и Java у нас есть языковая платформа. Это генератор сервисов, при запуске которого вы можете скормить ему proto-файл, а на выходе получить правильную структуру проекта, все нужные системные файлы, настройки для Kubernetes, GitLab, ещё ряда наших внутренних компонентов. Мы используем gRPC, соответственно, любой сервис имеет описание в формате proto.

Результат работы генератора — базовая реализация имплементации всех методов. У нас полностью сгенерирован весь RPC-слой. Есть gRPC и есть gRPC-Gateway, чтобы предоставлять HTTP-слой. В случаях с Go и .NET они встроены непосредственно в бинарник. В случае с Java мы умеем генерировать сайдкар рядом. Есть Swagger для документации. Есть кастомизация — можно настраивать rate limit и circuit breaker по разным умным правилам. И есть телеметрия на все случаи жизни. То есть, любое взаимодействие сервиса со всем остальным миром покрыто сотнями метрик.

Ещё есть поддержка онлайн-конфигурации. Это очень классная штука. Использовать Twelve-Factor App и конфигурировать всё через переменные не очень удобно, на наш взгляд, потому что конфигурация в этом случае получается статической. А некоторые вещи (даже какие-то системные настройки) мы хотим иметь возможность модифицировать онлайн.

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

В итоге этот манифест с помощью простой утилиты загружается в etcd Vault, если нужно хранить секреты. Сервис подписывается на etcd и получает информацию о том, что какой-то параметр изменился, — и разработчик может написать очень простой колбэк и что-то сделать внутри своего приложения. А для управления всем этим мы генерируем автоматически веб-интерфейс, в котором есть все параметры. Здесь на скриншоте приведён пример одного из сервисов на Go. Есть параметры, которые относятся непосредственно к рантайму: настройки сборщика мусора, настройки gRPC-сервера и т. д.

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

Как платформа помогает налаживать взаимодействие между сервисами

Сервисы не живут в вакууме — они должны взаимодействовать. Для этого нам нужно понимать, какие методы есть у каждого сервиса, как взаимодействовать с ним. Нам нужны клиенты к сервисам. Да, мы используем gRPC, и клиенты легко генерируются. Но вот проблема: у нас 3000 сервисов, 3000 контрактов — где их хранить, какой сервис и каким образом должен генерировать клиенты?

Три-четыре года назад, когда мы начинали работать над этим, всё было очень печально. Мы особо не занимались этой историей, и разработчики делали так, как хотели. У нас вообще не было никаких правил написания proto-файлов. Люди разделяли их на множество файлов, использовали неймспейсы, не использовали… Кто-то генерировал клиенты самостоятельно и мог для Go-сервиса сгенерировать клиент только на Go, а как будет жить какая-нибудь команда, которая пишет на .NET, его мало волновало. Другие копировали proto-файлы из чужого репозитория, то есть просто сохраняли копию файла на какую-то дату. Сервис мог обновляться, но сервис-клиент, естественно, не узнавал про эти обновления. Не работала gRPC Reflection (достаточно важная штука).

В 2020 году сервисов стало так много и это стало такой большой проблемой, что мы поняли: надо с этим что-то делать. Начали стандартизировать процессы написания proto-файлов и генерации клиентов. Мы написали достаточно простую CLI-утилиту Protogen, которая делала нечто похожее на то, что делает менеджер зависимостей для языка. Утилитка парсила proto-файл, понимала, какие в нём есть зависимости (можно специально указать репозиторий и версию для каждой зависимости), рекурсивно резолвила все зависимости, формировала локально дерево proto-файлов и занималась генерацией кода на основе protoc или Buf. Этот шаг позволил нам внедрить первые стандарты.

Т.к. до сих пор в индустрии нету единого подхода к управлению зависимостями proto-файлов, то логика в нашей утилите менялась достаточно часто, потому что находились всякие сложные кейсы и часто приходилось просить ребят обновить . В итоге мы решили сложный кусок, связанный с резолвингом, вытащить из клиента, а сам клиент сделать максимально простым. Написали серверную реализацию Protogen’a, которая работает очень просто: берёт нужный proto-файл и отправляет его на сервер. Сервер осуществляет всю сложную логику и отправляет обратно правильно собранный архив с каталогом proto-файлов правильных версий, который точно сгенерируется нужными плагинами. Очень классно и удобно. Возможно, когда-нибудь мы эту штуку заопенсорсим, потому что эта проблема мало кем решалась до нас.

Для сборки и деплоя приложений мы используем GitLab. У нас есть сложные большие пайплайны для всех языков. На скриншоте приведён пример пайплайна сервисов на Go:

Мы запускаем линтеры, тесты, проверку системных файликов, собираем образы. Можем задеплоить сервис в девелопмент-окружение. Если все проверки прошли, всё хорошо, можно деплоить этот сервис и в продакшен. Для этого у нас есть ещё более объёмный пайплайн, который делает ещё более сложные вещи. Он повторно прогоняет множество тестов и пытается найти секреты в коде (потому что периодически команды оставляют в коде пароли или кладут ключи внутрь репозитория и забывают об этом).

Например, “secret search” обнаруживает такие вещи и говорит: «Сначала удали этот пароль, и только после этого мы будем тебя деплоить». Security Scan проверяет внешние зависимости на наличие каких-то уязвимостей. Эти шаги пайплайна очень сильно нам помогли весной этого года, когда по всем известным причинам нужно было очень быстро и аккуратно оградить себя от внешнего мира, чтобы не скачать какие-нибудь неправильные зависимости и не уронить весь продакшен.

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

Service mesh

Мы шутим, что Service mesh — это как подростковый секс. Все о нём говорят, но мало кто это действительно делает. И все это делают очень по-разному. Вот и у нас есть своя реализация.

В далёком 2018 году, когда мы только начинали строить нашу инфраструктуру и у нас появился Kubernetes, мы стали интересоваться, что есть на рынке. Одним из перспективных проектов был Linkerd. Глобально это работает так: у нас есть пользователь, он отправляет какой-то запрос; этот запрос в Kubernetes попадает через Ingress, дальше попадает в первый сервис — и дальше сервисы общаются друг с другом не напрямую, а через Linkerd.

Вроде бы всё классно, но были проблемы. Мы столкнулись с очень большими задержками.

Linkerd написан на Java. Мы принципиально не деплоили его в виде сайдкаров: когда у вас есть маленькие приложения на Go, которые занимают десятки мегабайт оперативки, а рядом — такая Java-история, это не лучший вариант.

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

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

Небольшие задержки есть, потому что есть промежуточные хопы, но нас всё устраивало. Но концептуально так делать неправильно, ведь Ingress должен использоваться только как входная точка в Kubernetes и это очень не нравилось команде куберменов.

Поэтому мы решили написать свою систему для service discovery — Warden. Если коротко, работает она так: есть сервис, который подписывается на кучу событий из Kubernetes, получает оттуда апдейты, строит глобальную карту того, где и как задеплоен каждый сервис (в каком дата-центре, в какой стойке, какая у него версия). А ещё Warden предоставляет очень простой API для других сервисов, с помощью которого сервис №1 может подписаться на изменения сервиса №2 и получать информацию о том, что сервис №2 имеет такие-то IP-адреса и порты. Надёжно, быстро, просто.

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

Что мы получили? Ingress перестал использоваться как какой-то промежуточный балансировщик — теперь он действительно используется, как и положено для Ingress. У нас нет дополнительных задержек, потому что нет лишних хопов, трафик летает напрямую между подами. И у нас нет никаких sidecar’ов, которые накладывают оверхед (потому что в случае с sidecar’ами количество контейнеров на каждой машине увеличивается, докеру становится хуже). Вся эта логика реализована в виде библиотеки, которая работает с API Warden.

На текущий момент Warden — большая сложная система, которая вышла за пределы сервисов. Она предоставляет единый API для всего, что есть: для баз, для различных кешей (Redis/Memcached). Ещё может дискаверить кластеры Kafka. Она поддерживает разные алгоритмы балансировки: WRR, P2C. Также у разработчиков есть возможность задавать кастомные алгоритмы. И на базе Warden со всеми этими плюшками у нас строятся «канареечные» деплои: мы можем очень удобно вручную тестировать новые версии сервисов.

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

«Канареечный» деплой на схеме выглядит очень просто. Есть сервис №1 и есть две версии сервиса №2. Мы можем настроить трафик так, чтобы 90% шло в версию А, а 10% — в версию В. При этом с точки зрения API отдаётся IP, а у каждого эндпоинта отдаётся соответствующий вес. Поэтому библиотека внутри сервиса №1 знает, куда сколько трафика отправить.

Также есть очень классная штука, которая позволяет принудительно отправить запрос в нужную версию сервиса с помощью специального заголовка — x-o3-meshversion.

Смысл заключается в следующем: в случае стандартного запроса трафик идёт в сервис №1, в дефолтную версию сервиса №2 и потом — в сервис №3. Но можно сделать так, чтобы для конкретного запроса использовалась не версия А, а версия В. Я могу отправить этот заголовок — и тогда мой трафик пойдёт через другую версию сервиса. Таким образом, мы можем выложить новую версию сервиса в продакшен и, не включая «канарейку», не раскатывая релиз на какой-то процент живых пользователей, потестировать новую версию сервиса самостоятельно. В том числе мы умеем делать это для мобильных приложений.

Эта схема может быть и сложнее. Она работает на любом уровне взаимодействия сервисов. Если граф или цепочка вызовов состоит из десятка или двух уровней, мы можем на любом уровне сказать: «В пятнадцатый сервис пойди по альтернативному пути». И также Warden умеет делать subsetting. Вот пример с несколькими клиентами и многими копиями сервиса №2:

В большой системе, в которой сервисов не единицы, а десятки или сотни, нет никакого смысла устраивать такой full mesh, когда каждый клиент соединяется с каждым сервисом. Это очень накладно. Достаточно каждому клиенту дать какое-то подмножество инстансов сервиса №2, чтобы они взаимодействовали между собой.

Кажется, что это очень простая задача, но на самом же деле алгоритм достаточно сложный — нужно гарантировать, что на каждый сервис №2 будет одинаковая нагрузка. Но это действительно очень полезная штука. При любом TCP-соединении, если у вас 100 клиентов и 100 инстансов, вы получите 10 000 соединений, которые вам на самом деле не нужны. Каждое соединение, независимо от того, на каком языке вы пишете, требует накладных ресурсов. В случае с Go это несколько горутин. В случае с другими языками всё равно появляются какие-то абстракции — хотя бы даже память для обслуживания этого соединения.

Телеметрия

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

Что мы вкладываем в понятие телеметрии? Это достаточно стандартный набор: метрики, трейсинг, логи и continuous profiling.

Давайте начнём с метрик. Мы снимаем системные метрики со всех серверов. Операционная система не имеет значения. Мы снимаем метрики с Kubernetes, с Containerd — со всего, до чего можно дотянуться. Также, если говорить о приложениях, мы сохраняем метрики из рантайма языка. Неважно, это Go, .NET или Java — можно покопаться и получить огромное количество информации о том, что происходит внутри приложения: сколько потоков, сколько памяти, как часто работает сборщик мусора и т. д.

У нас есть суперподробные метрики обо всём RPC-слое (входящие и исходящие запросы), о взаимодействии сервиса с любыми внешними зависимостями. На основе этих метрик (благодаря тому, что они унифицированы и зафиксированы в тех самых конвенциях) мы строим общие дашборды, которыми очень легко пользоваться. Вот пример:

Здесь есть количество RPS, время ответа сервиса в различных квантилях и ещё куча информации — несколько десятков вкладок на все случаи жизни. Можно посмотреть граф зависимостей и понять, кто приходит в мой сервис и в какие сервисы хожу я. Можно получить детальную информацию о хендлерах — понять, что тот или иной хендлер используется, на него приходит 1000 RPS, а на все остальные — 10 000.

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

Есть информация о каждом протоколе взаимодействия — gRPC, HTTP. Есть метрики из рантайма языков: количество горутин, запусков сборщика мусора, потоков.

Можно посмотреть, сколько ресурсов использует сервис: CPU, памяти, сети — как в целом, так и в разрезе по подам. Есть детальная информация о внешних запросах, о том, как сервис видит взаимодействие с другими сервисами.

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

Переходим к трейсингу. В 2018 году мы начинали с ванильного Jaeger. Наверное, многие из вас за эти годы успели поработать с ним. Но мы достаточно быстро поняли, что Jaeger прикольный, но из коробки он скорее красивая игрушка, чем полезный инструмент. Он удовлетворял не все наши потребности, и в 2019 году мы целиком переписали бэкенд Jaeger, оставив от него только интерфейс. А в 2020 году перешли на OpenTelemetry с точки зрения протокола (бэкенд остался прежним — нашим).

Что мы умеем теперь? Мы храним абсолютно все трейсы и данные обо всех запросах, которые происходят на бэкенде Ozon за последние 10-15 минут. Мы умеем делать умное семплирование, то есть сохранять эти трейсы по разным параметрам, которые можно настраивать. Умеем вычислять критический путь и получать много другой прикольной статистики. Здесь я рассказал о том, как мы строили нашу инфраструктуру трейсинга.

Что мы добавили поверх того, что есть в Jaeger, с точки зрения интерфейса? Я думаю, многие из вас видели эту картинку с «колбасками»:

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

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

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

Наконец, continuous profiling. Мы регулярно собираем с разных приложений внутреннюю информацию о том, как они работают: сколько CPU и памяти тратят, на что. С некоторыми языками это делать очень просто. Например, Go предоставляет такую возможность из коробки. И мы немного пошаманили над нашими фреймворками для .NET и Java, чтобы они тоже могли это делать. То есть, раз в пять-десять минут мы собираем со всех приложений эту информацию, сохраняем её и предоставляем интерфейс, который позволяет узнать, что в таком-то сервисе в такое-то время ресурсы CPU тратились на такие-то вещи. На скриншоте ниже в правой половине — интерфейс того, что предоставляет тулинг Go.

Это актуально, например, когда вы хотите найти ответ на вопрос, что случилось с вашим сервисом вчера в три часа ночи, когда он упал. Благодаря этому инструменту всегда можно вернуться в прошлое и посмотреть, что там происходило.

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

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

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

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

Мы решили начать делать технологии-as-a-service. Для команд разработки они должны были уменьшить время реагирования на запросы за счёт отсутствия в процессе человека, который занимается решением задачи.

В общем виде технология *-as-a-service выглядит так:

У нас есть что-то, что мы хотим автоматизировать. Есть сервисы, которые хотят этим пользоваться. Нам нужно написать control plane, который позволит запускать и создавать это что-то. ITC — это наш внутренний интерфейс для управления облаком. Он взаимодействует с control plane.

И мы воплотили эту идею в жизнь. Разработчики получили мониторинг, алерты, красивые дашборды и возможность настраивать доступ. А для нас из плюсов можно отметить стандартизацию. Мы говорим: «Хотите использовать PostgreSQL — используйте её вот так». Есть различные конфигурации, но их количество ограниченно. Мы контролируем всё — от железа до библиотек, которые умеют работать с той или иной технологией.

На текущий момент мы умеем предоставлять в таком формате следующие технологии:
— PostgreSQL
— S3
— Memcached
— Redis
— Kafka
— ClickHouse

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

Например, для PostgreSQL уже сейчас можно запустить обычный кластер, который будет состоять из мастера, одной синхронной и нескольких асинхронных реплик, которые распределены по разным дата-центрам. Такая конфигурация позволяет сервису переживать отказ как одной конкретной реплики, так и любого дата-центра: благодаря Warden’у сервис получает обновленную конфигурацию и продолжает работать как ни в чем не бывало. Также, совсем недавно мы запустили шардированный PostgreSQL: можно создать кластер, состоящий из нескольких шардов. Автоматика умеет их перевозить с сервер на сервера, а библиотека предоставляет удобный API для работы с шардами.

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

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

что такой-то ресурс принадлежит такому-то сервису

сервис принадлежит такой-то команде

у команд есть квоты на запуск ресурсов

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

Заключение

Для Ozon платформа стала настоящим фундаментом для разработки — на ней сейчас строятся все информационные системы, которые у нас есть. Платформа обеспечивает нам нужную скорость, удобство (и для разработки, и для управления), внедрение новых технологий, телеметрию, безопасность, стандарты. Если у вас в компании сложный ИТ-ландшафт, то подобная платформа очень поможет устранить типичные для больших проектов трудности.

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