Обычный трехсторонний подход к решению онлайн-проблем:重启-回滚-扩容, может решить проблему быстро и эффективно, но по моему многолетнему онлайн опыту, эти три операции немного просты и грубы, а вероятность решения проблемы очень случайна, что не всегда эффективно. Вот краткое изложение решений, которые я обычно использую для устранения сбоев, возникающих в приложениях.
в общем
Некоторые принципы, которых необходимо придерживаться при работе с отказами
Раннее выявление проблем и предотвращение распространения сбоев
Ссылка, по которой возникает ошибка, обычно показана на следующем рисунке.
У каждого слоя могут быть проблемы, чем больше проблем в нижнем слое, тем больше влияние. Таким образом, для каждого уровня требуется соответствующий механизм мониторинга проблем, поэтому чем раньше возникнет проблема, тем больше вы сможете устранить сбой как можно скорее, избегая распространения проблемы. Например, у владельца базы данных есть проблема, если вы ждете, пока пользователь сообщит, это может занять несколько минут. Ожидание, когда вы проанализируете проблему, решите проблему, переключите хост, и, возможно, прошло несколько минут. Ударный доступ относительно велик. Если оповещение получено, оно устранено, и других сообщений может не быть, проблема решена.
Быстрая трансляция
Когда приходит оповещение P0, определяется, что у приложения есть проблемы, и транслируется первый раз. Все сотрудники вошли в боевой статус первого уровня, обнаружили, что другие зависимые сервисы/промежуточное ПО/эксплуатация/облачные поставщики, немедленно уведомили соответствующих ответственных лиц, требуя вступления в совместные операции.
быстрое восстановление
Сохранение сцены важно, чтобы помочь обнаружить первопричину. Однако, когда происходит сбой, мы должны бороться со временем, мы не можем тратить несколько минут на дамп памяти и состояние потока jstack, чтобы сохранить сцену. Службу необходимо восстановить как можно скорее, а затем на основе данных мониторинга на тот момент найти первопричину
непрерывное наблюдение
Для решения проблемы может потребоваться перезагрузка/откат/макет/ограничение тока и другие операции онлайн, и обязательно проверьте, достигнут ли ожидаемый эффект.
Вам нужно продолжать наблюдать в течение определенного периода времени, действительно ли служба работает нормально. Иногда это может длиться только короткое время, и оно контратакует.
Средства обработки
Методы обработки — это не что иное, как перезагрузка, расширение, откат, текущее ограничение, понижение версии, исправление.
Ниже приведен мой общий процесс решения онлайн-проблем.
В основном разделен на четыре блока
шаг 1: Есть ли какие-либо изменения
Точно так же, как большинство автомобильных аварий вызвано изменениями, онлайн-сбои часто вызваны изменениями. Внешние изменения трудно воспринять, но легко воспринять изменения самих сервисов, когда есть такие изменения, как выпуск сервисов и изменения конфигурации. Тогда сначала определите, можно ли его откатить, а откат можно будет сделать сразу.
step2: Является ли это одной машиной
Сейчас он вообще развернут в кластере, и сервис высокодоступен. Если есть проблема только с одной машиной, немедленно удалите ее, если служба съемная. Если его нельзя удалить немедленно, его следует сначала расширить, а затем удалить.
Шаг 3: следует ли кластеризовать
У всего сервисного кластера есть проблема, и проблема относительно сложнее, ее нужно разделить на один API и множественные ошибки API.
одиночная ошибка API
Влияет ли это на другие API, модули и нижестоящее хранилище в приложении. Если есть влияние, оно может быть понижено во времени. Текущее ограничение вызвано увеличением объема запросов. Это не влияет на другие модули, а затем устранить проблему, исправить.
Несколько ошибок API
Обычно это ошибка на шаге 4, вы можете перейти непосредственно к шагу 4 для просмотра.
Если это не ошибка шага 4, если трафик превышает ожидаемый, ограничьте ток и увеличьте пропускную способность. Если нет, найдите проблемы с кодом, исправьте онлайн
Шаг 4: Проблема с зависимой службой/хранилищем
Немедленно найдите соответствующую команду и вместе устраните проблему. Если это вызвано аномальным запросом собственной службы, внесите соответствующее исправление. Если это вызвано нормальной работой, требуется экстренное расширение и обновление конфигурации.
Как предотвратить
Из приведенных выше операций видно, что при возникновении ошибки необходимо принимать еще много решений.Если опыт недостаточно богат, а обработка не выполняется должным образом, легко вызвать эскалацию ошибки и потерю активов.
Поэтому его нужно предотвратить заранее.
Знай свой сервис
Как и философский анализ, как вы узнаете ваш сервис. Как правило, включают следующее
Нарисуйте схему архитектуры системы приложений
Следующие модули должны быть включены,
Для кого предназначена услуга?
Кого следует уведомить, если что-то пойдет не так
Какие модули включены
Какие функциональные модули применяются. Когда пользователь сообщает о проблеме, он знает, в какой службе возникла проблема.
Системный поток
Как перемещаться между модулями
Зависимое промежуточное программное обеспечение
На какое промежуточное программное обеспечение полагается, и кто является ли ответственным лицом
Зависимое хранение, очередь сообщений
На каком хранении полагается, и кто является лицом, отвечающим за эксплуатацию и обслуживание хранения
зависимые услуги
От каких служб зависят, какие функции зависят от каких служб и к кому следует обращаться в случае возникновения проблемы. Будь то слабая зависимость, даунгрейд.
Нарисуйте схему развертывания прикладной системы
Как развернута система и в какой среде. Как войти в систему, расширить и обновить.
Разобраться с уровнями отказов системы
Какие модули являются основными, а какие модули менее важны и могут быть понижены.
Стресс-тестовая дрель
Количество запросов в секунду для одной машины, которое может поддерживать текущая система, — это то, сколько и какие узкие места в производительности могут существовать, необходимо получить с помощью испытаний под давлением.
Каков коэффициент чтения/записи API для текущего приложения и какой коэффициент соответствует каждому уровню хранения. Когда приложение QPS поднимается, какая зависимость первой выйдет из строя. Redis/mysql по-прежнему является зависимой службой или самим приложением.
Регулярный инвентарь
Будь то ошибки обратной связи с пользователем или сигналы тревоги мониторинга, в основном уже слишком поздно, потому что к этому времени накопилось определенное количество неправильных вызовов. Поэтому вам нужно сделать шаг вперед и регулярно проводить инвентаризацию приложений. Измеряемые показатели обычно вращаются вокругИспользование, насыщение, пропускная способность и время откликаСодержимое инвентаря включает все зависимости.
Уровень приложения
Дисковый процессор, память, номер загрузки, ситуация jvm gc
системный уровень
запросов в секунду
зависимое хранилище
Диск, процессор, IOPS, qps.
очередь сообщений
Расход нормальный?
Кроме того, системный журнал является источником информации об ошибках из первых рук.Владелец приложения должен регулярно запрашивать журнал ошибок, что может эффективно устранить потенциальные проблемы в базовой станции.
Мониторить оповещения
Предупреждения мониторинга могут помочь обнаружить сбои на раннем этапе, поэтому убедитесь, что элементы мониторинга завершены, а предупреждения переданы эффективно.
Ниже приведены некоторые часто используемые элементы мониторинга.
тип
Элемент мониторинга
Статус хоста
Использование диска > 85
Статус хоста
5-минутная нагрузка > количество ядер*1,5
Статус хоста
5 минут Использование памяти> 80
Статус хоста
5 минут ЦП > 50
API
Частота ошибок API за 5 минут > 0,1
SQL
Медленный запрос занимает> 100 мс
бревно
Ошибок за 1 минуту > 10
бревно
5 минут ошибок> 50
Обратите внимание на паблик-аккаунт [Abbot's Temple], как можно скорее получите обновление статьи и начните путь технической практики вместе с настоятелем