Всем привет! Я Максим, тимлид SRE команды бэкенда и SSO, последние семь лет занимаюсь вопросами надежности сервисов и услуг банка. Раз в год мы проводим месяц поиска уязвимостей — Month of Bugs. В 2022 году, когда все компании столкнулись с новыми вызовами, мы превратили Month of Bugs в Month of Reliability — месяц надежности. И сосредоточились не на поиске отдельных багов, а на обеспечении надежности всех систем.

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

Что такое MoR

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

Мы хотели повысить вовлеченность разработчиков, тестировщиков, аналитиков в вопросы надежности, сократить количество сбоев и улучшить реагирование на них и привлечь их в ряды SRE.

Мы собрали самых заинтересованных инженеров надежности, деврела и начали готовить Month of Reliability. В команду вошли DevRel, Head of SRE, тимлид SRE команды платформы разработки и тимлид SRE команды API физлиц и SSO. 

Чтобы привлечь инженеров к участию, мы:

— договорились с топами выделить время на такие задачи;

— отправили мотивирующее письмо всем руководителям команд разработки, аналитики и тестирования;

— анонсировали мероприятие в тематических каналах нашего мессенджера;

— создали канал для общения организаторов и участников;

— запустили анонсы в еженедельной рассылке и на внутреннем портале.

Еще больше вовлечения и заинтересованности

Чтобы сотрудники активно регистрировались, мы организовали несколько внутренних встреч-митапов. Цель — создать дополнительный интерес к надежности и убедить, что в участии нет ничего страшного и надо пробовать!

Частью месяца надежности стали доклады.

«Создание надежного программного обеспечения» 

Дмитрий Масленников, руководитель SRE Тинькофф

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

«Путь из SWE в SRE» 

 Иван Ишмаметьев, тимлид команды SRE SME

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

«Путь тимлида SRE-команды, или Почему лучше расти осознанно» 

Станислав Сычев, тимлид команды SRE Runtime

Стас рассказал историю своего роста и выделил ключевые знания и компетенции, которые позволяют управлять командой и расти самому. Поделился, с каким бэкграундом становятся тимлидами, как меняется понимание ответственности в новой роли и чем TeamLead SRE-команд отличается от TeamLead команд разработки.

Сбор заявок

Регистрация была максимально простой и проходила на внутреннем портале. Из важных критериев мы выделили:

• название команды;

• состав команды;

• продукт или сервис;

• проблемную область;

• постановку задач;

• ожидаемые результаты.

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

• что было сделано;

• на какие показатели надежности повлияли;

• каких ожидаемых результатов достигли;

• каких ожидаемых результатов не достигли и почему;

• ссылки.

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

1. Реагирование на инциденты, анализ первопричин и отладка:

• создание инструментов для быстрого выявления причин сбоев: проберы, предсказатели, аналитическая обработка метрик;

• автоматизация устранения типовых сбоев; 

• автоматизация тестирования поверх продакшена: пробберы, sanity, smoke, chaos.

2. Устранение рутины и автоматизация для работы SRE:

• создание админок для SRE: инструменты для динамической конфигурации сервиса и безрелизных изменений.

3. Наблюдаемость и мониторинг:

• доработка метрик для увеличения наблюдаемости: RED, USE, 4 Golden Signals, etc.);

• улучшение логирования и интеграция с Sage;

• внедрение распределенного трейсинга Distributed tracing: RFC.

4. Устойчивость приложений к сбоям

• архитектурные изменения, направленные на увеличение надежности;

• рефакторинг кода на увеличение надежности;

• внедрение безопасных релизов: Feature Toggles, Rolling Update, 100%-я откатываемость релизов, версионирование базы;

• автоматическое устранение типовых сбоев.

Оценка работ

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

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

Я называю метрики, трейсинг и логи уликами, а SRE — детективами. Так ближе всего к реальности. Чем детальнее и полнее улики, тем проще раскрыть дело.

В книге The Tyranny of Metrics попалась интересная мысль: объективные метрики часто ломают медицину, бизнес и другие сферы. Не нужно слепо следовать метрикам, иногда лучше опираться на опыт и интуицию, а метрики использовать как дополнительный источник данных. Фиксация на метриках приводит к тому, что люди просто подгоняют под них жизнь. Например, врачи не берут рисковые кейсы, чтобы не портить статистику по успехам, а страдают при этом люди. 

Наши SLI и SLO выбирают люди, их можно подогнать под любые таргетные девятки. Ничего объективного в этом нет. Поэтому критерии оценки для команд получились такими:

1. Сложность проекта определялась: 

— по количеству команд, затронутых при реализации улучшения;

— количеству услуг, надежность которых была улучшена;

— технической сложности реализации.

2. Соответствие тематике мероприятия:

— чем больше проект соответствует понятию «надежность», тем большее количество баллов ставили. 

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

3. Влияние проекта на продакшен:

— изменения доказывают влияние на продакшен;

— есть страховка от сбоя;

— исключили возможные причины сбоев;

— минимизировали последствия сбоя.

Дополнительно оценивали значительность влияния и количество услуг, которые улучшали.

4. Презентация:

— понятна жюри;

— описывает результаты проекта и его влияние на продакшен.

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

Мы набрали 57 команд, и такое количество нереально прослушать за два запланированных часа, поэтому сначала организовали полуфинал, по итогам которого отобрали 10 команд-финалистов. 

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

Для всех участников мероприятия дошедших, до полуфинала, мы разработали фирменные худи. С офигенным гекконом!

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

Победители MoR

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

Парни не зря взяли такое название: они — единственные, кто сделал презентацию прямо в Grafana. Интерактивная презентация, которую сразу можно разобрать на рабочие примеры, — это просто бомба.

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

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

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

Любой SRE знает, как важен сон. Теперь это знают и члены команды, получившей приз жюрительских симпатий Winner Winner Chicken Ddinner. В своей презентации ребята шутили, что очень мало спали, готовясь к финалу, и мы придумали для них особенный приз. Каждый член команды получил сертификат на покупку одеял, подушек или анатомического матраса — для комфортного сна.

Победителем финала стала команда %tbd%. Парни нешуточно вложились в улучшение надежности платежных сервисов компании. Они разделили сервисы на внешние и внутренние инсталляции. Внешние стали обслуживать интеграции сторонних компаний, а внутренние — интеграции внутренних сервисов Тинькофф. Также они установили лимиты на сервисы, чтобы их было сложнее уронить чрезмерной нагрузкой.

За победу в MoR и огромный вклад в надежность своих сервисов команда получила 

эргостолы или эргокресла на выбор. А еще всеобщее признание и уважение.

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

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

Немного цифр и новостей

Всего 60 команд зарегистрировались на MoR и 138 человек из 57 команд участвовали. Считаем это отличным результатом для первого подобного мероприятия!

И на прощание приятная новость из мира SRE: 19 июня стартует бесплатный курс «SRE в современном ИТ». Участников ждет сильная программа от хардкорных специалистов, расширение экспертизы и много практики. В мире SRE много интересного и невероятного — присоединяйтесь. Если остались вопросы, ждем в комментариях.