Вместе с Гергелием Орошем мы продолжаем изучать интересные уроки из аварийных ситуаций (часть 1, часть 2), которые можно применять в своих организациях.
Ранее автор статьи уже и ранее хвалил компанию GitHub за прозрачность в отношении перебоев:
“Меня очень восхищает прозрачность страницы состояния GitHub. В то время как многие производители пытаются скрыть инциденты, GitHub очень прозрачен и сообщает о таких инцидентах, которые многие производители обычно не обнародуют, например, о снижении производительности в подмножестве системы. Вот один из примеров, когда неделю назад git clone работал медленнее, чем обычно, и GitHub объявил об инциденте. Впоследствии они устранили эту неполадку за 30 минут.”
Компания продолжает придерживаться этой хорошей привычки – прозрачно сообщать о перебоях в работе, даже если они кратковременны. Так, 29 июня в некоторых регионах США наблюдался 30-минутный перерыв в работе сервиса. Причина? GitHub проводил тренировки по аварийному восстановлению и обнаружил проблему с отказоустойчивостью. Из их отчета:
“Мы работали над созданием резерва для устранения ранее обнаруженной единой точки отказа в нашей сетевой архитектуре на второй граничной точке Интернета. Строительство второй граничной точки Интернета было завершено в январе, и с тех пор она активно маршрутизирует производственный трафик. Сегодня мы проводили тест на отказ, чтобы убедиться в том, что мы действительно можем использовать эту вторую граничную точку Интернета в случае отказа основной.
К сожалению, во время этого аварийного переключения мы нечаянно вызвали остановку производственных мощностей. В ходе тестирования выяснилось, что на вторичном сайте возникла проблема с конфигурацией сетевого маршрута, которая не позволяла ему корректно функционировать в качестве основного объекта. Это вызвало проблемы с интернет-подключением к GitHub, что в конечном итоге привело к перебоям в работе.”
Тестирование отказоустойчивости означает перенос приложения из одного места (например, в одном центре обработки данных) в другое. Аварийное переключение включает в себя запуск приложения в новом месте и перенаправление трафика на это новое место.
Однако когда GitHub выполнял это упражнение, выяснилось, что восстановление работоспособности работает не так, как планировалось.
В этом есть некоторая ирония, поскольку если бы GitHub не проводил упражнение по повышению отказоустойчивости, то сервис не пострадал бы от сбоя. Однако в произошедшем есть и положительная сторона. Поскольку инженеры знали, что это был тест на восстановление работоспособности, они смогли очень быстро устранить неполадки. С момента получения первого сигнала прошло две минуты, и изменение было отменено. Можно предположить, что в менее контролируемых условиях запуск мер по устранению последствий мог бы занять больше времени.
Кроме того, приципиально, чтобы отказоустойчивость работала корректно: т.е. в течение всего времени реального сбоя в работе одного из центров обработки данных. Хотя клиентам, безусловно, не понравилось, что они столкнулись с перебоями в работе, автор предпочтет более кратковременный перерыв в работе благодаря тому, что поставщик провел тест на отказоустойчивость, чем более длительный перерыв в работе из-за того, что поставщик не смог обеспечить отказоустойчивость.
В итоге компания GitHub подтвердила, что извлекла урок, а также принесла извинения своим клиентам:
“Этот тест на отказа помог выявить проблему с конфигурацией, и мы устраняем недостатки как в конфигурации, так и в тестировании на отказ, что поможет сделать GitHub более устойчивым. Мы осознаем серьезность этого сбоя и приносим извинения за его последствия для наших клиентов”.
Тестирование отказоустойчивости становится все более важным для подтверждения надлежащей надежности. Если мы чему-то и научились за последние несколько месяцев, так это тому, что центры обработки данных могут и будут выходить из строя. За последние три месяца целые регионы столкнулись с проблемами в AWS (регион us-east-1 в июне), Google Cloud (ргеион europe-west-9 в апреле) и Azure (регион Western Europe в июле). Во всех трех случаях сбоев компании, готовые переключиться на другой регион, могли работать без перебоев. Те же, кто не имел такой возможности, или те, у кого переключение на другой регион не сработало, пережили более длительный перерыв.
Если перебои в работе GitHub о чем-то и свидетельствуют, так это о том, что GitHub стал более серьезно относиться к надежности – в соответствии с внутренним регламентом компании. При повышенном внимании к надежности автор ожидает, что ситуация станет намного лучше, а затем будет оставаться такой же, благодаря внедрению более устойчивых систем и практик.
А что касается вопроса о том, нужно ли проводить тестирование отказоустойчивости, несмотря на то, что отказоустойчивость несет в себе определенные риски? Безусловно. Во много раз лучше обнаружить, что при тестировании отказа возникли проблемы, если ваша цель – убедиться в работоспособности отказоустойчивости. Если аварийное переключение не работает, можно вернуться к исходному состоянию. Однако если вы обнаружите, что процесс переключения не работает в тот момент, когда вам нужно переключиться, во время сбоя, вот тогда у вас действительно возникнут проблемы.
Провести надлежащее тестирование отказа не так просто. Это достаточно просто провести тестирование отказоустойчивости, когда все вроде бы в порядке, и объявить об успешном результате. Однако тестирование отказоустойчивости в условиях “отсутствия ошибок”, когда все части системы работают так, как ожидалось, может дать ложное ощущение безопасности.
При реальном аварийном переключении, может возникнуть внезапная проблема в основном центре обработки данных. Эта проблема может означать, что вы не можете корректно завершить работу приложений или служб, и тогда аварийное переключение продуктивной среды завершится неудачей.
Поэтому при выполнении упражнений по аварийному переключению старайтесь создать сценарий, в котором аварийное переключение происходит мгновенно, а приложения и сервисы выходят из строя в середине процесса (и не отключаются должным образом), чтобы можно было проверить возможность аварийного переключения в этих более реалистичных условиях. Не забудьте также выполнить упражнение по восстановлению работоспособности. Нередко бывает так, что переключение работает, а при восстановлении возникают проблемы!
Конечно, чем реалистичнее моделирование процесса аварийного переключения, тем выше риск того, что при первом выполнении такого переключения произойдет сбой. К сожалению, это краткосрочный риск, на который приходится идти ради повышения общей надежности.
Через неделю в последней части Вы узнаете о сложном решении компании Reddit, попытаться ли исправить ситуацию на месте или провести длительное восстановление.
Оригинал статьи здесь.
