Почему веб-сайты (даже этот) иногда «не работают»?

36

Я лично никогда не делал этого. Я не понимаю, почему так много сайтов делают, если вы разрабатываете на сервере разработки, зачем вам вообще нужно закрывать свой рабочий сайт?

Я всегда задавался вопросом об этом.

Что они делают в это время, что для этого нужно?

web-development maintenance

— JD Исаакс
источник

56

Они заменяют вакуумные трубки на серверах.

— Mipadi

11

Я думал, что они складывают перфокарты.

— Кристофер Махан

5

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

— Дин Хардинг

4

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

— Франциско Presencia

1

У меня возникает вопрос: «Какие стратегии можно использовать для достижения нулевого (запланированного) времени простоя в веб-приложении, поддерживаемом базой данных?» В частности, обновления, требующие изменения схемы БД: softwareengineering.stackexchange.com/questions/336945/…

— Стивен,

59

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

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

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

— Уайетт Барнетт
источник

3

+1 - переполнение стека только для чтения не очень хорошо. Там не будет много, что вы не смогли бы найти в Google :)

— CorsiKa

10

@glowcoder: при поиске в Google вы находите ТАКИЕ ответы.

— Donal Fellows

@ Донал, это была моя точка зрения.

— corsiKa

1

Google массивный и обязательно имеет массивную базу данных; почему я никогда не вижу "вниз для обслуживания" для Google? (Главная страница Google.com)

— alexyorke

7

@ alexy13 - Google относится к особой категории масштабов, где у них не может быть ни одной базы данных, ни даже центра обработки данных, части системы всегда недоступны, и они написали интерфейс для его обработки. Я бы тоже, если бы вы дали мне такое время и бюджет на НИОКР.

— Уайетт Барнетт

7

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

Изменения базы данных
Изменения DAL
Обновление услуг

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

Кроме того, если вы будете касаться web.config (в ASP.NET) для своего сайта, вы должны сначала отключить его для технического обслуживания, поскольку это приведет к срыву сеанса для пользователей. Таким образом, если бы они были в середине чего-то, это было бы потеряно.

— Tyanna
источник

2

сеанс будет потерян, если используется состояние сеанса «В процессе». Если вы используете состояние сеанса вне процесса, сеанс не будет потерян при изменении web.config.

— Энтони

2

Последний пункт верен только в том случае, если вы проводите внутрипроцессные сессии, которые, я надеюсь, вы не находитесь на производственной площадке! Это больше, чем просто прикосновение к web.config, которое остановит рабочий процесс.

— Дин Хардинг

7

Ну, это как-то абстрактный вопрос - я даже видел сайты, которые использовали «Down for Maintenance» вместо HTTP 500.

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

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

— Ладислав Мрнка
источник

2

Разве HTTP 503 (вместо 500) не является правильным кодом состояния «не работает»?

— Нубок

4

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

Одна компания, в которой я работал, в конце 90-х годов имела сайт электронной коммерции, который приносил более $ 1 000 000 в месяц. Кто-то выдвинул неправильную таблицу налогов на сервер производственной базы данных. Лекарство было в том, чтобы восстановить сервер БД из резервной копии и применить транзакции с момента последнего резервного копирования. Это заняло несколько часов, в течение которых веб-сайт был недоступен для приема заказов. Так как часть заказов и статические рекламные брошюры работали на одном сайте и были неразделимы, оба должны были сойти на нет.

Одна компания, в которой я работал, вставила неправильный текст в неправильное место, а генеральный директор отключился, и веб-сайт был отключен «для обслуживания», в то время как макет и текст были «исправлены», а соответствующая жертва обвинена и уволена.

— Tangurena
источник

Даже это можно смягчить с помощью правильной балансировки нагрузки

— Voycey

4

Хотя другие ответы верны, вы почти всегда можете избежать простоев, используя правильные архитектуры. Но это имеет свою стоимость, и эта стоимость может не стоить того: час простоя обходится Amazon или инфраструктуре NASDAQ. Переполнение стека ? Скорее всего, не так много.

Как избежать простоев:

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

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

— Дэвид Курнапо
источник

4

Разве NASDAQ не имеет около 14 часов в день запланированного простоя?

— Питер Тейлор

3

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

— Барри Браун
источник

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

— jwenting

3

Здесь также есть психологическая и маркетинговая сторона. В некоторых случаях (я осмелюсь сказать, что в большинстве случаев, но я не настолько смел, * g *), чтение «Неисправность из-за обслуживания» может также означать «Сервер вышел из строя или вышел из строя по любой другой причине».

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

Таким образом, «отказ в обслуживании» часто является просто термином «не работает».

— perdian
источник

2

Ни один сервер НЕ ДОЛЖЕН отключаться для обслуживания. Вы можете избежать этого для чего угодно, в любом масштабе, изменения БД, обновления сервера и т. Д.

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

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

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

Экономика.

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

— е-удовлетворяться
источник

0

Я не понимаю, почему так много сайтов делают, если вы разрабатываете на сервере разработки, зачем вам вообще нужно закрывать свой рабочий сайт?

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

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

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

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

— luis.espinal
источник

1

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

— Donal Fellows

Правда. Но тогда я бы сказал, что проблема не в формальной проверке спецификаций, а в проверке этих спецификаций. Если ваши спецификации недействительны, то, очевидно, все оттуда отделится, но проверка спецификаций ( «действительно ли мы строим правильную вещь, необходимую предполагаемому пользователю для намеченной цели» ), это не фокус проверки (*), учитывая эти спецификации, мы строим эту вещь правильно, или она может быть построена? "), неформально или иначе. Полагаю, мне следовало бы предупредить об этом (по отношению к

— действию

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

— Donal Fellows

Ой. Я думаю, что мы как будто думаем. Изменение требований (и требование валидации) - это ахиллесова пята формальных методов. Поскольку это творческая задача (из-за ее человеческой природы), я не верю, что она разрешима, не так , как этого хотели бы формалисты / пуристы . Я думаю, что это было одним из невыполненных обещаний FM; они были перепроданы (я имею в виду, например, формальные методы для веб-разработки ?). Спецификации должны быть тщательно изучены и не подвержены быстрым изменениям (что типично для критических систем, а не для очень гибких). Последние являются скорее нормой, чем исключением.

— luis.espinal

99% пользовательских интерфейсов связаны не с формальными методами, а с прикладной психологией. Остальные доказательства очевидны («не блокируйте пользовательский интерфейс»), даже если доказательство не всегда очевидно. Но если вы разделили веб-приложение в соответствии с лучшими практиками, то формальные методы будут иметь большой смысл на уровне бизнес-методов (также на уровне хранения данных, но обычно это стандартный совет «не пишите свой собственный»). БД »применяется в любом случае. :-))

— Donal Fellows

-2

Однажды наш сайт был взломан (старый сервер IIS6 и Windows 2003 несколько лет назад). пока мы работали над реставрацией, мы помещали страницу «на техническое обслуживание» на несколько часов ....

— Serega
источник