5 ошибок масштабирования

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

Золотой молоток

Понятие это происходит из американской поговорки:

Если все, что у вас есть – это молоток, то все остальное выглядит для вас, как гвозди

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

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

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

Ком грязи

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

Почему так происходит? Любое приложение, особенно растущее – это эволюционирующий организм. Любые проблемы имеют временный характер, какие-то перестают быть актуальными уже через день, какие-то – через несколько лет. Попытка “переписать по-нормальному” почти всегда приводит к неудаче, ведь в момент проектирования никто не может предсказать будущее.

В итоге, из одного кома грязи получается другой.

Кома грязи избежать нельзя. Зато можно научиться эффективно им управлять и снизить его влияние на систему. Микросервисы – хороший подход.

Герой

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

Хорошее решение этой проблемы – автоматизация.

Если ваш герой – робот, это не так страшно.

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

Не автоматизация

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

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

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

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

Важно не попасть в ловушку переавтоматизации. Если какое-то действие нужно выполнить один…два раза – это, обычно, плохой кандидат на автоматизацию.

Не измерение метрик

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

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

Не так важно, какой именно мониторинг использовать. Это может быть трекинг нагрузки на процессор и количества запросов в СУБД. А может быть количество просмотров товаров и добавлений в корзину. Главное – мерить все критичные для бизнеса события и наблюдать за ними. Только тогда вы сможете в любой момент времени ответить на два вопроса:

• Все ли хорошо?
• Если нет, что именно плохо?

<h2>TL;DR

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

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