Черная пятница. ИТ-сбой (произошедший в ноябре 2018)

1.

ИТ-сбой (произошедший в ноябре 2018)

2.

1.
Что произошло?
2.
Почему произошло?
3.
Хронология восстановления
4.
УРОКИ

3.

В середине ноября в рамках подготовки к высокому сезону было принято
решение добавить мощности в терминальные сервера ERP ситемы. Также
требовались мощности под Excel в терминалах. Для этого было необходимо
быстро ввести в строй дополнительный физический сервер (HPE ProLiant DL360
Gen9 Server)
22 ноября в 13 часов системный администратор проводил в дата-центре работу
по добавлению этого физического сервера в структуру основного виртуального
пула серверов
Частью процедуры установки является форматирование диска нового сервера –
при выполнении этой операции ошибочно были стерты все данные, не только с
этого диска, но и 70% данных основной системы хранения данных (иллюстрация
на следующем слайде)

4.

Связаны оптическим линком
Два массива в
режиме
синхронной
репликации
VVOL1
Физический сервер 1
Свой
диск
VVOL2
Виртуали
зировано
VVOL3
Общая
система
Общая
система
хранения
хранения
(отдельная
(отдельная
физическая
HPEHPE)
физическая
3PAR 8200)
VVOL4
Физический сервер N
Свой
диск
VVOL5
Его и пытались очистить
А стерли все это
Физический сервер БД
ERP
Свои
персональ
ный диски
из HPE

5.

Админ использовал стандартный мастер установки сервера HPE
У нас на СХД были нарезаны большие диски и они
хостам VMWARE
ВСЕ отданы были ВСЕМ
Соответственно они все были доступны в этом мастере установки сервера. И
мастер нашел все доступные диски, и дал команду СХД их затереть (а должен
был только своим собственным дискам сервера команду давать)
Вишенка на торте – на СХД был включен режим повышенной безопасности – т.е.
тотальное забивание нулями первого гигабайта в каждом томе по команде
«стирай». Естественно разметка файловой системы лежит в этом первом
гигабайте. В итоге – восстановление с помощью самых продвинутых утилит
оказалось невозможно – на дисках остался несвязанный мусор
Ну и конечно оба дублирующих друг друга массива СХД стояли в режиме
синхронной репликации

6.

Нет защиты
«от дурака»
в
приложении
HPE
Админ не
прочитал
инструкцию где
было указано что
нужно
ОТКЛЮЧИТЬ
диски внешней
СХД от сервера

7.

С точки зрения пользователей перестали работать практически все основные
ИТ-системы – ERP, WMS, 1C. Также перестали работать серверные части систем
получения заказов (от ТП, через EDI и через email). Продолжали работать
системы, находящиеся в старом дата-центре (для второстепенных систем) –
почта, коммуникаторы, доступ в Интернет. Также работали облачные сервисы
(GoToMeeting, WhatsApp, почта ТП на mail.ru)
ERP попал в специфичную ситуацию – сама система работала (ее хранилище
данных – отдельное, и там ничего не потерялась), но не было способа
пользователям в нее попасть (т.к. подключение осуществляется через
терминальные сервера, данные которых пропали)
Несмотря на потерю продуктивных данных, все необходимое для
восстановления по состоянию «на момент остановки» было в наличии (кроме
системы 1С, где была полностью потеряна утренняя работа за 22.11). Проблема
была только в том, что метод быстрого восстановления не был создан.
Пришлось восстанавливаться «по медленному»

8.

Продолжали все время работать: почта, pidgin, lync, internet, телефония. Помогали облачные
сервисы: GoToMeeting, WhatsApp
22.11.18 13:00 Начало простоя
23.11.18 10:29 SRS
23.11.18 11:47 Файловые ресурсы
только по ERP отчетам, т. к. базы WMS не доступны
ресурс доступен
23.11.18 11:54 ERP
term2. Доступ частично, только для передачи в отбор и печати документов
23.11.18 13:39 ERP
term3. Доступ частично, только для передачи в отбор и печати документов
23.11.18 14:00 EDI
23.11.18 22:00 WMS В
23.11.18 22:47 ERP
23.11.18 23:16 Феникс
24.11.18 15:00 WMS НН
24.11.18 17:00 СМТ
24.11.18 18:00 WMS Каз
24.11.18 22:00 WMS Ч2
24.11.18 23:55 Антор
простой завершен
простой завершен
term4, term6, term23 доступ не ограничен
ресурс доступен
простой завершен
простой завершен
простой завершен
простой завершен
простой завершен
25.11.18 14:14 ERP
Доступ в ERP с серверов term1 и term2 открыт без ограничений
25.11.18 03:00 WMS С
25.11.18 15:00 WMS К
25.11.18 15:00 WMS У
25.11.18 17:00 WMS А
26.11.18 00:00 WMS У
26.11.18 15:00 ERP
26.11.18 18:00 WMS В
26.11.18 18:00 WMS Т
26.11.18 18:00 WMS Т
26.11.18 18:00 WMS М
26.11.18 18:00 WMS С
26.11.18 21:00 WMS Я
26.11.18 21:00 WMS К
04.12.18 00:00 WMS М
окончание простоя
окончание простоя
окончание простоя
окончание простоя
окончание простоя
term33 открыт
окончание простоя
окончание простоя
окончание простоя
окончание простоя
окончание простоя
окончание простоя
окончание простоя
окончание простоя, отбор проходил по ERP
1 сутки
2 сутки
3 сутки
4,5 суток

