В прошлом году в Тинькофф, как и во многих крупных компаниях, задумались о возможной нехватке мощностей. Раньше мы могли быстро утилизировать железо, но при этом регулярно его закупать и планировать такие закупки на год вперед. Из‑за санкций в 2022 году поставки стали менее предсказуемыми. Это не критично для инфраструктуры, но мы решили, что пришло время задуматься об оптимизации.

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

Год, который все изменил

В последние годы Тинькофф активно рос. Разработчики занимались бизнес‑задачами: доставкой новых приложений и масштабированием тех, что уже есть. Задачи по оптимизации и устранению техдолга отодвигались на второй план. Из‑за этого многие команды стали занимать много железа и использовали его далеко не оптимально.

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

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

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

В поисках подходящего формата

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

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

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

Так мы пришли к месяцу оптимизации.

Month of Performance

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

Целевой аудиторией месяца оптимизации в первую очередь были бэкенд‑разработчики. Для подачи заявки было два важных требования:

• приложение или набор приложений должны занимать минимум 10 ядер;

• для приложения должны собираться метрики потребления CPU и памяти.

И тут у нас сразу вылезает главный вопрос, который сильно повлиял на итоговый формат мероприятия. Как считать? Ведь проекты очень разные по содержанию и размеру. Для одного проекта высвободить 10 ядер — это приложить много усилий и вдвое улучшить показатели. А на другом проекте можно легко высвободить 20 ядер. Чтобы все было справедливо, мы решили поделить участников на две группы: крупные и небольшие проекты. И в каждой группе считать победителей по двум категориям: абсолютным и относительным цифрам, чтобы оценить и существенную оптимизацию, и существенный вклад. Итого получалось четыре команды‑победителя.

Как я уже сказала, наша команда хотела сделать тему оптимизации популярной, чтобы больше инженеров прониклись эффективным использованием ресурсов. Поэтому я стала организовывать внутренние митапы, где потенциальные участники могли познакомиться с инструментами оптимизации. Это оказалось полезно не только для мероприятия, но и в целом для профессионального развития. Такие митапы я организовала в сообществах JVM, Golang, Node.js,.NET и Python, и в сумме их посетили более 600 человек.

На участие в Month of Performance мы получили заявки от 30 команд. 26 из них одобрили — это 60 участников. На этом этапе я отправляла участникам стартовый мерч. Да, кто‑то мог зарегистрироваться, получить мерч и дальше ничего не делать (спойлер: некоторые так и поступили). Но мы осознанно шли на этот шаг, потому что хотели собрать базу по оптимизации ресурсов. К тому же мы не понимали, какое количество человек может заинтересовать эта задача, потому что раньше не устраивали таких мероприятий.

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

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

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

Но были и положительные элементы. Участники писали вдохновенные отзывы и комментарии, особенно те, кто дошел до финала. Финалистам (всем, кто завершил заявленные задачи) мы вручили спортивные сумки, а победителям — классные гаджеты на выбор. Кстати, абсолютное большинство победителей выбрали в качестве подарка квадрокоптеры.

Плюсы, минусы и уроки месяца оптимизации

Самым большим сюрпризом для нас стало количество команд, не дошедших до финала. Оказалось, мало привлечь участников, надо еще и поддерживать их мотивацию в процессе. Этому моменту я уделила отдельное внимание уже в следующем мероприятии — в Month of Reliability, который провела в декабре, — там до финала дошли 57 команд из 60.

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

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

По итогам Month of Performance я организовала митап, где мы попросили финалистов рассказать, как и что они оптимизировали, чтобы коллеги могли познакомиться, обсудить кейсы друг друга и перенять лучшие практики.

UPD: Статья одной из команд-финалистов, как они оптимизировали микросервисы.

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

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

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

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

Заключение

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

Вот как может выглядеть план действий:

1. Собрать рабочую группу из заинтересованных людей.

2. Зафиксировать, какую проблему решаем, — это важно для обсуждения целей мероприятия. А главное — это поможет в принципе избежать организации мероприятия, если проблему проще решить другим способом.

3. Зафиксировать цели мероприятия — это пригодится при формировании критериев победы участников и при планировании коммуникации. Также благодаря цели мы сможем по итогу оценить успешность мероприятия.

4. Определить критерии участия — кто может податься, каким составом, какие минимальные входные требования.

5. Придумать способ сбора заявок, их рассмотрение и подтверждение участия. Не обязательно что‑то сложное: мы, например, решили отказаться от красивых форм регистрации в интранете и организовали все в Confluence.

6. Определить сроки — проведения мероприятия, рассмотрения заявок, определения победителей.

7. Решить, как будем определять победителей. Если метрики, то какие и как будем собирать? Если судейство с помощью жюри, то по каким критериям?

8. Продумать мотивацию. Это призы или внутренние баллы компании? А может, плюсы в ревью? Это только победителям или финалистам тоже? Или всем участникам?

9. Выстроить общение с участниками и сбор обратной связи. Специальные формы и/или просто чат участников?

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

Если у вас есть интересный опыт проведения подобных мероприятий, делитесь в комментариях. Нашей команде и, думаю, другим читателям будет интересно этот опыт почерпнуть. И успешных вам мероприятий!