- PVSM.RU - https://www.pvsm.ru -
Рано или поздно в любом проекте настает время работать над стабильность/доступностью вашего сервиса. Для каких-то сервисов на начальном этапе важнее скорость разработки фич, в этот момент и команда не сформирована полностью, и технологии выбираются не особо тщательно. Для других сервисов (чаще технологические b2b) для завоевания доверия клиентов необходимость обеспечения высокого uptime возникает с первым публичным релизом. Но допустим, что момент X все-таки настал и вас начало волновать, сколько времени в отчетный период "лежит" ваш сервис. Под катом я предлагаю посмотреть, из чего складывается время простоя, и как эффективнее всего работать над его уменьшением.
Очевидно, что прежде чем что-то улучшать, нужно понять текущее состояние. Следовательно, если мы начали уменьшать downtime, его в первую очередь и нужно начать измерять.
Мы не будем здесь подробно говорить о том, как конкретно это делать, плюсы и минусы разных подходов, но тезисно процесс выглядит как-то так:
Когда говорят об uptime/downtime, часто упоминают еще один показатель:
MTTR (mean time to repair) — среднее время от начала инцидента до его окончания.
Проблемы с ним начинаются прямо с первого слова в аббревиатуре. Учитывая, что все инциденты разные, усреднение длительности ни о чем в системном плане нам сказать не может.
В этот раз мы не будем ничего усреднять, а просто посмотрим, что происходит в ходе инцидента.
Давайте посмотрим, какие значимые этапы можно выделить в ходе инцидента:
Возможно наша модель неполная и есть какие-то еще стадии, но предлагаю их вводить только после осознания, как это поможет нам на практике. А пока рассмотрим подробнее каждую стадию.
Почему вообще мы тратим время на обнаружение внештатной ситуации? Почему не отправлять уведомление при первой же ошибке, которую получил пользователь? На самом деле я знаю многие компании, которые пытались так делать, но от этой идеи отказывались буквально через несколько часов, за которые получили несколько десятков SMS. Я думаю, что не существует ни одного более-менее крупного сервиса, у которого бы не было постоянного "фонового" потока ошибок. Не все из них признак того, что что-то сломалось, бывают еще и баги в софте, невалидные данные полученные из формы и недостаточная валидация, итд.
В итоге в качестве критерия для открытия инцидента используется уровень ошибок (или других метрик), которые превосходит ежедневные колебания. Именно это и приводит к тому, что уведомление ответственных сотрудников происходит позже фактического начала проблемы.
Но вернемся к нашей изначальной задаче — снижению длительности инцидентов. Как мы можем сократить время обнаружения? Быстрее уведомлять? Придумывать супер-логику обнаружения аномалий?
Я предлагаю пока ничего не делать, а посмотреть на следующие стадии, так как на самом деле они взаимосвязаны.
Здесь у нас чисто человеческий фактор. Мы предполагаем, что мониторинг справился с обнаружением проблемы и мы успешно разбудили дежурного инженера (вся эскалация тоже отработала на предыдущем этапе).
Рассмотрим "худший" случай, выделенной дежурной службы у нас нет, и алерт настиг мирно спящего админа. Его действия:
В итоге в худшем случае получаем 35 минут реакции. По моим наблюдениям такое время реакции похоже на правду.
Так как в на этом этапе мы имеем дело с людьми, нужно действовать крайне осторожно и продумано. Ни в коем случае не нужно писать регламент, согласно которому только что проснувшийся человек должен пошевеливаться! Попробуем просто создать условия.
Давайте для начала уберем сомнения инженера в том, что проблема закончится сама. Это делается очень просто: сделать критерий алерта нечувствительным к мелким проблемам и уведомлять, если инцидент длится какое-то значимое время. Да, мы только что увеличили длительность стадии "detection", но давайте рассмотрим на примере:
Потенциально такой подход позволит сократить суммарное время реакции, на 15+ минут. Если вас и такое время реакции не устраивает, стоит подумать о дежурной службе.
Пожалуй, эта самая сложная стадия аварии, когда вам нужно понять, что происходит и что делать. В реальности эта стадия очень часто совмещена со стадией принятия мер, так как обычно процесс идет так:
Эта стадия обычно самая значимая в суммарной длительности инцидента. Как же ее уменьшать?
Здесь все не очень однозначно, есть несколько векторов:
Как я говорил выше, эта стадия часто сливается с предыдущей. Но бывает так, что сразу понятна причина, но восстановление будет очень долгим. Например, у вас умер сервер с master primary (еще долго не смогу к этому привыкнуть:) базой данных, а реплику вы ни разу не промоутили, то есть вы будете читать документацию, раскатывать новый конфиг приложений итд.
Естественно после каждого значимого инцидента нужно разбираться, как не допустить такое снова или сильно ускорить восстановление. Но давайте посмотрим, какие направления нам можно попробовать проработать проактивно:
Еще один распространенный показатель, который упоминают при обсуждении uptime. Я предлагаю опять ничего не усреднять, а просто поговорить о количестве инцидентов, которые случаются за интервал времени.
Здесь на первый план выходит вопрос, насколько вы позаботились об отказоустойчивости вашего сервиса:
Иногда, чтобы все это просчитать/спрогнозировать делают "карту рисков", где у каждого сценария (который смогли предположить, естественно всегда остаются те, которых мы пока не знаем) есть вероятность + эффект воздействия (даунтайм короткий/длинный, потеря данных, репутационные потери, итп). Потом по такой карте планомерно работают, закрывая в первую очередь высоковероятные и серьезные по воздействию сценарии.
Другой прием, который можно использовать — классификация прошедших инцидентов. Сейчас много говорят о том, что очень полезно писать "разборы" (post mortem) инцидентов, где анализируются причины проблемы, действия людей, прорабатываются возможные будущие действия. Но чтобы быстро взглянуть на причины всех аварий за прошлый период удобно просуммировать их длительность с группировкой по "классам проблем" и там где больше всего downtime принимать меры:
То есть, если даже не пытаться предугадать возможные сценарии проблем, то работать с уже случившимися инцидентами определенно стоит.
Все инциденты разные:
Алгоритм работы над увеличением uptime очень похож на любую другую оптимизацию:
измеряй -> анализируй -> пробуй улучшить -> оценивай результат
По своему опыту могу сказать, что для существенного улучшения аптайма достаточно просто начать за ним следить и анализировать причины инцидентов. Обычно бывает, что самые простые изменения приносят самый значимый эффект.
Наш сервис мониторинга [3] помогает не только со стадией "detection", но и сильно сокращает " investigation" (клиенты подтвердят)
Автор: Николай Сивко
Источник [4]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/292867
Ссылки в тексте:
[1] chaos monkey: https://en.wikipedia.org/wiki/Chaos_Monkey
[2] мой доклад про балансировку: https://habr.com/company/okmeter/blog/423085/
[3] Наш сервис мониторинга: https://okmeter.io/?utm_source=habr&utm_medium=habr-post&utm_campaign=blog&utm_content=incident_anatomy
[4] Источник: https://habr.com/post/422973/?utm_source=habrahabr&utm_medium=rss&utm_campaign=422973
Нажмите здесь для печати.