Меня зовут Илья Вазем, я отвечаю за всю инфраструктуру в СберМегаМаркете. Сегодня мы поговорим о наболевшем для любой команды разработки — об инцидентах. Я расскажу о том, как мы пытаемся с ними справляться и сводить возможность их появления к минимуму. А по ссылке можно посмотреть видео с моего доклада на DevOps Conf. 

СберМегаМаркет, наш маркетплейс, — высоконагруженная онлайн-платформа, где более 8 000 продавцов и более 100 000 заказов в день. Мы хостимся в трех дата-центрах, у нас 250 микросервисов, 2 500 виртуальных машин. Поддерживать такую систему без серьезного подхода к инцидентам невозможно. Итак, что представляет собой этот подход в нашем случае?

Проблема и инцидент: причина и следствие

Для начала немного теории. Многие разработчики объединяют понятия «проблема» и «инцидент». Но, например, IT-специалист и автор тренингов по ITIL Майкл Скарборо (Michael Scarborough) говорит, что проблема — это причина, а инцидент — следствие. Если заниматься только устранением инцидента, то это решение лишь на короткий срок. Эксперт в области ITSM профессор Росс Вайз (P. Ross S. Wise) говорит, что проблема — это причина возникновения инцидента. На проблему указывает вопрос «почему?», который мы задаем при инциденте.

Допустим, у нас упал сайт. Это инцидент. А вот проблема может заключаться в баге в релизе, который должным образом не протестировали. Другой пример — у нас недоступна база (инцидент), потому что кончилось место на диске (проблема). Если это касается экспериментального стенда, то проблема незначительная. Но если подобное произошло на продовой базе, то у нас могут быть очень серьезные последствия, даже потеря сайта, и просто пытаться поднять базу недостаточно, надо решать проблему.

Чтобы определить, возник ли у нас инцидент, задайте себе четыре вопроса: 

1. Можно ли пользоваться услугой?

2. Пострадали ли бизнес-процессы?

3. Ухудшилась ли функциональность услуг?

4. Пострадало ли качество предоставляемой услуги? 

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

Итак, инцидент — это любое событие, которое дестабилизирует работу стандартной услуги, ограничивает ее доступность и функциональность.

Какие события в IT чаще всего приводят к возникновению инцидента? Неудачные релизы, неполадки в дата-центре, с железом, с приложениями, с сетью, внешние воздействия (DDOS-атаки, отзывы сертификатов, отсутствие алертинга на продление доменов). Еще причиной инцидента могут быть плановые работы. Хотя к ним вроде готовятся, но команды бывают разные, и даже плановые работы могут привести к инцидентам.

Когда наша компания была стартапом, и в те времена доступ на прод был у всех, начиная с техдира и заканчивая разработчиком. Разработчики сами писали миграции, переезжали с одной схемы на другую, занимались оптимизацией. Но в какой-то момент наша база жестко легла. Об этом узнали все, сайт не работал, мы долго решали проблему. После этого случая был тяжелый разбор полетов, и мы решили внедрить практику написания post-mortem’ов. Но о них речь пойдет ниже. Сперва разберемся в теории инцидентов.

Жизненный цикл инцидента

Стандартный жизненный цикл инцидента описывается простой схемой: обнаружение — реакция — расследование — восстановление. Вкратце остановимся на каждом из этих пунктов.

Как происходит обнаружение инцидента? У нас для этого предусмотрено пять способов: алерты и сообщения в чат, письма на почту, звонки и смс дежурному. Днем больше актуальны алерты и сообщения в чате, а в неурочное время — звонки и смс. Почему мы используем смс? Дежурный может спросонья ответить на звонок, пообещав решить проблему, и продолжить спать. Но через несколько секунд приходит смс с транскрипцией разговора, чтобы он мог еще раз посмотреть и понять, что на самом деле возник инцидент и нужно решать проблему.

Реакция на инцидент у нас происходит в режиме «броска кобры» и состоит из пяти этапов: фиксация проблемы, классификация, эскалация, уведомление об инциденте и сбор оперативной рабочей группы. Первый этап, надеюсь, всем понятен, второй в каждой компании будет свой, потому что у всех своя приоритизация и классификация инцидентов. Поэтому поговорим о последних трех.

Эскалация в нашей компании основана на шаблоне карточки мониторинга в комплексной системе зонтичного мониторинга. В карточке указывается имя алерта, владелец, набор ссылок на регламент реагирования, ссылки на support card, план эскалации, митигации, различные теги, номера телефонов, адреса электронной почты и дополнительная информация, которая поможет дежурному максимально быстро среагировать на инцидент.

Уведомления об инциденте у нас сейчас настроены довольно просто. Есть всего два типа уведомлений: почтовая рассылка и сообщение в чат о статусе каждые 15 минут, если случилось что-то страшное, и мы не совсем понимаем, когда решим проблему. 

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

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

Лидером в оперативной рабочей группе, если проблема лежит на срезе между продуктом и инфраструктурой, становится дежурный админ. Если проблема полностью завязана на бизнес-продукт, фичу, сервис, интеграционную платформу, то ответственным назначается владелец сервиса или его заместитель по группе. Все эти регламенты расписаны у нас в плане эскалации. В оперативную группу также входят ответственные из области влияния проблемы и компетентные в этой области системные администраторы.

Этап расследования у нас состоит из четырех пунктов. Сначала мы собираем алерты в кучу, далее выдвигаем гипотезы в рамках ранее собранной рабочей группы. Если гипотез несколько, то распределяем их по членам группы в зависимости от того, насколько сложна проработка каждой. При этом параллельно смотрим логи. И так ходим по кругу, прорабатывая каждую гипотезу, пока не выйдем на верный путь.

Для расследования мы пользуемся несколькими инструментами. Grafana отрисовывает метрики из Zabbix, Prometheus и VictoriaMetrics; логи собираем в EVK (Elastic — Vector — Kibana) и практически весь кастомный мониторинг у нас находится в комплексной системе зонтичного мониторинга.

Часто инциденты решаются не в один клик и не за одну минуту. Иногда бывает, что они не решаются даже за час. Тут важно уведомлять всех заинтересованных: клиентов, заказчиков, партнеров, коллег по смежному отделу. Мы следуем принципу открытости.

Также не стоит забывать и про план Б. Когда мы понимаем, что решение проблемы затягивается, и не уверены, что, например, длинное восстановление базы из тяжелого дампа точно устранит инцидент, мы переходим к плану Б. Например, у нас есть некий MVP или workaround, который мы сможем вставить в сервисное взаимодействие, чтобы наладить доступность услуги, которая вышла из строя.

Что можно сделать, чтобы время восстановления было минимальным? Прежде всего необходимо прорабатывать инструментарий управления конфигурациями. Это может быть автоматизация, основанная на Ansible, Chef, Puppet — неважно, какой инструмент вы выберете, главное, описывайте все кодом, автоматизируйте, заворачивайте все в красивые пайплайны с проверками. Далее создавайте инструкции и регламенты, следите за их актуализацией. То, что невозможно автоматизировать, поручайте под чью-либо ответственность. Например, у нас за актуализацию документации по сервису и стеку отвечает владелец этого стека.

Плановые учения также могут сократить время восстановления. Многие их боятся, считают их лишними, но, проведя их один раз, вы поймете, как много узких мест есть в ваших сервисах и инфраструктурных узлах. В результате вы сможете лучше подготовиться к будущему инциденту. После учений ваши действия перестанут быть хаотичными, у вас появится возможность создавать хорошие DRP-модели, приводящие к успеху за минимальное время. Особенно если модели автоматизировать.

И еще для быстрого восстановления важно взаимодействие с подрядчиками. Кто-то может пользоваться услугами облачного провайдера, кто-то — услугами colocation или Anti-DDoS. Важно иметь возможность быстро связаться с подрядчиком, например, знать все телефоны дежурного, уметь с ним правильно взаимодействовать, обозначать приоритеты таким образом, чтобы ваша заявка всегда была у подрядчика в топе, когда у вас возникает критический инцидент. Проработайте эти вопросы со всеми поставщиками услуг.

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

Post-mortem

Post-mortem — это задокументированный отчет, который хранит в себе подробную информацию об инциденте, его причинах, следствиях, широте влияния и наборе превентивных мер. Основные цели создания post-mortem — это изучение инцидента, документирование, понимание основных причин его возникновения и принятие превентивных мер.

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

После написания post-mortem мы собираемся оперативной группой, которая участвовала в устранении инцидента, и проговариваем все моменты, формируем ретроспективное видение того, что можем сделать, чтобы такое больше никогда не повторилось. Разбираемся, как можно превратить ту или иную особенность нашего сервиса в его сильную сторону. В результате обсуждения мы создаем набор задач с блокирующим приоритетом, ответственность за решение которых возлагается на тимлида или руководителя отдела. Затем обозначаем исполнителей и сроки.

Наш шаблон post-mortem’а состоит из трех частей: шапка (краткая информация об инциденте, 1–2 предложения), описание инцидента и подробный отчет.

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

