Почему мы перезагружаем серверы

Довольно регулярно возникает вопрос: следует ли серверы перезагружать в плановом порядке — например, раз в неделю — или же им следует давать работать как можно дольше для достижения максимального «аптайма». Для меня ответ прост: за редкими исключениями, регулярные перезагрузки являются наиболее подходящим выбором для серверов.

Как и любое правило, оно не применяется в ряде случаев. Например, некоторые предприятия, эксплуатирующие критически важные системы, не могут допустить простоя и должны быть доступны круглосуточно. Очевидно, что такие системы нельзя просто перезагружать в плановом порядке. Однако если система настолько критична, что не может никогда отключаться, это должно служить тревожным сигналом: данная система является единой точкой отказа, и, возможно, стоит задуматься о том, как справляться с простоем — как плановым, так и внеплановым.

Ещё одним исключением являются некоторые системы AIX, которым требуется значительное время работы — более нескольких недель — для достижения максимальной эффективности, поскольку система является самонастраивающейся и нуждается во времени для сбора информации об использовании и соответствующей корректировки. Это, как правило, характерно для крупных, редко меняющихся серверов баз данных и аналогичных сценариев использования, менее распространённых, чем другие платформы.

В IT мы нередко поклоняемся концепции «аптайма» — тому, как долго система может работать без необходимости перезапуска. Но «аптайм» — это концепция, не приносящая ценности бизнесу, а IT всегда должен держать в уме потребности бизнеса, а не сосредотачиваться на искусственных метриках. Бизнес не интересует, как долго сервер умудрялся работать без перезагрузки — ему важно лишь то, что сервер доступен и готов к работе в момент необходимости для бизнес-процессов. Это принципиально разные концепции.

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

Я часто слышу, как люди заявляют, что, поскольку они используют операционную систему X, а не Y, им больше не нужно перезагружаться, — но это просто не так. Существуют две основные причины регулярно перезагружаться: чтобы убедиться в способности сервера успешно перезагрузиться и чтобы применить патчи, которые нельзя применить без перезагрузки.

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

Проверка способности сервера успешно перезагрузиться — это то, о чём часто забывают. На большинстве серверов изменения применяются на регулярной основе. Изменениями могут быть патчи, новые приложения, изменения конфигурации, обновления и тому подобное. Любое изменение несёт риск. То, что сервер работает исправно сразу после применения изменения, не означает, что сам сервер и запущенные на нём приложения запустятся как ожидается после перезагрузки.

Если сервер никогда не перезагружается, мы никогда не знаем, способен ли он успешно перезагрузиться. Со временем количество изменений, применённых с момента последней перезагрузки, будет увеличиваться. Это очень опасно. Чего мы боимся — это накопления большого количества изменений, возможно, многие из которых не задокументированы, и последующего отказа при перезагрузке. В этом случае определить, какое именно изменение вызывает сбой системы, может оказаться непосильной задачей. Нет ни одного изменения для отката, нет известного пути к восстановлению. Именно тогда наступает паника. Конечно, сервер, который никогда намеренно не перезагружается, с большей вероятностью перезагрузится непреднамеренно — а значит, вероятность неудачной перезагрузки как выше, так и выше вероятность того, что она произойдёт во время активного использования.

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

Я слышал от многих системных администраторов, что они избегают перезагрузок по выходным, поскольку не хотят работать в воскресенье из-за серверов, не сумевших подняться после перезагрузки. Меня самого нередко поднимали по воскресным утрам из-за неудачной перезагрузки, но каждый раз, получая такой звонок, я испытываю облегчение. Я знаю, что мы только что поймали проблему в тот момент, когда бизнес финансово не пострадал. Если бы тот сервер не был перезапущен в нерабочие часы, обнаружить его «незагружаемость» могли бы лишь тогда, когда он откажет в рабочее время и повлечёт потерю выручки.

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

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