Архитектурные ошибки
1. Проектирование реализации, но не поиск архитектурного решения
Какие из следующих подходов вы бы использовали для описания архитектуры своего продукта?
Вариант А: «Мы Java-магазин, работающий на GlassFish, Apache Felix с MySQL и СУБД MongoDB».
Вариант В: «У нас 3-х уровневая архитектура с изолированными зонами, которые для устойчивости к сбоям не имеют синхронной коммуникации друг с другом. Постоянное хранилище данных — сочетание реляционной и NoSQL- баз данных с использованием встроенной репликации с горизонтальным шардингом».
Правильный ответ «В». Ответ «А» лучше описывает реализацию архитектуры по состоянию на любой день, но не говорит о масштабируемости. Компоненты (язык программирования, операционные системы, базы данных, аппаратное обеспечение и т.д.) будут масштабироваться или нет в зависимости от того, каким образом взаимодействуют эти системы. Масштабируемость и доступность не появляются из воздуха. Только правильное проектирование дает возможность легкой замены компонентов программного решения в случае необходимости.
2. Проектирование без расчета на ошибку
Оборудование, программное обеспечение, центры обработки данных, интернет-провайдеры, процессы и люди, особенно люди. Когда система правильно спроектирована, и основные службы или потребительские сегменты изолированы, последствия любого отказа каждого элемента незначительны. Временное отключение оплаты в ecommerce-платформе не должно сбить возможность поиска, просмотра или добавления продуктов в корзину для последующей покупки. Чрезвычайно высокая загрузка от одного клиента не станет причиной сбоев у всех остальных.
Гибель «Титаника» — один из самых известных примеров ошибки проектирования, стоившей целого проекта: отсеки корабля не были полностью изолированными, и когда корабль дал крен на нос, вода просто переливалась поверх переборок, пока не залила всё
3. Вертикальное масштабирование вместо распределения нагрузки
Многие продукты все еще полагаются на реляционную базу данных (MySQL, Oracle, SQL Server и т.д.) в качестве основного хранилища. Вместо сегментирования клиентов по множеству небольших баз данных (каждый хостинг с несколькими клиентами для повышения эффективности затрат) многие компании по-прежнему полагаются на дорогое и высокопроизводительное оборудование для масштабирования монолитной системы.
Подобное «решение» в конечном итоге приведет к увеличению расходов на транзакции и большему урону в случае сбоя по мере роста компании. Кроме того, эффективность капиталовложений окажется низкой, так как громоздкая система будет простаивать пока постепенно не вырастет нагрузка. В конце концов, крупнейшая система окажется недостаточно крупной, и у вашего продукта все равно возникнут проблемы. Вспомните eBay 1999 года или PayPal в 2004 году.
4. Использование неверных инструментов
Пригласите плотника починить ваш санузел, и он придет с молотком. Вы, вероятно, не будете довольны результатами. Это то же, что попросить специалиста по базам данных помочь с архитектурой продукта. Реляционная база данных по-прежнему основная и часто оптимально подходит для хранения решений, требующих строгого соблюдения требований ACID, или связанных данных (например, продукты, показывающие организационные иерархии, иерархичные каталоги продукции и т.д.). Тем не менее, теперь мы располагаем множеством альтернативных вариантов для создания распределенного хранения в зависимости от типа данных. Так, если у вас есть данные формата JSON, то хранилище документов будет лучшим решением. Хранение данных в естественном формате всегда должно быть сбалансировано с накладными расходами на внедрение и поддержку дополнительных технологий.
Организационные неудачи
5. Разделение по функциям
В прошлом, когда мы создавали и продавали программное обеспечение, роль функциональных менеджеров заключалась в полной изоляции функциональных отделов таким образом, чтобы нейтрализовать все отвлекающие факторы и позволить максимально сосредоточиться на выполнении задачи. Было хорошо, когда каждая команда имела узкоспециализированную направленность, а результат работы передавался на линию сборки. Сегодняшние SaaS-компании производят услугу, и изменения в решение вносятся раз в две недели, а иногда и несколько раз в день. Это обязывает product-менеджеров говорить с инженерами чаще, а инфраструктурных инженеров реагировать еще до начала кодирования. Функциональная организация иногда приводит к снижению качества, медленному выходу на рынок, низкому уровню инноваций и конфликтам между функциональными командами. Лучшие команды сегодня — это многопрофильные, автономные и контролирующие сервис от зарождения идеи до поддержки (по дизайнерскому принципу Уильяма Макдоноу «от колыбели до колыбели» для развития услуг). Если вы сомневаетесь в этом принципе, спросите себя: «Что мы делаем в период кризиса?». Почти всегда ответ будет следующий: «Собираем людей из разных команд, закрываем их в комнате и просим, чтобы они решили проблему». Если это важно в кризис, то почему мы не делаем этого каждый день?
6. Слишком большие команды
Еще одна важная ошибка в масштабировании организации — наличие излишнего количества людей, работающих с одним кодом. Когда команда составляет более чем 15-20 инженеров, связи между ними и координация начинают страдать. Разногласия возникают в планировании ресурсов, субординации и принятии решений. Эти конфликты занимают отведенное на производство нового функционала время, что снижает ценность продукта для клиентов.
Изоляция неисправностей в службах (см. п. 2 про архитектуру) может создать естественные разделения в продукте, которые нейтрализуют эти конфликты. Хорошо, когда команда отвечает за несколько служб (логин, регистрация, поиск), но две команды не должны быть в ответе за одну и ту же службу.
7. Неумение ухаживать за своим садом
Хорошие руководители всегда засеивают, поливают и пропалывают свой «сад» сотрудников: привлекают новые таланты (посев), развивают членов команды (полив), а при необходимости позволяют им уйти (прополка). Для лучшего результата необходимо постоянно оценивать свою команду. Нам нравится анализировать производительность работника по трем направлениям: мастерство, рост и поведение. Категория умения — это то, насколько хорошо они знают и выполняют роль, для которой были наняты.
Если это Java-разработчик, насколько хорошо он кодирует на Java? Категория роста — имеют ли коллеги возможность выйти за пределы их нынешней роли. Готовы ли некоторые из них стать старшими разработчиками? Способны ли они быть архитекторами? Хотят ли и в состоянии руководить? Последняя категория — поведение. Насколько поведение соответствует культуре компании? Эта часто упускаемая из виду категория оказывает наибольший негативный эффект на команду в целом. Сотрудник может быть отличным разработчиком Java и лучшим в мире архитектором масштабируемых систем, но если он демотивирует или мешает остальной части команды, от него нужно избавляться как от сорняка.
Сбой процесса
8. Неспособность учиться
Пророческая фраза Сантаяна «Кто неспособен учиться на ошибках истории, обречен повторять ее» — верна для организаций и продукции. Сервис оказался недоступен в результате сбоя, и если вы хотите только восстановить его работоспособность, то упускаете потрясающую возможность сделать выводы и научиться новому. Каждую неудачу следует рассматривать как повод больше не повторять ошибок прошлого. Требуется самодисциплина, чтобы потратить время и провести тщательное расследование. Если считаете, что причиной отключения вашего сервиса был аппаратный сбой, вы точно промахнулись. Продолжайте задавать вопрос «Почему?», пока не обнаружите основные причины в архитектуре, людях и процессах.
9. Вера в Agile как в панацею
Гибкая методология разработки — великая вещь, но ее использование не решает проблем со структурой команды (см. пункты 5 и 6 в разделе неудач с организацией) или бизнес-задачами, такими как коммуникации между продуктовым и торговым отделом. Понимание Agile как части бизнес-процесса, а не просто теории разработки программного обеспечения очень важно для достижения успеха. Наконец, Agile может исправить часть проблем, для решения которых она предназначена. Ожидать от нее гарантии получения конкретных результатов в конкретные даты аналогично ожиданиям, что плотник починит ваш санузел (см. п. 4 в архитектурных ошибках).
10. Нагрузочное и тестирование производительности покажут все проблемы масштабирования
Если ваша компания зависит от системы, выполняемой раз в год, например, в кибер-понедельник, то вам необходимо направить все средства на проведение нагрузочного тестирования производительности. Однако, проблема проверки в том, что она проводится на предполагаемых действиях пользователей. Это довольно эффективный способ тестирования, если ПО не меняется. Но в большинстве компаний программное обеспечение меняется часто, а следовательно, часто меняется и поведение клиентов. Клиенты запускают более тяжелые отчеты или делают в два раза больше запросов, если вы измените цвет кнопки поиска. Иначе говоря, их поведение отчасти непредсказуемо. И поскольку тестирование сравнивает текущую версию с базовой, подумайте, как некоторая промежуточная версия будет соотносится с последней? Не следует верить, что результаты тестирования покажут все возможные сбои. Вместо этого, разделение клиентов на зоны изоляции (см. пункт 2 в проблемах с архитектурой) поможет выкатить обновление для небольшой группы пользователей и использовать фактическое поведение клиентов на новом программном обеспечении для проведения тестирования.
Рекомендуем книгу к прочтению. Авторы книги не описали догму, но указали на тонкости, о которых порой могут забыть даже лучшие из нас, а именно:
- правильно подобранные и применённые инструменты и методологии;
- грамотный менеджмент в команде;
- опора на полученный ранее опыт.
Достаточно ли такой триады для успеха софтверного продукта?
Предыдущие посты:
This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.
Комментариев нет:
Отправить комментарий