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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оригинал статьи на нашем сайте.

#it #itтехнологии #безопасностьданных #itинфраструктура #сервер