Я лично никогда не делал этого. Я не понимаю, почему так много сайтов делают, если вы разрабатываете на сервере разработки, зачем вам вообще нужно закрывать свой рабочий сайт?
Я всегда задавался вопросом об этом.
Что они делают в это время, что для этого нужно?
web-development
maintenance
JD Исаакс
источник
источник
Ответы:
Большой плюс для всего, что связано с большими масштабами, - это то, что если кто-то изменяет схемы базы данных, у него обычно есть несколько больших и неприятных сценариев обслуживания.
Теперь это может занять секунду или около того, чтобы работать с вашим набором данных разработки. Но когда вы начинаете измерять данные в терабайтах и петабайтах, даже добавление одного столбца в таблицу может занять несколько часов.
Поэтому независимо от того, насколько быстро и автоматизировано развертывание, у вас все еще есть проблемы с обслуживанием данных. Если вы планируете действительно хорошо, вы можете установить зеркало сайта только для чтения, пока вы проходите этот процесс, но для многих сайтов чтение только бессмысленно и, следовательно, не стоит затраченных усилий.
источник
Существует ряд причин, по которым вы можете отключить сайт для обслуживания. Назвать несколько:
По сути, если ваш сайт не статичен, при выполнении обновления логики вы хотите его отключить, иначе люди, попавшие на ваш сайт, могут получить ошибки или непредвиденное поведение.
Кроме того, если вы будете касаться web.config (в ASP.NET) для своего сайта, вы должны сначала отключить его для технического обслуживания, поскольку это приведет к срыву сеанса для пользователей. Таким образом, если бы они были в середине чего-то, это было бы потеряно.
источник
Ну, это как-то абстрактный вопрос - я даже видел сайты, которые использовали «Down for Maintenance» вместо HTTP 500.
Для веб-сайтов вам иногда нужно сделать некоторые обновления. Например, если вы изменяете базу данных, вы не хотите, чтобы другие пользователи в это время касались базы данных. Если база данных отключена, сайт также должен быть корректно отключен, поскольку показ SqlException не очень приятен. Другая причина - сбой в работе системы или сбой системы (например, утечка ресурсов), которая требует перезагрузки приложения или даже системы.
Когда-то я участвовал в модернизации системы интернет-банкинга в одном из крупнейших банков в моей стране. Весь процесс обновления веб-сайтов, среднего уровня и баз данных занял три дня, когда система была недоступна для клиентов. Он также включал полную резервную копию всего, поэтому в случае сбоя система может быть возвращена к старой версии.
источник
Для запуска серверов требуются исправления, а во многих операционных системах эти исправления требуют перезагрузок. Так что это одна категория простоя. Многие компании планируют перезагрузки из исправлений на малое время использования, например, в воскресенье утром. Если исправлений нет, они все равно перезагружают серверы в запланированное время обслуживания (это похмелье с дней NT4, когда определенные счетчики переполнялись каждые полторы недели, поэтому еженедельная перезагрузка предотвращала другие ошибки).
Одна компания, в которой я работал, в конце 90-х годов имела сайт электронной коммерции, который приносил более $ 1 000 000 в месяц. Кто-то выдвинул неправильную таблицу налогов на сервер производственной базы данных. Лекарство было в том, чтобы восстановить сервер БД из резервной копии и применить транзакции с момента последнего резервного копирования. Это заняло несколько часов, в течение которых веб-сайт был недоступен для приема заказов. Так как часть заказов и статические рекламные брошюры работали на одном сайте и были неразделимы, оба должны были сойти на нет.
Одна компания, в которой я работал, вставила неправильный текст в неправильное место, а генеральный директор отключился, и веб-сайт был отключен «для обслуживания», в то время как макет и текст были «исправлены», а соответствующая жертва обвинена и уволена.
источник
Хотя другие ответы верны, вы почти всегда можете избежать простоев, используя правильные архитектуры. Но это имеет свою стоимость, и эта стоимость может не стоить того: час простоя обходится Amazon или инфраструктуре NASDAQ. Переполнение стека ? Скорее всего, не так много.
Как избежать простоев:
Как правило, в многоуровневой архитектуре, чем ближе вы находитесь к «вершине», тем труднее становится избежать простоев, то же самое для состояний (с веб-сервером и базой данных).
источник
Сайт может запланировать регулярное время простоя, даже если нечего делать каждый раз, когда наступает время запланированного простоя. Таким образом, они привыкают пользователей к идее, что сайт будет закрываться на определенное время время от времени, поэтому, когда работа действительно должна быть выполнена, пользователи не будут так сильно жаловаться.
источник
Здесь также есть психологическая и маркетинговая сторона. В некоторых случаях (я осмелюсь сказать, что в большинстве случаев, но я не настолько смел, * g *), чтение «Неисправность из-за обслуживания» может также означать «Сервер вышел из строя или вышел из строя по любой другой причине».
Я видел это довольно часто. Обычно, как разработчику, вам нужны «настоящие» сообщения об ошибках, говорящие что-то вроде: «Ой, мы сейчас испытываем большую нагрузку, и не все запросы могут быть обработаны», но некоторые маркетологи скажут вам «чувак, вы не можете Скажите клиенту, что у нас возникли проблемы. Скажите им, что мы находимся на плановом обслуживании - это будет выглядеть намного лучше ".
Таким образом, «отказ в обслуживании» часто является просто термином «не работает».
источник
Ни один сервер НЕ ДОЛЖЕН отключаться для обслуживания. Вы можете избежать этого для чего угодно, в любом масштабе, изменения БД, обновления сервера и т. Д.
Проблема в том, что система с нулевым временем простоя в определенном масштабе очень дорогая в создании и обслуживании. Везде нужно резервирование, везде балансировка нагрузки, репликация данных, синхронизация. Это тяжелые проблемы.
По сути, вам нужно достичь уровня возможности выпуска Netflix Chaos Monkey в prod, чтобы убедиться, что он работает, даже если часть вашей системы занята обновлением или просто не синхронизирована. Это, безусловно, выполнимо. Это также очень дорого, требует много времени и большого количества специалистов для работы над проблемой.
Перевод сайта в режим обслуживания может быть промежуточной точкой, которую вы выберете, потому что вы не хотите вкладывать столько средств, просто чтобы время от времени отказываться от вашего сайта.
Экономика.
Конечно, если вы выберете вариант времени простоя, ваш сайт получит больше, чем просто доступность, он также получит надежность, поскольку эти передовые методы служат обеим целям.
источник
Дерьмо случается. Если вы не проводите какую-либо математическую проверку своих результатов ( и ваши спецификации действительны ), независимо от того, насколько вы осторожны, случается дерьмо.
Кроме того, бывают случаи, когда вам может потребоваться внести изменения в ключевой элемент вашей инфраструктуры (скажем, в изменение структуры вашей базы данных), которые требуют простоя.
Если вы не разрабатываете критически важную систему (скажем, систему пять-девять или шесть-девять ), то ответственное и экономически эффективное решение состоит в том, чтобы создать систему с принятием простоев как части реальности.
Кроме того, вы продвигаете этот принцип дальше, делая время простоя управляемым и поддающимся планированию (или, по крайней мере, обнаруживаемым) с четким пониманием и процедурой для эффективного восстановления.
источник
Однажды наш сайт был взломан (старый сервер IIS6 и Windows 2003 несколько лет назад). пока мы работали над реставрацией, мы помещали страницу «на техническое обслуживание» на несколько часов ....
источник