Программное обеспечение взаимозависимости (схема серверов компании)

В мире Интернета так много мелочей может сломать сайт (обновление библиотеки, кода и т. Д.).

У нас в нашей компании есть эта проблема, чтобы недостаточно проверить, что может случиться после обновления).

Эта тема предназначена для того, чтобы объяснить вам, что мы ищем: программное обеспечение / ваши советы, чтобы легко проверить все воздействия, которые могут спровоцировать новый код / ​​новое обновление библиотеки / и т. Д.

Вот два примера:

Пример 1:

Мы установили NewRelic на один из наших серверов, однако мы не знали, что NewRelic (по-видимому) включал много файлов PHP для каждого запроса.

Вот что произошло: достигнут предел максимального количества включенных файлов в PHP, и некоторые страницы потерпели крах (ошибка E_WARNING).

Пример 2:

Мы изменили тип репликации между 2 MySQL Server (с Master -> Slave на Master <-> Master).

Вот что произошло: мы использовали Percona, и неправильная конфигурация привела к запрету двух серверов (из-за большого количества запросов SQL).

Наш вопрос:

Мы хотели бы подробно описать нашу текущую структуру. Затем мы хотели бы полагаться на все серверы, библиотеку, используемую для каждого сервера, специфику нашего самодельного кода и т. Д. И использовать эти данные, когда мы хотим что-либо обновить.

Мы можем сказать: "Я собираюсь обновить небольшой PHP-код на этом сервере". И программное обеспечение может помочь нам узнать все возможные проблемы / последствия.

1 ответ

Очень просто: это называется тестовая или промежуточная среда.

Он настроен точно так же, как ваша производственная среда, затем вы развертываете его так же, как и на производстве, а затем тщательно тестируете.

Нет аналитического способа сделать это; ты должен сделать это. /edit - чтобы расширить это. Нет никакого способа, которым одно только программное обеспечение могло бы сделать это, особенно с вашими собственными продуктами в соединении. Вам нужно будет создать набор правил, основанный на подробном чтении каждого набора замечаний к выпуску и, возможно, баз данных ошибок, для каждого задействованного продукта - при условии, что они были общедоступными и полными, на что не стоит рассчитывать, Когда-либо. Таким образом, единственным реальным тестом является выполнение запланированного обновления и тестирование функциональности, предпочтительно включающей что-то вроде рабочей нагрузки.

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

Другие вопросы по тегам