Владимир Маракшин, «Киберпротект»: Наличие актуального плана аварийного восстановления — показатель устойчивости бизнеса

Пока система обслуживает десятки пользователей, архитектура кажется надёжной. Но с ростом нагрузки внезапно выясняется, что решения, которые отлично работали на этапе пилота, становятся источником проблем. Где проходит граница между успешным тестом и реальной эксплуатацией, какие ошибки мешают масштабированию и как подготовить инфраструктуру к росту — обсудили с Владимиром Маракшиным, директором департамента стратегического развития «Киберпротекта».

Рынок уже прошёл этап импортозамещения, и сегодня главный вопрос — как обеспечить управляемость и согласованную работу всей ИТ-инфраструктуры в крупных компаниях? В них ведь всё сложнее.

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

А в какой момент происходит этот переход? Как понять бизнесу, что ему пора об этом задуматься?

В.М.: Было бы проще, если бы существовала чёткая граница: вот этот критерий выполнили, и сразу понятно, что пора менять подход. Но на практике всё не так однозначно.

Здесь важны два фактора: влияние ИТ на бизнес и масштаб компании. Если в штате один-два ИТ-специалиста, а сама инфраструктура не критична для непрерывности бизнеса, то можно позволить себе эксперименты: самостоятельно разбираться, тестировать решения, пробовать новые продукты. Для айтишников это, в общем-то, естественная история.

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

Что происходит, если она не заметила этот момент?

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

Хорошо, клюнул жареный петух. Что делать тогда в такой ситуации?

В.М.: Если говорить глобально, то в первую очередь стоит посмотреть, кто вообще обслуживает ИТ-ландшафт и как выстроены процессы эксплуатации, есть ли проектное управление, есть ли люди, отвечающие за непрерывность бизнеса. По сути, важно понять, от чего бизнес действительно зависит.

Нужно определить, какие ИТ-системы и бизнес-решения составляют фундамент, на котором всё держится. Например, если основным каналом взаимодействия с клиентом является мобильное приложение, то многое зависит от того, какую долю бизнеса оно уже занимает. Пока через приложение проходит условные 10 % взаимодействия с клиентами, а потеря этой доли не критична, серьёзных рисков может и не быть.

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

Владимир, обычно же говорят: «Наше решение совместимо…». Что-то недоговаривают?

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

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

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

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

И здесь возникает вопрос. Да, система резервного копирования совместима с вендором оборудования А и совместима с платформой виртуализации Б. Но будут ли все эти решения одинаково хорошо работать вместе в одной инфраструктуре? И это нужно проверять отдельно: имплементировать, тестировать, смотреть рекомендуемые настройки и, возможно, делать какие-то доработки.

Правильно ли я понимаю, что основная проблема на самом деле не на этапе внедрения, а на этапе закупки происходит?

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

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

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

Получается, что клиент остаётся один на один со своим внедрением.

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

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

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

Сегодня была на пленарной сессии главного зала ЦИПР, где ты тоже выступал. Говорили про риски, совместимость ИТ и ИБ. Что интересного там было? К чему пришло комьюнити в этом вопросе?

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

Я так понимаю, «Киберпротект» придерживается второго сценария?

В.М.: Совсем остановиться и перестать развиваться тоже можно, конечно. Но это уже никому не нужно. Поэтому здесь скорее нужно балансировать.

Это тоже так называемое внедрение? А если говорить о внедрении в целом, что в этом процессе обычно недооценивают? На что действительно стоит обратить внимание?

В.М.: Если связать это с предыдущей темой, то раньше часто недооценивали информационную безопасность. Подразделения ИБ в компаниях не всегда могли чётко сформулировать, какие именно требования предъявлять к продуктам с точки зрения защиты и безопасности.

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

Что обычно недооценивают? Продукт могут хорошо протестировать, провести пилот, посмотреть, как он работает в минимальном объёме — там, где с ним удобно работать и где всё можно сделать относительно недорого. Но когда начинается масштабная миграция, в какой-то момент возникает точка перегиба: решение просто перестаёт справляться. Оказывается, что архитектура к таким нагрузкам или масштабам изначально не была готова.

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

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

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

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

