Por que os sites (até mesmo este) às vezes são “Down for Maintenance”?

36

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

Eu sempre me perguntei sobre isso.

O que eles estão fazendo durante esse tempo, o que requer fazer isso?

    
por JD Isaacks 26.04.2011 / 23:00
fonte

10 respostas

59

O Big kicker para qualquer coisa com grande escala é que, se alguém estiver alterando os esquemas do banco de dados de alguma forma, normalmente alguns scripts de manutenção grandes e desagradáveis serão executados.

Agora, isso pode demorar um pouco mais ou menos para ser executado com seu conjunto de dados de desenvolvimento. Mas quando você começa a medir dados em terabytes e petabytes, até mesmo adicionar uma única coluna a uma tabela pode levar horas.

Portanto, não importa o quão rápida e automatizada seja a implantação, você ainda terá problemas de manutenção de dados. Se você planeja muito bem, você pode colocar 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.

    
por 26.04.2011 / 23:16
fonte
7

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

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

Basicamente, se o seu site não for estático, ao fazer uma atualização lógica, você deverá desativá-lo, caso contrário, as pessoas que acessarem seu site poderão receber erros ou comportamentos inesperados.

Além disso, se você estiver tocando o web.config (no ASP.NET) para o seu site, você deve retirá-lo para manutenção primeiro, pois isso apagará a sessão para os usuários. Assim, se eles estivessem no meio de algo, estaria perdido.

    
por 26.04.2011 / 23:06
fonte
7

Bem, essa é uma questão abstrata - eu até vi sites que usavam "Down for Maintenance" em vez de HTTP 500.

Para sites da Web, às vezes, você precisa fazer alguma atualização. Por exemplo, se você estiver alterando o banco de dados, não desejará que outro usuário toque no banco de dados durante esse período. Se o banco de dados estiver off-line, o site deve ser desativado também porque a exibição de SqlException não é muito agradável. Outra razão é alguma falha de HW ou falha no sistema (como vazamento de recursos) que requer aplicação ou mesmo 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, camadas intermediárias e bancos de dados levou três dias em que o sistema estava offline para os clientes. Também incluiu backup completo de tudo, de modo que, em caso de falha, o sistema poderia ser revertido para a versão antiga.

    
por 26.04.2011 / 23:06
fonte
4

Os servidores precisam de patches para serem executados e, em muitos sistemas operacionais, esses patches exigem reinicializações. Então essa é uma categoria de tempo de inatividade. Muitas empresas agendam reinicializações a partir de patches para tempos de uso baixos, como na manhã de domingo. Se não houver patches, eles reinicializam os servidores de qualquer maneira no tempo de manutenção regular (isso é uma ressaca dos dias NT4, quando certos contadores transbordavam toda semana e meia, então a reinicialização semanal evitava outros bugs).

Uma empresa para a qual eu trabalhei tinha um site de comércio eletrônico no final dos anos 90 que gerava mais de US $ 1 milhão em vendas por mês. Alguém promoveu a tabela de impostos errada para o servidor de banco de dados de produção. A cura foi restaurar o servidor db a partir 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 de pedidos e os folhetos de vendas estáticos estavam sendo executados no mesmo site e eram inseparáveis, ambos tiveram que descer.

Uma empresa para a qual eu trabalhei tinha algum texto errado inserido no lugar errado e o CEO saiu e o site foi desligado "para manutenção", enquanto o layout e o texto foram "consertados" e a vítima apropriada foi culpada e demitida.

    
por 26.04.2011 / 23:28
fonte
4

Enquanto outras respostas estão corretas, você quase sempre pode evitar o tempo de inatividade usando arquiteturas corretas. Mas isso tem um custo, e esse custo pode não valer a pena: uma hora de paralisação custa muito para a Amazon ou para a infraestrutura por trás do NASDAQ. Stackoverflow? Muito provavelmente não muito.

Como evitar tempos de inatividade:

  • desligando as páginas de veiculação de hardware: se você tiver proxies na frente de seu website, poderá colocá-las off-line sem causar impacto no usuário
  • reconfigurando servidores: o mesmo que acima
  • atualizando / alterando dados em 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 o estado (servidor da Web versus banco de dados).

    
por 27.04.2011 / 00:24
fonte
3

Um site pode agendar um tempo de inatividade regular, mesmo que não haja nada a fazer toda vez que o tempo de inatividade programado chegar. Ao fazer isso, os usuários ficam acostumados com a idéia de que o site ficará inativo por um determinado período de tempo, de modo que, quando o trabalho precisar ser feito, os usuários não vão reclamar tanto. .

    
por 27.04.2011 / 06:55
fonte
3

Existe também um lado psicológico e de marketing para isso. Em alguns casos (atrevo-me a dizer a maioria dos casos, mas não sou tão ousado * g *) a leitura "Down for maintenance" também pode significar "O servidor travou ou saiu de serviço por qualquer outro motivo".

Eu já vi isso com bastante frequência. Normalmente, como desenvolvedor, você vai querer uma mensagem de erro "real" dizendo algo como "Opa, estamos com uma carga alta agora e nem todas as solicitações podem ser manipuladas", mas algumas pessoas do marketing dirão "cara, você não pode diga ao cliente que estamos com problemas. Diga a eles que estamos em manutenção programada - isso ficará muito melhor ".

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

    
por 27.04.2011 / 16:01
fonte
2

Nenhum servidor precisa ser interrompido para manutenção. Você pode evitar fazer isso para qualquer coisa, em qualquer escala, alteração de banco de dados, atualizações do servidor, etc.

O problema é que um sistema de tempo de inatividade 0, em uma determinada 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 lançar o Netflix Chaos Monkey no prod para ter certeza de que funciona mesmo se parte do seu sistema estiver ocupado 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 um meio-termo que você escolhe, porque você não quer investir muito apenas para evitar derrubar seu site por algum tempo de vez em quando.

Economia.

É claro que, se você escolher o caminho de 0 tempo para baixo, o seu site ganhará mais do que apenas a disponibilidade; ele também ganhará confiabilidade, já que essas práticas servem a ambos os propósitos.

    
por 27.11.2016 / 14:06
fonte
0

I don't understand why so many sites do, if you do your development on a development server why would you ever need to shut down your production site?

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

Além disso, há momentos em que você pode precisar fazer uma alteração em uma parte essencial de 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 (por exemplo, um sistema five-nine ou six-nine ), o Uma coisa responsável e rentável 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 mais além, reduzindo os tempos gerenciáveis e passíveis de agendamento (ou pelo menos detectável), com um claro entendimento e procedimento para uma recuperação efetiva.

    
por 27.04.2011 / 00:40
fonte
-2

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

    
por 27.11.2016 / 15:29
fonte