Система

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

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

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

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

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

1. Создание графиков и маршрутов обходов.

2. Контроль своевременного обхода маршрутов сотрудниками.

3. Учет действий сотрудников при прохождении маршрутов.

4. Возможность получать фото- и текстовые уведомления с контрольных точек.

5. Удобство для обходчика: возможность фиксировать все с помощью телефона (планшета), никаких журналов.

6. Хранение отчетов в системе на протяжении всего времени.

Формирование системы обхода маршрутов

Сперва нужно было доработать нашу существующую систему. Исходя из составленного плана было решено разработать специальное приложение под Android (TARGControl Patrol) и новый модуль для нашей облачной системы, который мы назвали просто Маршруты.

Для WEB сразу написали возможность добавления точек обхода и формирования из них маршрутов (первоначально это были только RFID-метки), чтобы изучить возможность сканирования меток на устройствах с помощью NFC-считывателя. Параллельно велась работа и над APP (приложение писали на Java/Kotlin), с помощью которого мы собственно и считывали метки.

После первых успешных тестов мы начали допиливать функционал WEB. Сразу же для визуализации маршрутов был создан раздел Отчеты, где можно было просмотреть время прохождения маршрута и точек, после чего добавили в систему раздел Расписания маршрутов для тестирования возможностей прохождения маршрутов по заданному графику (дням и времени).

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

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

Итого на WEB были сформированы следующие разделы модуля Маршруты:

1. Отчет (глобальный отчет по маршрутам).

2. Отчет по точке (отчет по конкретной точке за заданный интервал времени).

3. Отчет по параметрам (отчет по показателям оборудования, снятыми соответствующим персоналом).

4. Контрольные метки (в данном разделе создаются (QR) или вносятся существующие (RFID) контрольные метки).

5. Маршруты (создание маршрутов с помощью внесенных в систему меток).

6. Расписание маршрутов.

7. Графические планы.

Во время разработки приложения TARGControl Patrol было решено добавить возможность не только считывания меток маршрутов, но также регистрации и замен этих же меток, что дало бы возможность вносить данные автоматически, не вбивая RFID-коды руками в систему. Дублировать отчеты по маршрутам, точкам и параметрам в приложение не стали, ибо для большинства обходчиков этот функционал не нужен.

Итого функционал приложения позволяет:

1. Авторизация в приложении с помощи карты или личного PIN-кода.

2. Просмотр маршрутов и их контрольных точек.

3. Просмотр расписания маршрутов.

4. Процесс прохождения маршрутов по контрольным точкам и просмотр прогресса.

5. Возможность оставлять у каждой контрольной точки текстовую и фотоинформацию. Можно просто сфотографировать показатели или оставить дополнительную информацию, если на объекте, например, произошло ЧП.

6. Регистрация меток.

7. Замена этих же меток.

Настройка системы маршрутов обхода для производства

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

1. RFID-метки, которые будут использоваться как контрольные точки маршрута (возможны QR-метки).

2. Приложение TARGControl Patrol.

3. Смартфон (или планшет) на операционной системе Android.

4. Система учета рабочего времени (УРВ) TARGControl Cloud

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

В качестве контрольных точек были взяты RFID-метки следующего вида.

Данные метки хороши тем, что подходят для помещений с тяжелыми условиями работают при температуре от -20 до 200 C, что соответствовало запросам предприятия.

Подробнее остановимся на создании самих маршрутов в системе TARGControl Cloud. Компания, для которой разработали приложение и доработали облачное ПО, использовало нашу систему УРВ и активно пользовалась ей, поэтому весь список необходимых сотрудников был внесен и все учетки, необходимые для входа в приложение, были созданы. Осталось дело за малым настроить сам модуль Маршруты.

В системе создаем группу меток (для удобства), после чего вносим туда сами метки, в нашем случае это RFID.

При создании метки вбиваем имя, выбираем тип метки, вносим сам код (как писал выше, можно выполнить данную операцию и с помощью приложения) и создаем нужные строки для снятия показаний. Готово, выполним операцию еще n-ое количество раз, пока не внесем все нужные метки.

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

Остается лишь создать расписание: указать дату/время обходов, выбрать необходимых сотрудников, которые будут осуществлять обход по заданному маршруту и проставить галочку напротив поля Учитывать порядок обхода, чтобы считывание меток осуществлялось в заданном заранее порядке. Существует возможность и дополнительных настроек расписания, таких как Учитывать время начала и Учитывать время окончания, благодаря чему сотрудники, проходящие маршрут, должны будут начать и закончить маршрут только в определенно установленное время (с допустимым интервалом). На этом настройки закончены, можно приступить к самому принципу работы.

Как происходит процесс обхода?

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

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

2. Зайдя под своим именем, сотрудник выбирает маршрут, на котором будет осуществлен обход. Выбрав нужный маршрут, сотрудник отправляется в путь.

