У нас есть производственный сервер базы данных SQL Server, доставляющий резервные копии журналов транзакций на два резервных сервера. План аварийного восстановления уже завершен: у нас есть хорошо документированная процедура и люди, обученные запускать резервный сервер в производственную среду и запускать репликацию, запускать задания и т. Д. С минимальным временем простоя.
Проблема, которая вызывает обсуждение, заключается не в самом плане действий в чрезвычайных ситуациях, а в РЕШЕНИИ запустить резервный сервер в производство и потерять, в худшем случае, 12 минут информации (резервное копирование журнала транзакций выполняется каждые 10 минут и выполняется очень быстро. скопировано на другие серверы).
Решение может быть трудным, потому что мы можем тратить время, пытаясь определить проблему. С другой стороны, проблему можно было бы легко решить, и мы могли бы вернуть сервер в производство, не используя другие серверы.
Мы понимаем, что ситуация станет очень напряженной в случае сбоя системы, и думаем, что в таких ситуациях лучше иметь стандартную процедуру и минимум решений.
Итак, перед нами дилемма. Что лучше: просто сменить сервер, когда что-то не так с основным сервером, или лучше попытаться определить и решить проблему на основном сервере? Что вы думаете об этом, ребята?
Фреймворк, который вы, возможно, захотите использовать, - это два временных окна для решения этого вопроса во время возникновения проблемы. Конец первого временного окна будет мягким пределом, а второй - жестким пределом переключения.
Мягкий предел будет первой точкой пересечения. Если вы пытались решить проблему, но нигде не приблизились к ее решению, чем когда вы начали, вы бы переключились на мягкий предел. Если вы думаете, что приближаетесь к решению проблемы на мягком пределе, продолжайте идти до жесткого предела. Таким образом, мягкое ограничение будет, например, 5 минут, а жесткое ограничение будет примерно 8 минутами с начала попытки исправить проблему. На жестком пределе переключаться не важно.
Длину используемых окон вам придется решать самостоятельно. Вы также должны выяснить, хотите ли вы включить количество времени, которое потребуется, прежде чем вы действительно начнете рассматривать проблему.
Вы также можете, конечно, просто взяться за дело и делать то, что вы считаете лучшим в данный момент - вполне нормально не планировать каждую мелочь.
Все дело в затратах. Сколько стоит попытаться решить проблему за X минут / часов? Это меньше, чем затраты на переключение на резервный сервер, потерю какой-либо даты и, в конечном итоге, возврат на основной производственный сервер?
Как только затраты на исправление превышают затраты на переключение, принимается решение переключаться. Как вы можете определить понятие «катастрофа», пока не разберетесь с расходами?