[Хд] logo

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

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

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

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

Например, общее решение задачи сохранения пар ключ=значение — это использование СУБД. Такой выбор делается, как правило, потому, что организация или разработчики хорошо владеют технологией СУБД (к тому же, как правило, она уже используется в системе для других целей). Проблемы возникают тогда, когда устройство базы данных (как правило, реляционной) становится узким местом и препятствует масштабированию. Это происходит потому, что стоимость роста решения на основе базы данных, как правило, существенно дороже, чем другие имеющиеся решения.

Есть множество альтернатив традиционным реляционным базам данных для решения подобной задачи.

Большой ком грязи

Зависимости являются необходимым злом в большинстве систем и неспособность управлять зависимостями может пагубно влиять на оперативность.

Есть несколько подходов управления зависимостями кода:

  1. Компилировать весь код в один пакет
  2. Выбирать компоненты только известных версий
  3. Все модели и сервисы должны быть обратно-совместимыми
  1. В большом коме грязи вся система представляет атомарную единицу. В принципе, это имеет очевидное преимущество — перенос проблем зависимостей на компилятор. Но, в тоже время, это связывает решение проблем масштабирования с развертыванием всей системы... каждый раз! В подобной системе становится значительно труднее вносить какие-либо изменения.
  2. Во втором подходе зависимости выбираются по желанию, но каждый компонент отражает проблемы первого подхода на более низком уровне
  3. Третий подход обеспечивает клиентов обратно-совместимыми интерфейсами. Это позволяет добиться постепенного и независимого обновления всех клиентов. Кроме этого, изменения в данных происходят на серверной стороне, что помогает изолировать клиента. Данный подход сводит проблемы зависимостей к минимуму

Герой

Одним из популярных решений для обеспечения работоспособности системы — это наличие в команде "героя", который берет на себя решение всех проблем. Подобный подход может быть справедлив в небольших системах и малых командах, когда есть один человек, ответственный за всю техническую составляющую. Для крупных систем, с множеством компонент, этот подход не масштабируем (единственный человек имеет ограниченную пропускную способность), к тому же рискован... Хотя именно им и пользуются весьма часто, результат — неэффективно потраченное время, а значит деньги.

Лучшее решение проблемы Героя — это автоматизация и описание системы. У Вас должен быть герой — но им не может быть человек, им должны быть автоматизированная подсистема.

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

Эта проблема сильно связана с предыдущей и достаточно проста.

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

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

Мониторинг

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

  read in english
[Хд]

Подписывайтесь на отборные материалы по продвинутой разработке

Google Email

Esc, чтобы подписаться позже