Программное обеспечение взаимозависимости (схема серверов компании)
В мире Интернета так много мелочей может сломать сайт (обновление библиотеки, кода и т. Д.).
У нас в нашей компании есть эта проблема, чтобы недостаточно проверить, что может случиться после обновления).
Эта тема предназначена для того, чтобы объяснить вам, что мы ищем: программное обеспечение / ваши советы, чтобы легко проверить все воздействия, которые могут спровоцировать новый код / новое обновление библиотеки / и т. Д.
Вот два примера:
Пример 1:
Мы установили NewRelic на один из наших серверов, однако мы не знали, что NewRelic (по-видимому) включал много файлов PHP для каждого запроса.
Вот что произошло: достигнут предел максимального количества включенных файлов в PHP, и некоторые страницы потерпели крах (ошибка E_WARNING).
Пример 2:
Мы изменили тип репликации между 2 MySQL Server (с Master -> Slave на Master <-> Master).
Вот что произошло: мы использовали Percona, и неправильная конфигурация привела к запрету двух серверов (из-за большого количества запросов SQL).
Наш вопрос:
Мы хотели бы подробно описать нашу текущую структуру. Затем мы хотели бы полагаться на все серверы, библиотеку, используемую для каждого сервера, специфику нашего самодельного кода и т. Д. И использовать эти данные, когда мы хотим что-либо обновить.
Мы можем сказать: "Я собираюсь обновить небольшой PHP-код на этом сервере". И программное обеспечение может помочь нам узнать все возможные проблемы / последствия.
1 ответ
Очень просто: это называется тестовая или промежуточная среда.
Он настроен точно так же, как ваша производственная среда, затем вы развертываете его так же, как и на производстве, а затем тщательно тестируете.
Нет аналитического способа сделать это; ты должен сделать это. /edit - чтобы расширить это. Нет никакого способа, которым одно только программное обеспечение могло бы сделать это, особенно с вашими собственными продуктами в соединении. Вам нужно будет создать набор правил, основанный на подробном чтении каждого набора замечаний к выпуску и, возможно, баз данных ошибок, для каждого задействованного продукта - при условии, что они были общедоступными и полными, на что не стоит рассчитывать, Когда-либо. Таким образом, единственным реальным тестом является выполнение запланированного обновления и тестирование функциональности, предпочтительно включающей что-то вроде рабочей нагрузки.
Это та же самая причина, по которой вы выполняете тестирование резервного копирования / восстановления и тестирование аварийного восстановления - вы не будете знать, что пропустили, или что было неправильно настроено, пока не будете вынуждены это сделать. И лучше сделать это по плану, в качестве теста, чем запустить его в производство.