Мартин Л. Эббот и Майкл Т. Фишер, авторы книги «Искусство масштабируемости», перечисляют наиболее распространенные архитектурные, организационные и технологические проблемы масштабировании в product-группах. Список был сформирован на основе их опыта, а также в ходе коммуникаций с клиентами и лег в основу первой книги.
Какие из следующих подходов вы бы использовали для описания архитектуры своего продукта?
Вариант А: «Мы Java-магазин, работающий на GlassFish, Apache Felix с MySQL и СУБД MongoDB».
Вариант В: «У нас 3-х уровневая архитектура с изолированными зонами, которые для устойчивости к сбоям не имеют синхронной коммуникации друг с другом. Постоянное хранилище данных — сочетание реляционной и NoSQL- баз данных с использованием встроенной репликации с горизонтальным шардингом».
Правильный ответ «В». Ответ «А» лучше описывает реализацию архитектуры по состоянию на любой день, но не говорит о масштабируемости. Компоненты (язык программирования, операционные системы, базы данных, аппаратное обеспечение и т.д.) будут масштабироваться или нет в зависимости от того, каким образом взаимодействуют эти системы. Масштабируемость и доступность не появляются из воздуха. Только правильное проектирование дает возможность легкой замены компонентов программного решения в случае необходимости.
Оборудование, программное обеспечение, центры обработки данных, интернет-провайдеры, процессы и люди, особенно люди. Когда система правильно спроектирована, и основные службы или потребительские сегменты изолированы, последствия любого отказа каждого элемента незначительны. Временное отключение оплаты в ecommerce-платформе не должно сбить возможность поиска, просмотра или добавления продуктов в корзину для последующей покупки. Чрезвычайно высокая загрузка от одного клиента не станет причиной сбоев у всех остальных.
Гибель «Титаника» — один из самых известных примеров ошибки проектирования, стоившей целого проекта: отсеки корабля не были полностью изолированными, и когда корабль дал крен на нос, вода просто переливалась поверх переборок, пока не залила всё
Многие продукты все еще полагаются на реляционную базу данных (MySQL, Oracle, SQL Server и т.д.) в качестве основного хранилища. Вместо сегментирования клиентов по множеству небольших баз данных (каждый хостинг с несколькими клиентами для повышения эффективности затрат) многие компании по-прежнему полагаются на дорогое и высокопроизводительное оборудование для масштабирования монолитной системы.
Подобное «решение» в конечном итоге приведет к увеличению расходов на транзакции и большему урону в случае сбоя по мере роста компании. Кроме того, эффективность капиталовложений окажется низкой, так как громоздкая система будет простаивать пока постепенно не вырастет нагрузка. В конце концов, крупнейшая система окажется недостаточно крупной, и у вашего продукта все равно возникнут проблемы. Вспомните eBay 1999 года или PayPal в 2004 году.
Пригласите плотника починить ваш санузел, и он придет с молотком. Вы, вероятно, не будете довольны результатами. Это то же, что попросить специалиста по базам данных помочь с архитектурой продукта. Реляционная база данных по-прежнему основная и часто оптимально подходит для хранения решений, требующих строгого соблюдения требований ACID, или связанных данных (например, продукты, показывающие организационные иерархии, иерархичные каталоги продукции и т.д.). Тем не менее, теперь мы располагаем множеством альтернативных вариантов для создания распределенного хранения в зависимости от типа данных. Так, если у вас есть данные формата JSON, то хранилище документов будет лучшим решением. Хранение данных в естественном формате всегда должно быть сбалансировано с накладными расходами на внедрение и поддержку дополнительных технологий.
В прошлом, когда мы создавали и продавали программное обеспечение, роль функциональных менеджеров заключалась в полной изоляции функциональных отделов таким образом, чтобы нейтрализовать все отвлекающие факторы и позволить максимально сосредоточиться на выполнении задачи. Было хорошо, когда каждая команда имела узкоспециализированную направленность, а результат работы передавался на линию сборки. Сегодняшние SaaS-компании производят услугу, и изменения в решение вносятся раз в две недели, а иногда и несколько раз в день. Это обязывает product-менеджеров говорить с инженерами чаще, а инфраструктурных инженеров реагировать еще до начала кодирования. Функциональная организация иногда приводит к снижению качества, медленному выходу на рынок, низкому уровню инноваций и конфликтам между функциональными командами. Лучшие команды сегодня — это многопрофильные, автономные и контролирующие сервис от зарождения идеи до поддержки (по дизайнерскому принципу Уильяма Макдоноу «от колыбели до колыбели» для развития услуг). Если вы сомневаетесь в этом принципе, спросите себя: «Что мы делаем в период кризиса?». Почти всегда ответ будет следующий: «Собираем людей из разных команд, закрываем их в комнате и просим, чтобы они решили проблему». Если это важно в кризис, то почему мы не делаем этого каждый день?
Еще одна важная ошибка в масштабировании организации — наличие излишнего количества людей, работающих с одним кодом. Когда команда составляет более чем 15-20 инженеров, связи между ними и координация начинают страдать. Разногласия возникают в планировании ресурсов, субординации и принятии решений. Эти конфликты занимают отведенное на производство нового функционала время, что снижает ценность продукта для клиентов.
Изоляция неисправностей в службах (см. п. 2 про архитектуру) может создать естественные разделения в продукте, которые нейтрализуют эти конфликты. Хорошо, когда команда отвечает за несколько служб (логин, регистрация, поиск), но две команды не должны быть в ответе за одну и ту же службу.
Хорошие руководители всегда засеивают, поливают и пропалывают свой «сад» сотрудников: привлекают новые таланты (посев), развивают членов команды (полив), а при необходимости позволяют им уйти (прополка). Для лучшего результата необходимо постоянно оценивать свою команду. Нам нравится анализировать производительность работника по трем направлениям: мастерство, рост и поведение. Категория умения — это то, насколько хорошо они знают и выполняют роль, для которой были наняты.
Если это Java-разработчик, насколько хорошо он кодирует на Java? Категория роста — имеют ли коллеги возможность выйти за пределы их нынешней роли. Готовы ли некоторые из них стать старшими разработчиками? Способны ли они быть архитекторами? Хотят ли и в состоянии руководить? Последняя категория — поведение. Насколько поведение соответствует культуре компании? Эта часто упускаемая из виду категория оказывает наибольший негативный эффект на команду в целом. Сотрудник может быть отличным разработчиком Java и лучшим в мире архитектором масштабируемых систем, но если он демотивирует или мешает остальной части команды, от него нужно избавляться как от сорняка.
Пророческая фраза Сантаяна «Кто неспособен учиться на ошибках истории, обречен повторять ее» — верна для организаций и продукции. Сервис оказался недоступен в результате сбоя, и если вы хотите только восстановить его работоспособность, то упускаете потрясающую возможность сделать выводы и научиться новому. Каждую неудачу следует рассматривать как повод больше не повторять ошибок прошлого. Требуется самодисциплина, чтобы потратить время и провести тщательное расследование. Если считаете, что причиной отключения вашего сервиса был аппаратный сбой, вы точно промахнулись. Продолжайте задавать вопрос «Почему?», пока не обнаружите основные причины в архитектуре, людях и процессах.
Гибкая методология разработки — великая вещь, но ее использование не решает проблем со структурой команды (см. пункты 5 и 6 в разделе неудач с организацией) или бизнес-задачами, такими как коммуникации между продуктовым и торговым отделом. Понимание Agile как части бизнес-процесса, а не просто теории разработки программного обеспечения очень важно для достижения успеха. Наконец, Agile может исправить часть проблем, для решения которых она предназначена. Ожидать от нее гарантии получения конкретных результатов в конкретные даты аналогично ожиданиям, что плотник починит ваш санузел (см. п. 4 в архитектурных ошибках).
Если ваша компания зависит от системы, выполняемой раз в год, например, в кибер-понедельник, то вам необходимо направить все средства на проведение нагрузочного тестирования производительности. Однако, проблема проверки в том, что она проводится на предполагаемых действиях пользователей. Это довольно эффективный способ тестирования, если ПО не меняется. Но в большинстве компаний программное обеспечение меняется часто, а следовательно, часто меняется и поведение клиентов. Клиенты запускают более тяжелые отчеты или делают в два раза больше запросов, если вы измените цвет кнопки поиска. Иначе говоря, их поведение отчасти непредсказуемо. И поскольку тестирование сравнивает текущую версию с базовой, подумайте, как некоторая промежуточная версия будет соотносится с последней? Не следует верить, что результаты тестирования покажут все возможные сбои. Вместо этого, разделение клиентов на зоны изоляции (см. пункт 2 в проблемах с архитектурой) поможет выкатить обновление для небольшой группы пользователей и использовать фактическое поведение клиентов на новом программном обеспечении для проведения тестирования.
Рекомендуем книгу к прочтению. Авторы книги не описали догму, но указали на тонкости, о которых порой могут забыть даже лучшие из нас, а именно:
Достаточно ли такой триады для успеха софтверного продукта?
Предыдущие посты:
Архитектурные ошибки
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 в проблемах с архитектурой) поможет выкатить обновление для небольшой группы пользователей и использовать фактическое поведение клиентов на новом программном обеспечении для проведения тестирования.
Рекомендуем книгу к прочтению. Авторы книги не описали догму, но указали на тонкости, о которых порой могут забыть даже лучшие из нас, а именно:
- правильно подобранные и применённые инструменты и методологии;
- грамотный менеджмент в команде;
- опора на полученный ранее опыт.
Достаточно ли такой триады для успеха софтверного продукта?
Предыдущие посты:
Комментарии (32)
occam
01.11.2015 06:54+2В основу триады успеха могло бы тоже войти: «развивать продукт от потребностей пользователей, а не от своих представлений об идеальном». Касаемо масштабируемости, мысли есть интересные, хорошая, наверное, книга, с пользой. Но в шорт-лист ошибок опять не попала экономика. Ведь каждый дополнительный сантиметр к потолку масштабируемости — это могут быть и тысячи, и десятки тысяч долларов: железо, VPCs, избыточное лицензирование, люди, которые берутся впрок — а не правильнее ли иногда потратить однократно миллион на прогноз роста, чем каждый месяц тот же миллион платить в не сбывающие ожидания highload?
VolCh
01.11.2015 08:22+9Так, если у вас есть данные формата JSON, то хранилище документов будет лучшим решением.
Слишком категорично, чтобы быть правдой. Смотреть надо не на формат, а на роль данных, на типовые операции с ними. Преобразование из формата в формат как правило дешево при записи и окончательном выводе, а сама работа с данными может быть очень дорогой при миллионах и миллиардах итераций при неудачном выборе формата хранения.
excoder
01.11.2015 15:42Так точно. А то потом мы будем воротить 2-phase-commit и прочие ad-hoc извращения вокруг нашего чудо-кластера из JSON-NoSQL-базы.
conf
01.11.2015 14:46+1Посоветуйте, пожалуйста, какую-нибудь хорошую книгу по масштабируемости и высоким нагрузкам?
stalkerg
02.11.2015 19:25+4Многие продукты все еще полагаются на реляционную базу данных… Подобное «решение» в конечном итоге приведет к увеличению расходов на транзакции и большему урону в случае сбоя по мере роста компании.
А ничего так, что в не реалицонных БД с этими транзакциями всё совсем плохо? Как вы будете сохранять консистентность? А CAP теорема?
Короче trade-off. Чудес не бывает, либо вам надёжно (с гарантиями) и медленно или вам быстро и ненадёжно (без гарантий). И да масштабирование в ширь оно так же происходит с потерями т.е. это не silver bullet.
lybin
03.11.2015 07:23+13. Вертикальное масштабирование вместо распределения нагрузки
Scaling Up Instead of Out
сегментирования клиентов по множеству небольших баз данных — шардирование же, горизонтальное масштабирование
Shubinpavel
03.11.2015 11:42Зря так про Титаник. Он специально был так спроектирован. Так как если бы переборки были закрыты он бы очень быстро перевернулся на нос и затонул. Куда быстрее, чем в реальности. Подобные случаи, с другими кораблями, упоминались в литературе.
relgames
«Сотрудник может быть отличным разработчиком Java и лучшим в мире архитектором масштабируемых систем, но если он демотивирует или мешает остальной части команды, от него нужно избавляться как от сорняка. „
Интересно, как именно демотивирует. Просто так, без причины? Люди бывают недовольны из-за косяков в менеджменте, например.
i360u
Бывают люди, разговор с которыми — как боксерский поединок: поговорил минут двадцать и часа полтора потом нужно отлеживаться. Бывает, что лучше весь день по стаковерфлоу луркать, чем просто подойти к соседнему столу и спросить. И часто такие персонажи довольно сильны в своих компетенциях, но команду они замедляют в итоге, сидят эдакими буками, загородившись от всего мира кучей мониторов, и тучи с молниями над ними. Сталкивался не раз, и каждый раз, увольнение такого сотрудника — почти единственный выход, не смотря на все его регалии и скилы.
relgames
Интересно. А вы не пробовали у них спрашивать о причинах? Я вот сам такой иногда бываю, достают вопросами, на которые можно в гугле ответ найти.
i360u
Не, не пробовали. Сразу увольняли и все. Конечно, в гугле ведь можно найти все ответы, особенно на вопросы, касающиеся кода, написанного этим конкретным индивидом. Сарказм.
Если серьезно, то расставание с толковым инженером — всегда стресс для команды и менеджеров (которые понимают, насколько тяжело этого человека будет заменить), и конечно, такой ситуации стараются избежать, но воспитывать взрослых людей — дело совсем неблагодарное. Есть люди, которые в принципе органически не способны работать в команде. И если вы «таким бываете» — это повод задуматься о.
excoder
Люди бывают по-природе токсичны. Токсин отравляет всю компанию. Единственный выход – нейтрализовать токсин. Иногда удаётся это сделать, правильно перекалибровав источник токсина. В 80% случаев увольнение есть единый выход.
RPG18
Хреновый из вас боксер. Всегда считал, что стрессоустойчивость необходимое качество для руководителя.
Причины такого поведения нужно обязательно исследовать, а не рубить с плеча. Проблема может быть не в индивиде, а в организации.
xReaper
У нас была точно такая же ситуация, и я рад сейчас что тот человек ушел, спасибо руководителю что его уволили. Задача руководителя это не нянчится с людьми а наладить процесс работы.
RPG18
Что там в вики про организационное поведение написано:
Это соответствует первому комментарию relgames.
i360u
Знаете, я вообще не боксер. Мне больше нравится быть эльфом из страны радуги и розовых пони. И про эту вашу ярлычную «стрессоустойчивость» вы лучше расскажите на тренинге для менеджеров в Макдональдс, а я продолжу искренне и сильно переживать за то, что происходит в команде и с проектом. А реально хороших инженеров, работа с которыми приносит удовольствие, мне (слава Глобу!) попадалось больше, чем неисправимых бук (хотя конечно их также очень мало в общей массе). Вот с ними я и предпочитаю работать.
lega
i360u
А если проект на всех — один? Таких людей, практически всегда, нанимают в расчете на то, что они будут играть одну из ключевых ролей в команде. В этом то и проблема.
dstarcev
del
dstarcev
Коллектив вообще любит середнячков, а слишком глупых и слишком умных отторгает. Но лично я, как разработчик, предпочел бы действовать иначе. Если у меня случается батхерт от того, что кто-то разбирается в моем предмете лучше меня (и нагло указывает на это), то я предпочту воспринять это как вызов и поднять свою квалификацию. Можно, конечно, устранить «обидчика» и расслабиться, но тогда пропадает хороший пинок к собственному развитию.
Подчеркну, что это мнение разработчика. Менеджеру, наверное, больше по душе набор покладистых середняков.
i360u
Ага, это как в первой части фильма герой огребает от злодея, потом долго и упорно изучает кунг-фу, и в конце с блеском всем мстит! Но жизнь — это не кино, и простое человеческое общение — немаловажная часть командной работы. Если этот скил не прокачан (причем не нужно для этого посещать курсы красноречия, достаточно не огрызаться злобно на любой раздражитель) — это чаще оказывается вашей проблемой.
121212121
Коллектив отторгает того, кто не хочет считаться с правилами коллектива. Не имеет значения, глупый они или умный, в этом контексте.
Менеджеру по душе команда высококлассных специалистов своего дела.
Но главное — именно команда. Т.е. когда недостатки одного умело прикрыты достоинствами другого.
Это как кластер серверов: есть несколько нод, хотя можно было бы поставить одну помощнее.
Не нужно же объяснять, какое решение надежнее и масштабируемее.
vbif
Речь вроде шла немножко не о том. Работает со мной такой кадр, которого спросишь «не встречался ли ты с такой проблемой», он не просто ответит «загугли», он встанет за спиной и будет давать рекомендации в стиле капитана Очевидность, и попробуй от него отвязаться! При том, что не сказать даже, что он такой прямо высококлассный специалист.
xSRGx
А иногда есть сотрудники, которые по тысячу раз задают один и тот же вопрос и не учатся на своих ошибках.
i360u
Если человек тупой, то возникает вопрос: как он вообще попал в вашу команду? Для отсева некомпетентных тугодумов и существуют всякие технические интервью и тестовые задания. А иногда, даже умнейшие люди начинают тупить в каких-то смежных областях, просто потому, что не успели подстроиться под задачу. И к этому тоже стоит уметь относиться с пониманием.
olku
Вероятно, речь идет о «диве» — спецу со «звездной болезнью», не способным работать с коллективом. Хотя и косяк менеджмента (он платит зарплату, между прочим) не является оправданием саботажа. То, что тут мягко названо демотивацией и помехой команде.
ivanko
Довольно сильно. Говорю с позиции как раз такого сотрудника. Скорее всего, это часто эмоционально неуравновешенные люди с определенной долей инфантилизма. Легко раздражаются в случае активного согласия или малейшего несогласия и начинают саркастически перебивать, унижать собеседника. Исправление зависит от степени испорченности и на мой взгляд достигается чтением книг про переговоры. Как-то так )
VolCh
Например, путём постоянной критики унаследованных, созданных и создаваемых решений. Скажем, в плане отказоустойчивости. Бизнес взвесил риски и стоимости разных альтернатив, принял решение о внедрении одной из них, о такой человек постоянно публично напоминает о том, что считает принятое решение ошибкой. Может он и прав, но способ донести своё мнение выбрал неудачный.