Краткое описание состоит из нескольких предложений об инциденте, его продолжительности, серьезности и влиянии.

Подробный отчет начинается с последовательности событий, которые привели к инциденту. Важно тщательно все вспомнить, найти чаты, звонки, все собрать в кучу. Далее мы описываем влияние инцидента на финансово-экономическую часть, на репутацию, на пользователей. В нашей компании нужно указать количество потенциально потерянных клиентов (постоянных и новых), объем GMV (Gross Merchandise Volume). 

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

В подробном отчете post-mortem’а мы также указываем, как инцидент был устранен, описываем все пути и предлагаем идеи, как можно сократить время восстановления в подобных случаях. Все эти идеи мы обсуждаем на ретро-встрече оперативной группы.

В post-mortem’е нужно также указать таймлайн инцидента — описать все события поминутно или даже посекундно. Также необходимо четко прописать установленную причину инцидента. А еще важно указывать связанные инциденты. Если по поводу подобных случаев уже составлялся post-mortem, то можно указать ссылку.

Не забывайте, что post-mortem нужно писать в кратчайшие сроки, по свежим следам, пока информация свежая, никто не уволился, не ушел на больничный, не потерлись логи и не сломались метрики.

После того, как вы написали post-mortem, обсудили его внутри команды, публикуйте результаты для сотрудников. Если у вас в компании действует принцип открытости для всех, сделайте отчет общедоступным. Мы результатами обсуждения делимся с отделом бизнеса. Он у нас ведет собственный учет инцидентов, поэтому по каждой неприятной ситуации сотрудники могут впоследствии посмотреть, что произошло и что будет сделано для предотвращения подобного в будущем.

Плановые работы

При плановых работах мы ломаем продакшн, потому что хотим что-то в нем изменить, и, возможно, в это время будет downtime. Поэтому для проведения таких работ требуется план.

Плановые работы у нас состоят из следующих этапов. Сначала формируется задание в тикетной системе. Потом мы составляем план работ. Далее следует согласование со всеми, кого эти работы могут затронуть. Желательно начать его пораньше, чтобы все успели ознакомиться с планом. Если по какой-то причине нельзя провести работы в указанное время (например, уже запланирован серьезный релиз), ответственный за сервис сможет вовремя об этом сообщить.

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

Задача в тикетной системе — это, по сути, некий исходник, который включает в себя описание работ, кто, что и когда будет делать, что будет меняться, и что мы ожидаем получить в результате.

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

Как видно из таблицы, каждый этап делится на шаги. У каждого шага — название и описание действий. Это описание мы делаем максимально подробно. Колонка «Статус» нужна для того, чтобы в случае инцидента сразу понять, на каком этапе все пошло неправильно. Еще в предварительном плане мы отмечаем, кто осуществляет те или иные работы и в рамках какой задачи.

Таблица с описанием проведения работ — самая важная часть. Здесь нужно фиксировать каждый шаг — какую команду вводим, с какими ключами, на каком сервере, с какой базой данных, и так далее. Логинов и ключей здесь нет, но все действия расписаны подробно, для того чтобы, если мы проводим работы утром (мы часто делаем это часов в 5–6, когда у нас не праймтайм, и если что-то пойдет не так, влияние будет минимальным), у инженера из-за недосыпа не возникли какие-то неожиданные идеи, что делать дальше. Во время работы мы шаг за шагом заполняем все пункты, прописывая, за какими показателями, метриками, логами, спейсами надо следить.

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

В таблице «Завершение плановых работ» мы описываем все шаги, которые нужно будет сделать, чтобы убедиться в стабильности нашей системы. Проверки могут быть автоматизированными, могут запускаться после окончания работ, если вы завяжете их на пайплайны. Можно что-то посмотреть и в ручном режиме.

Еще одна важная часть плана — откат (возвращение на прежнюю стабильную версию продукта). Здесь мы прописываем каждый шаг, где и как вернуться к предыдущему стабильному состоянию. Таблица с шагами по откату связана с таблицей по проведению работ. Когда мы понимаем, что в какой-то момент у нас что-то пошло не так, у нас есть пункт из таблицы с откатом, где указано, какие нужно выполнить действия, ввести команды, чтобы вернуться назад.

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

И последний совет по плановым работам — не забывайте про рассылку, уведомляйте обязательно о начале и завершении работ.

Support cards

Support cards (карты поддержки) — это документ, в котором записана вся необходимая информация о сервисе, чтобы передать его другой группе, например, в техническую поддержку или дежурному администратору. Support cards повышают уровень знания систем, формируют библиотеку с подробным описанием каждого сервиса. Так уменьшается время устранения инцидента, упрощается онбординг новых сотрудников, предотвращается bus-фактор.

