Pull to refresh

Comments 6

И еще хотел бы добавить. На практике так случалось, я встречал организации, где админом настроено регулярное создание бэкапов, и в теории, в случае проблемы, все можно было откатить. Но вот никто ни разу не проводил мероприятия по восстановлению из этих бэкапов. И когда приперло — оказалось, что бэкапы делались не корректно или левым (не правильно настроенным) софтом. А у админа спокойно на душе — бэкапы делаются регулярно.
Проверяйте бэкапы! ИМХО
Пропущены некоторые прописные истины.

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

2. Quis custodet ipsos custodes? Мониторинг может молчать не потому, что всё хорошо, а потому, что он сам лёг полежать.

3. Мониторинг может орать как положено, но не мочь докричаться, т.к. каналы доставки сообщений по каким-то причинам ему недоступны (например, на площадке пропал интернет, или лёг сервер, через который он отправляет сообщения).
> сразу же после создания бекап должен разворачиваться в песочнице и проверяться на валидность.

Если бы всё было так просто… Для этого нужен дубликат боевой дисковой системы, что далеко от реальности в подавляющем большинстве случаев. А единственная надежная проверка на валидность — сверка копии с оригиналом, что от реальности ещё дальше. То есть проверять-то надо, но каждую копию и полностью — это излишне накладно.

> Мониторинг может молчать не потому, что всё хорошо, а потому, что он сам лёг полежать.

В случае бэкапа просто делаются сообщения не только об ошибках, но и об успешном завершении операций. Тогда отсутствие сообщений от мониторинга — само по себе свидетельство наличия проблем.
3. Мониторинг может орать как положено, но не мочь докричаться, т.к. каналы доставки сообщений по каким-то причинам ему недоступны (например, на площадке пропал интернет, или лёг сервер, через который он отправляет сообщения).


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

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

Ну можно и галочку не там поставить, или по привычке «да» в диалоговом окне нажать не читая.
Sign up to leave a comment.