«Трагедия» из-за синхронизации времени сервера

задний план

Во многих случаях нам не нужно уделять особое внимание времени сервера, например, системе управления фоном.Если время сервера неправильное, самое большее, на странице будет получено неправильное время, что мало на что влияет. Но некоторые программы очень чувствительны ко времени и не могут сделать небольшую ошибку.Сегодня я хочу рассказать о том, что случилось со мной в прошлом году: сбой на уровне отдела, вызванный проблемой синхронизации времени, которая привела к очень серьезным последствиям. Поскольку инцидент произошел менее года назад, и он был рядом со мной, память была еще свежа. Старое правило состоит в том, чтобы понять предысторию, прежде чем рассказывать историю.Упрощенная архитектура предыстории системы X в истории выглядит следующим образом:

Включает в себя три модуля Client->Connector->Heartbeat (конечно, модулей на самом деле много, остальные модули здесь опущены для упрощения архитектуры и не влияют на описание проблемы)

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

проходить через

На приведенном выше рисунке количество машин с клиентским модулем > 10 000, количество машин с модулем Connector > 100, но есть только одна машина с модулем Heartbeat, которая и является основной причиной трагедии. Что случилось:

Когда я однажды утром пришел в компанию, в отделе уже царил хаос. Немного поразмыслив, я понял, что упомянутая выше машина Heartbeat была отключена прошлой ночью, и многие данные Heartbeat не могли быть переданы. Проблема в настоящее время заключается в том, что клиент не может сообщать данные пульса, что не влияет на обычный сбор данных.
Ops начинает развертывание модуля Heartbeat на новом компьютере и запускает его (может быть автоматически зарегистрирован и обнаружен).
Данные о сердцебиении постепенно улучшались, но достигали только 60-70% от нормы.
Различные отделы начали сообщать нашему отделу, что машины их собственных отделов часто генерируют файлы ядра клиента (файлы на месте, генерируемые при неожиданном завершении работы программы на C++), и они имеют большой размер.
Лидер команды разработчиков и связанные с ним люди получили файл ядра и начали его анализировать.После некоторого позиционирования они обнаружили, что клиент аварийно завершил работу, потому что в клиенте была ошибка деления на ноль. Код в исключении примерно такой:

int g_lastReportTime = sometime;
void report() {
    int currentTime = getCurrentTime();
    if (somevalue / (currentTime - g_lastReportTime ) > threshold) {
        reportSomething();
        g_lastReportTime = currentTime;
    }
}

Из приведенного выше кода видно, что currentTime - g_lastReportTime не будет равен нулю в теории, а потому, что только что запущенное машинное время не согласуется с внутренней X-системой. В результате клиентское время откатывается, и происходит currentTime - g_lastReportTime = 0.

Эксплуатация и техническое обслуживание сразу же подумали о времени новой машины Heartbeat.Поскольку фоном нашей системы X являются все машины Linux, команда ntpdate используется для унификации времени новой машины, и эта команда добавляется в элемент запуска.
Данные сердцебиения постепенно возвращались к норме.

Описанный выше процесс занял почти 40 минут и произвел очень сильное впечатление. Позже ведомство привлекло к ответственности и общеведомственное уведомление виновных в аварии. Эта авария кажется случайной, но на самом деле она неизбежна, с момента сердцебиения машины единой точки. Авария, вызванная простоем машины, гораздо менее серьезна, чем авария, вызванная клиентским ядром.Видно, что основная причина этой аварии вызвана асинхронностью времени, но она не изолирована, а является результатом единого действия. многих факторов. «Трагедия», вызванная синхронизацией времени этого титровального сервера, не является преувеличением, и я надеюсь, что она может пробудить внимание и задуматься читателей.

считать

Я не слишком много думал об этом, когда случилась авария, в конце концов, как новичок, я не мог придумать причину. Однако по мере накопления опыта работы я постепенно делал некоторые выводы из этой аварии. Авария подняла четыре основных вопроса:

1. Проблемы мониторинга

