Анатомия инцидента, или как работать над уменьшением downtime


    Рано или поздно в любом проекте настает время работать над стабильность/доступностью вашего сервиса. Для каких-то сервисов на начальном этапе важнее скорость разработки фич, в этот момент и команда не сформирована полностью, и технологии выбираются не особо тщательно. Для других сервисов (чаще технологические b2b) для завоевания доверия клиентов необходимость обеспечения высокого uptime возникает с первым публичным релизом. Но допустим, что момент X все-таки настал и вас начало волновать, сколько времени в отчетный период "лежит" ваш сервис. Под катом я предлагаю посмотреть, из чего складывается время простоя, и как эффективнее всего работать над его уменьшением.


    Показатели


    Очевидно, что прежде чем что-то улучшать, нужно понять текущее состояние. Следовательно, если мы начали уменьшать downtime, его в первую очередь и нужно начать измерять.


    Мы не будем здесь подробно говорить о том, как конкретно это делать, плюсы и минусы разных подходов, но тезисно процесс выглядит как-то так:


    • опираемся на около-бизнесовые метрики (ошибки в работе сервиса, время отклика сервиса, $/second, signups/second итп)
    • определяем, что такое хорошо, а что такое плохо
    • переход хорошо->плохо является началом инцидента
    • переход плохо->хорошо — конец инцидента
    • время от начало до конца — длительность инцидента (кэп с нами)
    • сумма длительностей инцидентов за период (месяц/квартал/год) — время простоя (downtime)
    • (100 — <время простоя>/<длительность периода> * 100) = процент доступности за период

    Когда говорят об uptime/downtime, часто упоминают еще один показатель:


    MTTR (mean time to repair) — среднее время от начала инцидента до его окончания.
    Проблемы с ним начинаются прямо с первого слова в аббревиатуре. Учитывая, что все инциденты разные, усреднение длительности ни о чем в системном плане нам сказать не может.


    В этот раз мы не будем ничего усреднять, а просто посмотрим, что происходит в ходе инцидента.


    Анатомия инцидента


    Давайте посмотрим, какие значимые этапы можно выделить в ходе инцидента:



    • detection — интервал между первой ошибкой, которую мы отдали пользователю, до того, как дежурному пришло SMS
    • reaction — от получения уведомления о проблеме до момента, когда человек приступил к решению данной проблемы (обычно в этот момент событие в мониторинге переводится в состояние Acknowledged)
    • investigation — от начала работы над проблемой до момента, когда понятна причина инцидента и мы знаем, что нужно сделать, чтобы восстановить работу.
    • elimination — время восстановления, например, откатываем релиз, промоутим новый master primary сервер БД

    Возможно наша модель неполная и есть какие-то еще стадии, но предлагаю их вводить только после осознания, как это поможет нам на практике. А пока рассмотрим подробнее каждую стадию.


    Detection


    Почему вообще мы тратим время на обнаружение внештатной ситуации? Почему не отправлять уведомление при первой же ошибке, которую получил пользователь? На самом деле я знаю многие компании, которые пытались так делать, но от этой идеи отказывались буквально через несколько часов, за которые получили несколько десятков SMS. Я думаю, что не существует ни одного более-менее крупного сервиса, у которого бы не было постоянного "фонового" потока ошибок. Не все из них признак того, что что-то сломалось, бывают еще и баги в софте, невалидные данные полученные из формы и недостаточная валидация, итд.


    В итоге в качестве критерия для открытия инцидента используется уровень ошибок (или других метрик), которые превосходит ежедневные колебания. Именно это и приводит к тому, что уведомление ответственных сотрудников происходит позже фактического начала проблемы.


    Но вернемся к нашей изначальной задаче — снижению длительности инцидентов. Как мы можем сократить время обнаружения? Быстрее уведомлять? Придумывать супер-логику обнаружения аномалий?


    Я предлагаю пока ничего не делать, а посмотреть на следующие стадии, так как на самом деле они взаимосвязаны.


    Reaction


    Здесь у нас чисто человеческий фактор. Мы предполагаем, что мониторинг справился с обнаружением проблемы и мы успешно разбудили дежурного инженера (вся эскалация тоже отработала на предыдущем этапе).


    Рассмотрим "худший" случай, выделенной дежурной службы у нас нет, и алерт настиг мирно спящего админа. Его действия:


    • среагировать на SMS: тут очень помогает жена с чутким слухом, различные приложения для телефона, усиливающие эффект от получения SMS (1-5 минут)
    • принять решение о том, что из кровати он все-таки будет вылезать: если алерты настроены неправильно, человек может 2 минуты ждать "а вдруг придет resolve?" и уснуть (1-15 минут)
    • добраться до ноута, открыть глаза, проснуться, добраться до мониторинга, нажать Ack: (1-15 минут)

    В итоге в худшем случае получаем 35 минут реакции. По моим наблюдениям такое время реакции похоже на правду.


    Так как в на этом этапе мы имеем дело с людьми, нужно действовать крайне осторожно и продумано. Ни в коем случае не нужно писать регламент, согласно которому только что проснувшийся человек должен пошевеливаться! Попробуем просто создать условия.


    Давайте для начала уберем сомнения инженера в том, что проблема закончится сама. Это делается очень просто: сделать критерий алерта нечувствительным к мелким проблемам и уведомлять, если инцидент длится какое-то значимое время. Да, мы только что увеличили длительность стадии "detection", но давайте рассмотрим на примере:


    • увеличиваем время обнаружения на 5 минут
    • количество инцидентов снижается: все короткие всплески ошибок как правило укладываются в 1 минуту. Эти короткие инциденты нужно обязательно фиксировать, но без уведомления людей. Часто суммарно они дают очень большое время простоя, но разбираться с ними можно в рабочее время. Для этой задачи вам потребуется высокая детализация в мониторинге, так как проблема уже закончилась, а диагностические тулзы в большинстве своем не хранят истории.
    • если человек вынужден реагировать на алерты раз в месяц или реже, а не через день, он будет реагировать на это более адекватно и не относиться к этому как к рутине
    • отложенная нотификация позволяет человеку не думать: если SMS пришло, значит всё серьезно и само не исправится

    Потенциально такой подход позволит сократить суммарное время реакции, на 15+ минут. Если вас и такое время реакции не устраивает, стоит подумать о дежурной службе.


    Investigation


    Пожалуй, эта самая сложная стадия аварии, когда вам нужно понять, что происходит и что делать. В реальности эта стадия очень часто совмещена со стадией принятия мер, так как обычно процесс идет так:


    • смотрим в мониторинг, логи (если мониторинга недостаточно), запускаем еще какие-то диагностические тулзы
    • выдвигаем гипотезы
    • проверяем гипотезы, либо по метрикам, либо выполняя какие-то действия (рестартим все подряд:)
    • оцениваем результаты изменений
    • коммуницируем с коллегами, если ваших знаний о конкретной подсистеме недостаточно
      и так до просветления или окончания инцидента.

    Эта стадия обычно самая значимая в суммарной длительности инцидента. Как же ее уменьшать?
    Здесь все не очень однозначно, есть несколько векторов:


    • упрощать инфраструктуру: представьте, как быстро траблшутят люди, у которых одна база данных и один сервис
    • распространение знаний в команде: идеально, если коммуникация людей будет идти не в процессе инцидента, а во время ежедневной работы (коммуникация людей вообще очень долгий процесс)
    • мониторинг: многие думают, что мониторинг работает только на стадии "detection", но на самом деле он может выступать оптимизацией процесса проверки гипотез ("штатно ли работает БД?", "не уперся ли мой сервис в ресурсы?") и еще как транспорт распространения знаний в команде. "Серега, проверь, есть ли в логе X ошибки про дедлоки?" можно превратить в триггер, в описание которого будет ссылка на wiki с инструкцией.

    Elimination


    Как я говорил выше, эта стадия часто сливается с предыдущей. Но бывает так, что сразу понятна причина, но восстановление будет очень долгим. Например, у вас умер сервер с master primary (еще долго не смогу к этому привыкнуть:) базой данных, а реплику вы ни разу не промоутили, то есть вы будете читать документацию, раскатывать новый конфиг приложений итд.


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


    • инструментарий управления инфраструктурой: если для того, чтобы все починить вам нужно раскатить новый конфиг, но это делается минимум за 20 минут — это ваше ограничение. Попробуйте придумать сценарии, что может произойти и способ экстренного ускорения каких-то процессов. Например, в ansible у вас настроен serial (параллельность выполнения задач) = 3, но если все равно лежим, можно катиться с serial=30, нужно всех научить это переопределять (аналогично про rolling update strategy в kubernetes).
    • учения: если вы знаете вероятные сценарии отказа и восстановление у вас не автоматизировано, у вас должны быть инструкция, которая обязательно должна быть протестирована. Запланируйте downtime (если нужно), проведите учения. Часто на этом этапе такие кейсы автоматизируются, так как в процессе учений выясняется большинство подводных камней даже самых сложных на первый взгляд процедур.
    • взаимодействие с подрядчиками: вы должны заранее знать, что будете делать, если вашему хостеру станет плохо. Часто осознание вероятности проблемы и затрат на закрытие рисков приводит к выводу — "просто будем ждать восстановления". Но с другой стороны к такому сценарию будут готовы и инженеры и бизнес. Например, можно проработать вопрос с переключением вашего трафика на заранее заготовленную заглушку, уведомить пользователей заранее заготовленным письмом итд. Или наоборот, вы делаете инструкцию, по которой мы даем хостеру 30 минут на восстановление, а дальше начинаем переезд в другой ДЦ, где уже есть реплика БД, но нужно развернуть все остальное. И здесь опять же учения, засекаем время на переезд итд.

    MTBF (Mean Time Between Failures)


    Еще один распространенный показатель, который упоминают при обсуждении uptime. Я предлагаю опять ничего не усреднять, а просто поговорить о количестве инцидентов, которые случаются за интервал времени.


    Здесь на первый план выходит вопрос, насколько вы позаботились об отказоустойчивости вашего сервиса:


    • есть ли единые точки отказа (SPOF) в инфраструктуре, какова вероятность отказа?
    • насколько вы уверены, что нет SPOF, о которых вы не знаете? (это ровно та проблема, которую решают с помощью chaos monkey)
    • хорошо ли балансировщики нагрузки отрабатывают отказы? (мой доклад про балансировку)
    • насколько отказоустойчива сеть?
    • насколько надежен датацентр?

    Иногда, чтобы все это просчитать/спрогнозировать делают "карту рисков", где у каждого сценария (который смогли предположить, естественно всегда остаются те, которых мы пока не знаем) есть вероятность + эффект воздействия (даунтайм короткий/длинный, потеря данных, репутационные потери, итп). Потом по такой карте планомерно работают, закрывая в первую очередь высоковероятные и серьезные по воздействию сценарии.


    Другой прием, который можно использовать — классификация прошедших инцидентов. Сейчас много говорят о том, что очень полезно писать "разборы" (post mortem) инцидентов, где анализируются причины проблемы, действия людей, прорабатываются возможные будущие действия. Но чтобы быстро взглянуть на причины всех аварий за прошлый период удобно просуммировать их длительность с группировкой по "классам проблем" и там где больше всего downtime принимать меры:


    • человеческие ошибки: снижать количество ручных действия в production, разные защиты от ошибки операторов
    • неудачные релизы: стоит улучшать тестирование (в том числе нагрузочное)
    • ошибки в приложениях: чинить утечки, крэши и другие "зависания"
    • сеть: купить оборудование, настроить, нанять сетевиков, сменить подрядчика
    • базы данных: нанять DBA, позаботиться про отказоустойчивость, купить железо получше
    • ДЦ: думать про резервный или переезд
    • внешние воздействия (ddos, блокировки, отзывы сертификатов, домены): купить antiddos, запастись проксями, замониторить срок действия доменов/сертификатов, иметь несколько сертификатов от разных CA.

    То есть, если даже не пытаться предугадать возможные сценарии проблем, то работать с уже случившимися инцидентами определенно стоит.


    Итого


    Все инциденты разные:



    Алгоритм работы над увеличением uptime очень похож на любую другую оптимизацию:


    измеряй -> анализируй -> пробуй улучшить -> оценивай результат

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


    Наш сервис мониторинга помогает не только со стадией "detection", но и сильно сокращает " investigation" (клиенты подтвердят)

    okmeter.io

    72,00

    Осмысленный мониторинг серверов и сайтов

    Поделиться публикацией
    Комментарии 13
      0
      У всех есть много скелетов в шкафу в связи с мониторингом, но я горжусь, что в наших системах, помимо скелетов умершего техдолга, есть достаточно много проверок, дающих несколько warning/critical в неделю, которые устраняются до того, как задевают клиента. Не то, чтобы это было всегда и во всём, но само наличие таких штук — гордость.
        0
        Мониторящих инженеров тоже 10?
          0
          Если честно, я не знаю размера нашего operations, но он довольно эффективен — инсталляций у нас сильно больше, чем инженеров operations team.
            0
            Как получается не увеличивать операционщиков при расширении парка? Эта зависимость — почти линейная.
              +1
              Она линейная, если работа операционного отдела не оптимизируется. Если выделить чуть-чуть времени на оптимизацию самой частой операции операционного отдела (сама операция меняется от захода к заходу, упор на «самую частую за последнее время»), то кривая становится ближе к логарифмической. Постоянно нужно вкладывать константное количество усилий на автоматизацию и оптимизацию всё большего потока событий. В идеальном мире это кривая костантная прямая (т.е. оптимизируются всё), но в реальном мире растёт число плохооптимизируемых процессов. К счастью, они растут медленнее, чем количество инсталляций.

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

              PS Надо различать operations и on-site. Замена жёстких дисков, увы, процесс физиологический и требует от реального человека потыкать сервер. Зато задачу на замену диска и всё софтовое после замены (файловая система и т.д.) может сделать робот. Сам.

                0
                На практике получается, чтобы кривая была логарифмическая, необходимо просто «грузить» ИТ персонал больше, сделать, например из одной позиции — 2, а то и 3. Непокорных — выгнать. Тогда, вероятно ваши слова имели бы смысл. Но возможно просто у меня такой стереотип об оптимизации. Во всех конторах где я трудился — не важно какой там CIO — имбицил или спец с XX-летним стажем, оптимизация начинается именно с «нагружания» персонала, а тут, как ни крути и 12-ти часовой рабочий день, и выгорание, и даже пьянство на рабочем месте (не я сам, но приходилось у коллег и такое наблюдать) и все остальное. Получилось ли у Вас сделать так, чтобы и волки были целы (оптимизировать ИТ) и овцы целы (чтобы админы не расползлись в другие конторы)?
                  0
                  Очевидно, что для выделения 20% времени персонала на автоматизацию, эти 20% можно сделать одним из трёх видов: добавить персонала, уменьшить operational нагрузку на персонал или увеличить общую нагрузку (добавить 20%). Это как с капитальными инвестициями. Их можно делать за счёт заёмных средств (с надеждой, что отобъётся), можно за счёт собственных средств (забирая оборотные средства), а можно за счёт снижения прибыли (выплат акционерам/владельцам).

                  С практической точки зрения на уровне микроменеджмента, этот вопрос решается подбором кадров — обычно те, кто умеют автоматизировать, либо прагматичны и хотят за это много денег (и тогда делают ровно то, что их попросят), либо рок-звёзды (денег меньше, зато надо мириться с их архитектурными и технологическими предпочтениями), либо нерды (и тогда надо отдельного человека для трансляции их умной работы в business value).

                  Во время текучки кадров на следующую позицию искать человека, у которого в обязанностях с самого начала будет заявлена автоматизация, и дальше с такого человека спрашивать на 50% за автоматизацию (а не только на operation).
                    0
                    Вот о том я и говорю — берется как правило 3-й вариант — увеличить общую нагрузку, только как правило она увеличивается не на 20%, а скажем, от 100% и выше. Кстати, чем меряете те 20%? Часами, KPI-ями, кол-вом закрытых инцидентов/тикетов? В реалии нигде не сталкивался с грамотным просчетом таких цифр, зачастую они просто берутся с потолка, никто со сбором статистики не парится особо, т.к. ее сбор (внезапно) тоже ресурсоёмок. Итог — одна позиция пашет как минимум за 2-х, в том числе и за те 20% оптимизатора. Не забываем, что операционка далеко не статична и тоже растет (как это модно называть — расширяются компетенции сотрудника/отдела, условно — работал человек эникеем — на ему ВЭБ-сайт и АТС-ку в операционную нагрузку — профит — сэкономили на вэбдизайнере (сайт-админе) и телефонисте (инфраструктурном админе), теперь админ может заниматься оптимизацией, но нагрузка а эникея возросла минимум на 100% и так что 2-й вариант тоже не вариант, операционка не уменьшается никогда — это аксиома, за исключением «схлопывания» конторы. Я уже 3-й раз переживаю за свою карьеру подобное «расширение компетенций», реально уже бесит такой подход сверху. Как-то хочется не допускать такого обращения с собой, но вероятно, мне не хватает опыта правильно сказать «Нет!» руководству и чтобы после этого не было последствий (без выговоров, матов и мордобоя). Первый также вариант отпадает — расширять ИТ-персонал никто не будет, по крайней мере до того как, человек, работающий за 3-х, не пошлет работодателя, когда на него соберутся вешать очередную операционку 4-го человека. Было — проходили, во все конторы после моего ухода берут минимум 2 человека, т.к. один новый человек со старта просто тупо не потянет тот пул операционки.
                      0
                      В такой компании не может быть системной автоматизации. Почему? Потому что им нечего автоматизировать. Отдать на аутсорс всё хозяйство, да и всё.

                      Автоматизация подразумевает существенный фронт работ, и процессы, которые можно автоматизировать. Как можно автоматизировать работу эникея, у которого половина работы — общение с людьми? Засунуть всё в трекер? Это не автоматизация, это организационные изменения и к автоматизации не имеет отношения.

                      Вообще, малый энтерпрайз образца 2000ых (своя АТС, свой веб-сайт на своих мощностях, свой админ с AD, принтерами, рабочими станциями, свой почтовый сервер, свой колхозный ДЦ, возможно, своё видеонаблюдение) — это тупиковый путь. Хотя и отличный карьерный трамплин для тех, кто оказывается в таких конторах в качестве админа в первый раз. (Но главное свойство трамплина — либо он тебя подкидывает, либо ты слетаешь с него в какую-то дыру — т.е. это не работа на пол-жизни).

                  0
                  И еще — нельзя просто так взять и начать оптимизацию ®. Для нее нужны ресурсы — но ни менеджмент, ни проектировщики, ни аналитики, а банально руки и мозги админов.
                    0
                    Именно. Хорошая автоматизация operation'а идёт по одному из двух направлений: автоматизация снизу (себе сделали удобно) и автоматизация сверху (начальство себе сделало удобно). Оба варианта имеют право на существование, но автоматизация снизу обычно даёт количественное улучшение, а автоматизация сверху — качественное.
          0
          Вы эти показатели считаете как-то автоматом или вручную по каждому крупному инциденту?
          Если автоматом, то хотелось бы подробнее узнать как, особенно по detection.
            0

            Автоматом можно надежно посчитать только время от уведомления до Ack.
            Detection можно глазами на графиках увидеть: начались ошибки/провал бизнес-метрик, а уведомление мы знаем когда было.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое