Меня зовут Дмитрий Масленников, и я руковожу Центром надёжности информационных систем в Тинькофф. Недавно я выступал на вебинаре Слёрма «Особенности SRE в России». В поддержку своего курса «SRE: внедряем DevOps от Google» Слёрм собирает интересные кейсы внедрения SRE в российских компаниях. Я рассказал, как устроена наша экосистема SRE, зачем мы используем самописные сервисы, почему в SRE должна работать инженерная элита и как примкнуть к этой элите за один день. А теперь делюсь этим здесь. 

Как работает SRE-экосистема в Тинькофф

Тинькофф — IT-компания с банковской лицензией, которая ведёт много своей разработки. Внутри компании есть Центр надёжности информационных систем, где работают около 80 SRE-команд — от 4 до 8 человек в каждой. Часть отвечает за внешние сервисы, а часть — за внутренние.

Я работаю в Тинькофф 3 года. За это время у нас появился целый набор внутренних сервисов для облегчения работы SRE. Мы используем Oncall, чтобы вести расписание дежурств. Pager, чтобы доставлять дежурным срочные сообщения. Чтобы знать, какие есть команды, за что они отвечают и какие инженеры в них входят, мы написали SRE-каталог. Для эскалации заметных сбоев мы используем сервис Omg. Для мониторинга SLA — Slaser, а для мониторинга и анализа работы сервисов — Sage. Расписание плановых работ мы ведём в Knotty. 

Все, кроме Oncall – наши внутренние разработки, и сейчас перед нами стоит задача более тесной интеграции этих систем. Мы часто пишем инструменты для себя, а не используем готовые, и на это есть две причины. Во-первых, Тинькофф — большая компания со сложившимися процессами. Нам удобнее их сохранять, а не переделывать. Поэтому под каждый процесс нужен удобный инструмент. Во-вторых, для некоторых процессов готовых инструментов нет. Например, я не знаю инструмента, который годился бы для подсчёта SLA.

Несколько моих команд целый год пытались выяснить, как это сделать с помощью доступных систем мониторинга. Потом я сам написал простенький инструмент для подсчёта SLA, и несколько команд до сих пор пользуются им. Тогда же другая команда написала ещё один инструмент — Slaser. Сейчас Slaser активно развивается. Он не просто позволяет мониторить SLA сервисов, но и делает комплексный анализ всего, что связано со сбоями: считает влияние сбоев, делает постобработку (указывает инженеру причины сбоев) и предоставляет отчёты о причинах. Инструментом пользуются десятки команд, и мы планируем сделать его обязательным для всех сервисов.

Почему человеческий фактор — главная причина сбоев

Работая в SRE-экосистеме, я понял одну простую вещь: причиной сбоев всегда оказываются ошибки людей. «Корневая причина» сбоев — человеческий фактор, и с этим ничего нельзя поделать.

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

Мы изучили причины сбоев, поправили классификацию и увидели полную картину. Так, в одной команде в качестве причины около 80% сбоев отмечали «релиз новой версии». И все считали, что проблему должны решить SRE-инженеры. Благодаря новой классификации мы выяснили, что 80% сбоев происходило из-за ошибок в программном коде продукта. А это уже общая проблема разработчиков, QA-инженеров и SRE-команд.

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

Что следует считать инцидентом

Много ненужных споров вызывает терминология: под инцидентом все понимают разное. Я думаю, что «инцидент» в SRE — это существенное (заметное для пользователей) и длительное отклонение в работе сервиса, которое требует вмешательства инженеров и коммуникации с пользователями сервиса. Инцидентами не считаются короткие периоды отклонения, когда автоматика приводит сервис в норму без вмешательства человека и пользователи ничего или почти ничего не замечают. Кто-то называет такие отклонения от нормы «маленьким инцидентом», который способен вырасти в полноценный. Я предпочитаю два независимых термина: «отклонение» и «инцидент» (большое отклонение).

Во время дискуссий лучше придерживаться одной терминологии. Выработать её обычно помогает образование — студентов приучают использовать термины, чтобы им было проще понимать друг друга. SRE пока мало где обучают полноценно, но я стараюсь что-то делать в этом направлении и с сентября буду читать лекции для студентов.

Как устроены будни SRE в Тинькофф

Есть мнение, что SRE — это про дежурства, и многих это пугает. Но SRE-команды нужны в первую очередь для того, чтобы делать сервисы надёжнее. А это очень сложно и требует высокой квалификации. Если команда слабая, то её работа, в том числе дежурства, превращается в реакцию на сбои.

Я видел, как опытные команды снижали количество алертов с 20-30 в день до 3-5 в неделю. И если в начале дежурному приходилось непрерывно что-то делать, то благодаря изменениям дежурства стали проходить без единого действия. К этому и нужно стремиться. Но добиться отсутствия сбоев сложно: нужно очень хорошо разбираться в архитектурах программных продуктов и распределённых сервисов, коде и предметной области. Поэтому опытный SRE — это инженерная элита. Рабочие будни такого специалиста состоят из размышлений о прошлых и потенциальных сбоях, путях их предотвращения, разработки тулов для детектирования и исправления проблем.

