Назад | Перейти на главную страницу

Предвидение / предотвращение проблем с исправлением или обновлением на базе данных / веб-серверах

Я поддерживаю 2 среды в моем текущем проекте, 2 сервера (1 веб-сервер и 1 SQL Server) как для производства, так и для тестирования. В прошлом месяце мы установили / обновили до последних патчей / ценных бумаг Microsoft, и диспетчер отчетов от Reporting Services перестал работать на сервере тестовой базы данных. После нескольких дней устранения неполадок я обнаружил, что расширение веб-службы ASP.NET 2.0 в ISIS было полностью удалено и все было запрещено.

Я не могу сказать наверняка, но я думаю, что это было вызвано патчем / обновлением, которое я сделал на этом сервере за несколько дней до этого. Что можно сделать, чтобы предвидеть или предотвратить подобные воздействия на SQL Server, Reporting Services, IIS, ASP.NET при установке исправления?

(с точки зрения Linux, но довольно общий)

  1. Не позволяйте ОС автоматически устанавливайте патчи - просто скачайте их и сообщите вам. Затем вы можете установить их вручную, чтобы, если что-то пойдет не так, вы могли сразу решить эту проблему.
  2. Я настраиваю все свои критические серверы в кластеры, чтобы их можно было исправлять по одному и перезагружать без простоев - и если что-то пойдет не так, мне будет время благодати чтобы исправить это, и лучше спланируйте следующий.
  3. Я всегда сначала устанавливаю патч на менее критичный сервер, чтобы, если он все испортит, никто не заметил :)
  4. Наша среда виртуальный, что позволяет нам снимок состояние сервера, прежде чем что-либо с ним делать (например, исправлять). Возможно, эквивалентом будет создание полной резервной копии хоста перед установкой исправлений.
  5. иметь план отката это позволит вам вернуться в состояние, в котором находилась система до внесения каких-либо изменений.

Один из подходов - оценить исправления, а не просто сразу установить их. У нас есть группа людей, которые специально рассматривают исправления для Microsoft и других распространенных приложений, оценивают серьезность уязвимости и обсуждают с владельцами приложений риски и т. Д.

Некоторые исправления считаются критическими и применяются в течение 48 часов (или меньше) после выпуска. Мы начали исправлять уязвимость RPC прошлой осенью в течение 30 минут после ее выпуска. В других случаях мы подождем до 6 недель в зависимости от серьезности проблемы, способности снизить риск эксплуатации и необходимых усилий по тестированию.

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

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

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

При применении к производственной среде всегда имейте проверенный план отката, чтобы вы могли вернуться в исходное состояние, когда что-то выйдет из строя. (это технический термин)