Кейс: Как решить IT-задачу на секретном объекте без удаленного доступа

Падение SQL-серверов, виртуальных машин, отключение систем хранения данных – довольно частое явление, поэтому восстановлением работоспособности СУБД SQL Server, ProxMox, СХД после аварий нам приходится заниматься едва ли не каждый месяц. И задача это вполне стандартная, но только в том случае, если есть возможность выехать на место или подключиться к сети и ПК через интернет.

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

В советское время такие предприятия назывались «ящики», потому что производили они секретную (как правило, оборонную) продукцию, имели повышенный уровень безопасности, а вместо привычного адреса у них был номер почтового ящика (п/я №).

Секретный объект с особыми требованиями по безопасности

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

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

IT-отдел завода и нерешаемая проблема с СХД: SQL-серверы не стартуют, ProxMox не работает, инфраструктура стоит

Представьте себе – производственное госпредприятие, 1000+ сотрудников, серьезные проекты – серьезные обороты, несколько миллиардов в месяц. Продвинутое оборудование, современные технологии, весь процесс производства завязан на IT, соответственно, информационная инфраструктура масштабная и очень сложная. И вдруг – «лег» SQL-сервер, базы данных оказались недоступны. Производство встало, каждый час простоя – миллионные убытки, госзаказ под угрозой срыва.

IT-отдел предприятия в это время как раз проходит реорганизацию, на весь завод осталось всего два айтишника в штате. То ли компетенций, то ли ресурсов у сотрудников IT-отдела не хватило, но не справились.

Естественно, хватаются за голову, начинают искать помощь со стороны. Обзванивают профильные компании по всей России – везде отказ. Предприятие закрытое, повышенный уровень секретности, интернет по защищенным каналам, регламенты безопасности не позволяют предоставить удаленный доступ. Как решать проблему без удаленного подключения – непонятно.

Можно было на месте разобраться, что происходит с SQL-сервером и виртуальной средой ProxMox, однако объект не просто находится на расстоянии – на него физически вообще не попасть. Ну а лишних телодвижений никто делать не хочет.

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

Как решить IT-задачу на режимном объекте без удаленного доступа: ищем обходные пути

Проблематика: не стартуют серверы SQL (“умер” сетевой интерфейс), к базам не подключиться (сбой связи с Active Directory), не поднимаются службы, отсутствует управление. ИТ-инфраструктура встала, работа предприятия парализована. Ситуация усугубляется тем, что из-за регламентов безопасности удаленный доступ невозможен.

Задача: восстановить операционную деятельность предприятия, реанимировав SQL-сервер и базы данных. Для этого мы должны выполнить переустановку сетевой карты, перенастроить интерфейсы ProxMox, настроить IPMI (он не был настроен) для управления сервером.

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

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

Другого выхода нет – серверы надо «поднимать», ProxMox запускать, работу завода восстанавливать. Или объект будет просто стоять. И сложно представить, к каким последствиям приведет простой – материальные потери будут гигантскими, а руководству придется расплачиваться как минимум карьерой.

Как мы восстанавливали диски для виртуальных машин: восстановление и настройка ProxMox

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

Исходная информация

1. Виртуальные машины ProxMox запускались, но выдавали ошибку no bootable device (нет загрузочного устройства), то есть девайс не видел загрузочных дисков. Не хотели стартовать диски, на которых хранились эти виртуальные машины.
2. Разделы на двух машинах загадочным образом обнулились – судя по всему, заводские айтишники пытались самостоятельно восстановить работоспособность системы, но что-то пошло не так.
3. И в лучших традициях 99% наших заказчиков: бекапы удалены, никакой документации нет. Ее вообще почему-то никто в принципе не делает и не ведет – не доходит даже до описания того, что настроено, не говоря о хранении.

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

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

Первый этап – диагностика и поиск решения

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

• кластер из серверов “развалился”;
• RAID рассыпался;
• по сети подключиться невозможно;
• управление виртуалкой не получить;
• бекапы ProxMox отсутствуют.

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

Что было в наших силах, мы сделали:

• подключили к другой виртуалке;
• отсканировали данные на диске;
• вытащили базы.

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

Второй этап – восстановление баз

Договорились с заказчиком, чтобы нерабочие PDM-базы выгрузили нам. На своей инфраструктуре мы подготовили и развернули среду для тестирования. Сразу обратили внимание, что лог по какой-то причине был в десять раз больше самих БД. Это свидетельствовало о том, что план обслуживания был некорректно настроен – по всей видимости, обслуживанием баз никто не занимался – они просто росли и росли вместе с логами. Что уже свидетельствует о неправильном подходе.

Начались попытки восстановить PDM-базы (без этого этапа мы не могли приступить к следующему). Сами базы как сущность мы вытащить смогли, но их целостность была нарушена – часть после обработки запустилась, а часть нет. К сожалению, большинство данных восстановить не удалось. К восстановлению БД решено было подключить разработчиков программного обеспечения, которые лучше знают структуру и нюансы. Так что восстанавливать структуру баз данных помогали сотрудникам IT-отдела завода уже профильные специалисты по PDM.

Подводим итоги

Главную проблему мы решили, несмотря на отсутствие удаленного доступа из-за жесткой политики безопасности и неудобств, связанных с коммуникацией через видеосозвон. После нашего вмешательства SQL-сервер стартовал, ProxMox заработал, часть баз была реанимирована. Это позволило восстановить операционную деятельность предприятия.

В итоге полностью парализованный завод, на котором трудится 1000+ человек и где остановка производства влечет ущерб, исчисляемый миллионами рублей, заработал. Продолжал стоять только отдел проектировщиков, и то не весь – у них оставалась недоступной часть информации в базах – остановилась разработка и работа с технической документацией. То есть все производственные и технологические процессы возобновились, завод продолжал выпускать продукцию, выполнять план, но у него приостановилась проектная деятельность. Здесь мы уже помочь не могли, и восстановлением информации в БД проектного отдела занимались разработчики специализированного PDM-софта.

На технический аудит ушло два рабочих дня. Мероприятия по восстановлению функционирования SQL-сервера, виртуализации ProxMox, баз данных и в конечном счете всего предприятия заняли еще два рабочих дня.

Наша команда, задействованная в работе над этим кейсом, состояла из трех человек:

• специалист по базам данных;
• специалист по виртуализации;
• руководитель технической поддержки.

Предложения по повышению отказоустойчивости IT-инфраструктуры

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

1. Внедрить систему мониторинга.

2. Создать и настроить систему резервного копирования. Поскольку из-за политики безопасности хранить бекапы на облаке госпредприятию нельзя, мы предложили настроить резервное копирование на основании более подходящих комплексных решений – Veeam Backup & Replication или Acronis True Image.

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