3. Подойдя к первой точке маршрута, сотрудник подносит телефон (планшет) к метке, после чего приложение просканирует ее и предложит ввести определенные параметры оборудования, которые мы заранее указали в облаке TARGControl Cloud (описано выше). Существует возможность прикрепить фотографию. Все данные сразу же прилетают в систему.

4. Далее обходчик просто направляется к следующей точке маршрута и повторяет операцию. На маршруте могут комбинироваться типы меток. Например, точка 1, 2 и 3 RFID-метки, а точка 4 QR.

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

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

Итог

После внедрения решения маршрутов обхода, на предприятии отпала необходимость вести бумажные журналы на предприятии и все отчеты по маршрутам были размещены в облачной системе УРВ TARGControl (с возможностью экспорта в Excel). Все показатели оборудования стали фиксироваться в режиме реального времени, что позволило оперативно устранять неисправности.

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

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

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

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

Рассмотрим поставленные перед нами идеи внимательнее и ответим на них. Для этого будем использовать только то, что автор сам сообщил нам.

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

Сперва закроем вопрос о курсах. Они действительно не дают по настоящему фундаментальных знаний в информатике. Курсы заточены по быстрому переквалифицировать человека из другой профессии на решение типичных бизнес проблем в IT, таких как переливание json-ов между сервисами и базой, и прочую знакомую нам рутину. И свою задачу курсы решают целиком.
Судите сами, может ли неудавшийся менеджер Коля, прошедший полгода курсов, запилить очередной CRUD? С ревью техлида? С четко поставленным техническим заданием?
Ответ: безусловно да, может. А большего от него и не требуется. Если же Коля, наловчившись на решениях таких задач, разовьет свои навыки, то бизнес получает даром выращенного под нужные условия специалиста с лояльностью к компании. Одни плюсы!
При этом курсы, как бы мы не смеялись с примитивности подхода, освобождают сильных специалистов для по настоящему интересных задач, оставляя скучные вещи новичкам.

С этим разобрались, что дальше насчет возмущения автора о лычках?

Cбербанк. Да, этот мастодонт принял несколько таких специалистов к себе в штат на должности разработчиков. И не абы каких, а самых настоящих старших инженеров.
. . .

МТС Банк. Данная организация предложила по результатам собеседования должность Senior разработчика ещё одному соискателю.
. . .
Senior разработчик, это человек, который может управлять другими людьми и принимать решения. Вы с ума сошли?

Давно пора понять, особенно тем кто заявляет о себе, что давно работает в IT, что само собеседование не больше чем сделка на рынке труда. Здесь нет ни четких планок как в закрытой ремесленной гильдии, ни испытаний как в секте асасинов. И это просто отлично!
Все решает умение кандидата продать свои навыки работодателю по самой выгодной цене, и желание работодателя купить подходящего разработчика повыгоднее. А дальше в действие вступают законы рынка о спросе и предложении. Как правило, поскольку 99% типовых задач это вышеупомянутый CRUD, люди после курсов с умением их писать, подходят здесь точно так-же как отучившийся в вузе пять лет и отслуживший в армии один год, по всем понятиям "правильный" специалист.
В реальности не существует фиксированных должностей сеньоров, мидлов, джунов, старших, младших и т. д. Это всего лишь шкала зарплаты, которая в разных компаниях отличается. Ни для кого не секрет, что уйдя мидлом из одной компании можно сразу же устроиться сеньором в другую, и наоборот, что некоторые компании желая сэкономить ищут по всем требованиям сеньора, но на должность мидла. А где-то всех этих детсадовских лычек вообще нет.

Но тогда чего же на самом деле боится автор? А боится он именно ...конкуренции!

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

Среднестатистический выпускник ВУЗа (рассматриваем только тех кто реально учился) идёт на зарплату в 40-80к в надежде почерпнуть хоть маломальский опыт работы для дальнейшего роста, понимая что больше он не стоит. Зато самозванец на полном серьёзе претендует на место старшего инженера.

Встает логичный вопрос, если автор действительно высококлассный инженер, то как ему могут угрожать js-формошлепы и писатели CRUD-ов? Если он после своего великолепного технического образования конкурирует наравне с ними, то может быть дело все-таки именно самом в авторе, а не в некоей "системе", о которой он упоминает нам в публикации и комментариях?
А во вторых, действительно ли нужно фундаментальное техническое образование чтобы писать CRUD? Высшее образование нужно тем кто занимается наукой, серьезными расчетами, аналитикой, чтобы потом как раз ставить задачи программистам. Если автор получил высшее образование чтобы писать формочки на .NET, и теперь жалуется на конкуренцию, то при всей моей любви к .NET автор сделал не самый умный выбор и может винить только себя.

их пичкают информацией о том, как обмануть систему с непоколебимым видом.

. . .
самозванец на полном серьёзе претендует на место старшего инженера

"А что, так можно было?" Здесь автор что-то начинает понимать насчет рынка, но вместо правильных выводов включается зависть и желание "расставить всех по местам".

