Почему мы не даем "Highload"

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

Для тех кто не в теме

Из википедии:

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

Красивая теория и чуть менее красивая практика заключается том что «Highload» это когда система хотя-бы не падает сразу под большой нагрузкой.

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

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

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

Думаю про требуемую степень ответственности за такой проект и уровень вознаграждения рассказывать не надо?

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

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

Инцидент

Совсем недавно был реализован один интересный проект, требующий обработки достаточно большого объема данных: ~300Гб в виде XML документов, которых после ряда преобразований нужно было загрузить в систему.

Вообщем-то объем далеко не самый эпический на нынешние реалии, я бы даже сказал «детский».

И хрен бы с ним, что некоторые XML были по 1.5-2Гб размером и требовали особого подхода к обработке.

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

А когда были пройдены все тесты и дошло до реального использования, оказалось (причем далеко не сразу) что заказчик взял и поставил дисковое хранилище на SATA-дисках вместо SSD.

Где он смог достать столько работающих SATA в 2023м году сказать уже невозможно, зато можно сказать про другое — про падение производительности раз так в пять:

на машине разработчика стоял быстрый SSD диск а на продакшне оказалась виртуальная машина, запущенная на хосте работающем с программным(!) дисковым массивом на SATA дисках.

Что случилось дальше после объяснения ситуации?

За свой счет разумеется.

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

Ситуацию конечно удалось разрешить, но не без потерь и «на грани».

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

Объясняю.

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

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

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

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

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

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

Настоящий хайлоад

Первое что надо запомнить раз и навсегда:

Минимум 50% работы над высоконагруженной системой это тонкая настройка и тюнинг всего: оборудования, ОС, фреймворков и инструментов.

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

Поэтому первое что вам стоит сделать это нанять толкового сисадмина.

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

Для США все несколько сложнее, но суть не меняется: толковая эксплуатация стабильно на голову бьет любую разработку, как хорошую так и плохую.

Что будет если вы проигнорируете этот совет и вложите все свои миллионы в одну только разработку?

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

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

Метрики и статистика

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

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

Очевидно что эти метрики и статистику еще надо подключить и настроить и к разработке этот «кто-то» отношения обычно не имеет. Как думаете в каком количестве случаев на моей практике обратившиеся за помощью с хайлоадом имели настроенные метрики?

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

Но в компаниях попроще, с метриками полный провал: чаще всего их нет совсем.

Симуляция нагрузки

Помимо уже озвученного про разграничение зон ответственности за эксплуатацию существует еще одна важная проблема:

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

Врядли вы помните или видели, но первые версии Amazon и Netflix падали как раз из-за плавающей нагрузки в предпразничные дни.

И как вы думаете, какое количество сервисов нагрузочного тестирования сегодня дают симуляцию рождественской распродажи?

Ноль.

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

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

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

Круто? Круто.

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

Уже не так круто.

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

Затраты на оживление базы, как вы уже догадались.

Затем оказалось что большая часть этих новых заказов — левая, накрученная ботами, часть из оставшихся была сделана детьми ради шутки, либо из тех мест и стран куда вы при всем желании не сможете доставить — аля колония строгого режима «Рязанский Лебедь» или «войсковая часть № 4567 Калининградская обл., 101 км трассы».

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

Ну и получили кучу негатива от пользователей которые «вам поверили» и думали что вы как «Яндекс» — работаете всегда и без сбоев.

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

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

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

В теории конечно можно такое провернуть, но риски очень уж велики.

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

Слово "бекофис" уже слышали? Нет?

А если хотите развивать масштаб бизнеса то придется этот термин запомнить — ооочень много внутренней разработки будет у вас проходить как раз по этой категории.

Подрядчики с большой дороги

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

Так что, возможно ли вообще такое:

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

Вне зависимости от бюджета и степени компетенции.

Сам запрос на такое, это примерно как просить проститутку за деньги воспитать вам ребенка «под ключ» вместо жены.

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

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

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

С своей командой, своими серверами и внутренними процессами.

Внешние подрядчики вроде меня вам смогут лишь немного помочь (и то не всегда), но точно не заменить полностью вашу команду.