Однажды заказчику нужно было провести онлайн олимпиаду по математике для школьников, при этом олимпиада проходила сразу по всей стране. Соответственно, несколько сотен тысяч человек (школьников) должны были зайти на определенный сайт, там решать математические задачи, и в конце объявлялись результаты этой олимпиады. Чтобы держать такую нагрузку, мы арендовали 20 серверов и взяли два месяца на подготовку. Помимо аренды серверов, нужно было настроить сеть, развернуть диски, настроить операционную систему, поверх нее развернуть приложение, проверить, что все это работает, провести нагрузочное тестирование. И чтобы у нас был какой-то запас, после того как мы проделали все работы, еще 2-3 недели эти сервера стояли и ждали олимпиады, и ничего с ними не происходило. Плюс после того, как олимпиада прошла, надо было поменять профиль серверов, потому что теперь нужно было раздавать дипломы участникам олимпиады, а это совершенно другая нагрузка, и там, условно, даже по-другому должны быть сделаны диски, должен быть большой размер, потому что дипломы были достаточно тяжелыми, и их нельзя было сгенерить на лету (это были pdf-файлы).
И вот из этой истории видно, что большая часть оборудования стояла без дела, она нужна была там буквально на несколько часов - на время проведения олимпиады, плюс работы по настройке этого оборудования заняли несколько человеко-месяцев.
Настраивать железное оборудование - достаточно сложная и ручная операция. В идеальном мире хотелось бы просто нажать кнопочку, чтобы все это развернулось, а когда нам это больше не нужно - нажать другую кнопочку, чтобы все исчезло, а мы заплатили за время использования этих ресурсов, и не тратили время на настройку оборудования.
Заказчик - обучающая платформа для корпоративного рынка.
В крупных корпорациях в выходные большинство сотрудников не работает, и одна из идей основателя этой компании была в том, чтобы, например, на выходные уменьшать объем ресурсов, чтобы гибко подстраиваться под трафик, и платить только за те ресурсы, которые используются. Опять же, на железной инфраструктуре, на железных серверах это сделать невозможно.
Также очевидно, что в период, когда у большинства людей отпуск, а у школьников каникулы, трафик на, например, туристические сайты резко растет и, соответственно, когда люди никуда особо не ездят, трафик резко падает. И возможность гибко масштабировать инфраструктуру под существующей трафик помогла бы существенно экономить многим компаниям, у которых сезонные нагрузки. Сэкономить помогла бы и возможность резко менять мощности под нагрузку, которая существует в конкретный период, но сделать это крайне тяжело, почти невозможно. Обычно квант аренды железных серверов - месяц.
Об этом кейсе расскажем на примере какого-нибудь банка.
Немножко специфики крупных организаций: они все нарезаны функционально, и, допустим, за инфраструктуру и железные сервера отвечает один отдел, за уровень операционной системы - другой, за уровень приложения - третий. Соответственно, если понадобился новый тестовый стенд, пишутся заявки в конкретную структуру или в отдел закупок (если готового железа нет, и его нужно купить), другие отделы настраивают операционную систему, потом следующий отдел настраивает уровень приложения, отдел базы данных настраивает базы данных, а если вам нужны какие-то данные из тестовых серверов (данные мониторинга), вы пишите заявку в отдел мониторинга. Это типичная история в крупном банке. Там на развертывание нового тестового стенда уходит минимум месяц. А если что-то пошло не так, вы снова пишите заявку, и дальше запросы разбегаются по разным отделам, где люди долго-долго выясняют, что же сделать, чтобы все заработало.
Еще более интересная история с созданием нагрузочных стендов. Дело в том, что если, допустим, тестовый стенд может по ресурсам быть достаточно небольшим, то нагрузочный стенд все-таки должен быть гораздо более приближен к продакшену. Соответственно, железо (оборудование) для нагрузочного стенда должно быть гораздо дороже, а нагрузочное тестирование обычно занимает достаточно короткий промежуток времени. Условно говоря, вы месяц собираете нагрузочный стенд, затем два-три часа, максимум день, его используете для тестирования, а дальше он снова стоит и ждет следующего релиза. И в идеальном мире хотелось бы, чтобы нагрузочный тест появлялся у вас по щелчку пальцев, вы проводили свои нагрузочные тестирования, получали результат, и дальше этот стенд можно было бы разбирать для боевых серверов. То же самое, что вы сделали какую-то новую функцию в вашем продукте: он стал популярным, или, наоборот, стал потреблять больше ресурсов, и если у вас нет готовых железных серверов, чтобы резко увеличить ресурс, вы можете просто лечь под нагрузкой. Повторимся, железную структуру, которая управляется руками, сделать практически невозможно.
Для многих крупных организаций огромная проблема, что часть ресурсов простаивает, а часть скрепит под нагрузкой. И оптимизация этих ресурсов дала бы значительный экономический эффект.
Например, вам нужно собрать новый сервис. Вы понимаете, что для того, чтобы его быстро собрать, нужна база данных, очередь сообщенией, кэширующий сервис, отдача в статике и т.д. И все это нужно быстро собрать из готовых кубиков, потом нажать кнопочку, чтобы появилась база данных, появился application-сервер, веб-сервер, из этого собрать рабочую систему (работает - масштабируем, не работает - разбираем). К несчастью, опять же, в крупных организациях собрать такой готовый кубик занимает недели-месяцы. А если, например, вам нужно использовать новую технологию, а внутри вашей организации нет экспертизы, это либо вообще невозможно, либо это будет сделано с низким уровнем качества.
Опять же, если, например, у вас есть отдел баз данных, и у них есть не вся нужная экспертиза, то в зависимости от того, из какого отдела запрос придет первым, или какой начальник более важный, запросы скапливаются в очередь, и вы не можете быстро что-то менять в вашей базе данных. Например, не можете быстро развернуть новую копию базы данных, потому что у соседнего отдела более высокий приоритет. Плюс, если даже вы научитесь делать эти кубики сейчас, в современном мире этих кубиков множество, и держать внутри крупной организации экспертизу по всем ним очень дорого - сегодня, условно, нужно много экспертизы по Oracle, завтра ее требуется гораздо меньше, после экспертиза нужна по каким-то другим сервисам.
В результате сотрудники либо простаивают, либо перегружены. Соответственно, это актуально и для компаний-стартапов, которые проверяют новые гипотезы, и для крупных организаций, которые занимаются продуктовой разработкой.В зависимости от степени стабильности отрасли, для каких-то отраслей это более важно, для каких-то менее.
Подводя итог, вспомним кейс массовых акций с проведением олимпиады: в той конфигурации, которую мы тогда использовали, ценник в месяц составил 160 тысяч рублей, и за два месяца они отдали 320 тысяч рублей, ресурсы сотрудников также можно было сэкономить. К несчастью, померить потерю от невыхода вовремя новой функциональности продукта крайне сложно, но достаточно очевидно, что в современном мире на рынке побеждает тот, кто быстрее всех бежит, быстрее может удовлетворить потребности своих клиентов.
Запишитесь на вебинар
Расскажите о вашем проекте, мы свяжемся с вами
и вместе рассчитаем стоимость в индивидуальном порядке.
Давайте обсудим ваш проект
и разберемся, как мы можем вам помочь
Остались вопросы?
Мы перезвоним и ответим на них!
Спасибо, ваши данные успешно отправлены!
Мы свяжемся с вами как можно скорее