9.

Перегруженные
задачами Админы
Перед очередным
M&A торопились все
важное перенести
на новые скоростные
диски в рамках СХД
Сбои возможны всегда – важно
уметь быстро восстанавливаться
после них, а именно с этим была
главная проблема в этот раз!
Забыли (не успели)
настроить для
перенесенных VM
онлайн-бекап
(снапшоты на
StoreOnce)

10.

Оценка масштаба аварии
Собран штаб восстановления
Связались с поставщиками системы из РФ, с производителем системы (HPE)
Связались со сторонней компанией, которую рекомендовали HPE (r-lab)
Нехватка места для 2х сценариев параллельного восстановления
Восстановили данные - часть из бекапов, часть из снепшотов и базы данных из логов
Итого - потерь данных в системах ERP,WMS, СМТ не произошло. Потеря данных в системах
1С была минимальной (половина дня 22.11 с ночного бекапа до 13.00). Операции на
складе и обработка заказов началась с того же момента с какого остановилась (с точки
зрения целостности остатков, цен, товаров, клиентов, продаж и т.д.)

11.

Внедрили новую версию машины RMC, положили ее на другую СХД – IBM. Ежедневно мы
ее бекапим. Её данные каждый час бакупим 2мя разными методами: на StoreOnce и
внешний отдельный сервер. Без RMC мы не можем взять данные со сторванса (в случае
краха СХД или в случае что нужна копия глубже 2х дней)
Более мелкие тома в СХД для всех машин (это снижает риски тотального стирания)
Разные машины лежат в разных RAID-группах
По 50% серверов – выделены критически важные машины и только им их том отдан
(чтобы ситуация не повторилась). НЕ ВСЕМ МАШИНАМ - ВСЕ ТОМА
Глубину хранения в сторвансе увеличили с 14 дней до 21
Бекапы логов в 1С каждые 10 мин
Все ВМС сервера бекапятся
Терминальные сервера ERP разложены по разным СХД (HP и IBM)

12.

Организуем рискованные и критические работы в дата-центре по методу «четырех глаз» (такие работы будут проводится всегда
вдвоем).
При установке ОС (переустановке) хоста - отключать все интерфейсы методом физического вынимания проводов
Разместим систему управления онлайн-бекапами на другой СХД (не на той же где лежат данные, которые она бекапит).
Улучшить план BCP (действий в случае катастроф) теми идеями и границами принятия решений, что родились в процессе устранения
сбоя – опыт медленного принятия некоторых решений будет учтен.
Внедрим организационные изменения отдела ИТ-инфраструктуры, которые приведут к большему фокусу на процессе бекапирования
Настроить ежедневный бекап на ленту
Перенос базы знаний и остатков из WMS в облако (чтобы не пропадала когда проходит катастрофа)
В каждый первый месяц квартала делаем полный бекап. 2 экземпляра – один остается у админов, второй – банковская ячейка
Переместить часть ИТ-сервисов во внешний дата-центр. Это позволит разнести риски по разным локациям, а также позволит
высвободить резервное место в собственном дата-центре, для потребностей быстрого параллельного восстановления в случае сбоев.
Разработать регламент бекапов и восстановления , и иметь его в распечатанном виде в кабинете ИТ
В январе и июле каждого года проводить учения по восстановлению из бекапов . По результатам изменять ИС для уменьшения
времени восстановления и повышения надежности восстановления
Проанализировать бекап файл-серверов на файлы не требующие бекапирования (exe и т.д.)

13.

Потратить час. Если не понятно что делать и что произошло, то
Делимся на 2 команды - одна ищет стертые данные, вторая восстанавливает че может из имеющихся бакупов. Починит первая
команда хорошо. Не починит не потеряли время и стали восстанавливать
Важное условие – должно быть место КУДА восстанавливать (старое трогать нельзя – пытаемся восстановить)