Как регулярный бэкап позволил сэкономить 120 млн. ₽

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

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

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

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

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

Сумма потенциального ущерба — 120 млн рублей.

В Kotelov мы делаем бэкап и бэкапа на этот бэкап, чтобы 100% сохранить данные клиенты. Никто не защищен от человеческого фактора — ошибаются любые профи.

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

Рассказывайте, были ли у вас тупые ошибки, которые если бы не бэкап — принесли бы чудовищные последствия.

Недавно к нам обратился клиент, у которого потенциально 2 млн пользователей и ему нужно разработать стриминговый сервис, где 10К-20К пользователей могут смотреть медиа-контент в разрешении 4К онлайн.

Фильм 4К весит 5 гб, если 10К пользователей одновременно его смотрят, то это большая нагрузка на хранилище данных. Сложность в том, чтобы сбалансировать трафик на сервис, чтобы система не перегружалась, а пользователи не испытывали дискомфорта.

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

Для хранения контента на 2 млн человек, потребуется от 300-400 ТБ устойчивого хранилища. Нужно построить системы хранения данных.

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

Когда 10 тыс. человек запрашивают одно видео или хотя бы два-три видео, это легко решается кешированием. А если эти 10 тыс. смотрит разный контент, то стандартная СХД не справится. Скорость не позволит находить это на жестких дисках.

В реализации нужно:

— Построить архитектуру хранения и обслуживания клиентов СХД с высоким уровнем IOPS — количество запросов, которые приходят к системе хранения данных за секунду. Чем ровнее запросы из разных секторов жестких дисков, тем сложнее и дольше приходится обрабатывать их сервера.

— Построить балансировщики, которые обрабатывают большое количество разного контента на обычных HDD дисках и отказоустойчивых хранилищах.

В новом подкасте Kotelov digital finance Александр Волков (возглавляет разработку API в Тинькофф Инвестициях) рассказал, как устроена работа в компании, с какими сложностями сталкивается крупный брокер в IT и каковы особенности API в современной торговле.

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

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