30 октября 2020

Без бэкапа по жизни

    Накануне первоапрельского праздника дураков все прогрессивное человечество празднует Международный день бэкапа (World Backup Day). Праздник родился в 2011-м году из одной ветки на Reddit. "Но сегодня не канун 31-го марта", скажете вы. А я скажу, что "дуракам закон не писан" и расскажу о своей прошедшей неделе.
    Компания, в которой я работаю, уже несколько лет сопровождает в одном важном министерстве старую аналитическую систему... За 10 лет своей жизни система обросла огромным количеством отчетов и сотней гигабайт странных, никому не нужных, цифр. Больше трех тысяч пользователей со всей страны старательно вносят их в эту базу данных. Месячные, квартальные, полугодовые, годовые... работа по составлению отчетности и подачи ее по территориальной иерархии вверх не прерывается ни на день. Точнее не прерывалась до прошлого понедельника. В этот прекрасный день, чиновники разного уровня, обсудив прошедшие выходные за утренней чашечкой кофе, зашли в систему… И о ужас!... Отчеты формируются, но в них нет ни одной циферки. Оказалось, что "все, что нажито непосильным трудом", доступно только узкому кругу лиц, именуемому "Администраторы".
    Тут на сцену выходят два красавца: я (считается, что я знаю, как работают базы данных) и мой товарищ (считается, что он знает, как работает эта аналитическая система). "Дамы и господа! Без паники! Сейчас мы вас спасем!". Спасли, но это "сейчас" немного затянулось. Все оказалось не так просто, как нам хотелось бы. На сервере с резервными копиями нас ждал сюрприз - последней копии базы данных уже исполнилось четыре с половиной месяца! Причина банальная - на диске тупо закончилось место. Самое интересное, что примерно полтора года тому назад, я уже ставил в известность руководство заказчика, что у них полмесяца не делаются резервные копии баз данных, т.к. на сервере закончилось место. Администраторам должны были выписать "премии", но, похоже или мало выписали, или вовсе забыли это сделать.
    Итак, резервной копии базы данных нет. Как вернуть систему в строй и понять причину сбоя? Проблема в том, что аналитическая система проприетарная, поэтому исходных кодов нет, алгоритмы ее работы не всегда логичны и понятны, а метаданные хранятся в нескольких десятках таблиц в бинарном виде. То есть перед нами "черный ящик". Анализ логов системы и допрос "пауэр юзера" показал, что сбой произошел после создания новой отчетной формы и назначения на нее прав. Это стало отправной точкой нашего поиска. Три дня мозгового штурма в попытке смоделировать ситуацию или хотя бы 100%-но понять механизм назначения, пересчета и использования прав на различные объекты системы не привели к успеху. Мы часами изучали запросы в SQL Server Profiler, десятки раз восстанавливали различные копии базы данных на стенд, потом портили там данные и снова восстанавливали... Время шло. Но ни починить базу, ни аналогично поломать работающую нам не удавалось. Мы начали терять надежду и морально готовили себя и руководство к тому, что единственный выход – это вернуться к резервной копии базы данных, которой исполнилось четыре с половиной месяца... Но мы не сдались и нашли решение. Между прочим, не без помощи старой резервной копии.
    Что мы имеем?
  1. Почти неделя недоступности аналитической системы и простоя ее пользователей.
  2. Примерно 50 человеко-часов на восстановление ее работоспособности.
  3. Огромное количество не восстанавливаемых нервных клеток у нас, у нашего руководства и у заказчика.
Наличие актуальной резервной копии базы данных позволило бы этого избежать. Пользователи могли бы спокойно работать на восстановленной из нее базе данных, а простое сравнение поломанной и восстановленной базы выдало бы нам причину сбоя.
    Случай уникальный? К сожаленью – нет. За свою жизнь я не раз сталкивался с тем, что пользователи информационных систем живут по принципу "без бэкапа по жизни". Восстановить базу данных из вчерашней резервной копии – это не их метод. Вместо выполнения регламента по проведению резервного копирования баз данных лучше оплатить работу по их восстановлению. Например, базу данных одного филиала страховой компании я восстанавливал три раза, и только потом там админы согласились, что есть проблема с жестким диском и его нужно заменить. Хотя зачем платить? Можно ведь сделать разработчика "крайним". В годы моей молодости я работал в компании, которая разрабатывала собственную систему электронного документооборота (СЭД). У одного властного госоргана сгорел сервер, а единственная копия базы СЭД была сделана почти месяц до этого нашим сотрудником при установке обновления. Нас заставили ввести потерянные за это время заказчиком регистрационные карточки документов с их печатных копий. Были и курьезные случаи. Например, одно министерство купило нашу СЭД и в тайне от нас растиражировало ее по своим "дочерним" подразделениям. Пират себя разоблачил, когда в одном подразделении в результате сбоя на жестком диске сломалась база данных и ее принесли нам чинить. Так благодаря отсутствию резервной копии базы данных мы узнали о первом случае воровства нашей СЭД.
    Время идет, технологии совершенствуются... Администраторы, как не делали резервное копирование, так и не делают, как складывали резервную копию на один жесткий диск с оригиналом, так и складывают... Жесткие диски и базы данных, как ломались, так и продолжают ломаться... Shit happens... Стабильность.

Комментариев нет:

Отправить комментарий