11 октября сбои затронули сразу несколько сервисов «Яндекса» после проблем с инфраструктурой дата-центров компании. На этом фоне Abn.Agency спросило экспертов, насколько бизнес уязвим при отказе крупной цифровой платформы, какие процессы оказываются под риском и что компании могут сделать, чтобы продолжить работу при длительном простое.
Дмитрий Гачко, основатель корпорации ITG и технопарка «ИТ ПАРК РУС», считает, что в первую очередь при деградации сервисов страдают платежи и логистика, а наиболее уязвимыми оказываются компании, сосредоточившие IT-инфраструктуру у одного провайдера.
«В дальнейшем для минимизации рисков бизнесу жизненно необходимы регулярные бэкапы и диверсификация используемых сервисов», — отметил Гачко.
По его мнению, концентрация рынка вокруг крупных цифровых платформ сама по себе создает дополнительную уязвимость.
«Фаза консолидации и концентрации рынка вокруг таких гигантов, как Яндекс, а также Wildberries и Ozon, является частью цикла и сопряжена с рисками уязвимости. Очевидно, что теперь начнется фаза децентрализации», — заявил он.
Михаил Зайцев, ведущий системный инженер онлайн-школы «ИнтернетУрок» (ООО «Интерда»), эксперт по автоматизации IT-инфраструктуры и бизнес-процессов, также считает малый бизнес наиболее зависимым от крупных поставщиков. Такие сервисы позволяют предпринимателям передать на сторону сложные процессы и не создавать собственную инфраструктуру.
При отсутствии резервных каналов потери крупных компаний, по его оценке, могут быть существенными, считает эксперт.
«Если брать крупных ритейлеров, которые завязаны на такие сервисы и не имеют резервного канала, потери могут исчисляться миллионами рублей в час, а может быть, даже десятками миллионов рублей в час. Но это при условии, что нет резервного канала для этих транзакций», — отметил Зайцев.
При этом он считает, что малому бизнесу содержать полноценный резерв зачастую экономически невыгодно. Для компаний с собственной IT-инфраструктурой выходом может стать ее устройство таким образом, чтобы при аварии быстро перенести сервисы к другому провайдеру. В качестве примера зависимости от внешней платформы он привел «Консоль.Про», где, по его словам, в текущей ситуации остановились выплаты самозанятым, а сама платформа сообщила о переезде в новую облачную инфраструктуру.
Павел Кондратьев, генеральный директор сервиса IP-телефонии «Плюсофон», отметил, что крупные поставщики привлекательны для бизнеса именно объединением нескольких функций в одной инфраструктуре.
«Крупный поставщик создаёт не отдельные сервисы, а строит целую связанную инфраструктуру, которая включает в себя: приём платежей, логистику, карты и разные облачные сервисы. Такая инфраструктура создаёт удобство для работы бизнеса. Но в такой централизации кроется риск, с последствиями которого сегодня столкнулись многие представители МСБ», — отметил Кондратьев.
Для снижения зависимости он советует держать альтернативные каналы хотя бы для ключевых функций.
«Даже если основной канал один, важно иметь альтернативу: второй эквайринг, вторую служба доставки, второй номер телефона. На них можно перекидывать небольшое количество оплат и заказов, чтобы просто держать в запасе. А в случае необходимости оперативно перебрасывать на них основные мощности», — рассказал он.
Константин Лучников, юрист, партнер адвокатского бюро «Этлегис», считает, что при оценке рисков важнее смотреть не на количество подключенных сервисов, а на то, действительно ли они независимы друг от друга.
«Главная уязвимость бизнеса возникает, когда прием заказа, оплата, доставка и связь с клиентом зависят от одного поставщика. Четыре разных приложения внутри одной инфраструктуры могут отказать одновременно. Поэтому резерв нужно оценивать по зависимости, а не по количеству установленных сервисов», — отметил Лучников.
Он также обращает внимание на договорную сторону сбоев.
«Технический сбой не дает универсального освобождения от договорной ответственности. По статье 401 ГК РФ требуется оценить обстоятельства и условия обязательства. В предпринимательских отношениях нарушения контрагентов и отсутствие денег не относятся к безусловным основаниям освобождения», — заявил юрист.
Во время инцидента, по его словам, компаниям важно сохранять сообщения о недоступности, обращения в поддержку, данные о сорванных операциях и документы о дополнительных расходах. Для подготовки к сбоям Лучников предлагает заранее определить критические операции, допустимое время их остановки, независимый резерв и сотрудников, отвечающих за переключение.
Юлия Бузыкова, доцент кафедры информационных технологий факультета информационных технологий и анализа больших данных Финансового университета при Правительстве РФ, выделяет три группы процессов, наиболее чувствительных к зависимости от одного поставщика: транзакционные операции, клиентские коммуникации и инфраструктурный слой.
«Если компания построила все три слоя внутри одной экосистемы, она получает классическую единую точку отказа — ситуацию, когда инцидент у вендора останавливает бизнес целиком, а не отдельную функцию», — отметила Бузыкова.
По ее мнению, резервный поставщик особенно важен для функций, напрямую связанных с выручкой.
«Малой компании не требуется собственная дорогая инфраструктура. Доступные меры: регулярное резервное копирование критичных данных в независимое хранилище, второй платёжный агрегатор даже с нулевым оборотом, письменный регламент действий персонала при сбое, локальные копии ключевой клиентской базы и прайсов. Это вопрос организационной гигиены, а не капитальных затрат», — заявила она.
Дмитрий Лившин, генеральный директор «Сайбер Бизнес Консалтинг», также относит к наиболее чувствительным функциям платежи, доставку, облачную инфраструктуру, рекламу и аналитику. По его словам, риск усиливается, когда несколько таких инструментов компания получает у одного поставщика.
«Резерв нужен обязательно, но дублировать все подряд дорого и бессмысленно. Приоритет нужно расставлять по критичности с точки зрения выручки. В первую очередь я рекомендую резервировать прием платежей, нужен запасной вариант эквайринга или платежный провайдер, обеспечивающий переключение за считанные минуты», — рассказал Лившин.
Он считает, что значительную часть рисков можно снизить организационными мерами.
«Большинство мер требуют не дополнительной траты денег, а грамотной организации работы. Начать нужно с простого, составить карту зависимостей и ответить, от каких внешних сервисов непосредственно зависит ваша выручка», — отметил он.
Анатолий Баранов, член Центрального Совета независимого профсоюза «Новый Труд», считает, что перенос российских сайтов и сервисов на зарубежные серверные площадки технически возможен, однако такой вариант требует дополнительных расходов и несет собственные риски.
«Для России переход на серверные площадки соседних стран закрыт, если говорить о Европе. Но при наличии дополнительных затрат перенести сайты и сервисы российской компании на иностранные площадки вполне реально. Главное решить вопрос оплаты, допустим, через банки стран СНГ. Однако важно понимать, что этот канал нестабилен из-за санкционных рисков», — отметил Баранов.
Он также напомнил о прежних сбоях российских дата-центров, после которых, по его словам, менялись требования к их работе.
«На память приходит форс-мажор несколько лет назад, когда отечественные дата-центры в Москве из-за аномальной жары не смогли обеспечить достаточного охлаждения и сервисы встали. Тогда выводы сделали, требования к помещениям дата-центров изменились. Сейчас возникла другая угроза», — заявил он.
При этом для обычного пользователя возможностей самостоятельно повлиять на ситуацию практически нет, считает Баранов.
«Рядовой пользователь тут объективно ничего поделать не может. Только ждать, когда Яндекс сам решит свои проблемы — вероятно, при помощи государства. Там подвязаны и многие государственные службы», — сказал он.
Собеседники издания сходятся в том, что полный отказ от крупных платформ для большинства компаний не является обязательным условием устойчивости. Основная задача — определить критические зависимости, заранее подготовить независимые каналы для ключевых операций, регулярно сохранять данные и обеспечить понятный порядок переключения сотрудников при длительном сбое.