Устройство сердцебиения не работало, и данные о сердцебиении были недоступны, пока они не были обнаружены, когда я пошел на работу на следующий день, более 8 часов. К счастью, это только внутренняя система, и если она похожа на Taobao и Tmall, то можно себе представить экономические потери и влияние молвы. Я слышал, что посреди ночи мониторинг сообщил об аномалиях, но новый коллега не обнаружил никаких проблем в позиционировании, что привело к финальному эффекту бабочки. Однако кажется, что даже если он будет найден на месте, если синхронизация времени не будет выполнена хорошо при переходе на новую машину, произойдет авария ядра. У меня есть следующие предложения по мониторингу системы:

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

2. Одноточечная задача

Это общая тема.Решений в интернете много.Об универсальности тут говорить не буду,а только познакомлю с Х системой. Из-за специфики системы модуль Heartbeat нельзя развернуть на нескольких машинах. Итак, есть только одна точка, поэтому мы можем только надеяться, что машина с одной точкой не выйдет из строя? Согласно закону Мерфи: если вы беспокоитесь о том, что что-то может произойти, вероятность того, что это произойдет, возрастает. Так что не рискуйте, ибо единая точка Heartbeat системы X, хотя и не может быть реконструирована за короткое время, мы все же можем делать некоторые вещи без необходимости вручную переключать машины для эксплуатации и обслуживания. Один из вариантов выглядит следующим образом:

Мониторинг машины с модулем Heartbeat в сервисном регистрационном центре, если обнаружено, что в сервисном регистрационном центре нет модуля heartbeat более определенного периода времени. Затем запустите Heartbeat на резервной машине и выдайте сигнал тревоги. Таким образом, вы можете вовремя переключиться на резервный Heartbeat, чтобы не забыть то и это в спешке. Простая структурная схема выглядит следующим образом:

3. Проблемы с качеством кода

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

Самотестирование программиста: Программисты должны провести достаточное самотестирование после написания кода.Хотя нет 100% гарантии отсутствия ошибок, по крайней мере, можно найти большинство логических ошибок и ошибок низкого уровня. Не думайте, что вам помогут тесты, вы можете быть ленивыми, они часто тестируют только на уровне использования, а не на уровне кода. Если у вас нет специальных тестов, вы должны сделать это самостоятельно и иметь достаточно еды и одежды.
Обзор кода (CodeReview): Все они говорят, что не знают настоящего лица горы Лу только потому, что родились на этой горе. Инспекция кода тоже есть, проверяйте свой код, сложно найти какие-то скрытые ошибки. В это время вам нужен кто-то еще, чтобы проверить это для вас, то есть CodeReview. Конечно, CodeReview всего кода — вещь трудоемкая и трудоемкая, так что будьте избирательны. Код некоторых основных модулей должен подвергаться самостоятельному тестированию и повторному просмотру CodeReview. Что касается плана CodeReview, то он зависит от тестовой ситуации.
Добавьте профессиональных тестировщиков: (1) и (2) могут устранять только ошибки на уровне кода, но некоторые краеугольные ошибки уровня использования (1) и (2) не всегда могут быть найдены. Поэтому профессиональные тестировщики и тестовые платформы должны полностью протестировать код перед тем, как он появится в сети.

4. Распределенные или кластерные проблемы с синхронизацией времени

Временная синхронизация распределенных или кластерных систем также является одной из проблем, которые необходимо решить в распределенных системах, помимо сценариев аварии в системе X. Есть много сценариев, которые должны поддерживать согласованность времени на каждом узле (машине) в распределенной системе.Например, в системе банковских транзакций время следующей транзакции не может быть сделано раньше, чем время предыдущей транзакции, в противном случае это вызовет путаницу у пользователей. Разные распределенные системы имеют разные решения, простые и сложные. Такая простая, как система X, может быть реализована непосредственно с помощью ntpdate.Что касается сложной, обратитесь к статье блога «Распределенная система — Синхронизация часов», чтобы реализовать собственную систему синхронизации.

Конечно, вышесказанное является лишь общим обсуждением, и право следует использовать для привлечения инсайтов. Есть ли у вас аналогичная проблема в системе, которую вы поддерживаете?Лучше выявить известные проблемы заранее, чем скрывать их. Если вы обнаружите проблему до аварии, вы можете завоевать благосклонность босса, возможно, вы можете получить повышение и прибавку к зарплате, но если вы решите проблему после аварии, вы можете нести только вину.. Не забудьте обратить внимание на официальный аккаунт, в котором записан путь обучения программиста C++ Java.