¿Por qué los sitios web (incluso este) a veces están "inactivos por mantenimiento"?

Yo personalmente nunca he hecho esto. No entiendo por qué tantos sitios lo hacen, si haces tu desarrollo en un servidor de desarrollo, ¿por qué necesitarías cerrar tu sitio de producción?

Siempre me he preguntado acerca de esto.

¿Qué están haciendo durante este tiempo, qué requiere hacer esto?

La gran patada para cualquier cosa con gran escala es que si uno está cambiando los esquemas de la base de datos de alguna manera, normalmente tiene que ejecutar algunos scripts de mantenimiento grandes y desagradables.

Ahora, estos pueden tardar un segundo más o menos en ejecutarse con su conjunto de datos de desarrollo. Pero cuando comienza a medir datos en terabytes y petabytes, incluso agregar una sola columna a una tabla puede llevar horas.

Entonces, no importa cuán rápido y automatizado sea el despliegue, todavía tiene problemas de mantenimiento de datos para resolver. Si planifica realmente bien, puede colocar un espejo de solo lectura del sitio mientras se somete al proceso, pero para muchos sitios de solo lectura no tiene sentido y, por lo tanto, no vale la pena el esfuerzo.

Hay varias razones por las que es posible que desee eliminar un sitio para realizar tareas de mantenimiento. Para nombrar unos pocos:

• Cambios en la base de datos.
• Cambios DAL
• Servicios de actualizacion

Básicamente, si su sitio no es estático, al realizar una actualización lógica, debe eliminarlo; de lo contrario, las personas que accedan a su sitio pueden recibir errores o comportamientos inesperados.

Además, si va a tocar el web.config (en ASP.NET) para su sitio, primero debe quitarlo para realizar el mantenimiento, ya que eliminará la sesión para los usuarios. Por lo tanto, si estuvieran en medio de algo, se perdería.

Bueno, esta es una pregunta abstracta: incluso vi sitios que usaban "Down for Maintenance" en lugar de HTTP 500.

En el caso de los sitios web, a veces debe actualizarse. Por ejemplo, si está cambiando la base de datos, no desea que ningún otro usuario toque la base de datos durante ese tiempo. Si la base de datos está fuera de línea, el sitio también debe estar apagado correctamente porque mostrar SqlException no es muy bueno. Otra razón es alguna falla de hardware o falla del sistema (como la pérdida de recursos) que requiere la aplicación o incluso el reinicio del sistema.

Una vez participé en la actualización del sistema de banca por Internet en uno de los bancos más grandes de mi país. Todo el proceso de actualización de sitios web, nivel medio y bases de datos tomó tres días donde el sistema estaba fuera de línea para los clientes. También incluía una copia de seguridad completa de todo, por lo que en caso de falla, el sistema podría volver a la versión anterior.

Los servidores necesitan parches para ejecutarse, y en muchos sistemas operativos, esos parches requieren reinicios. Esa es una categoría de tiempo de inactividad. Muchas compañías programan reinicios desde parches para tiempos de bajo uso, como el domingo por la mañana. Si no hay parches, reinician los servidores de todos modos en el tiempo de mantenimiento programado regularmente (esta es una resaca de los días NT4 cuando ciertos contadores se desbordaron cada semana y media, por lo que reiniciar semanalmente evitó otros errores).

Una empresa para la que trabajé tenía un sitio de comercio electrónico a finales de los 90 que generaba más de $ 1,000,000 en ventas por mes. Alguien promovió la tabla de impuestos incorrecta al servidor de la base de datos de producción. La cura fue restaurar el servidor db desde la copia de seguridad y aplicar las transacciones desde la última copia de seguridad. Esto tomó varias horas, durante las cuales el sitio web no estuvo disponible para tomar pedidos. Dado que la parte de pedidos y los folletos de ventas estáticos se estaban ejecutando en el mismo sitio y eran inseparables, ambos tuvieron que bajar.

Una empresa para la que trabajé tenía un texto incorrecto insertado en el lugar equivocado y el CEO se volcó y el sitio web se desconectó "por mantenimiento", mientras que el diseño y el texto fueron "reparados" y la víctima apropiada fue culpada y despedida.

