Карьера в хайлоад-проекте: к чему готовиться - II?

Это продолжение прошлого поста, вот - первая часть.

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

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

Есть ли какая-то специфика хайлоад-проектов для небекендеров? Конечно, в первую очередь для фронтендеров: ваш фронт будет доставляться и работать на огромном количестве устройств, он должен доставляться быстро, не тормозить на клиентской машине (особенно при старте), и быть оптимально спроектирован, чтобы не создавать “лишних” нагрузок на бэкенд. Это же касается и мобильных разработчиков, за тем исключением, что они не занимаются оптимизацией загрузки: весь “контент” уже упакован в приложение.

Аналитикам, которые (вдруг зачем-то) занимаются системной архитектурой, придется отказаться от булшитовых кружочков и стрелочек, и опуститься под капот - к апи, к запросам между компонентами. Аналитикам данных, придется столкнуться с обработкой больших массивов данных и связанных с этим технологических вызовов: собрать, прокачать, хранить и обрабатывать эти массивы нужно успевать, и иногда их обработка идет медленнее, чем они собираются.

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

Мир не очень приветствует погружение под капот - это ж сложно. Современные облака хотят от скрыть от нас детали, предоставляя planet-scale решения с автоматическим масштабированием. В больших проектах развит внутренний тулинг – так что масса вопросов скрыта даже для опытных инженеров, которе выросли в таком проекте. Это не хорошо, и не плохо - это данность. Так что если хотите копать глубоко – просто попасть в крутой проект может оказаться недостаточно, нужно копать самостоятельно, читать чужой код, ресерчить, исследовать, применять новые подходы, пробовать компоненты. А эта область уже чисто исследовательская.

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

Кстати, о тулинге. Самая быстрая и легкая в мире “стрелялка”, wrk2, с 2016-го года особенно не поддерживается, поэтому отличные community-патчи, в том числе критичные, висят годами. Один из участников буткемпа – Даниил Дук - сделал титанический ресерч, в числе прочего найдя критичный патч, которые убирает проблему 100% нагрузки CPU при определенных условиях. Короче, я решил это исправить, и сделал вот такой реп: https://github.com/devhands-io/wrkx, “wrk2 с комьюнити-патчами”. Сделаем 14-го мая вечером митап про нагрузочное тестирование и про wrk и про автоматизацию - stay tuned, ещё напишу про это.