Как стать автором
Обновить

Комментарии 16

Сайт сайберспорта регулярно падает по время знаковых событий. Когда NaVi выиграли мажор - упал, VP вылетели из турнира - упал. TS победили на инте - упал. Если этим занимались тоже вы, то я бы не сказал что вы справились.

С другой стороны масштабировать битрикс больно, я вас понимаю

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

Хм, они все таки его наконец поменяли. Cybersport был ранее сайтом virtuspro, который был на битриксе

Ваше сообщение более чем логично, но если даже масштабирование не спасает от ухода в 403 в пике, то что тогда спасает ? :)

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

Ваше сообщение более чем логично, но если даже масштабирование не спасает от ухода в 403 в пике, то что тогда спасает ? :)

403 - это все-таки про другое, вы наверное имели в виду 5** ошибки.
Спасает конечно, разница между упасть на все время всплеска посещений против 5% таймаутов на 10% запросах, как пример :). Плюс вопрос в трудоемкости операций, запасе отказоустойчивости, гибкости и простоты изменения инфраструктуры, и многих других факторах. Я уж не говорю про запас ресурсов, которые без удобной автоматизации, наращивать достаточно некомфортно, особенно в условиях "пожара".
Инфраструктура такого рода позволила нам избавиться от множества узких мест и перейти на качественно иной уровень. Что касается частных случаев ошибок на сайте - их надо разбираться отдельно и предметно, это в том числе позволит улучшить пользовательский сервис ;).

В проекте была необходимость строго соблюдать бюджет на инфраструктуру. 

Не расскажете поподробнее - почему?

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

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

поскольку недооценили нагрузки, которые предстоит принять. 

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

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

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

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

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

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

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

Богатый опыт эксплуатации разных по размеру и сложности проектов показывает, что всегда найдется возможность для косяка (уж простите за слэнг) :). Тут же речь не о том, что "кто-то говорил надо больше - мы не послушали" или "мы чайники и не поняли, что надо иначе/больше/лучше", а исключительно в разрезе комплекса факторов в виде определенной ограниченности в ресурсах, сложности выстраивания нагрузочных тестов, невозможности быстро и просто определить, а сколько ресурсов потребуется для сайта, если посетителей будет в 2 раза больше, или в 5, или в 10. Об этом и было сказано в статье. С нашей стороны мы сделали best effort - подготовили такую инфру, которая в базе уже покрывает все эти кейсы, а дальше вопрос регулировки и подстройки для частных случаев.

Все так, а вопрос в чем?

В том, что непонятен смысл облака, с ограничениями.

 невозможности быстро и просто определить, а сколько ресурсов потребуется для сайта, если посетителей будет в 2 раза больше, или в 5, или в 10

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

В общем, как понимаю, не смотря на падения прода, вы считаете, что сделали все, что смогли, и ошибок не допустили?

В том, что непонятен смысл облака, с ограничениями.

Так их нет, ограничений :). Вы же видите разницу между "заказать железки, дождаться их поставки, настройки, сетапа ОС, настройки ОС, подключить в кластер" и "изменить два параметра в yaml-манифесте и через 5-10 минут получить +20 виртуалок (уже подключенных в кластер и принимающих pod'ы и трафик)"? Так вот это самая поверхностная разница и смысл.

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

Везде хватает своих вызовов. Иначе программист через 10 лет работы не допускал бы уже ошибок и весь его софт работал бы без багов, автослесарь через 200 машин мог бы починить любую проблему с закрытыми глазами и так далее, и развиваться бы им было некуда, верно?

В общем, как понимаю, не смотря на падения прода, вы считаете, что сделали все, что смогли, и ошибок не допустили?

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

 автослесарь через 200 машин мог бы починить любую проблему с закрытыми глазами

Опытный и правда может перебрать мотор с закрытыми глазами: https://www.youtube.com/watch?v=1S8R-MKjgfo

Так, он вроде бы из экосистемы VK GROUP. Почему решение вопроса с ним отдали сторонней орге, а не сами спецы из VK.

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

российские веб-проекты должны хранить данные на территории РФ;

это относится ко всем данным или только к первичной базе с персональными данными? Лет 6 назад достаточно было хранить первичные персональные данные.

Речь конечно про персональные данные.

Смотрел интервью с директором Фланта на итбороде, интересно было

Вспомнил интервью после упоминания "slave-узлов" )

Не думали перейти на связку Vue + node.js для SSR? Временно отдавать данные с старого бека, постепенно переходить на что-то быстрее. Если экспертиза в PHP, можно остановиться на Laravel для API. Проводил тесты: на скромном железе (2 ядра Xeon 3.2 ГГц, 4gb ddr4) Rust и Go могут отправлять данные для 2000 страниц в секунду, PHP и Python примерно для 900.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий