13.10.2026

Облако тоже горит: как не потерять записи звонков, когда падает дата-центр.

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

Про такие истории принято говорить «форс-мажор». Но форс-мажор случается с площадкой, а последствия достаются тем, кто на ней работает. Одни компании переключаются за часы, другие неделями не могут ни звонить, ни поднять архив.
В мае 2024 года австралийский пенсионный фонд UniSuper почти на две недели остался без IT-систем: облачный провайдер по ошибке удалил его подписку целиком, вместе с копией во втором регионе. 647 тысяч клиентов не видели свои счета. Фонд спасла третья копия, которую его инженеры когда-то положили у совсем другого поставщика.

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

Главное

Облако физически стоит в конкретном здании. При пожаре или атаке данные без копии на другой площадке могут пропасть навсегда, как это случилось с корейским правительственным хранилищем G-Drive в 2025 году.
Резервная копия защищает, только если лежит в другом здании, у другого провайдера и не удаляется тем же доступом, что и основные данные.
Компании, которые взыскивают долги, обязаны по 230-ФЗ записывать каждый разговор с должником и хранить записи не менее трёх лет.
В нашем примере день простоя отдела на 10 000 звонков в месяц стоит около 91 тысячи рублей поступлений.

Что происходит с данными, если дата-центр физически уничтожен

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

Слово «облако» сбивает с толку. Кажется, что данные живут где-то в сети и им ничего не грозит. На деле у каждого облака есть адрес: здание, этаж, серверная, батареи бесперебойного питания. И если с этим зданием что-то случается, если что-то случается со зданием, вместе с ним страдают и данные.

Южная Корея, 2025 год. 26 сентября в дата-центре государственной службы NIRS в Тэджоне загорелись аккумуляторы в серверной на пятом этаже. Пострадали 96 критичных государственных систем. Почти у всех нашлись копии: их ежедневно делали на отдельном оборудовании и на удалённой площадке. Исключением стало облачное хранилище G-Drive, где с 2018 года обязаны были хранить рабочие файлы госслужащие. Из-за большого объёма внешней копии у него не было, и данные пропали безвозвратно. Сильнее всех пострадало ведомство, которое требовало хранить все документы только в G-Drive: его сотрудники собирали работу заново из локальных файлов, писем и распечаток.

Kakao, 2022 год. 15 октября пожар в батарейной комнате дата-центра SK C&C под Сеулом отключил 32 тысячи серверов. Мессенджер KakaoTalk, которым пользуется почти вся страна, платежи, такси и карты легли на срок до пяти дней. Сопредседатель правления компании ушёл в отставку, прямые потери Kakao оценила в 40 млрд вон. В том же здании стояли серверы Naver, но у этой компании часть мощностей работала в собственных дата-центрах, и серьёзных сбоев она не заметила.

OVHcloud, 2021 год. В ночь на 10 марта в Страсбурге полностью сгорело здание дата-центра одного из крупнейших хостингов Европы. Часть клиентов отдельно платила за резервное копирование, но копии лежали в том же здании и сгорели вместе с серверами. Французский суд взыскал с провайдера около 250 тысяч евро в пользу двух компаний и отметил, что все копии в одном месте не защищают данные вообще.
Во всех трёх случаях решало одно: была ли копия за пределами того здания, которое пострадало.

Почему резервная копия не всегда спасает данные

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

Пожар не единственный сценарий. Чаще копия формально существует, а в нужный момент оказывается бесполезной.

Code Spaces, 2014 год. Сервис для хранения кода обещал клиентам отработанный план восстановления. Злоумышленник получил доступ к панели управления облаком, потребовал выкуп, а когда команда попыталась вернуть контроль, начал удалять всё подряд. Копии управлялись из того же аккаунта и исчезли вместе с основными данными. Через 12 часов компания объявила о закрытии.

GitLab, 2017 год. Инженер поздно вечером перепутал сервер и стёр около 300 ГБ рабочей базы. Из пяти способов резервирования ни один не сработал как задумано: одни копии неделями молча не создавались, другие так и не были настроены. Спас снимок, сделанный вручную за шесть часов до аварии, а данные за эти шесть часов пропали.

СДЭК, 2024 год. После атаки с шифрованием данных компания около трёх суток не принимала и не выдавала посылки. Группировка, взявшая атаку на себя, утверждала, что копии делались раз в полгода. Компания это не подтверждала, но эксперты тогда напоминали, что у крупного бизнеса копии обновляются ежедневно, а восстановление из них занимает часы.

«Винлаб», 2025 год. В июле вымогатели атаковали Novabev Group, и около двух тысяч магазинов закрылись. Выкуп компания платить не стала, первые сто с небольшим магазинов заработали через восемь дней. Эксперт «Коммерсанта» связал долгое восстановление с тем, что плана на такой случай, по всей видимости, не было.

iiko, 2025 год. DDoS-атака на хостинг, где работали системы многих ресторанных сетей, несколько дней мешала принимать заказы. Атака на одного поставщика стала проблемой сразу для десятков бизнесов.

Требования 230-ФЗ к записи и хранению звонков

230-ФЗ обязывает тех, кто взыскивает просроченные долги, записывать каждый разговор с должником и хранить записи не менее трёх лет.

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

Подробнее, что требует закон:

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

В 2024 году ФССП уточнила, что звонок через мессенджер тоже считается телефонными переговорами, а значит, требования к записи распространяются и на него.

Зачем это нужно на практике. Когда должник жалуется, инспектор ФССП запрашивает записи, детализацию звонков и переписку. Запись оказывается единственным способом показать, что оператор говорил корректно и звонил в разрешённое время. Нарушения закона наказываются по статье 14.57 КоАП, а невыполнение требований инспектора может стать отдельным нарушением.

Есть и вторая сторона: записи звонков содержат персональные данные. С 30 мая 2025 года за их утечку действуют отдельные штрафы, от 3 до 5 млн рублей уже при утечке данных от тысячи до десяти тысяч человек, а за повторную утечку предусмотрен оборотный штраф до 3% выручки. Об утечке нужно сообщить в Роскомнадзор в течение 24 часов. Поэтому хранить записи нужно не только надёжно, но и безопасно.

Штрафы за потерю записей звонков: зарубежный опыт и российская практика

За рубежом регуляторы уже штрафовали финансовые компании за незаписанные, невыданные и утёкшие записи звонков. В России похожие ситуации подпадают под статью 14.57 КоАП и закон о персональных данных.

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

Запись остановилась, и никто не заметил. В январе 2014 года в одном из офисов Goldman Sachs после обновления безопасности оборудование для записи перезапустилось с ошибкой и около трёх недель не писало звук. Сбой обнаружили случайно, на выборочной проверке. Когда регулятор CFTC запросил записи за этот период по другому делу, значительную часть банк предоставить не смог и получил штраф в 1 млн долларов.

Как это выглядело бы у нас. Три недели разговоров с должниками без обязательной записи сами по себе нарушают 230-ФЗ. А на любую жалобу за этот период компании нечем ответить.

Записи были, но выдать их не смогли. Брокер Edward Jones в 2022 году заплатил 1,1 млн долларов по соглашению с регулятором FINRA. Несколько лет компания по десяти проверкам не предоставляла вовремя и полностью данные о звонках и ошибочно сообщала, что старые записи недоступны.

Как это выглядело бы у нас. Если компания не выдаёт записи по запросу ФССП, это может обернуться отдельным штрафом за невыполнение требований, такая практика есть. Но важнее другое: без записей спор с должником проигрывается по существу.

Записи утекли от подрядчика. В 2021 году вымогатели атаковали Debt-IN, коллекторское агентство крупнейших банков ЮАР. Утечку заметили только через пять месяцев, когда данные примерно 1,4 млн человек и записи разговоров с должниками всплыли на закрытых сайтах. Уведомлять клиентов и регулятора пришлось уже самим банкам.

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

Как хранить записи звонков: три схемы и сроки восстановления

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

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

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

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

Свои серверы и внешний поставщик. Часть системы работает снаружи, часть на собственном оборудовании. Архив остаётся под контролем компании, и на запрос ФССП можно ответить в любой день. Взамен нужны свои специалисты и защита: свои серверы тоже атакуют, и резерв в общей внутренней сети шифровальщик заденет вместе со всем остальным. Получится ли звонить в аварию, зависит от того, что именно стоит внутри: только архив или запись тоже.

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

Что выбрать.

Небольшой компании хватит одного поставщика, если рядом есть независимая копия архива: у другого провайдера или у себя. Звонки в день аварии это не спасёт, зато архив и ответы ФССП будут в безопасности, и обходится это заметно дешевле второго полноценного поставщика.
Средней компании с постоянным потоком звонков стоит смотреть на два облачных поставщика с копиями у обоих или на одного поставщика плюс собственный архив.
Крупной компании, особенно с агентскими портфелями и обязательствами перед банками, разумно держать гибрид или двух поставщиков и регулярно проверять переключение.

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

Как защитить записи звонков: восемь шагов

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

1. Опишите, где лежат данные. Записи звонков, сообщения, звонки из мессенджеров, результаты аналитики: в телефонии, CRM, архиве, у подрядчиков. За каждое место должен отвечать конкретный человек.
2. Держите записи минимум в двух независимых местах. Разные здания, лучше разные провайдеры и разные учётные записи.
3. Разведите доступы. Основное хранилище и резерв не должны удаляться одним паролем, а в резерв лучше разрешить только добавлять записи.
4. Каждый день сверяйте счётчики. Сколько звонков прошло через телефонию и сколько записей легло в архив. Расхождение покажет сбой записи в тот же день, а не через три недели.
5. Раз в квартал проверяйте восстановление. Найдите и прослушайте несколько случайных записей за прошлые годы, засеките, сколько займёт собрать пакет для ФССП.
6. Пропишите хранение в договорах. Где лежат данные, сколько копий, как быстро подрядчик всё выдаст при аварии и при расторжении, как подтверждает удаление.
7. Не держите у подрядчиков лишнего. Если записи нужны поставщику только для обработки, пусть он удаляет их сразу после неё.
8. Напишите план на день аварии. Кто решает, куда переключаемся, как отвечаем ФССП. И храните план там, куда авария не дотянется, хотя бы на бумаге.

Какие вопросы задать поставщику записи и аналитики звонков

Задайте их до подписания договора и попросите ответить письменно.

Где и в скольких местах хранятся наши записи и результаты анализа?
Можно ли одним доступом удалить всё, включая резерв?
Как быстро вы отдадите наши данные, если откажет ваш собственный провайдер?
Когда удаляются записи после обработки и как вы это подтверждаете?
Как мы узнаем, что загрузка или обработка звонков перестала работать?

Как KlevelCC работает с записями звонков

Мы анализируем записи звонков, но не храним их. Вот как это устроено.

Обезличенные результаты анализа хранятся параллельно в двух независимых хранилищах. Если одно становится недоступным, система продолжает работать со вторым.
Распознавание и обезличивание разговоров проходят в России.
Мы не храним персональные данные и не являемся их оператором. Записи звонков удаляются сразу после анализа, у клиента остаются только обезличенные результаты.

Если хотите проверить нас по пяти вопросам выше, задайте их нам, ответим письменно. А посмотреть, как речевая аналитика KlevelCC разбирает звонки, можно на бесплатном тесте на 100 звонках.

Вывод

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