Si bien otras respuestas son correctas, casi siempre puede evitar el tiempo de inactividad utilizando las arquitecturas correctas. Pero esto tiene un costo, y este costo puede no valer la pena: una hora de tiempo de inactividad le cuesta mucho a Amazon o la infraestructura detrás de NASDAQ. Desbordamiento de pila ? Lo más probable es que no tanto.

Cómo evitar tiempos de inactividad:

• cerrar páginas de servicio de hardware: si tiene proxies frente a su sitio web, puede ponerlos fuera de línea sin ningún impacto para el usuario
• reconfigurar servidores: igual que el anterior
• actualización / cambio de datos en bases de datos: puede poner su sitio web en modo de solo lectura, etc.

En general, en una arquitectura en capas, cuanto más cerca esté de la "parte superior", más difícil será evitar el tiempo de inactividad, lo mismo para Stateful (servidor web frente a base de datos).

Un sitio puede programar un tiempo de inactividad regular incluso si no hay nada que hacer cada vez que se produce el tiempo de inactividad programado. Al hacerlo, se ponen los usuarios acostumbrados a la idea de que el sitio no estará disponible por una cierta cantidad de tiempo de vez en cuando para que cuando el trabajo hace necesario tomar radiografías, los usuarios no se quejan tanto.

También hay un lado psicológico y de marketing en esto. En algunos de los casos (me atrevo a decir la mayoría de los casos, pero no estoy en negrita * g *), leer "Inactivo por mantenimiento" también puede significar "El servidor se ha bloqueado o ha dejado de funcionar por cualquier otro motivo".

He visto esto con bastante frecuencia. Normalmente, como desarrollador, querrás recibir mensajes de error "reales" que digan algo como "¡Vaya! Estamos experimentando una gran carga en este momento y no todas las solicitudes se pueden manejar", pero algunas personas de marketing te dirán "amigo, no puedes dígale al cliente que tenemos un problema. Dígale que estamos en mantenimiento programado, esto se verá mucho mejor ".

Por lo tanto, "inactivo por mantenimiento" a menudo es solo otro término para "fuera de servicio".

Ningún servidor NECESITA bajar por mantenimiento. Puede evitar hacerlo para cualquier cosa, a cualquier escala, cambio de base de datos, actualizaciones del servidor, etc.

El problema es que un sistema de tiempo de inactividad 0, a cierta escala, es muy costoso de crear y mantener. Necesita redundancia en todas partes, equilibrio de carga en todas partes, replicación de datos, sincronización. Esos son problemas difíciles.

Básicamente, debe llegar al nivel de poder lanzar Netflix Chaos Monkey en prod para asegurarse de que funciona incluso si parte de su sistema está ocupado con la actualización, o simplemente no está sincronizado. Esto es ciertamente factible. También es muy costoso, requiere mucho tiempo y muchos expertos para trabajar en el problema.

Poner un sitio en modo de mantenimiento puede ser un término medio que elija, porque no desea invertir tanto solo para evitar desmontar su sitio por un tiempo de vez en cuando.

Ciencias económicas.

Por supuesto, si elige el camino del tiempo 0down, su sitio obtendrá más que solo disponibilidad, también ganará confiabilidad, ya que esas mejores prácticas sirven para ambos propósitos.

No entiendo por qué tantos sitios lo hacen, si haces tu desarrollo en un servidor de desarrollo, ¿por qué necesitarías cerrar tu sitio de producción?

Mierda pasa. A menos que esté haciendo algún tipo de verificación matemática de sus entregas ( y sus especificaciones son válidas ), no importa cuán cuidadoso sea, las cosas suceden.

Además, hay momentos en los que puede que tenga que hacer un cambio en una pieza clave de su infraestructura (por ejemplo, un cambio en las estructuras de su base de datos) que requieren un tiempo de inactividad.

A menos que esté desarrollando un sistema crítico (digamos un sistema cinco-nueve o seis-nueve ), lo más responsable y rentable es construir un sistema con la aceptación de los tiempos muertos como parte de la realidad.

Además, lleva ese principio más allá al hacer que los tiempos de inactividad sean manejables y susceptibles de programación (o al menos detectable) con una comprensión clara y un procedimiento para una recuperación efectiva.

Una vez que nuestro sitio web fue pirateado (el antiguo servidor IIS6 y Windows 2003 hace unos años). mientras trabajábamos en la restauración, pusimos la página "en mantenimiento" durante unas horas ...