Для облегчения работы SRE-команд мы создали чек-лист. По нему можно самостоятельно проверить, все ли сделано для стабильной работы. Например, у SRE всегда должна быть возможность откатить проект на предыдущую версию менее чем за 10 минут. С одной стороны, это налагает ограничения на работу с данными. Ведь если мы применяем необратимую или сложно обратимую миграцию данных между версиями, никаких откатов быть не может. С другой стороны, это необходимо, чтобы повысить надёжность сервиса. И таких пунктов в чек-листе больше 50. Чтобы выполнить все, придётся проделать много работы, но надёжность сервиса выйдет на новый уровень. Сейчас мы дорабатываем чек-лист, чтобы оценивать по нему SRE-команды. Все эти наработки я добавляю в свой курс по SRE.

Как сделать надёжный сервис

Наличие SRE-команды само по себе не делает сервис надёжным. Нужна совместная работа всей команды: бизнеса, аналитиков, разработчиков, QA, SRE, UI и UX. Если не учесть этого, появление SRE-специалистов может дать обратный эффект. Например, разработка и QA могут решить, что теперь надёжность сервиса — не их забота. Но SRE — это просто специалист по надёжности. Точно так же, как UX-дизайнер — специалист по пользовательским интерфейсам. Он может что-то сделать сам, а может направить разработку по правильному пути.

Надёжность сервиса лежит в правильной архитектуре, особом «надёжном» написании кода и умении кода правильно рассказать о том, что с ним происходит (логи и метрики). Долгое время специалисты призывали фокусироваться на другом — например, на масштабировании архитектуры. Но мало кто рассказывал, как сделать её отказоустойчивой. Или понятной — такой, чтобы её было просто объяснить. Если не сделать этого, во время сбоя SRE-инженер не сможет вспомнить архитектуру системы, потому что не разобрался в ней. И не может предсказать её поведение в нестандартных условиях.

Сделать сервис надёжнее помогают также особые приёмы и паттерны написания кода. О них мало говорят, поэтому опытные разработчики приходят к этому сами. Суть такого подхода в том, что нужно учитывать возможные ошибки, а не только работу кода в штатном режиме. Например, как на работу кода повлияет ошибка в коде по соседству. Чем сильнее защищены разные участки кода, тем меньше им угрожают ошибки.  

Как видите, сильнее всего на надёжность влияет работа на этапах проектирования и разработки, а не эксплуатации. А задача SRE — следить за эксплуатацией и давать разработчикам рекомендации.

Про тренды в резюме

В последнее время мне попадаются кандидаты-коллекционеры «замечательных технологий» в портфолио. Они считают, что будущее, например, за Kubernetes или Go. А на собеседованиях говорят: «Хочу работать в проекте, где есть Kubernetes, тогда я буду востребован на рынке».

С одной стороны, они правы: знание Kubernetes помогает найти работу. Но тем, кто хочет расти в профессии и много зарабатывать, я советую становиться «решателями проблем», а не знатоками Kubernetes. А для этого нужно научиться решать по-настоящему сложные задачи. Деплоймент приложения в Kubernetes — это не сложная, а рутинная задача. Её вполне можно сделать по документации. Крутой специалист может задеплоить и в Kubernetes, и в Rancher, и на bare-metal. Да, в первый раз он задеплоит приложение в Kubernetes медленнее, чем специалист по Kubernetes. Но потом начнёт справляться быстрее, а ещё автоматизирует процесс и научится предлагать подходы для разных случаев. И все благодаря тому, что он накопил экспертизу и видит связи между элементами лучше, чем специалист с хорошими знаниями Kubernetes.

Я уверен, что задачи «деплоймент» не существует. Существуют задачи бизнеса и потребности клиентов. Людям не важно, умеешь ли ты работать с Kubernetes — они хотят производить товары и получать услуги.

Кого мы хотим видеть в команде Тинькофф

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

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

Допустим, на собеседование приходит мидл. У него должна быть история автоматизации, о которой он может подробно рассказать. Причём автоматизация должна быть нетривиальной. Если мидл опытный, он должен объяснить, что конкретно он делал и как это повлияло на процессы в компании. Чтобы сделать в 10 раз больше работы, нужно не нанимать в 10 раз больше людей, а уметь автоматизировать — так мыслят люди, которых мы хотим видеть в команде.

Вместо итогов

В последние выходные января в Тинькофф пройдёт Weekend Offer для инженеров SRE. Это прекрасная возможность пройти технические секции в ускоренном режиме — всего за день. И получить оффер в течение трёх дней.

Мы ждём тебя на Weekend Offer для инженеров SRE, если:

• ты программист и поддерживал свой код на продакшене;

• ты DevOps-администратор и что-то автоматизировал или программировал pet-проекты.

Кстати, ещё мы ищем инфрастурктущиков — людей, которые много знают про железо и сеть. Особенно тех, кто умеет автоматизировать.