ЦИПР — это место, где можно напрямую пообщаться и с заказчиками, и с конкурентами. Вы здесь уже второй день. С какими запросами или вопросами к вам чаще всего подходят на стенде?

В.М.: Как ни странно, многие приходят даже не по теме бэкапа, а по нашему продукту — киберхранилищу. Многие хотят его пилотировать, задают технические вопросы. Интерес есть и со стороны партнёров, и со стороны заказчиков.

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

Много вопросов связано с интеграцией и с информационной безопасностью, и с SIEM-системами, и с интеграцией в operations-центр. Например, был интересный запрос по API-интерфейсам. Клиенты хотят интегрировать систему резервного копирования не просто в свои процессы, а в собственные порталы самообслуживания. Чтобы из единой точки можно было запускать резервное копирование или восстановление данных. Это позволяет не отвлекать инженеров и при этом делать всё максимально быстро.

Заказчики, которые об этом задумываются, характеризуют свой бизнес как устойчивый. Что вообще в вашем понимании устойчивый бизнес?

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

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

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

В.М.: Как и в любом проекте, всё начинается с анализа. Нужно посмотреть на инфраструктуру, понять, что именно мы собираемся защищать.

Я бы даже разделил это на две картинки. Первая — как есть сейчас: какой у нас ландшафт, какие требования предъявляются к непрерывности, отказоустойчивости, времени восстановления.

Вторая — как будет дальше, с учётом роста. Потому что масштабирование — это всегда про рост, причём довольно быстрый. И если о нём заранее не подумать, внедрение может пройти нормально, первый год тоже всё будет работать. А потом начинается рост и выясняется, что архитектура к нему не готова. И тут уже не всё можно закрыть дополнительными мощностями или лицензиями. В какой-то момент может оказаться, что нужно переделывать значительную часть решения — 90 %.

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

Это когда больно?

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

Каким сферам больнее? По профилю организации?

В.М.: Наверное, можно назвать это диджитализированными компаниями. То есть если у компании — в B2C, B2B или даже в госсекторе — есть плотный контакт через ИТ-системы и они глубоко встроены в бизнес-процессы, то любой простой даётся им особенно тяжело.

Финтех — это один из наших ключевых сегментов, с которым мы сейчас активно работаем. Потому что для них даже минутный, а тем более часовой простой — это уже серьёзная проблема. Они в первую очередь и выстраивают инфраструктуру вокруг отказоустойчивости и доступности 24/7, буквально без перерывов.

ЦИПР традиционно собирает государство, бизнес, вендоров. Все хвалятся, говорят о своих достижениях. Давайте без скромности: что у вас?

В.М.: В этом году мы отмечаем 10 лет — для компании это важная веха. За это время мы прошли путь от небольшого вендора до достаточно крупного игрока с серьёзными внедрениями, заказчиками и в бизнес-сегменте, и в госсекторе.

Сильно вырос и продуктовый портфель. Если начинали мы с одного-двух решений, то сейчас закрываем и B2C-, и B2B-сегменты, работаем с операторами связи, расширяемся за пределы только защиты и хранения данных — в сторону гиперконвергентных инфраструктур.

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

Каких?

В.М.: Больше хороших продуктов, разных направлений и постоянное развитие уже существующих решений.

Владимир, мы на ЦИПР, и здесь можно министра встретить буквально проходящим рядом. И если бы у вас была возможность, любому министру, любому руководителю или даже ведомству адресовать какой-то один вопрос или просьбу. Что бы это было?

В.М.: Я бы, наверное, сказал, что ИТ-компании знают достаточно много про построение ИТ-ландшафта. И хорошо было бы иметь ещё больше диалога. Диалог есть, но его не бывает мало.

А с какими конкретно ведомствами?

В.М.: С цифровыми ведомствами, Минцифры — по линии информационной безопасности.

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

Владимир, спасибо большое за интересную беседу. Удачи вам по всем направлениям!