Записки программиста

Темы пятого выпуска: скандальная правда о том, что и как устроено внутри Echo, почему нельзя так просто взять и протащить Haskell в продакшн, спасет ли Spanner программистов от импотенции, почему лучше дать денег Амазону, чем делать свое облако, а также немного о continuous delivery и нагрузочных тестах. Предыдущие выпуски: четвертый, третий, второй, первый.

Слушать онлайн:
http://eaxcast.podfm.ru/_eaxcast/5/

Скачать файл:
http://eaxcast.podfm.ru/_eaxcast/5/file/podfm_eaxcast__eaxcast_105.mp3

Шоу нотес:

• Названные базюльки: Couchbase, DynamoDB;
• Облачные хостинги: Amazon, Joyent, DigitalOcean, Rackspace;
• Бест практис по использованию DynamoDB от Амазона, плюс тут еще есть слайды [PDF] на эту тему;
• Доклад «That’s Billion with a B: Scaling to the Next Level at WhatsApp» с Erlang Factory 2014, видео и слайды [PDF];
• Ваня пишет звук этой внешней звуковухой и этим микрофоном;

Голоса выпуска: Иван @gliush Глушков, Валерий @sum3rman Мелешкин, Александр @afiskon Алексеев

Фоновая музыка: The Panets — Winter Beats (Big Power Mix)

 

Александр: Всем привет. EaxCast, первый сезон, пятый выпуск.

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

Валерий: Привет!

А: И у нас в гостях специальный гость, широчайше известный в узких кругах Иван Глушков. Привет, Вань.

Иван: Ты меня сейчас перехвалишь. Привет, привет.

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

И: Я закончил МФТИ. Учился там не с самого начала, я сперва начинал в далекой республике Марий Эл, потом перевелся в МФТИ, закончил его и какое-то время работал над процессорами «Эльбрус», делал компиляторы для семейства процессоров «Эльбрус» порядка шести-семи лет.

Потом меня Лев Валкин позвал в проект Echo, и я с удовольствием откликнулся на предложение. Я давно хотел заниматься этой областью, и переехал в Ульяновск из Москвы, и сейчас уже больше четырех лет работаю. Пишу на Erlang в основном, делаю всякие функциональщины, OCaml, Haskell тоже трогаю иногда. То есть, в целом полностью поменял образ мыслей и свои инструменты, за исключением Vim’а, пожалуй. Как-то так.

А: Vim, отлично. Собралось три вимера.

В: Три вимараста.

А: Как там, в Ульяновске? Я никогда не был, как там погода сейчас?

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

А: Скажи, пожалуйста, с какими базами данных тебе сейчас приходится работать?

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

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

А: Просто очень странно, мне казалось, что в «Эхе» должно быть обязательно какой-то key-value, Riak, или хотя бы Memcached. Неужели обходитесь?

И: Я их не называю как таковыми базами данных, я их называю больше как Key Value решения, поэтому мы расходимся немножко в номенклатуре. Да, у нас, конечно же, есть и Риак, мы сейчас попытаемся прикручивать DynamoDB амазоновскую, у нас есть мемкеш, Membase — точнее, уже Couchbase, и вроде все.

B: А почему вдруг решили взяться за DynamoDB?

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

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

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

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

А: То есть, ты, в целом, рекомендуешь?

И: Не скажу, что я рекомендую, потому что мы еще ее в бою не пробовали. Мы сейчас ее пытаемся трогать, мы пытаемся на нее часть данных перекинуть, чтобы на каком-то тестовом кластере проверить, но в целом… Это интересно, и я хотел бы, чтобы у нас был в этом опыт. Поэтому я пока рекомендовать не могу, но мы думаем, что это довольно удобное решение.

В: Если не секрет, то у вас сейчас какая версия Риак крутится в продакшне?

И: Это сложный вопрос. Я не помню.

А: 2.0 или 1.4…

В: Не, в смысле… 2.0, понятное дело, не крутится. Просто Иван сказал, что тяжело добавлять большое количество узлов, где-то — то ли в 1.1, то ли в 1.2 они сделали так, чтобы это было сильно проще, как раз, по-моему, на основе того, что делали для Echo.

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

В: Почему хочется разных клиентов держать на одном Риак-кластере?

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

А: А какой размер кластера, если не секрет?

И: Порядка десятков нод. Несколько десятков нод.

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

И: Не десяти, но меньше, чем пятьдесят, точно.

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

В: Я не сказал, что нельзя…

А: … или, в случае с Эрлангом, ты можешь держать что-то в ETS-ках, это не считается за базу.

В: Я сказал, что это импотенция всего мира как разработчиков, потому что ничто не мешает сделать нормальное решение.

И: А какое нормальное решение ты предложишь?

В: Смотри, у Гугла есть Spanner, например. Они могут в нем одновременно его и как KV использовать, когда им надо, и оно по скорости тогда как KV. А когда им не хочется вжимать, там прямо перформанс дичайший, они его используют как обычную SQL-базу. Да, коммит, может, занимает 500 миллисекунд, но им — ок.

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

В: Нет, 500 миллисекунд — это кросс датацентр, то есть, 500 миллисекунд — это твои данные, реплицированные в трех гео-зонах. Ты быстрее все равно не сделаешь в трех гео-зонах.

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

И: На самом деле, это очень интересно. Я готов еще продолжить, если честно. А они насколько полноценный SQL предоставляют?

