Мартин Л.
Бонд и Майкл Т.
Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабирования продуктовых команд. Список был составлен на основе их опыта, а также в ходе общения с клиентами и лег в основу первой книги.
Архитектурные ошибки
1. Проектируйте реализацию, а не ищите архитектурное решение
Какой из следующих подходов вы бы использовали для описания архитектуры вашего продукта? Вариант А: «Мы — магазин Java на базе GlassFish, Apache Felix с MySQL и MongoDB».Вариант Б: «У нас 3-уровневая архитектура с изолированными зонами, которые для устойчивости к сбоям не имеют синхронной связи друг с другом.
Постоянное хранилище данных — сочетание реляционных и NoSQL баз данных с использованием встроенной репликации с горизонтальным шардингом».
Правильный ответ — «Б».
Ответ «А» лучше описывает реализацию архитектуры на текущий момент, но не говорит о масштабируемости.
Компоненты (язык программирования, операционные системы, базы данных, аппаратное обеспечение и т. д.) будут масштабироваться или нет в зависимости от того, как взаимодействуют системы.
Масштабируемость и доступность не появляются из воздуха.
Только правильное проектирование дает возможность при необходимости легко заменить компоненты программного решения.
2. Проектируйте без ошибок
Аппаратное обеспечение, программное обеспечение, центры обработки данных, интернет-провайдеры, процессы и люди, особенно люди.Когда система спроектирована правильно и основные услуги или сегменты клиентов изолированы, последствия любого сбоя каждого элемента незначительны.
Временное отключение оплаты на платформе электронной коммерции не должно мешать возможности поиска, просмотра или добавления товаров в корзину для последующей покупки.
Чрезвычайно высокая нагрузка со стороны одного клиента не вызовет сбоев у всех остальных.
Гибель «Титаника» — один из самых известных примеров проектной ошибки, которая стоила всего проекта: отсеки корабля не были полностью изолированы, а когда корабль накренился вперед, вода просто переливалась через переборки, пока не затопила все.
3. Вертикальное масштабирование вместо балансировки нагрузки
Многие продукты по-прежнему используют реляционную базу данных (MySQL, Oracle, SQL Server и т. д.) в качестве основного хранилища.Вместо того, чтобы сегментировать клиентов по множеству небольших баз данных (каждая из которых содержит несколько клиентов в целях экономической эффективности), многие компании по-прежнему полагаются на дорогостоящее высокопроизводительное оборудование для масштабирования монолитной системы.
Такое «решение» в конечном итоге приведет к более высоким транзакционным издержкам и большему ущербу в случае неудачи по мере роста компании.
Кроме того, эффективность инвестиций будет низкой, поскольку громоздкая система будет простаивать до постепенного увеличения нагрузки.
В конце концов, самая большая система окажется недостаточно большой, и у вашего продукта все равно будут проблемы.
Вспомните eBay в 1999 году или PayPal в 2004 году.
4. Использование неправильных инструментов
Пригласите плотника починить вашу ванную, и он придет с молотком.Вероятно, вы не будете довольны результатом.
Это то же самое, что попросить специалиста по базам данных помочь с архитектурой продукта.
Реляционная база данных по-прежнему является основной и часто лучше всего подходит для хранения решений, отвечающих требованиям безопасности.
КИСЛОТА или связанные данные (например, продукты, показывающие организационную иерархию, иерархические каталоги продуктов и т. д.).
Однако теперь у нас есть множество альтернативных вариантов создания распределенного хранилища в зависимости от типа данных.
Итак, если у вас есть данные в формате JSON, то хранилище документов будет лучшим решением.
Хранение данных в собственном формате всегда должно быть сбалансировано с накладными расходами на внедрение и поддержку дополнительных технологий.
Организационные неудачи
5. Деление по функциям
Раньше, когда мы создавали и продавали программное обеспечение, роль функциональных менеджеров заключалась в полной изоляции функциональных отделов таким образом, чтобы нейтрализовать все отвлекающие факторы и обеспечить максимальную концентрацию на задаче.Хорошо, когда каждая команда имела узкоспециализированную направленность, а результат работы передавался на конвейер.
Сегодняшние SaaS-компании производят сервис, и изменения в решение вносятся каждые две недели, а иногда и несколько раз в день.
Это обязывает менеджеров по продуктам чаще общаться с инженерами, а инженеров по инфраструктуре — отвечать еще до начала кодирования.
Функциональная организация иногда приводит к более низкому качеству, медленному выходу на рынок, низкому уровню инноваций и конфликтам между функциональными командами.
Лучшие команды сегодня являются междисциплинарными, автономными и контролируют сервис от идеи до поддержки (следуя принципу непрерывного проектирования услуг Уильяма Макдоноу).
Если вы сомневаетесь в этом принципе, спросите себя: «Что нам делать во время кризисаЭ» Ответ почти всегда будет такой: «Мы собираем людей из разных команд, запираем их в комнате и просим решить задачу».
Если это важно в кризис, то почему бы нам не делать это каждый день?
6. Команды слишком большие
Еще одна серьезная ошибка при масштабировании организации — слишком много людей работают над одним и тем же кодом.Когда в команде более 15-20 инженеров, между ними начинает страдать коммуникация и координация.
Разногласия возникают в планировании ресурсов, цепочке подчинения и принятии решений.
Эти конфликты отнимают время, отведенное на производство нового функционала, что снижает ценность продукта для клиентов.
Изоляция ошибок в сервисах (см.
пункт 2 об архитектуре) может создать естественные разделения в продукте, которые нейтрализуют эти конфликты.
Хорошо, когда команда отвечает за несколько сервисов (вход, регистрация, поиск), но две команды не должны отвечать за один и тот же сервис.
7. Неумение ухаживать за своим садом.
Хорошие лидеры всегда сеют, поливают и пропалывают свой «сад» сотрудников: привлекают новые таланты (посев), развивают членов команды (полив) и позволяют им уйти, когда это необходимо (прополка).
Для достижения лучших результатов нужно постоянно оценивать свою команду.
Нам нравится анализировать производительность сотрудника по трем направлениям: навыки, рост и поведение.
Категория навыков — это то, насколько хорошо они знают и выполняют ту роль, для которой их наняли.
Если он разработчик Java, насколько хорошо он пишет код на Java? Категория роста — есть ли у коллег возможность выйти за рамки своей нынешней роли.
Готовы ли некоторые из них стать старшими разработчиками? Способны ли они стать архитекторами? Хотят ли они и способны лидировать? Последняя категория — поведение.
Насколько поведение соответствует корпоративной культуре? Эта часто упускаемая из виду категория оказывает наибольшее негативное влияние на команду в целом.
Сотрудник может быть отличным разработчиком Java и лучшим архитектором масштабируемых систем в мире, но если он демотивирует или мешает работе остальной команды, от него нужно избавиться, как от сорняка.
Сбой процесса
8. Неспособность учиться
Пророческая фраза Сантаяны: «Те, кто не извлекает уроков из истории, обречены повторять ее», справедлива для организаций и продуктов.Сервис оказался недоступен в результате сбоя, и если вы хотите только восстановить его работоспособность, то вы упускаете потрясающую возможность сделать выводы и узнать новое.
Каждую неудачу следует рассматривать как повод не повторять ошибок прошлого.
Чтобы выделить время и провести тщательное расследование, требуется самодисциплина.
Если вы думаете, что причиной отключения вашей службы был аппаратный сбой, вы определенно заблуждаетесь.
Продолжайте спрашивать: «ПочемуЭ» пока вы не обнаружите коренные причины в архитектуре, людях и процессах.
9. Вера в Agile как в панацею
Гибкая разработка — отличная вещь, но ее использование не решает проблем со структурой команды (см.пункты 5 и 6 в разделе о провалах с организацией) или бизнес-задач, таких как коммуникация между продуктовым отделом и отделом продаж.
Понимание Agile как части бизнес-процесса, а не просто теории разработки программного обеспечения, имеет важное значение для успеха.
Наконец, Agile может решить некоторые проблемы, для решения которых он предназначен.
Ожидать, что она гарантирует конкретные результаты в определенные даты, все равно, что ожидать, что плотник починит вашу ванную комнату (см.
пункт 4 в разделе «Архитектурные ошибки»).
10. Нагрузочное тестирование и тестирование производительности покажут все проблемы масштабирования.
Если ваша компания зависит от системы, которая запускается раз в год, например, в Киберпонедельник, вам необходимо посвятить все свои ресурсы нагрузочному тестированию производительности.
Однако проблема проверки в том, что она осуществляется по предполагаемым действиям пользователей.
Это достаточно эффективный способ проверки того, не меняется ли программное обеспечение.
Но в большинстве компаний программное обеспечение часто меняется, и поэтому часто меняется поведение клиентов.
Клиенты создают более тяжелые отчеты или делают вдвое больше запросов, если вы измените цвет кнопки поиска.
Другими словами, их поведение несколько непредсказуемо.
А поскольку при тестировании текущая версия сравнивается с базовой, подумайте, как какая-нибудь промежуточная версия будет сравниваться с последней? Не стоит доверять тому, что результаты испытаний покажут все возможные неисправности.
Вместо этого разделение клиентов на зоны изоляции (см.
пункт 2 в разделе «Проблемы архитектуры») поможет распространить обновление на небольшую группу пользователей и использовать для тестирования фактическое поведение клиентов в новом программном обеспечении.
Рекомендуем книгу к прочтению.
Авторы книги не стали описывать догму, но указали на тонкости, о которых порой могут забыть даже самые лучшие из нас, а именно:
- правильно выбранные и примененные инструменты и методологии;
- грамотное управление командой;
- опора на ранее приобретенный опыт.
- Проектирование программного обеспечения
- Разработка программного обеспечения: этапы и принципы
- Поддержка программного обеспечения
10 главных ошибок в системах масштабирования .
8 принципов планирования развития, которые упрощают жизнь .
5 основных рисков при разработке программного обеспечения на заказ .
Теги: #масштабирование #масштабирование веб-приложений #разработка #разработчик #agile #edisonsoftware #edisonsoftware #edisonsoftware #разработка веб-сайтов #программирование #разработка мобильных приложений
-
В Чем Основное Преимущество Ит-Поддержки?
19 Oct, 24 -
История Одного Неудачного Взлома
19 Oct, 24 -
Форма: Подкаст №2
19 Oct, 24 -
Застывший Момент Бесконечности...
19 Oct, 24 -
Школьные Дневники Теперь В Сети
19 Oct, 24
