Я новичок в этой теме и надеялся, что кто-нибудь сможет пролить на нее свет. Я работаю над созданием корпоративной сети, в которой, очевидно, будет несколько серверов и несколько рабочих станций.
Допустим, выходит новая версия Adobe Flash. Я думаю, вы захотите протестировать это обновление в тестовой среде, прежде чем «отправлять его» на серверы и рабочие станции.
Как вы, ребята, контролируете, тестируете, а затем выпускаете обновления приложений? (я не говорю об обновлениях Windows). Используете ли вы сторонний инструмент системного администратора? Домашнее программное обеспечение?
Любая информация будет принята с благодарностью :)
SCCM от Microsoft и другие продукты сделают это. Однако они позволяют выполнить конкретную задачу: установить программное обеспечение. Большой вопрос в том, как вы это координируете?
В «Практике системного и сетевого администрирования» есть глава, в которой рекомендуются следующие методики:
«один, несколько, много» - обновите свою машину и протестируйте ее в течение нескольких дней. Обновите еще несколько (скажем, других системных администраторов в вашей команде). Затем раскройте «многие»: все большие и большие группы.
"canary" - Обновляйте по одному каждые [период времени], пока не закончите.
«экспоненциальный» - обновить 1, затем еще 2, затем еще 4, затем еще 8. Размер группы каждый раз увеличивается вдвое.
«последний с неблагоприятным для риска» - разделите организацию на группы и сделайте в первую очередь наиболее рискованные, а в последнюю очередь - наиболее неблагоприятные для риска. Например, может быть одна группа, которая гордится тем, что является передовой и добровольно выйдет из нее (ИТ-отдел, инженерный отдел). Может быть группа, которая очень подозрительно относится к обновлениям, и они идут последними (бухгалтерия, руководители и т. Д.). Меньшие группы, вероятно, тоже должны идти первыми.
Независимо от того, как вы группируете обновления, сначала нужно протестировать обновления, а.
После каждой «группы» обновлений проведите серию тестов. Если какие-либо тесты не пройдут или появятся сообщения о проблемах, прекратите выполнение обновлений. Если возможно (или безопасно), вернитесь к предыдущей версии.
Обновления не должны начинаться, пока вы не выполните свои собственные тесты. Например, в лаборатории или на собственной машине. Более структурированные тесты будут включать в себя попытку обновления на одной машине каждого типа, одной версии каждой версии ОС и так далее. Тесты должны включать запуск и остановку программного обеспечения, а также выполнение его основных функций (поскольку вы упомянули Flash: попробуйте воспроизвести видео, запустить флэш-игру и т. Д.). Хорошо иметь вики-страницу, в которой документируется, какие комбинации тестировались и какие тесты вы запускали. В следующий раз, когда вы обновите этот пакет, у вас будет хороший список тестов. Если во время обновления сообщается о проблеме, добавьте тест в список, чтобы предотвратить эту проблему в будущем. Поскольку вы упомянули Flash, я недавно обнаружил проблему с приложением отслеживания еды Weight Watcher и определенной версией Flash. Мы добавили URL-адрес этого приложения в список тестов и теперь знаем, что новые обновления Flash должны быть протестированы с ним, прежде чем мы его выпустим.
Между каждой «группой» обновлений делайте паузу на некоторое время, чтобы увидеть, не возникнут ли ошибки. Будет ли это день или неделя, зависит от многих факторов: большое ли это изменение? Были ли предыдущие обновления группы успешными? Следите за своими обращениями в службу поддержки на предмет отчетов о проблемах, связанных с обновлением. Если у вас есть постоянные помощники службы поддержки, информируйте их о том, какие обновления находятся в стадии разработки, чтобы они искали проблемы.
Используете ли вы «одну, несколько, много» или другие методологии, зависит от многих факторов. «Один, несколько, много» хорош в небольших помещениях. «Экспонента» хороша для больших рабочих столов, где централизованно управляются сотни машин. "Risk-adveres last" хорош, когда вы можете разделить пользователей на определенные группы с разными "личностями". «Canary» используется в веб-фермах и грид-вычислениях, где у вас есть сотни или тысячи машин с одинаковой конфигурацией.
Самое главное - делать хорошие заметки. Если вам однажды пришлось сделать хорошее обновление, вам придется делать больше обновлений в будущем. Вы хотите, чтобы процесс стал повторяемым, и для этого важно вести список выполненных тестов. В следующий раз, когда вы сделаете подобное обновление, вам придется меньше думать, что означает меньше ошибок («ой, я забыл протестировать бла-бла-бла»), и оно пойдет быстрее. Фактически, если вы сохраните базовую документацию, вы можете делегировать ее новому, младшему системному администратору, которого вы наняли. Он или она может повторить ваш процесс, добавить к нему и улучшить его. Вы можете сосредоточиться на их обучении и проверке их работы. Тем временем вы можете работать над другими проектами.
Существуют инструменты, которые могут помочь в этом, такие как Microsoft SCCM, развертывание программного обеспечения Active Directory, Altaris, LanDesk и т. Д. Существует миллион и один способ распространять обновления, но компании, которые следуют лучшим бизнес-практикам и не заставляют своих пользователей-администраторов использовать по крайней мере, один из них.
Что касается тестирования, я обычно сначала загружаю обновление на свой компьютер и в небольшую тестовую лабораторию. Покопайтесь в течение нескольких минут, затем передайте его избранной группе в ИТ-отделе, которая знает, что они являются частью моего графика ранних выпусков. Потом, если нет проблем, всем подталкиваю.
если вы ищете легкий инструмент для создания сценариев обновления системы и управления различными профилями - взгляните на wpkg. он предоставляет вам только структуру, но в конце вы должны сами выяснить синтаксис обновления / тихой установки / удаления.
как только вы его установите, у вас может быть несколько виртуальных машин - членов тестовой группы - где вы тестируете новые версии, прежде чем сделать их доступными для всех пользователей.
сайты как Itninja [бывший appdeploy] или wpkg.org может быть источником рецептов автоматической установки для различного программного обеспечения.