Главная инфраструктура веб-сайта Stack Overflow находится в центре обработки данных, расположенном в Н1,ю-Йорке. Если в центре обработки данных происходит авария или отказ в обслуживании, то запускается дублирующее оборудование и программное обеспечение, находящееся в Колорадо. Дубликат в Колорадо - это полноценная работоспособная копия, за исключением того, что она находится в режиме резервирования и ждет активации.

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

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

    Другими словами, процесс аварийного восстановления сопряжен с риском. Когда Том работал в компании Stack Oveгflow, его первая мысль была "Я надеюсь, что такой сбой произойдет не на моем дежурстве".

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

    Нет, неправильно. Есть разница между поведением и процессом. Рискованное поведение является опасным по своей природе; оно не может стать менее рискованным. Вождение в пьяном виде - опасное поведение. Оно не может стать менее опасным, его можно только избегать. Аварийное восстановление - рискованный процесс. Его можно сделать менее рискованным, если выполнять его чаще.

    Однажды в компании Stack Overflow произошел сбой, на восстановление после которого понадобилось десять часов. Инфраструктура в Нью-Йорке стала значительно отличаться от инфраструктуры в Колорадо. Код, который должен был обеспечить гладкий переход, потерпел неудачу, потому что был проверен в идеальных условиях и подвел в реальной среде. Обнаружились неожиданные зависимости, в некоторых случаях создавая абсурдные ситуации, напоминающие порочный круг, которые должны были быть разрешены моментально.

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

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

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

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

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

    В ходе учений были обнаружены изменения инфраструктуры, которые не были скопированы в Колорадо, и код, который не восстанаnлиnался должным образом. Были идеmифицированы новые службы, которые не могли nосстанавливаться без проблем. Был выявлен процесс, который мог быn, выполнен только одним конкретным инженером. Если бы он был в отпуске или недоступен, то компания оказалась бы в сложном положении. Он был единственным, кто мог устранить проблему.

    В течение года были выявлены все эти проблемы. Код был заменен, были разработаны более точные предварительные тесты, а практические учения дали каждому члену команды, обеспечивающей надежность информационных систем (SRE - Site Reliabllity Engineering), возможность глубже изучить процесс аварийного восстановления. В конечном счете весь процесс был упрощен и стал проще для автоматизации. Компания Stack Overflow получила следующие выгоды.