Информационные Технологии

Как-то произошел в дата-центре интересный случай:

Клиент привез сервер на размещение (colocation) и все было хорошо до тех пор, пока в его системе не объявился модный на тот момент вирус-шифровальщик.

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

- А вы что, не делали мне бэкапы!? Зачем я тогда вообще размещаюсь по вашему???

….

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

А вот и продолжение истории из начала статьи, как говорится, это еще не все!

- А вы что, не делали мне бэкапы!? Зачем я тогда вообще размещаюсь по-вашему???

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

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

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

Как пропадают данные?

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

- молния ударила в дата-центр Google;

- что-то пошло не так при миграции сервера и MySpace потеряла все данные пользователей за 12 лет с 2003 по 2015 годы (включая музыку, фотографии и видео);

- 16000 результатов тестов на коронавирус было утеряно из-за технической ошибки в Excel в Великобритании, подробности не уточняются;

- Яндекс удалил виртуальные машины активных пользователей, применив некорректную фильтрацию и перепутав их с должниками;

- администратор ошибся, а gitlab лишился базы данных объемом 300Гб;

- в результате кибератаки вируса-шифровальщика все данные в базе данных компании ISS World были утеряны.

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

Наивность и дебиторка

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

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

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

- оплатить забыли или не успели;

- сейчас нет денег;

- не получили счет и забили;

- бухгалтерия где-то как-то что-то;

- прочая бюрократия.

Как хостеры обращаются с данными

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

Для понимания, обрисую ситуацию, которую мы транслировали при общении:

Первое число месяца, с баланса списывается абонентская плата и образуется минус, для простоты счёта, представим, что мы должны хостеру денег ровно за один месяц. Рассматривались такие услуги как аренда физического сервера (dedicated) и аренда виртуального сервера, т.к. я искренне (а может и наивно) полагаю, что мой личный сервер на размещении (colocation) не пропадет просто так, как и данные с него.

Первый вопрос довольно безобидный.

Как быстро, с момента образования задолженности сервер будет отключен?

Работа встала, но еще не все потеряно.

Однако, что происходит после того, как предоставление услуг приостановлено?

После появления задолженности, в какие сроки сервер будет разукомплектован / удален?

Аренда физического сервера:

Аренда виртуального сервера:

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

После того, как сервер разукомплектовали / удалили, есть ли возможность восстановить данные?

Аренда физического сервера:

Аренда виртуального сервера:

* если прошло не более 30 дней с момента удаления.

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

Что еще можно отнести к наивности?

“Договор, покажи ему свой договор!” (с)

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

Под меня будут подстраиваться. Уверены?

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

Ситуация, когда “наша бухгалтерия платит только по четвергам” (с) не единична, но весьма комична.

“А мы счет не получали!” (с)

“А мы отправляли!” (с) - вот типичный ответ, который можно получить в такой ситуации. Хостер получит свои деньги, просто позже, а вот что он сделает с сервером на время ожидания остается за кулисами, но не для того, кто счет “не получил”.

“Вы же профессионалы” (с)

Этим многие любят оправдывать неприятные ситуации, которые случаются. Да, профессионалы, но далеко не все услуги и уж тем более “профессионалов” включены по умолчанию. Тут можно вернуться к пункту про договор и забыть про экономию, так как многие клиенты именно в целях экономии отказываются от предлагаемых им дополнительных услуг, самостоятельно настраивают бэкапы, но не мониторят их. Сделали и забыли. А лучше бы доверились тем самым “профессионалам”.

“Уходя, гасите свет” (с)

Речь про забывчивость и утилизацию. Когда закончили аренду, сотрите данные и перезапишите диски. Уничтожьте бекапы у хостера. Просто правило хорошего тона как блокировать консоль и чистить зубы на ночь. В идеале это должен делать хостер, но должен ли? “На Бога надейся, а сам не плошай” (с)

Заключение

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

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

- проверяйте бэкапы (а можно ли из них что-то развернуть?);

внимательно читайте договор, задавайте вопросы, если важные для вас моменты не прописаны;

- убедитесь, что вы точно получите счет за услуги, резервируйте получателей;

- настройте автоплатеж, если не задействована бухгалтерия;

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

- спросите у своего хостера про бэкапы и другие, пусть даже самые очевидные ситуации;

- поинтересуйтесь у вашего менеджера как принято работать с дебиторкой, какие сроки у вас есть и как можно их “оттянуть”;

- не рассчитывайте, что хостер будет вас “кредитовать”, там тоже бизнес, тоже бюджеты и кормление “завтраками” никто терпеть не будет;

- не будьте наивными, это дорогого стоит.

Тут еще планировался большой текст о том, как работают с дебиторкой в нашем дата-центре, но в голову пришло два тезиса:

1. Мы не сможем точно ответить на ряд вопросов, потому что подход индивидуальный (и вот тут придется объясниться).

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

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

Да, у нас прописаны условные 20 дней когда должников нужно отключать (сервера по ethernet, само собой), причем в договоре прописаны сроки более жесткие, а эта цифра для менеджера. Вот и первый нюанс.

Да, у нас есть бэкапы по умолчанию для виртуальных серверов, но спросите менеджера когда исчезнут ваши данные и он не ответит. Почему? Потому что подход все еще индивидуальный. Факторов масса, но один, наиболее важный - мы не доверяем автоматизированным оповещениям. Счета рассылаются автоматически по электронной почте, туда же, с завидной периодичностью падают письма с напоминанием и дублем счета. Еще мы используем смс-оповещение, остановились на API greensms.ru, но это все автоматика.

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

===

А еще менеджер будет вам звонить, причем несколько раз, если вдруг вы решили трубку не брать. Мы ни разу не видели ситуацию, когда клиент пишет в заявку “Пожалуйста не отключайте, скоро платежку пришлю”, а его отключают.

Исключения наверное есть, но это те, кто:

а) не прислал платежку;

б) пользуется этим “лайфхаком” с завидной регулярностью.

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

Берегите свои данные, не позволяйте хостерам их уничтожать!

Материал подготовлен дата-центром ITSOFT

Бурные события последних месяцев безусловно затронули интернет. Российские ресурсы подверглись атакам, интенсивность которых ни в какое сравнение не идет с предыдущими периодами. Нападению подвержены в первую очередь сайты органов власти, СМИ и банки. Например, на портал Госуслуг обрушились десятки кибератак мощностью 1 Тбайт/с, а количество всех атак давно перевалило за тысячу. РБК сообщает, что 7 марта в DDos-атаке было задействовано 3,5 млн устройств. Выбранный в качестве жертвы ресурс может быть атакован в течение целого рабочего дня, а одна из недавних атак длилась более 6 дней.

Ситуация обостряется еще и тем, что с российского рынка ушли и продолжают уходить иностранные компании, разрабатывающие корпоративные средства безопасности. Более того, меняется и характер атак. По оценке Лаборатории Касперского пользователи сталкиваются с “постоянным усложнением ландшафта угроз и расширением поверхности атак: злоумышленники используют разные тактики и техники, в том числе, комбинированные, и стремятся проникнуть в инфраструктуру компании-жертвы через разные точки входа”.

Не обходят вниманием хакеры и крупнейших регистраторов и держателей сервисов. В результате происходили падения сайтов множества компаний, которые казалось бы ни при чем, но их накрыло, как говорится “взрывной волной”. И в этой связи важно заметить, что об угрозе нападения на регистратора, являющимся также держателем DNS-серверов, мало кто задумывается – все привыкли, что DDoS’ят конкретный сайт, ну, на крайний случай хостера. Но чтобы атаковали серверы DNS? Звучит необычно.

Как бороться с этим явлением?

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

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

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

Правда есть и другие способы, которые возможно вам не очень понравятся, тем не менее упомянем их. Сайт Avito, например, не пускает к себе заграничный трафик. Это тоже метод борьбы, но на наш взгляд слишком радикальный. Особенно, если учитывать, что объемы использования VPN-сервисов в последнее время значительно выросли. Yota, например, сообщает, что с начала года количество пользователей VPN-сервисов увеличилось более, чем в 50 раз.

Менее радикальный способ — подключить защиту для вашего ресурса. На рынке есть как и Российские компании (DDoS-GUARD, Куратор), так и зарубежные. На практике, дешевле обходятся зарубежные, например, Cloudflare, однако, платить им нужно в долларах. Российские же защиты обойдутся раз в 10 дороже. Ценники, само собой, зависят от ваших объемов и требований.

Цена вопроса

Если вы решили обезопасить бизнес и зарезервировать DNS, то во сколько это обойдется? Есть провайдеры, которые предоставляют DNS бесплатно, но тут как обычно с любым бесплатным сервисом — повезет/не повезет. Можно заказать и платные услуги. Зарубежный сервис стоит $5-10 в месяц за несколько доменов. В России примерно та же вилка, приведем для справки наш тариф — от 300 рублей в месяц за домен.

Выводы

Очень кратко:

а) Посчитайте возможные материальные и имиджевые убытки, которые могут нести, допустим несколько часов простоя вашего сайта, связанные с атакой на DNS-серверы регистратора;

б) Если убытки превышают производственные или денежные затраты на резервирование DNS, то соответственно стоит позаботиться о резервировании;

в) Primary DNS выбирайте у известного российского провайдера, а Secondary — у заграничного, и желательно облачного.