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

19 июня 2018

Колумнист Марк Орттунг изложил в материале для The Next Web несколько пунктов, по которым успешный стартап может проверить, готов ли он к масштабированию. Автор подчеркивает — процесс выставляет напоказ все недостатки и уловки компании. Он особенно актуален перед крупными слияниями и поглощениями, когда важно чувствовать максимальную уверенность в своем продукте. Журналист AIN.UA приводит адаптированный перевод материала.

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

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

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

Не забывайте про интерфейс
Масштабируемость — это не только про бек-энд. Я знал один стартап, в числе первых клиентов которого был ныне популярный райд-шеринговый сервис. В тот момент большинство клиентов стартапа вели всего по 20 открытых транзакций одновременно. Внутреннее веб-приложение поддерживало до 50 транзакций — то есть в два с половиной раза больше. Что могло пойти не так?

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

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

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

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

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

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

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

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

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

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

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