Есть ли недостатки в автоматическом обновлении программного обеспечения? [закрыто]

Обновление программного обеспечения может привести к поломке вашей системы. Вы хотите, чтобы это произошло, пока вы делаете что-то важное?

Возможно, кто-то взломает вашу систему, потому что вы еще не установили обновление для системы безопасности.

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

На протяжении многих лет я наблюдал перебои в работе нескольких служб из-за того, что люди выполняли автоматическое обновление:

• squid прекращает работу из-за новой обновленной второстепенной версии с немного другим синтаксисом;
• Службы DNS отключаются из-за того, что демон динамической маршрутизации прекратил поддержку sysV в второстепенном выпуске;
• Службы Apache не работают из-за нехватки места на диске в уже протестированном пакете;
• Apache не перезагружается из-за обновления, воссоздающего файл по умолчанию...
• Перезапуск Apache, но обновление заменяет главную страницу сайта страницей Apache по умолчанию;
• Неисправность служб DHCP из-за ошибки в второстепенном выпуске;
• Службы netflow остановились на несколько дней из-за того, что кто-то поместил скомпилированный двоичный файл вместо официального двоичного файла пакета;
• rsyslog перестал работать из-за того, что rsyslog изменил некоторый синтаксис, и кто-то настроил репозиторий резервного копирования, не зная толком, что делает;
• Службы FreeRadius перестают работать после отправки непроверенной версии в локальный репозиторий, когда неизвестно, кто настроил Radius с автоматическими обновлениями.

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

Как правильно указывает @panki,часто вы не можете обновлять программное обеспечение вслепую и вводить более короткие или более продолжительные простои во время обновления или, что еще хуже, длительные простои, пока человек не исправит некоторые мелкие (или серьезные )сбои, которые произошли во время обновления.

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

Что касается способов смягчения/управления жизненным циклом обновления, вы можете использовать несколько стратегий, также в зависимости от ваших требований к времени безотказной работы/размера инфраструктуры -:

• просто вручную:
• делать это полуавтоматически -под надзором кого-то;
• мониторинг всех служб и лица, контролирующего процесс, после проверки всех журналов обновлений, слежение за службами мониторинга;
• планировать, какие обновления являются критическими, а какие нет, а не делать их вслепую;
• использование различных выпусков Linux в системах с резервированием (больше работы и больше возможных неполадок... );
• использование резервных/тестовых стендов для услуг и поэтапное обновление;
• использование точки -в -времени "отмеченных" выпусков, например, поддерживаемых yum;
• использование локальных репозиториев/прокси для распределенных контролируемых/протестированных/утвержденных выпусков, подобных Satellite/Katello/Spacewalk для систем на базе RH/CentOS или Aptly для Debian;
• интегрируя эти стратегии с инструментами devops, такими как Ansible.

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

TDLR Управление жизненным циклом обновления операционной системы в производственной среде далеко не простое. Существует множество точек зрения на жизненный цикл обновления ОС: операционный, системный, управление версиями, безопасность, человеческий фактор, приложения и так далее.

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

PS.related, для Debian

aptly is a swiss army knife for Debian repository management: it allows you to mirror remote repositories, manage local package repositories, take snapshots, pull new versions of packages along with dependencies, publish as Debian repository.