Por que os sites (mesmo este) às vezes estão "em manutenção"?

Eu pessoalmente nunca fiz isso. Eu não entendo por que tantos sites o fazem, se você faz seu desenvolvimento em um servidor de desenvolvimento, por que você precisa desligar o site de produção?

Eu sempre me perguntei sobre isso.

O que eles estão fazendo durante esse período, o que exige isso?

O grande incentivo para qualquer coisa em grande escala é que, se alguém está alterando os esquemas do banco de dados de alguma maneira, normalmente possui alguns scripts de manutenção grandes e desagradáveis ​​para executar.

Agora, isso pode levar um segundo ou mais para executar com seu conjunto de dados de desenvolvimento. Mas quando você começa a medir dados em terabytes e petabytes, até a adição de uma única coluna a uma tabela pode levar horas.

Portanto, não importa quão rápida e automatizada seja a implantação, você ainda terá problemas de manutenção de dados. Se você planeja muito bem, pode criar um espelho somente leitura do site enquanto estiver passando pelo processo, mas para muitos sites somente leitura é inútil e, portanto, não vale o esforço.

Existem várias razões pelas quais você pode querer desativar um site para manutenção. Para nomear alguns:

• Alterações no banco de dados
• Alterações de DAL
• Atualizando serviços

Basicamente, se o seu site não é estático, ao fazer uma atualização lógica, você deseja removê-lo, caso contrário, as pessoas que acessam o site podem receber erros ou comportamento inesperado.

Além disso, se você tocar no web.config (no ASP.NET) do seu site, você deve retirá-lo primeiro para manutenção, pois isso interromperá a sessão dos usuários. Assim, se eles estivessem no meio de alguma coisa, isso seria perdido.

Bem, essa é uma pergunta de alguma forma abstrata - eu até vi sites que usavam "Down for Maintenance" em vez de HTTP 500.

Para sites, às vezes você precisa fazer alguma atualização. Por exemplo, se você estiver alterando o banco de dados, não deseja que nenhum outro usuário toque no banco de dados durante esse período. Se o banco de dados estiver offline, o site também deverá ser desativado normalmente, pois mostrar SqlException não é muito bom. Outro motivo é alguma falha de HW ou falha do sistema (como vazamento de recursos) que requer a aplicação ou mesmo a reinicialização do sistema.

Uma vez participei da atualização do sistema de internet banking em um dos maiores bancos do meu país. Todo o processo de atualização de sites, camada intermediária e bancos de dados levou três dias em que o sistema estava offline para os clientes. Também incluía backup completo de tudo, para que, em caso de falha, o sistema pudesse ser revertido para a versão antiga.

Os servidores precisam de patches para serem executados e, em muitos sistemas operacionais, esses patches exigem reinicializações. Portanto, essa é uma categoria de tempo de inatividade. Muitas empresas agendam reinicializações a partir de patches para pouco tempo de uso, como domingo de manhã. Se não houver correções, eles reiniciarão os servidores de qualquer maneira no horário de manutenção agendado regularmente (esta é uma ressaca dos dias do NT4, quando certos contadores transbordavam a cada semana e meia, portanto, a reinicialização semanal evitava outros bugs).

Uma empresa em que trabalhei tinha um site de comércio eletrônico no final dos anos 90 que gerava mais de US $ 1.000.000 em vendas por mês. Alguém promoveu a tabela de impostos incorreta para o servidor do banco de dados de produção. A solução foi restaurar o servidor db do backup e aplicar as transações desde o último backup. Isso levou várias horas, durante as quais o site não estava disponível para receber pedidos. Como a parte dos pedidos e as brochuras de vendas estáticas estavam sendo executadas no mesmo local e eram inseparáveis, ambas tiveram que descer.

Uma empresa para a qual trabalhei tinha um texto errado inserido no lugar errado e o CEO saiu e o site foi retirado da linha "para manutenção" enquanto o layout e o texto eram "consertados" e a vítima apropriada culpada e demitida.

Enquanto outras respostas estão corretas, você quase sempre pode evitar o tempo de inatividade usando as arquiteturas corretas. Mas isso tem um custo, e esse custo pode não valer a pena: uma hora de inatividade custa muito à Amazon ou à infraestrutura por trás da NASDAQ. Stackoverflow? Provavelmente nem tanto.

Como evitar paradas:

• desativando páginas de exibição de hardware: se você possui proxies na frente do site, pode colocá-los off-line sem causar nenhum impacto ao usuário
• reconfigurando servidores: o mesmo que acima
• atualização / alteração de dados nos bancos de dados: você pode colocar seu site no modo somente leitura, etc.

Geralmente, em uma arquitetura em camadas, quanto mais próximo do "topo" você estiver, mais difícil será evitar o tempo de inatividade, o mesmo para stateful (servidor da Web x banco de dados).

Um site pode agendar um tempo de inatividade regular, mesmo que não haja nada a fazer sempre que o tempo de inatividade programado ocorrer. Ao fazer isso, eles ficam usuários usados para a idéia de que o site será para baixo por um certo período de tempo a cada tantas vezes para que quando o trabalho faz necessidade de ser feito, os usuários se queixam tanto.

Há também um lado psicológico e de marketing nisso. Em alguns casos (ouso dizer a maioria dos casos, mas não sou tão ousado * g *), a leitura "Inativo para manutenção" também pode significar "O servidor travou ou ficou fora de serviço por qualquer outro motivo".

Eu já vi isso com bastante frequência. Normalmente, como desenvolvedor, você deseja mensagens de erro "reais" dizendo algo como "Opa, estamos com muita carga agora e nem todas as solicitações podem ser tratadas", mas algumas pessoas do marketing dirão "cara, você não pode informe ao cliente que estamos com problemas. Diga a eles que estamos em manutenção programada - isso parecerá muito melhor ".

Portanto, "em manutenção" geralmente é apenas outro termo para "fora de serviço".

Nenhum servidor PRECISA ir para manutenção. Você pode evitar fazer isso por qualquer coisa, em qualquer escala, alteração de banco de dados, atualizações de servidor, etc.

O problema é que um sistema de tempo de inatividade zero, em uma certa escala, é muito caro para criar e manter. Você precisa de redundância em todos os lugares, balanceamento de carga em todos os lugares, replicação de dados, sincronização. Esses são problemas difíceis.

Basicamente, você precisa chegar ao nível de poder liberar o Netflix Chaos Monkey em prod para garantir que ele funcione mesmo se parte do seu sistema estiver ocupada com a atualização ou apenas fora de sincronia. Isso é certamente factível. Também é muito caro, requer muito tempo e muitos especialistas para trabalhar no problema.

Colocar um site no modo de manutenção pode ser o meio termo que você escolher, porque não deseja investir muito apenas para evitar derrubar o site por um tempo, de vez em quando.

Economia.

Obviamente, se você escolher o caminho do tempo de inatividade, o site ganhará mais do que apenas disponibilidade, mas também confiabilidade, pois essas práticas recomendadas atendem a ambos os propósitos.

Eu não entendo por que tantos sites o fazem, se você faz seu desenvolvimento em um servidor de desenvolvimento, por que você precisa desligar o site de produção?

Merda acontece. A menos que você esteja realizando alguma forma de verificação matemática de suas entregas ( e suas especificações sejam válidas ), não importa o quão cuidadoso você seja, a merda acontece.

Além disso, há momentos em que você pode precisar fazer uma alteração em uma parte essencial da sua infraestrutura (por exemplo, uma alteração nas estruturas do banco de dados) que exige um tempo de inatividade.

A menos que você esteja desenvolvendo um sistema crítico (digamos, um sistema cinco-nove ou seis-nove ), a coisa responsável e com boa relação custo-benefício a fazer é construir um sistema com a aceitação de tempos de inatividade como parte da realidade.

Além disso, você leva esse princípio adiante, tornando os tempos de inatividade gerenciáveis ​​e passíveis de agendamento (ou pelo menos detectáveis) com um entendimento e procedimento claros para uma recuperação eficaz.

Uma vez que nosso site foi invadido (servidor IIS6 e Windows 2003 antigo, há alguns anos). enquanto trabalhamos na restauração, colocamos a página "em manutenção" por algumas horas ....