Как Мы Чуть Не Поседели 3 Раза, Прежде Чем Это Стало Мейнстримом: Кризисы Декабря И Января



Как мы чуть не поседели 3 раза, прежде чем это стало мейнстримом: кризисы декабря и января

Я обещал рассказать, что произошло в нашем дата-центре, и хотел закончить все это к концу февраля.

После этого стало немного сложнее, но все же, раз я обещал, то рассказываю.

Ха, тогда нам эти проблемы показались невероятно огромными.

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

И это не только мы, поэтому мы тесно сотрудничали с дизелями.

Затем у ККБ-банка отозвали лицензию, из-за чего было потеряно примерно 10% российской электронной коммерции, поскольку помимо WebMoney он предоставлял очень крупные платежные шлюзы.

И, наконец, у нас был грубый перебор по RDP эпических масштабов.

В промежутке между этими рассказами я еще был неприятно болен, поэтому не мог сразу рассказать об этом.

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

Скажем так, они значительно расширили мое понимание бизнес-рисков.

Первая кризисная ситуация началась 18 декабря прошлого года вполне обычным образом: несколько серверов были захвачены и перезапущены.

Когда мы начали разбираться в случившемся, оказалось, что сгорел «их» ИБП.

Почему сгорел ИБП? Потому что на подстанции, питающей городское электричество, произошел скачок напряжения.

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

Мы сразу же провели пробную эксплуатацию дизелей.

На первый взгляд все выглядело довольно обычно.



▍ Драма 18–29 декабря

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

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

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

Точных подробностей нам до сих пор не сообщили, но в 17:33 субботы мы остались без городской еды.

Дежурный по смене переключил питание на дизельное топливо.

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

Но топлива нам хватит на 9 часов работы на полной мощности.

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

Понедельник нас совершенно не устраивает, и мы просто не ожидали такого подстава от поставщика.

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

Один человек ночью начинает искать, где взять солярку, а второй – куда ее девать.

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

самый крупный.

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

-Вторник.

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

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

Это было очень полезно.

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

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

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

Только в понедельник.

Работа без резерва до понедельника нас совершенно не устраивала.

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

.

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

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

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

В следующий раз оба луча нам отключили на ремонт 29 декабря: там с 8 утра до 7 вечера мы работали на дизелях, но гораздо спокойнее.

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

Потому что это критично, а ездить самостоятельно и возить топливо от заправки до дата-центра на «Газели» как-то не очень вписывается в ИТ-бизнес, знаете ли.

Ну и наличные тоже надо иметь на случай срочной доставки: приличные конторы просто не смогут оформить документы в такое время, договориться можно только с частником, по сути.

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

Если не считать тех серверов, которые вышли из строя из-за сгоревшего ИБП, среднее время простоя у них составляло около получаса.



▍ Брутфорс RDP

Вторая проблема почти стандартная, но тоже достаточно потрепала мне нервы.

Нас атаковал крупный ботнет, который начал злоупотреблять клиентами через их RDP-порты.

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

Скажу сразу, это коснулось только тех машин, на которых фаервол не был настроен должным образом.

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

Какой брандмауэр, о чем ты говоришь? Он работает нормально.

У нас было решение с приманками, которое работает довольно хорошо.

Вот сообщение о нем.

Ставим самописный статистический анализатор трафика, который идентифицирует RDP-сессии (и другие, кстати, тоже) и умеет понимать адрес источника — на случай брутфорса и прочих атак.

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

Тот, кто пришел в гости, оказался большим.

Проблема в том, что мы обычно скрываем IP-адреса, с которых происходит атака.

Это делается вручную через вышестоящего провайдера связи.

У нас нет возможности автоматически отправлять списки BGP интернет-провайдеру для блокировки IP. Риск выстрелить себе в ногу слишком велик, когда ошибки конфигурации приводят к распространению неверной информации о маршрутизации.

В обзорной статье Cloudflare Указаны примеры таких случаев.

В 2004 году турецкий интернет-провайдер TTNet ошибочно объявил, что это лучший маршрут для всего интернет-трафика.

В результате некоторые пользователи по всему миру потеряли доступ к части или всему Интернету.

В 2008 году пакистанский интернет-провайдер попытался заблокировать YouTube с помощью BGP. Но из-за ошибки YouTube несколько часов был недоступен по всему миру.

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

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

Очевидно, виноват хостинг.

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

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

Это было веселое время, чтобы поддержать.

Служба поддержки сначала объяснила, как настроить брандмауэр.

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

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

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

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

Автоматически, на основе анализа трафика и дампов приманок.

Понятно, что в эту автоматику может попасть что-то не так, но мы все равно можем это исправить руками.

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



▍ Отзыв лицензии ККБ

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

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

До этого мы принимали платежи через один сервис.

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

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

Такой провал в прокате мог легко стоить нам годовой прибыли.

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

Наш шлюз выглядел чрезвычайно надежным: это был Paymaster, система WebMoney. Через него мы принимали карты, СБП, Вебмани, стики и прочее.

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

И пока не пришел ЦБ и не всем раздавал люли , ничего не предвещало беды.

Вообще-то, еще когда я приехал, говорили о запрете переводов между кошельками и запрете на пополнение кошельков на полгода.

Это произошло 6 декабря, запрет вступил в силу 7 декабря.

До этого ЦБ запрещал QIWI оплачивать зарубежные интернет-магазины, YuMoney получила такое же распоряжение, но обе системы живы.

Тогда ЦБ отозвал лицензии у нескольких финансовых организаций на расчеты с онлайн-казино.

Казалось, нас это никак не должно коснуться.

Но мы параноики, поэтому на новогодние праздники решили перейти на новый шлюз.

Это не самая простая и быстрая операция, плюс комиссия была выше.

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

В общем, мы поворчали, поставили задачу на высший приоритет, отодвинули все фичи и сделали это.

11 февраля 2022 Расчетный банк WebMoney (ОАО ККБ) внезапно перестал быть банком .

Центробанк отозвал у него лицензию.

В качестве причин ЦБ указал, что ККБ допустил нарушения законодательства в сфере борьбы с отмыванием денег и финансированием терроризма.

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

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

В результате этого, как я уже говорил, около 10% российских E-COM остались без платежного шлюза.

И это по самым скромным оценкам.

В 8 утра шлюз упал, мы час не принимали платежи, около 9 утра перешли на новый шлюз для карт, а в 9:30 и все остальные способы оплаты тоже.

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

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

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

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

Когда у тебя есть какая-то паранойя, это еще и страшно.



▍П.

С.

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

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



Как мы чуть не поседели 3 раза, прежде чем это стало мейнстримом: кризисы декабря и января

Теги: #ddos #Управление проектами #Хостинг #дата-центр #ИТ-инфраструктура #ruvds_articles #ruvds_articles #платежный шлюз #отключение электроэнергии

Вместе с данным постом часто просматривают:

Автор Статьи


Зарегистрирован: 2019-12-10 15:07:06
Баллов опыта: 0
Всего постов на сайте: 0
Всего комментарий на сайте: 0
Dima Manisha

Dima Manisha

Эксперт Wmlog. Профессиональный веб-мастер, SEO-специалист, дизайнер, маркетолог и интернет-предприниматель.