Все support cards у нас имеют идентичную структуру. Они включают в себя общее описание сервиса, технологии, процесс деплоя, мониторинг логирования, критические зависимости, технологические окна, инструкции к кейсам.

Общее описание состоит из названия сервиса, описания основного функционала, указания команды и ответственного за сервис, уровня критичности — при возникновении проблемы мы должны знать, важный сервис у нас захромал или второстепенный. Еще в общем описании стоит указывать статус сервиса — работает ли он в продакшене или пока в разработке либо на тестировании. Возможно, он вообще не используется, и во время инвентаризации его можно погасить.В компаниях часто возникает проблема, связанная с сервисами-сиротами. Например, 10 виртуалок обслуживают 20 контейнеров, и все это работает на сервис, который давно не используется, а ресурсы под него выделены. Иногда такое происходит из-за того, что за support cards следит разработчик, а до команды инфраструктуры информацию о приостановке сервиса он не довел. 

Support cards помогают при инвентаризации, с их помощью легко понять, какую часть инфраструктуры можно просто погасить.

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

В описании деплоя указываем инструменты для сборки (Jenkins, Gitlab, TeamCity — у каждого свой). Это особенно важно, если у вас несколько систем, прикрученных к CI/CD. Указываете окружение, что является девом, тестом, продом, предпродом. И ссылки на джобы и пайплайны для быстрого перемещения к адресату.

В описании мониторинга и логирования прописываем все метрики. Есть много метрик, общих для всех систем и сервисов, но у каждого сервиса есть что-то конкретное, уникальное, кастомное. Это нужно обязательно указать. Иначе велосипеды и костыли очень не вовремя дадут о себе знать.

Мы обязательно прописываем ссылки на борды и healtchecks касательно мониторинга и ссылки на спейсы и фильтры с логами, чтобы при возникновении инцидента с каким-то сервисом достаточно было открыть support card, нажать эту строчку и выйти на нужный фильтр или спейс с набором фильтров.

Критические зависимости имеют две части. Первая — инфровая, в ней прописаны базы данных, индексы, шины данных, Kafka и Rabbit. Здесь нужно указать, с чем взаимодействует сервис, и все, что нужно для его работоспособности. Удачное решение — внести из инвентаризации набор тех серверов и кластеров, где хостятся ваши сервисы. 

Вторая часть критических зависимостей — сторонние приложения, которые необходимы для межсервисного взаимодействия. Микросервис сам по себе существовать не может, либо его функциональность ничтожна. Например, у нас для оформления заказа нужен набор из 50-ти микросервисов, и в зависимостях желательно оказать всех этих товарищей, особенно близких по рангу. 

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

Еще одна часть support cards — технологические окна. Если у ваших сервисов есть технологические окна, то есть их на время можно остановить, нужно это обязательно указать. Есть сервисы, которые легко остановить в любой момент. А есть те, у которых аптайм (uptime) должен приближаться к 100%. Обязательно прописывайте эти моменты. Если сервис можно потревожить, то указывайте, когда и при каких условиях.

И последняя часть support cards — это инструкции по кейсам. Сюда входит описание возможных либо пережитых проблем. Со вторыми легче — мы просто указываем ссылку на post-mortem. В первом случае мы пишем небольшую инструкцию, как решить возможную проблему. Инструкции могут превратиться в регламент взаимодействия с процессом, который поможет избегать инцидентов. Важно также описать правила эксплуатации сервиса. Часто возникают нюансы, которые вроде и нельзя назвать проблемой, но в то же время что-то работает не так, как хотелось бы, и подобные явления важно описывать.

Заключение

Не стесняйтесь фиксировать инциденты и сообщать о них. Следуйте принципу открытости, пишите post-mortem’ы, обсуждайте их. Никогда не заметайте проблемы под ковер, так под ним может вырасти холм, о который вы споткнетесь сами, и при этом вряд ли упадете на ковер — а скорее, на бетонный пол. Проводите плановые работы правильно, уведомляйте о них и всегда следуйте согласованному плану. Описывайте свои сервисы в support cards. Это окажет помощь и вам самим, и вашим потомкам.

Напоследок рекомендую ряд неплохих материалов по риск-менеджменту:

• Посреди пепелища: пост-мортемы как инструмент непрерывного улучшения / Марат Киньябулатов

• Настраиваем инцидент-менеджмент: от хаоса до автоматизации / Сергей Бухаров (Dodo Engineering)

• Аварии помогают учиться / Алексей Кирпичников (Контур)