![](https://habrastorage.org/getpro/habr/upload_files/608/dee/bae/608deebae7a410680dc767623d430c15.png)
Всем привет! Я Максим, тимлид 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.
![Для анонса на внутреннем портале придумали лого мероприятия Для анонса на внутреннем портале придумали лого мероприятия](https://habrastorage.org/getpro/habr/upload_files/48b/15f/174/48b15f174bdaadea1ec1178a21c8770e.png)
Чтобы привлечь инженеров к участию, мы:
— договорились с топами выделить время на такие задачи;
— отправили мотивирующее письмо всем руководителям команд разработки, аналитики и тестирования;
— анонсировали мероприятие в тематических каналах нашего мессенджера;
— создали канал для общения организаторов и участников;
— запустили анонсы в еженедельной рассылке и на внутреннем портале.
Еще больше вовлечения и заинтересованности
![](https://habrastorage.org/getpro/habr/upload_files/fea/86e/093/fea86e093ef5f1b9f8991d404c3895eb.png)
Чтобы сотрудники активно регистрировались, мы организовали несколько внутренних встреч-митапов. Цель — создать дополнительный интерес к надежности и убедить, что в участии нет ничего страшного и надо пробовать!
Частью месяца надежности стали доклады.
![](https://habrastorage.org/getpro/habr/upload_files/50f/292/e98/50f292e9859a7fd762bb625c2c6ca7c0.png)
«Создание надежного программного обеспечения»
Дмитрий Масленников, руководитель SRE Тинькофф
Дима рассказал, почему у одних команд получается более надежный софт, чем у других, и почему команда SRE не сможет в одиночку сделать софт надежным. А еще рассказал о том, как в этом могут помочь разработчики.
![](https://habrastorage.org/getpro/habr/upload_files/b92/c16/18d/b92c1618d629bd1a5fb2b6cc36e96031.png)
«Путь из SWE в SRE»
Иван Ишмаметьев, тимлид команды SRE SME
Иван — разработчик, который стал SRE-инженером. Он рассказал, как растущий интерес к метрикам помог его команде улучшить показатели, а самому Ване выбрать вектор развития. А еще объяснил, какие вызовы были самыми сложными и как опыт помог SRE-команде растопить сердца разработчиков и наладить системный подход к разработке. Ваня поделился полезными советами, как расширить кругозор и увидеть полную картину цикла разработки.
![](https://habrastorage.org/getpro/habr/upload_files/ddc/ff6/a85/ddcff6a85c5f10488905b125a74b38c1.png)
«Путь тимлида SRE-команды, или Почему лучше расти осознанно»
Станислав Сычев, тимлид команды SRE Runtime
Стас рассказал историю своего роста и выделил ключевые знания и компетенции, которые позволяют управлять командой и расти самому. Поделился, с каким бэкграундом становятся тимлидами, как меняется понимание ответственности в новой роли и чем TeamLead SRE-команд отличается от TeamLead команд разработки.
Сбор заявок
Регистрация была максимально простой и проходила на внутреннем портале. Из важных критериев мы выделили:
название команды;
состав команды;
продукт или сервис;
проблемную область;
постановку задач;
ожидаемые результаты.
Когда на этапе подачи заявок число команд перевалило за 40, мы поняли, что нужно держать руку на пульсе мероприятия чуть сильнее. Для этого добавили еще одну таблицу, в которой нужно было описать результаты команды:
что было сделано;
на какие показатели надежности повлияли;
каких ожидаемых результатов достигли;
каких ожидаемых результатов не достигли и почему;
ссылки.
Мы хотели, чтобы повышение надежности происходило через модификацию кода, и предложили варианты, что участники могли реализовать в своих проектах:
Реагирование на инциденты, анализ первопричин и отладка:
создание инструментов для быстрого выявления причин сбоев: проберы, предсказатели, аналитическая обработка метрик;
автоматизация устранения типовых сбоев;
автоматизация тестирования поверх продакшена: пробберы, sanity, smoke, chaos.
Устранение рутины и автоматизация для работы SRE:
создание админок для SRE: инструменты для динамической конфигурации сервиса и безрелизных изменений.
Наблюдаемость и мониторинг:
доработка метрик для увеличения наблюдаемости: RED, USE, 4 Golden Signals, etc.);
улучшение логирования и интеграция с Sage;
внедрение распределенного трейсинга Distributed tracing: RFC.
Устойчивость приложений к сбоям
архитектурные изменения, направленные на увеличение надежности;
рефакторинг кода на увеличение надежности;
внедрение безопасных релизов: Feature Toggles, Rolling Update, 100%-я откатываемость релизов, версионирование базы;
автоматическое устранение типовых сбоев.
Оценка работ
Если убрать источник больших сбоев, который стрелял раз в полгода, то как оценивать влияние других факторов? На метриках все будет примерно так же.
Чем больше работаю, тем больше склоняюсь к мысли, что огромное значение играет инженерная интуиция, а метрики и SLA — подсказка, которая дает представление о случившемся. Но эта подсказка не отвечает на вопрос, как решать проблемы в будущем.
Я называю метрики, трейсинг и логи уликами, а SRE — детективами. Так ближе всего к реальности. Чем детальнее и полнее улики, тем проще раскрыть дело.
В книге The Tyranny of Metrics попалась интересная мысль: объективные метрики часто ломают медицину, бизнес и другие сферы. Не нужно слепо следовать метрикам, иногда лучше опираться на опыт и интуицию, а метрики использовать как дополнительный источник данных. Фиксация на метриках приводит к тому, что люди просто подгоняют под них жизнь. Например, врачи не берут рисковые кейсы, чтобы не портить статистику по успехам, а страдают при этом люди.
Наши SLI и SLO выбирают люди, их можно подогнать под любые таргетные девятки. Ничего объективного в этом нет. Поэтому критерии оценки для команд получились такими:
Сложность проекта определялась:
— по количеству команд, затронутых при реализации улучшения;
— количеству услуг, надежность которых была улучшена;
— технической сложности реализации.
Соответствие тематике мероприятия:
— чем больше проект соответствует понятию «надежность», тем большее количество баллов ставили.
Надежность — это устойчивость приложений к сбоям, скорость реагирования на инциденты, анализ первопричин и отладка, устранение рутины и автоматизация работы SRE, а еще наблюдаемость и мониторинг.
Влияние проекта на продакшен:
— изменения доказывают влияние на продакшен;
— есть страховка от сбоя;
— исключили возможные причины сбоев;
— минимизировали последствия сбоя.
Дополнительно оценивали значительность влияния и количество услуг, которые улучшали.
Презентация:
— понятна жюри;
— описывает результаты проекта и его влияние на продакшен.
Наше мероприятие проходило в конце года. Декабрь — пора подготовки к праздникам, и мы понимали, что сбои в это время были бы гораздо более неприятными, чем в другие месяцы. Поэтому мы попросили участников, которые предлагали рискованные изменения, рассказать о них жюри, но не отправлять на продакшен до января.
![](https://habrastorage.org/getpro/habr/upload_files/0c3/dec/baf/0c3decbafed5f2e3fa6fcf6f835203e0.png)
Мы набрали 57 команд, и такое количество нереально прослушать за два запланированных часа, поэтому сначала организовали полуфинал, по итогам которого отобрали 10 команд-финалистов.
Распределили по 12 команд в час, а в жюри позвали организаторов мероприятия. Это был незабываемый опыт. Все команды провели крутые исследования и внедрения, за что мы им благодарны. Пять полуфинальных часов были сложными, но потрясающими по количеству заинтересованных в надежности людей. Очень вдохновляюще и невероятно.
Для всех участников мероприятия дошедших, до полуфинала, мы разработали фирменные худи. С офигенным гекконом!
![Ну разве они не прекрасны? Ну разве они не прекрасны?](https://habrastorage.org/getpro/habr/upload_files/1f1/e70/aec/1f1e70aec48a3bf1c45e13ef9c814874.png)
Жюри было сложно выбрать десятку финалистов: команды в итоговой таблице шли плотно друг за другом. Результаты мы опубликовали не по количеству голосов, а по алфавиту для чистоты голосования в финале.
Победители MoR
Приз зрительских симпатий всегда спорная тема. Мы хотели избежать ситуации, когда побеждает тот, кто привел больше всего друзей для поддержки. Для этого на внутренней платформе подготовили голосование, в котором могли участвовать только члены команд, дошедших до полуфинала, и подход дал свои плоды. Победил самый необычный проект команды «Графаналевичи».
Парни не зря взяли такое название: они — единственные, кто сделал презентацию прямо в Grafana. Интерактивная презентация, которую сразу можно разобрать на рабочие примеры, — это просто бомба.
![Они рассказывали о построении обзорных дашбордов для систем на примере зонтичного дашборда с использованием плагина flow charting для Grafana Они рассказывали о построении обзорных дашбордов для систем на примере зонтичного дашборда с использованием плагина flow charting для Grafana](https://habrastorage.org/getpro/habr/upload_files/350/f5b/0a5/350f5b0a53739caedee11ecb93afb933.png)
![Реализация — вот так мы используем плагин Реализация — вот так мы используем плагин](https://habrastorage.org/getpro/habr/upload_files/2da/58e/998/2da58e998ebadbcf7fed08221bae69d9.png)
Интересный прецедент случился в финале: две команды набрали одинаковое максимальное количество баллов в результате голосования жюри.
«Проблема»? — подумали мы и собрали жюри заново. Помните, в американских фильмах про суды бывают сцены, где сидят присяжные и обсуждают свое решение? Так же было и у нас: мнения разделились. В итоге благодаря обсуждению удалось выбрать победителя, но оставлять второго победителя без приза было бы нечестно. И мы придумали номинацию «приз жюрительских симпатий».
Команда, занявшая второе место, реализовала библиотеку на Java, которая при срабатывании алерта сразу снимает JFR-дампы и публикует их на s3 для дальнейшего изучения. А еще реализовала гитопс-интеграцию с фича-флагами приложений.
Любой SRE знает, как важен сон. Теперь это знают и члены команды, получившей приз жюрительских симпатий Winner Winner Chicken Ddinner. В своей презентации ребята шутили, что очень мало спали, готовясь к финалу, и мы придумали для них особенный приз. Каждый член команды получил сертификат на покупку одеял, подушек или анатомического матраса — для комфортного сна.
Победителем финала стала команда %tbd%. Парни нешуточно вложились в улучшение надежности платежных сервисов компании. Они разделили сервисы на внешние и внутренние инсталляции. Внешние стали обслуживать интеграции сторонних компаний, а внутренние — интеграции внутренних сервисов Тинькофф. Также они установили лимиты на сервисы, чтобы их было сложнее уронить чрезмерной нагрузкой.
За победу в MoR и огромный вклад в надежность своих сервисов команда получила
эргостолы или эргокресла на выбор. А еще всеобщее признание и уважение.
После такого ошеломительного успеха мы не собираемся останавливаться. Следующий месяц надежности запустим уже в июле. В этот раз хотим изменить формат мероприятия и вместо одного финала сделать несколько по номинациям, чтобы упростить судейство и повысить прозрачность критериев.
Команды просили расширить месяц надежности до квартала. Это приятно, но пока невыполнимо, потому что в планах много других специальных месяцев и пересечение будет плохо влиять на продуктивность команд. Еще мы решили сделать единый план-формат презентации для всех команд, чтобы было легче готовиться к финалу.
Немного цифр и новостей
Всего 60 команд зарегистрировались на MoR и 138 человек из 57 команд участвовали. Считаем это отличным результатом для первого подобного мероприятия!
![](https://habrastorage.org/getpro/habr/upload_files/443/f95/94e/443f9594eeb6532921d94b32cc779c39.png)
И на прощание приятная новость из мира SRE: 19 июня стартует бесплатный курс «SRE в современном ИТ». Участников ждет сильная программа от хардкорных специалистов, расширение экспертизы и много практики. В мире SRE много интересного и невероятного — присоединяйтесь. Если остались вопросы, ждем в комментариях.