Хороший код — это еще не все: инженер LinkedIn рассказывает что делать, чтобы не было проблем на проде

Вчера, 7 октября 2021 года, стартовала закрытая онлайн-конференция Lviv IT Arena. Одна из спикерок ивента в этому году — Senior Director of Engineering в LinkedIn Шалини Агарвал. В своей лекции она рассказала о том, как они с командой разработки оказались в ситуации, когда все пошло не так, и какие принципы создания продукта они из этого вынесли.

Передаем слово Шалини.

Почему хорошего кода недостаточно для хорошего продукта

Представьте себя в ситуации: ваша команда упорно работает, но на этой неделе у вас было три проблемы на продакшене и все три связаны с действительно плохим пользовательским опытом.

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

В 2014 году мы собрали небольшую команду, которая должна была работать над созданием Linkedin Sales Navigator — стартапа внутри системы Linkedin, где sales-менеджеры смогут находить клиентов и заключать с ними контракты. Я была лидом этой команды и это я привела ее к той ситуации, о которой рассказывала выше.

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

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

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

И вот как это сделать.

Три области, которые должны быть в фокусе вашего внимания

Доступность (Availability)

Первое, что вам нужно сделать — это выяснить, какая часть вашей системы дает сбой. Для этого мы взяли все наши проблемы за последний год и категоризировали их. Оказалось, что только 50% из них были вызваны моей командой. Остальная половина зависела от других команд других продуктов LinkedIn — ведь все они были в одном монолите. И если происходит сбой в монолите, это влияет на всех. 

Так что нашим решением было изолировать Linkedin Sales из общей структуры Linkedin. Теперь нам развивать этот отдельный продукт сложнее, но это помогло нам уменьшить технический долг.

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

Качество (Quality)

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

Мы проводим локальное тестирование и также тестируем на продакшене с помощью нашей внутренней конфигурационной системы.

Кроме того, у нас в LinkedIn есть «философия гигиены» — мы против мусора. Но что мусор для инженера? Это зомби-код. Так что мы уделяем особое внимание документации и code review.

Продуктивность разработки (Dev Productivity)

От разработчика всегда требуют работать все быстрее и быстрее. Но как этого добиться? Ответ — автоматизацией. В контексте разработки программного обеспечения это означает автоматизировать выкатку (deployment). 

В Linkedin мы часто деплоим небольшие изменения продукта. Это позволяет осуществлять этот процесс непрерывно. Мы делаем это в три этапа:

1. Сначала на локальных машинах. В это время мы проверяем код и запускаем автоматические тесты. Мы стремимся к 80-90% покрытия тестами. Тестирование нужно автоматизировать насколько, насколько это возможно.
2. Канареечные развертывания. Мы деплоим продукт изолированно и на ограниченное время. И в это время отслеживаем его работу.
3. Третья фаза — это выкатка центров обработки данных. Но мы делаем это постепенно и не разворачиваем 100% центров сразу — на случай, если есть скрытый баг, который может привести к краху всей системы.

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