Обнаружил у себя привычку анализировать различные сбои с точки зрения их возможного предотвращения системным аналитиком. Вот если бы на проекте был аналитик — смог бы он задуматься о возможном сбое?
Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!)
Ну и что, всё то же, что и в других случаях: гонки параллельной записи, непредсказуемый эффект ретраев, плохо выстроенные границы транзакций, отсутствие проверок пустых значений, зажатые таймауты.
Темы интеграций, на самом деле. Но аналитики редко туда заглядывают. А тут ещё точка возникновения сбоя — план DNS, это в 99.9% случаев за пределами внимания аналитика.
Технически там вот что произошло: в AWS есть база DynamoDB, в которой хранится много всего интересного (например, настройки других сервисов). Эта база очень широко распараллелена, поэтому нужно балансировать нагрузку, динамически масштабировать, отключать и подключать вылетевшие и восстановившиеся копии. Это делается через DNS, поэтому планы DNS меняются очень динамично. Но в какой-то момент одно из изменений зависло, пересеклось с другими транзакциями и ушло в ретраи. Пока оно пыталось отретраиться, планы успели поменяться уже несколько раз. А отдельный процесс после успешной смены конфигурации ходит по узлам и удаляет старые планы. И вот в зазоре между обновлением плана и запуском очистки наконец успешно сработал один из ретраев, и переписал все планы на старую версию. Процесс очистки обнаружил план старой версии, и тут же его удалил. В DNS не осталось записей. А так как актуального плана не было, не на чем было основывать новые версии, и план вообще перестал обновляться, застряв в пустом состоянии.
Потом по цепочке всё начало валиться, в том числе перестали создаваться инстансы динамического масштабирования серверов EC2 — потому что даже после восстановления доступа к DynamoDB запросов на их создание скопилось столько, что их менеджер начал тормозить, и создание новых инстансов отваливалось по таймауту.
Непонятно, могли ли тут заранее помочь аналитики. Мне кажется, не особо. Возможно, помогло бы моделирование сценариев, но вся архитектура скорее всего развивалась эволюционно, и на каждое небольшое изменение имитационный сценарий не будешь запускать. Это особенно касается гонок параллельных процессов с учетом ретраев, потому что в голове такое сложно уложить, все варианты не учтешь.
Но вот удаление всех записей в базе (в DNS, в данном случае) — пожалуй, можно предотвратить. Пустые поля, удаленные записи — у Гугла же последний массовый сбой был тоже из-за отсутствия проверки на пустое значение. Тут, мне кажется, аналитик мог бы помочь.
Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате.
Отдельная тема — стратегия восстановления. Если у вас накопилось много сообщений или заданий в очередях, пока какой-то сервис лежал — как вы будете их накатывать? Если все сразу — это может превысить планируемую пиковую нагрузку, нужно как-то хитрее.
А главное, это всё может возникнуть совершенно неожиданно в любой сколько-нибудь нагруженной интеграции. И как это всё учесть?
Вот и сейчас — смотрю на отчет по сбою амазоновского US-EAST-1, который уронил чуть ли не все сервисы (люди урок в Duolingo пройти не могли! Стрики свои многомесячные потеряли!)
Ну и что, всё то же, что и в других случаях: гонки параллельной записи, непредсказуемый эффект ретраев, плохо выстроенные границы транзакций, отсутствие проверок пустых значений, зажатые таймауты.
Темы интеграций, на самом деле. Но аналитики редко туда заглядывают. А тут ещё точка возникновения сбоя — план DNS, это в 99.9% случаев за пределами внимания аналитика.
Технически там вот что произошло: в AWS есть база DynamoDB, в которой хранится много всего интересного (например, настройки других сервисов). Эта база очень широко распараллелена, поэтому нужно балансировать нагрузку, динамически масштабировать, отключать и подключать вылетевшие и восстановившиеся копии. Это делается через DNS, поэтому планы DNS меняются очень динамично. Но в какой-то момент одно из изменений зависло, пересеклось с другими транзакциями и ушло в ретраи. Пока оно пыталось отретраиться, планы успели поменяться уже несколько раз. А отдельный процесс после успешной смены конфигурации ходит по узлам и удаляет старые планы. И вот в зазоре между обновлением плана и запуском очистки наконец успешно сработал один из ретраев, и переписал все планы на старую версию. Процесс очистки обнаружил план старой версии, и тут же его удалил. В DNS не осталось записей. А так как актуального плана не было, не на чем было основывать новые версии, и план вообще перестал обновляться, застряв в пустом состоянии.
Потом по цепочке всё начало валиться, в том числе перестали создаваться инстансы динамического масштабирования серверов EC2 — потому что даже после восстановления доступа к DynamoDB запросов на их создание скопилось столько, что их менеджер начал тормозить, и создание новых инстансов отваливалось по таймауту.
Непонятно, могли ли тут заранее помочь аналитики. Мне кажется, не особо. Возможно, помогло бы моделирование сценариев, но вся архитектура скорее всего развивалась эволюционно, и на каждое небольшое изменение имитационный сценарий не будешь запускать. Это особенно касается гонок параллельных процессов с учетом ретраев, потому что в голове такое сложно уложить, все варианты не учтешь.
Но вот удаление всех записей в базе (в DNS, в данном случае) — пожалуй, можно предотвратить. Пустые поля, удаленные записи — у Гугла же последний массовый сбой был тоже из-за отсутствия проверки на пустое значение. Тут, мне кажется, аналитик мог бы помочь.
Я на тренинге упоминаю о статистических проверках данных: не просто вам пришло что-то, и ок, а проверьте — то, что пришло, оно вообще похоже на то, что вы ожидали? Возможно, обычно вам записей приходит около 10000, а тут пришло 100 — это нормально, или ошибка? Обычно суммы в договорах распределяются нормально, а тут вдруг 70% одинаковые — это нормально? Время выполнения домашних заданий у студентов тоже как-то распределено, а тут мы получили все с одним временем загрузки — подозрительно? Наш процесс собирается удалить все IP-адреса — правильно ли это? И так далее. Думать о таких вещах заранее — верх душноты. С другой стороны, достаточно один раз потерять все записи за день из-за сбоя в интеграционном слое — и будешь вставлять такие проверки на автомате.
Отдельная тема — стратегия восстановления. Если у вас накопилось много сообщений или заданий в очередях, пока какой-то сервис лежал — как вы будете их накатывать? Если все сразу — это может превысить планируемую пиковую нагрузку, нужно как-то хитрее.
А главное, это всё может возникнуть совершенно неожиданно в любой сколько-нибудь нагруженной интеграции. И как это всё учесть?