TL; DR: Мне интересно выяснить, есть ли причина для выбора аддитивного подхода к устранению неполадок вместо субтрактивного подхода или наоборот при попытке устранить проблему со многими переменными.
Обзор проблемы:
Я работаю с группой людей, пытающихся устранить периодически возникающую, но серьезную проблему в промежуточной системе, которая мешает нам продолжить работу с этой новой конфигурацией.
У нас есть сервер приложений Citrix XenApp, работающий в виртуальной инфраструктуре, обслуживающий приложения для клиентов, работающих на удаленных сайтах через глобальную сеть. В головном конце сети между глобальной сетью и физическим сервером (ами), на котором размещены виртуализированные серверы, имеется несколько устройств шифрования / безопасности / межсетевого экрана.
Так что в основном у нас проблема со многими переменными, и мы пытаемся ее устранить. До сих пор мы начали с субтрактивного подхода - пытаясь удалить что-то из системы за раз и пытаясь исключить это, если проблема исчезнет. Нам не очень повезло с этим подходом. Я думал предложить аддитивный подход, при котором мы начнем с минимума системных компонентов, с которыми приложение будет работать, и начнем добавлять вещи в различных комбинациях.
Исходя из вашего опыта, есть ли причины предпочесть аддитивное устранение неполадок субтрактивному или наоборот?
На самом деле я предпочитаю итеративный подход отладки: вы анализируете с помощью симптомов, файлов журналов, сетевых захватов, сравнения лучших практик и / или разработанного намерения с созданной средой и т. Д., Чтобы попытаться найти реальную проблему. Во многих случаях вы обнаружите, что не только один причина сообщенной проблемы с производительностью. Узких мест может быть несколько, или проблема может возникать из-за взаимодействия нескольких компонентов.
Я считаю, что это работает лучше, чем слепое удаление вещей или создание новой среды только для устранения неполадок. Хотя последний подход отлично подходит для предварительного планирования и тестирования: мы бы назвали это средой «разработчика», «тестовой» или «промежуточной» в зависимости от того, как она вписывается в общую архитектуру. Однако это требует, чтобы вы действительно планировали и тестировали ЗАРАНЕЕ, и не у каждой организации есть ресурсы, чтобы сделать это должным образом.