Почему кто-то решил, что быть программистом проще пареной репы
. . .

Тем, кто принимает решения об оффере, внимательно смотреть на опыт работы и реальные навыки, образование наконец.

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

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

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

А на рынке труда, в частных компаниях, никакой "системы" нет. Есть конкуренция и возможность добровольно выбирать где и с кем ты хочешь работать. На чьей вы стороне решать только вам. Удачного дня!

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

Все началось с того, что сервер статистики контактного центра заказчика (на тот момент ещё потенциального) сбросил все пользовательские сессии и перестал отвечать на запросы. Соответственно к нему подкатили тележку с монитором и перезагрузили. Это обычно надо делать раз в 90 дней по инструкции от вендора, но тут это не делалось больше 500 дней. В общем, сервер отметил юбилей аптайма.

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

Но после накатывания бэкапа система просто легла.

В этот момент нас позвали отмечать день рождения сервера. Без него не работала балансировка нагрузки на операторов внутри КЦ.

Что это была за система?

Система Avaya Call Management System (CMS). Это кусок колл-центра, который собирает статистику по звонкам, операторам, нагрузке исторические и реал-тайм данные. На этом же сервере каждое утро собираются отчёты о работе. В реальном времени сервер говорит, какие операторы сейчас в каких статусах находятся, какие звонки обрабатываются, сколько звонков висит в очереди. В целом система нужна, чтобы следить за группами операторов, за колл-центром, чтобы правильно распределять нагрузку, потому что можно переносить операторов из ненагруженных линий в нагруженные и так далее. Обычно там просто сидят супервизоры и следят за всем происходящим. Прямых аналогов нет, обычно используются самописные решения или же всё вообще делается вручную. Аваевскую систему выбирают за надёжность и многофункциональность.

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

Сбои со статистикой ведут к тому, что маркетологи не знают, как идут рекламные кампании, и это означает, что они сидят в неизвестности.

Первый день пятница

Ситуация абсолютно обычная. У кого-то что-то упало, нам никто деталей не сказал, но надо срочно. Это норма во всех странах, детали появляются потом, когда есть время их искать и рассказывать. На тот момент предполагалось, что мы, может быть, что-то придумаем и мгновенно спасём контакт-центр.

Приезжаем на место (напомню, что сервер лёг и удалённого доступа нет), подключаемся с монитором и клавиатурой, ещё раз смотрим, как система не стартует.

Я подключился не сразу. Когда подключился увидел, что диск переполнился ошибками из-за проблем бэкапа. Некоторые сервисы не стартовали почистили логи, стартовали руками.

У нас условно есть три части системы: железный сервер, который входит в ПАК, поставляемый сразу с софтом в виде чёрного ящика от вендора, CMS и база данных. Бэкапы CMS (конфигураций) и базы делаются в разные места.

ОК, система запустилась, но только база пустая данных никаких нет.

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

Итак, у нас на руках железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базjq Informix от IBM + пакет CMS от вендора. Решение продаётся как программно-аппаратный комплекс, то есть всё там как поставил вендор, так никто и не трогал.

Бэкапы БД делались. Итерации были по 180 дней, бэкапирование настроено в планировщике системы. Логи бэкапов никто особо не читал, консистентность не проверяли, назад до этого юбилея сервака накатывать не пытались.

Складировались бэкапы прямо на этот же сервер.

То есть сначала уронили рестартом систему, ребутнули с тележки и поставили бэкап системы CMS, который уронил окончательно железный сервак. Мы починили сервак, но там не было вообще никаких полезных данных. Предстояли интересные выходные.

Дальнейшее исследование

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

К утру мы всё ещё думали, что справимся быстро (в КЦ уже начались проблемы). Решили не трогать бренную земную оболочку сервера, а сразу снять с него образ и развернуть на виртуалке. Это стандартная процедура и для форензики, и для восстановления чего-то, где может посыпаться дальше диск, и вообще очень удобно в конечном итоге в плане не навреди ещё.

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

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

Откатили виртуалку из снапшота на начальное состояние (до бэкапа системы) и пробуем использовать только бэкап базы. Он восстанавливается удачно, но там нет данных.

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

В лаборатории

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

Сразу стало понятно, что свежий бэкап неконсистентен и вообще похож на записанный прямо из /dev/random. То есть последний месяц (который не бэкапился) пропал просто в силу того, что его никто никуда не резервировал. Следующие полгода пропали из-за битого бэкапа. И только в следующей итерации нашлись таблицы, где были реальные данные. То есть минус семь месяцев от момента аварии, и, как позже выяснилось, целых данных там было не очень много, не больше года, а часто по некоторым показателям и меньше.

Вручную с таблицы перенесли данные в базу данных и скормили всё это нашей виртуалке.

То есть в итоге оставили систему в рабочем режиме со старыми данными, руками настраиваем всё то, что не удалось восстановить из бэкапа системы (пользовательские учётки, коннекторы к другим системам, скрипты).

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

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

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

Выводы

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

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

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