Всем привет! Меня зовут Алексей Мерсон, я несколько лет работал Developer Advocate в Sage, платформе наблюдаемости Т-Банка. Эта платформа сама по себе очень немаленькая, со сложной архитектурой. Но если посмотреть на ландшафт экосистемы в целом, то Sage — всего лишь одна из платформ в Т-Банке, необходимых, чтобы наши услуги были надежными. А платформы, в свою очередь, — это тоже только часть более общей картины.
В этой статье хочу поговорить о том, какие инструменты и практики мы используем для надежности в Т-Банке. Уделим внимание работе с инцидентами. И отдельно сфокусируемся на клиентском опыте: мне кажется, мы, инженеры, часто забываем, что технологии делаются не ради технологий, а ради решения задач бизнеса и его клиентов. Если они будут довольны, то и у нас будет больше возможностей заниматься интересными нам вещами.
Что такое надежность
В Т-Банке мы описываем качество пирамидой.
Вверху пирамиды — enjoyment и experience: это клиентский опыт, насколько удобно пользоваться услугой, насколько она выполняет задачи.
В основе пирамиды лежит надежность. Очевидно, что если услуга ненадежная, то о каком клиентском опыте можно говорить? Услуга не работает, нет никакого клиентского опыта.
Если посмотреть в Google SRE Book, можно найти определение: надежность — это вероятность, что система выполняет заданные функции без отказов, в заданных условиях, на заданном периоде времени. Если упростить и немного перефразировать:
Надежность — это вероятность, что система будет работать.
Как понять, что система работает
Возьмем для примера лифт. Мы вызвали лифт, сели, поехали, вышли на нужном этаже. Вроде бы система «лифт» работает, мы же доехали до нужного этажа. А если там свет не горел в кабине? Вроде бы все равно работало, но что-то не так. Как будто бы клиентский опыт пострадал.
Пример приводит нас к мысли: чтобы понять, работает ли система, нужно ее поделить на разные услуги — и у этих разных услуг будут разные требования к надежности. Тут появляются три замечательных понятия: SLI, SLO, SLA.
SLI, или Service Level Indicator, — это показатель работоспособности услуги. Например, это может быть процент операций, выполненных успешно, относительно общего количества операций.
Важно, что SLI должен быть связан с клиентским опытом, с конечным потребителем услуги. Ведь если мы в качестве индикатора возьмем, например, uptime базы данных, а перед ней стоят балансеры, которые перестали работать , то базе данных будет хорошо и легко — ведь на нее не приходят запросы. Но клиенты при этом будут страдать.
SLO, или Service Level Objective, — целевое значение SLI. Например, 99% операций должно выполняться успешно.
SLA, или Service Level Agreement, — последствия нарушения SLO, что-то вроде компенсации по договору. Смысл SLA в том, что мы обещаем, например, вернуть деньги за услугу, если SLI упадет ниже SLO.
Но в индустрии прочно укоренилась история, когда говорят: «SLA — две девятки, три девятки, пять девяток». И с этим невозможно ничего сделать, так уже все привыкли. Поэтому ниже я буду использовать SLA именно в этом смысле.
Бюджет ошибок — еще один параметр надежности. По сути, это величина, обратная SLA. Если у нас SLA 99,99%, значит, на одну сотую процента времени система имеет законное право прилечь. Если это время пересчитать на промежутке в год, то 99,99% означает, что бюджет ошибок — 52 минуты 35 секунд: ровно столько система может не работать за весь год. Тогда получается, что:
Надежная система — это система, которая работает все время за вычетом бюджета ошибок.
Периоды downtime можно разделить на две части: плановый и внеплановый. Плановый downtime — это то, что вызвано разными сетевыми работами, миграциями данных, деплоем новых фич, обновлением железа и так далее.
Внеплановые даунтаймы — инциденты, которые не происходят по расписанию, если это не деплой в пятницу. Они как-то случайно распределяются по времени работы системы.
Если мы все периоды даунтайма сложим, поделим на количество даунтаймов и найдем среднее арифметическое, то получим характеристику надежности MTTR — mean time to repair, то есть сколько времени в среднем мы проводим в даунтайме.
А если мы то же самое сделаем с периодами аптайма, то получим величину MTBF — mean time between failure, время, которое мы в аптайме в среднем до следующего фейла.
MTBF и MTTR можно связать с бюджетом ошибок, и это дает нам формулу надежности, которая описывает математически, что мы должны делать, чтобы оставаться в бюджете ошибок. Важно, что в этой формуле бюджет ошибок не в абсолютных величинах, а в проценте времени даунтайма относительно общего времени работы системы.
Чтобы оставаться в бюджете ошибок, нам нужно увеличивать MTBF и уменьшать МТТR. Другими словами, нужно уменьшать количество и длительность периодов недоступности.
Кажется несложным. Единственная проблемка: есть такая буковка M, она как будто бы всего одна буква, но имеет очень большое значение, потому что M означает mean — среднее. А среднее означает, что нам нужна статистика для вычисления. А статистика означает, что нам нужно собирать кучу данных, нужно их где-то хранить и как-то анализировать. Все это приводит к тому, что нужно строить наблюдаемость.
Наблюдаемость системы
Раньше в Т-Банке был зоопарк различных инструментов, связанных с мониторингом, но мы в итоге смогли заменить все на единую платформу наблюдаемости — Sage.
Нам очень повезло:
Мы data-driven-компания — это значит, что у людей уже майндсет на то, что нужно собирать и анализировать данные, нам не приходилось проводить какую-то психологическую трансформацию.
Мы digital-only-экосистема — у нас нет офисов, все в цифровом виде, а это значит, что данные уже готовы к тому, чтобы их собирать. Например, нам не нужно ставить в офис какие-то хитрые рамки или умные камеры, чтобы посчитать количество обратившихся за услугой клиентов.
У нас миллионы пользователей, а это значит, что мы получаем хорошие статистические распределения. Нам не нужно из 10 пользователей делать какие-то выводы, у нас огромные выборки — и все готовые данные уже есть.
Но было и то, в чем нам не повезло:
Мы data-driven-компания — значит, как только появляется инструмент наблюдаемости, все в него ломятся лить данные и как-то анализировать. Получается огромная нагрузка, и платформе довольно тяжело в первые периоды жизни.
Мы digital-only-экосистема с миллионами пользователей и с кучей услуг. У нас огромное количество данных, их нужно собирать и хранить, по ним нужно искать. Это был большой челлендж, который мы решили, и сейчас система живет довольно хорошо и стабильно.
От всего этого мы получили профит для надежности в том, что мы быстрее обнаруживаем проблемы, у нас меньше время реакции, а значит, наш MTTR будет уменьшаться.
Мы понимаем, как работает экосистема. У нас есть наблюдаемость, мы видим, что и где сбоит или, может быть, скоро пойдет не так. Мы можем измерить результат усилий, которые направляем на прокачивание надежности. И это очень важно, иначе непонятно, как контролировать успех.
Но возникает вопрос: а SLA-то где? Мы же говорим, что надежность — это бюджет ошибок, бюджет ошибок связан с SLA.
Прежде чем говорить о SLA, надо понять, как его описывать. Чтобы внедрить идею SLA в компанию, нужно договориться о терминах: что такое доступность, сбой, что такое плохая минута, хорошая минута, как их учитывать.
Потом нужно составить каталог услуг и инвентаризировать все услуги, потому что SLA — это же S, то есть сервис, услуга. А что такое услуга? Выдача кредитной карты — это уже услуга или нет? А может быть услуга больше или меньше? Какая гранулярность у этих услуг должна быть?
Это была огромная задача, которая заняла очень много времени. Но сейчас каталог услуг у нас есть и к нему уже привязаны SLA.
А дальше нужно создать или купить инструмент, в котором будем описывать все эти SLA, услуги, требования к услугам. И для нас такая система — это FineDog, инцидент-менеджмент-система Т-Банка, в которой мы ведем учет надежности: SLA, услуг и всего, что с этим связано. Мы видим здоровье услуг и экосистемы в каждый момент.
В Sage мы видим, какие показатели самой механики услуг ломаются и могут привести к инцидентам. А в FineDog мы видим уже сами инциденты, то есть нарушение SLA услуги, к которому привели какие-то нарушения в работе.
Управление релизами
Для надежности нужно управлять релизами, ведь каждый инженер знает, что деплой — это не к счастью, деплой — это к проблемам. На масштабе в десятки миллионов клиентов и в тысячи или даже десятки тысяч сотрудников уже нельзя просто договориться между собой. «Ты сейчас не кати в прод, я сейчас буду катить» — так уже не работает.
У нас много людей, продуктов, и хотя мы еще используем чат-опс, чтобы координировать релизы, но давно уже поняли, что этого недостаточно. Представляете, в какое количество чатиков нужно сходить, чтобы объявить фичафриз на всю компанию или хотя бы на уровне одного управления?
Поэтому мы сделали свой инструмент для управления релизами — Колобок. Теперь у нас есть единое место, единый источник правды о том, какой релиз когда будет.
SRE-инженеры смотрят в календарь релизов в Колобке, видят, что запланировано, и это помогает им быть готовыми к каким-то проблемам, когда эти релизы идут. Таким образом мы уменьшаем время реакции, уменьшаем количество инцидентов и повышаем надежность.
Локально разные команды могут делать свои штуки. В Sage, например, используется светофор:
В соответствии с разными критериями светофор может быть красным, желтым или зеленым. Красный — нельзя релизить вообще, желтый — можно, но с разрешением от SRE-инженера, а зеленый — можно релизить без разрешения. Критерии: выходной или будний день, рабочее или нерабочее время, есть ли сейчас критические сбои и так далее.
Контроль качества
Для надежности нужен контроль качества, оно напрямую влияет на отсутствие или присутствие инцидентов.
Мы большие фанаты GitOps, стараемся все делать как код. Мы можем проводить ревью, навешивать какие-то автоматизированные проверки и так далее.
У нас есть целевые метрики: по всем проектам собираются отчеты о проценте дефектов и подобные штуки. Мы активно развиваем InnerSource для переиспользования хороших практик, потому что писать свои велосипеды — это тоже не очень качественно, у каждого велосипеда вначале будут детские болезни.
Еще у нас есть Quality Gates — это история про автоматические проверки: покрытия тестами, статический анализ, анализ уязвимостей, перформанс-тесты и так далее.
Профит очевиден: меньше дефектов, меньше инцидентов.
Управление устойчивостью
На масштабе в десятки миллионов клиентов физически становится так много железа, сервисов и инстансов этих сервисов, что по нам бьет статистика. Статистика говорит, что все рано или поздно сломается. И поэтому нужно управлять устойчивостью — reliability.
Мы разносим по разным дата-центрам приложения, железо, сервисы, делаем много всего as a service. У нас есть DBaaS, S3aaS, LBaaS, K[afka]aaS, K8SaaS и так далее. Мы много работаем над тем, чтобы распространять хорошие архитектурные практики внутри компании. Есть сообщества, обмен знаниями, митапы, встречи. Мы пишем RFC и ADR, disaster recovery планы, проводим учения по их отработке, у нас есть техрадары. Мы планомерно идем к тому, чтобы это работало везде.
Профит нашего подхода к устойчивости:
Можем катить в прод без даунтайма, отказоустойчивые конфигурации позволяют применять разные схемы деплоя: blue-green deployment или канарейки и подобные.
Исключаем типовые ошибки и шарим лучшие практики за счет платформ *aaS. Например, без Kafka as a service тысяче команд нужно будет поднять каждой свою Kafka. Где найти столько квалифицированных инженеров, которые умеют готовить Kafka настолько хорошо, чтобы она работала надежно и все было прекрасно?
Проверяем механизмы отказоустойчивости, ведь без учений мы не можем быть уверены, что они работают.
Устойчивы к отказу отдельных железок или даже целых дата-центров.
Создание центра надежности
Все, что я описал, в большой компании нужно как-то внедрить. Внедрение — это отдельная проблема, потому что в большой компании много людей, а много людей — много встречных интересов. Кому-то нужны фичи, а кому-то — надежность.
Разный бэкграунд у разных людей. Кто-то пережил проблему на проде и теперь живет по-новому, а кто-то пока еще делает как делал.
Дополнительно работает испорченный телефон, потому что люди, когда обмениваются информацией, ее искажают и она может доходить совсем не в том виде, в котором была задумана.
Через много людей информация распространяется медленно. Если разговаривать с людьми и доносить им что-то, то на масштабе в десятки тысяч людей это займет вечность. Поэтому мы создали центр надежности.
Центр надежности — отдельная структура, цель которой — внедрение практик надежности на уровне компании. С его помощью мы ввели стандарты профессии SRE, описали и внедрили практики надежности, ввели термины «инцидент», «уровень инцидента» и задрайвили внедрение наблюдаемости и разработку инструментов, таких как Sage и FineDog.
В команде центра надежности есть инженеры, которые могут прийти на помощь, если какой-то другой команде нужно внедрить мониторинг или построить наблюдаемость. Они могут подключиться к решению проблем, связанных с созданием надежности.
Но что бы мы ни делали, все равно по закону Мерфи все пойдет не так и инциденты случатся. Поэтому расскажу, как мы в Т-Банке работаем с инцидентами.
Работа с инцидентами
Сначала мы собираем телеметрию на всех уровнях: инфра, приложения, услуги. У нас есть и бизнесовые логи-метрики, и инженерные. Все это заливается в Sage — платформу наблюдаемости.
В Sage варится вся информация и есть механизм алертинга, который в случае каких-то проблем кинет алерт. Мы используем chatops: первое, куда алерт пойдет, — в какой-то из чатов, за которым смотрит дежурный.
Мы верим в принцип stateless-инженера. Представьте: в три часа ночи инженер просыпается от алерта. Он не готов решать ребусы и головоломки. Поэтому название алерта должно быть максимально говорящим, описывающим контекст: что и почему сломалось, как чинить.
В алерте есть все нужные ссылки: ссылка на Графану, где можно посмотреть, как сейчас себя чувствует услуга или часть этой услуги, с которой что-то пошло не так. Есть ссылка на поисковый запрос, который выполнялся в рамках алерта и привел к срабатыванию. И есть runbook, в котором описан более широкий контекст: что это за алерт, почему он написан, что, скорее всего, сломалось, если сработал этот алерт, и как это чинить, как это, может быть, чинили в прошлые разы.
Все алерты попадают к дежурному инженеру. Он должен убедиться, что это действительно инцидент, и выставить уровень критичности.
Мы описываем уровни критичности инцидента как совокупность значений по трем осям.
Первая ось — риски: финансовые, регуляторные, пиарные и другие. То есть чем нам грозит этот инцидент. Риски у нас зашиты в другую градацию критичности: уровни критичности наших систем и услуг. И чем выше критичность услуги, тем выше риски.
Для каждого уровня критичности услуги у нас есть табличка, которая говорит, что для такого уровня критичности услуги и для такого сочетания длительности и влияния на клиентов нужно задать вот такой цвет или уровень критичности инцидента.
Когда уровень критичности инцидента определен, его нужно зарегистрировать в системе инцидент-менеджмента FineDog, а дальше FineDog уже уведомляет всех причастных о том, что инцидент случился.
Уведомления о любых инцидентах падают в чатик Emergency Tech Team. Сейчас чатик, но в будущем, скорее всего, это поменяется. В нем сидят все заинтересованные.
К алерту подцепляется тред, в котором идет обсуждение инцидента. Findog автоматически кидает в тред сообщения, и инженеры могут там тоже что-то написать.
Об оранжевом сбое информируется Chief Reliability Officer (CRO) — особая роль, которую мы ввели. По сути, это правая рука CTO, зам по надежности. В большой компании без подобного фокуса очень сложно продвигать интересы такой зоны, как надежность.
Если инцидент красный, то информируется IT Board — люди, которые находятся высоко и должны знать, что у нас намечаются серьезные проблемы. Они должны быть готовы отвечать на вопросы со стороны при необходимости.
На черном уровне уже подключается Emergency Client Team — это специальные ребята, которые умеют работать с последствиями для клиентов, потому что черный сбой — это очень и очень серьезно.
А что, если алерты не сработали? Не поймал никто алерт, дежурный отвлекся — или даже, может быть, алерта не было?
У нас есть команда, саппорт 24 × 7, но это не клиентский саппорт. Они круглосуточно без выходных мониторят критичные услуги, собирают информацию о пострадавших, оценивают влияние инцидентов на бизнес и так далее. Глазами они в техническом мониторинге, смотрят, где что сломалось или может сломаться, и знают в лицо инженеров. А головой они в бизнесе и клиентах, оценивают все через призму влияния на клиентов, и их задача — сориентироваться, чтобы, когда наступят серьезные последствия, быть во всеоружии.
Один из инструментов саппорта 24 × 7 — это главная страница FineDog, которая описывает интегральное здоровье экосистемы. Когда все хорошо, все зелененькое, инцидентов нет и в контакт-центре тоже все спокойно.
Тут, мне кажется, вы должны отреагировать примерно так: «Стоп! В каком еще контакт-центре?! Мы разве не про мониторинг экосистемы говорим?»
На главную FineDog вытащен график обращений в контакт-центр, потому что это один из основных признаков, что что-то серьезное идет не так у клиентов. Если мы раньше не поймали какие-то алерты, если у клиентов какая-то проблема, они сразу идут в саппорт. И мы увидим пик обращений.
Саппорт 24 × 7 использует каталог услуг. Можно провалиться по дереву услуг до самого низа и посмотреть, что сейчас работает или не работает.
Есть каталог команд, а в нем — контакты всех дежурных, поэтому, если саппорт 24 × 7 видит, что алерт не приняла команда, он пойдет в каталог и найдет контакты того, кому позвонить.
Саппорт 24 × 7 может что-то не увидеть: проблема может оказаться настолько уникальной, что раньше никто с ней не встречался и даже не думал об этом. Но ведь все инженеры все равно хорошо знают свои системы, понимают, как что работает, и могут заметить это раньше саппорта 24 × 7. Поэтому любой сотрудник может и даже обязан тегнуть саппорт 24 × 7, если у нас действительно какие-то серьезные проблемы.
Если такие проблемы действительно случились, то на главной странице FineDog все расцветет от недоступных услуг. И если ситуация будет ухудшаться дальше и что-то совсем невероятное будет происходить, саппорт 24 × 7 может активировать кризис-менеджмент-план. Это план на самый крайний случай, не знаю, активировался ли он когда-нибудь.
Состав кризис-менеджмент-плана:
Описание состава особой кризисной группы, которая будет заниматься этой проблемой.
Список контактов всех нужных людей, потому что в случае крайне серьезного инцидента могут быть недоступны любые каталоги с контактами.
Список основных и запасных каналов коммуникаций — по той же причине.
Особые роли и координаторы по поиску пострадавших, координаторы по помощи пострадавшим, по коммуникациям со средствами массовой информации, с регулятором и так далее.
Но какой бы сбой ни был, инженеры занимаются его устранением.
Алгоритм выглядит предельно просто: ищешь гипотезы, проверяешь, подтвердилось — молодец, идешь устранять, не подтвердилось — ищешь дальше.
А в это время, в случае серьезного сбоя, клиенты начинают обрывать контакт-центр: пишут в чат и звонят, нарастает вал обращений.
В чем здесь проблема кроме собственно наличия инцидента? Проблема в том, что, какой бы емкости ни был контакт-центр, ее все равно не хватит. Представьте: 45 млн клиентов, допустим, пострадал 1% — это 450 тысяч. Допустим, треть от этих пострадавших решила написать в контакт-центр или позвонить. Получается, 150 тысяч человек приходят в контакт-центр, в который обычно идет порядка нескольких сотен одновременных обращений.
Любые ресурсы контакт-центра закончатся. Нужно что-то делать, чтобы контакт-центр выжил, а не упал под нагрузкой. С другой стороны, понятно, что, когда что-то не работает, мы тыкаем кнопочку «повторить». Получается, что систему, которой и так тяжело, еще больше ддосим — и это усугубляет инцидент.
Для разгрузки у нас есть несколько инструментов, и их тоже активирует саппорт 24 × 7.
Плашка. Может быть блокирующая плашка — когда в приложении нарисовано, что сейчас у нас проблемы, пожалуйста, зайдите попозже. Либо неблокирующая, информирующая о том, что сейчас происходит какая-то проблема и мы о ней знаем. Если клиент хотел написать о проблеме в саппорт, то, в принципе, может уже не писать.
Возможность встроиться в диалог. Мы умеем встраиваться в диалоги, в варианты ответов, которые предлагаются, и в часто задаваемые вопросы. Мы можем добавлять релевантные пункты по текущему сбою и умеем делать дополнительный этап перед переключением на оператора.
Сначала мы переключаем на оператора, но если понимаем, что очередь растет, то можем сделать так, чтобы еще раз пришел бот и спросил: может быть, через бота решим вопрос? А если надо позвать оператора, нажми кнопку отдельно.
Возможность закрыть все чаты. Во время серьезного сбоя очередь чатов огромная. Иногда ее просто невозможно обработать физически, к тому же это может не иметь смысла, если, например, инцидент решился. И в такой ситуации мы можем закрыть все чаты — есть такая фича.
Для клиента это выглядит как уведомление: «Сейчас операторы перегружены, мы знаем, что есть инцидент, и предлагаем такие-то решения. А если у вас какой-то другой вопрос, то можно еще раз обратиться в поддержку».
В работе с пострадавшими мы используем систему Forge. Это helpdesk-система, в которой тоже регистрируются инциденты, в том числе это делает саппорт 24 × 7.
Но в Forge инциденты представлены в другой проекции. Если в FineDog инцидент — это скорее проекция технической проблемы, проблемы недоступной услуги, то в Forge инцидент представлен в проекции влияния на клиента. В тикете Forge записано, что мы делали, чтобы помочь клиентам, какие предлагали обходные решения, и есть протокол того, что, с точки зрения клиента, происходило, где какие услуги были недоступны и так далее.
В Forge можно создать поиск пострадавших. По сути это запросы в Sage к бизнесовым логам, в результате которых можно вытащить пул ID клиентов, которые пострадали от сбоя. Например, они пытались воспользоваться услугой и мы увидели, что они получили пятисотку или что-то такое. И что потом мы с этими пострадавшими можем сделать? Мы делаем информирование.
Мы можем взять список пострадавших и отправить им пуш: «Мы знаем, что вы пытались воспользоваться услугой, у вас не получилось. Попробуйте обходное решение». Или, если решения нет: «Мы знаем и уже занимаемся решением проблемы».
Поиск пострадавших может быть как разовый, так и периодический — раз в минуту, например. Во втором случае список постоянно обновляется и пуши рассылаются вновь попавшим в инцидент.
Постанализ. Со временем любой сбой будет устранен, но это не повод расслабляться.
Для сбоев попроще мы делаем лайтовый постмортем, который называем постанализом. Для серьезных, красно-черных сбоев делаем серьезные посмортемы, которые разбираем на еженедельной встрече всех SRE-инженеров, SRE All Hands.
В постмортеме более детальная рефлексия, больше внимания уделяется последствиям для бизнеса и клиентов, а также детальному описанию, что происходило и как сделать, чтобы этого не было в будущем.
Итоги
В надежности на масштабе в 45 млн клиентов у нас нет права на ошибку. Треть населения России — это очень много. И если мы приляжем на недельку, это будет катастрофа национального масштаба. У нас нет такого права, мы ответственно подходим к клиентам. А еще есть организации вроде Центробанка, которые дополнительно напоминают нам об этой ответственности.
Невозможно поддерживать руками что-либо на таком масштабе, потому что нельзя лично сходить и поговорить с миллионами клиентов. Мы не можем лично написать им в чат или спросить, как у них дела, нравится ли им услуга. Все нужно делать автоматизированно, какими-то инструментами.
В компанию вовлечено слишком много людей. К десяткам тысяч сотрудников невозможно прийти лично, значит, нужны нормальные каналы информирования, распространения информации, обмена практиками. Нужны инструменты для этого и какие-то централизованные платформы. Мы создали эти платформы, потому что без них уже невозможно понять, что сейчас происходит.
Ну и никуда без статистики, потому что на таких масштабах мы уже можем рассуждать о событиях только в вероятностном ключе, а значит, нужно собирать, хранить и анализировать много данных.
Что из нашего опыта можно применить уже сейчас:
Строить наблюдаемость, это можно сделать независимо от размера сервисов.
Строить работу с инцидентами и учиться писать постмортемы, тренироваться вести журналы дежурных и так далее.
Переиспользовать опыт организации центра надежности и роль Chief Reliability Officer.
Держать фокус на клиентском опыте, потому что все, что мы делаем, мы делаем ради клиентов.
Когда мы начали строить платформу наблюдаемости, поняли, что нам особо не с кем обсудить вопросы наблюдаемости. Захотелось собрать сообщество — и мы сделали это в телеграм-чате. Присоединяйтесь и давайте дружить!