Как ограничить влияние изменений клиента на производственные системы

Question

Наш магазин разработал несколько ВЕБ-решений / SMS / DB для дюжины клиентских установок.Приложения предъявляют некоторые требования к производительности в режиме реального времени и достаточно хороши только для того, чтобы функционировать должным образом.Проблема в том, что клиенты (владельцы производственных серверов) используют один и тот же сервер / базу данных для настроек, которые вызывают проблемы с производительностью приложений, которые мы создали и развернули.

Несколько примеров пользовательских настроек:

• Добавление больших таблиц с большим количеством текстовых типов данных для столбцов, которые преобразуются в другие типы данных в запросах
• Никаких первичных ключей, индексов или ограничений FK
• Использование внешних скриптов, которые используют count(*) from table where id = x, в цикле из скрипта, чтобы определить, как позже создавать дополнительные запросы в том же скрипте.(никаких массовых действий, которые планировщик мог бы оптимизировать, или просто сделать все за один проход)
• Все новые файлы кода на сервере создаются / принадлежат root с правами доступа 0777

Клиенты плохо воспринимают предложения / критику.Если мы просто продолжим и попытаемся сами перенести / изменить скрипты, старый код может вернуться, перечеркивая любые внесенные нами изменения!Или, не имея ограниченных знаний об их вариантах использования, мы нарушаем функциональность, пытаясь оптимизировать их изменения.

Мой вопрос заключается в следующем:как мы можем ограничить ресурсы запросами / приложениями, отличными от тех, которые мы создаем и развертываем?Есть ли какие-то прагматичные варианты в подобных сценариях?Мы гордились тем, что у нас есть решение OSS, но, похоже, это стало помехой.

Мы используем PG 8.3, работающую в диапазоне дистрибутивов Linux.Клиенты предпочитают php, но shell-скрипты, perl, python и plpgsql - все они используются в системе в той или иной форме.

Answer 1

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

Во-первых, со стороны базы данных.Теперь есть способ управлять ресурсами запросов в PostgreSQL.Основная трудность заключается в том, что такие инструменты, как "nice", контролируют загрузку процессора, но если база данных не помещается в оперативную память, вполне возможно, что вас убивает использование ввода-вывода.Видишь это сообщение разработчика обобщая проблемы здесь.

Теперь, если на самом деле клиенты перегружают процессор, вы можете использовать два метода для улучшения этой ситуации:

• Установите функцию C, которая изменяет приоритет процесса (пример 1, пример 2) и убедитесь, что всякий раз, когда они что-то запускают, оно вызывается первым (возможно, поместите это в их конфигурационный файл psql, есть другие способы).
• Напишите скрипт, который ищет процессы postmaster, созданные по их идентификатору пользователя, и обновите их, сделайте так, чтобы он часто запускался в cron или как демон.

Похоже, ваша проблема заключается не в конкретных процессах запроса, которые они запускают, а скорее в других изменениях, которые они вносят в более крупную структуру.Есть только один способ справиться с этим:вы должны относиться к клиенту как к злоумышленнику и использовать подходы этой части сферы компьютерной безопасности, чтобы обнаружить, когда он что-то напортачит.Серьезно!Установите на сервер систему обнаружения вторжений, такую как Tripwire (есть инструменты получше, это всего лишь классический пример), и пусть она предупреждает вас, когда они к чему-либо прикасаются.Новый файл с номером 0777?Должно выскакивать прямо из соответствующего отчета IDS.

На стороне базы данных вы не можете напрямую обнаружить, что база данных была изменена с пользой.Вы должны каждый день делать pg_dump схемы в файл (pg_dumpall -g и pg_dump -ы, затем сравните это с последним, которое вы доставили, и снова предупредите вас, когда оно будет изменено.Если вам это удастся, контакт с клиентом превратится в "мы заметили, что вы изменились на сервере...чего ты пытаешься этим добиться?", что заставляет тебя выглядеть так, будто ты действительно уделяешь им внимание.Это может превратиться в возможность для продаж, и они, возможно, перестанут так много возиться с вещами, просто зная, что вы сразу же поймете это.

Еще одна вещь, которую вам следует начать делать немедленно, - это установить как можно больше программного обеспечения для контроля версий на каждый клиентский блок.Вы должны иметь возможность войти в каждую систему, запустить соответствующий инструмент status / diff для установки и посмотреть, что изменилось.Пусть это вам тоже регулярно присылают по почте.Опять же, это работает лучше всего, если сочетать с чем-то, что сбрасывает схему как компонент с тем, чем она управляет.Недостаточно людей используют серьезные подходы к контролю версий кода, который находится в базе данных.

Это основной набор технических подходов, полезных здесь.Остальное, с чем вы столкнулись, - это классическая проблема управления клиентами-консультантами, которая в гораздо большей степени касается людей, чем компьютеров.Не унывайте, могло быть и хуже - FSM помогут вам, если вы предоставите им доступ к ODBC, и они обнаружат, что могут писать свои собственные запросы в Access или что-то простое в этом роде.