В: Это не совсем SQL, но у них есть нормальные транзакции, притом не так, как, например, в H-Store, кажется, или… в общем, исследовательский проект Стоунбрейкера — там есть VoltDB и есть H-Store.

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

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

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

А: Понятно. Вань, давайте сменим немножко тему. Если я правильно понимаю, ты — тот самый человек, который в Echo сумел протащить Хаскель.

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

А: Скажи, с какими проблемами при этом ты столкнулся? У нас, например, есть такая проблема, что в целом система распределенная — SOA (Service Oriented Arcitecture), и если я, например, хочу на Хаскеле запилить сервис, то я понимаю, что мне нужно написать клиента для трех-четырех сервисов и в этих сервисах тоже написать клиента для этого, например, на Эрланге. Я понимаю, что мне придется поддерживать на трех языках несколько версий разных библиотек, притом это может быть даже на одном языке две библиотеки, если двум сервисам нужно немножко c разными вещами работать, немножко по-разному. Например, у нас есть такая проблема. А с чем ты столкнулся, когда протаскивал Хаскель?

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

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

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

А: Такой вопрос. Наверняка ты часто сталкиваешься с проблемой, что есть некоторый сервис, для примера CRUD к каким-то данным. Две проблемы: нужно, чтобы у тебя сдохшая машина не приводила к тому, что люди остались без сервиса, а вторая — это бесшовные релизы. Пробовал ли ты решать такие проблемы, и каким образом?

И: Что ты имеешь в виду под бесшовным релизом?

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

И: В Эрланге есть такая вещь, как hot code reload, он позволяет подобные проблемы решать.

В: Для Эрланга, не для базы данных.

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

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

В: Я знаю, что вы используете эрланговые релизы, в частности, я так понимаю, — hot upgrade. Как часто вы пользуетесь hot code upgrade, а как часто — рестартите сервис? И в каком проценте сервисов вообще это используете?

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

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

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

Я, по-моему, пропустил один из вопросов. Если что-то не ответил, поправьте.

В: У вас есть какие-то сервисы, которые вообще не используют hot code upgrade или вы все сервисы более-менее одинаково поддерживаете?

И: У нас вот этот хаскелевский не поддерживает, например, hot code upgrade. Конечно, его приходится рестартовать. Эрланговские мы, в основном, все за счет хот код апгрейда делаем.

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

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

В: Могу сразу с ходу пример привести. Есть кластер Риака. Понятное дело, что ты можешь взять выключить узел, заменить там код, поднять узел заново — за это время ты успеешь пропустить какое-то количество записей. Потом тебе придется эти записи туда-сюда переезжать. Конечно, лучше не нагружать лишний раз сеть, если есть такая возможность — просто сделать hot code reload.

А: Может быть, может быть. Вань, извини за нескромный вопрос, с Mnesia дела иметь не приходилось?

И: Ой, приходилось, и только негативный опыт. Давайте не будем про плохое здесь обссуждать.

В: Удивительно, но небезызвестный WhatsApp использует Mnesia. Недавно был Эрланг-фактори в Сан-Франциско, кажется. Там довольно много интересных видео и среди них есть доклад WhatsApp. И вот, на удивление, они используют Mnesia довольно активно.

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

А: Вань, вот ты говоришь… Я правильно понимаю, у вас все хостится в Амазоне в облаках?

И: Нет, у нас есть и колокейшн с базами отдельно.

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

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

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

В: Когда ты говоришь — Амазон, ты имеешь в виду любой infrastructure as a service, — например, Джоент или Диджител Оушен, Рэкспейс, или ты имеешь в виду именно Амазон и он имеет с твоей точки зрения какое-то суперконкурентное преимущество перед остальными infrastructure сервис-решениями?

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

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

В: Джоент предлагает, например, машины с установленными лоуд балансерами и Джоент хорош тем, что у них диск не какой-то EBS, а у них локальные SSD и локальные рейды.

И: Тот же EBS, скажем, он там будет работать? Или автоматическое расширение кластеров в зависимости от нагрузки — они предоставляют такую функцию?

А: Раньше нет, сейчас, по-моему, можно на их API самому сделать.

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

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

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

И: Это все верно, но Гугл и Яндекс имеют достаточно денег, чтобы сделать свои собственные кластера. Мы сейчас говорим все-таки про проекты, которые не имеют таких денег, чтобы сделать свой дата-центр. Более того, насколько часто вы видели, чтобы Амазон поднимал цены? Насколько я помню, они последние годы только и делают, что опускают.

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

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

И: А в Амазоне все включится назад, не это, так соседняя нода подхватит твою работу.

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

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

И: Это некий аналог релиза по частям для части аудитории, ты это имеешь в виду?

А: Да.

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

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

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

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

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

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

А: С Валерием.

И: Черт. Извините, пожалуйста.

В: Ничего страшного. Я даже поправлять не стал.

А: А меня все Лешей называют :( Я уже привык.

В: Кстати, да, я, если честно, постоянно путаюсь, тебя то ли Лешей, то ли Сашей называть.

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

И: Да, зовите почаще. С удовольствием приду.

А: Тогда у нас все. Спасибо, что слушали! Подписывайтесь, RSS, Twitter, iTunes, жмакайте на лайки и до следующего выпуска. Всем пока!

В: Пока.

И: Пока.

Дополнение: EaxCast S01E06, о разработке компиляторов и Эльбрусах

Метки: EaxCast.