En verano, tradicionalmente disminuyen tanto la actividad de compras como la intensidad de los cambios en la infraestructura de los proyectos web, nos dice Captain Obvious. Simplemente porque a veces incluso los especialistas en TI se van de vacaciones. Y el CTO también. Es aún más difícil para quienes permanecen en el cargo, pero ese no es el punto ahora: tal vez por eso el verano sea el mejor período para pensar lentamente en el sistema de reservas existente y elaborar un plan para mejorarlo. Y la experiencia de Yegor Andreev de , del que habló en la conferencia .
Hay varios errores en los que puede caer al crear sitios de respaldo. Y es absolutamente imposible quedar atrapado en ellos. Y lo que nos arruina en todo esto, como en muchas otras cosas, es el perfeccionismo y… la pereza. Estamos tratando de hacer todo, todo, todo perfectamente, ¡pero no es necesario que lo hagamos perfectamente! Sólo necesitas hacer ciertas cosas, pero hacerlas correctamente, completarlas para que funcionen correctamente.
La conmutación por error no es una especie de cosa divertida de “que así sea”; Esto es algo que debería hacer exactamente una cosa: reducir el tiempo de inactividad para que el servicio, la empresa, pierda menos dinero. Y en todos los métodos de reserva, sugiero pensar en el siguiente contexto: ¿dónde está el dinero?
Primera trampa: cuando construimos sistemas grandes y confiables y realizamos redundancia, reducimos el número de accidentes. Ésta es una idea errónea terrible. Cuando nos involucramos en despidos, es probable que aumentemos el número de accidentes. Y si hacemos todo bien, colectivamente reduciremos el tiempo de inactividad. Habrá más accidentes, pero ocurrirán a menores costos. ¿Qué es una reserva? - Esta es una complicación del sistema. Cualquier complicación es mala: tenemos más engranajes, más engranajes, en una palabra, más elementos y, por tanto, mayores posibilidades de avería. Y realmente se romperán. Y se romperán más a menudo. Un ejemplo sencillo: digamos que tenemos un sitio web con PHP y MySQL. Y hay que reservarlo urgentemente.
Shtosh (c) Tomamos el segundo sitio, construimos un sistema idéntico... La complejidad se vuelve dos veces mayor: tenemos dos entidades. También implementamos una cierta lógica para transferir datos de un sitio a otro, es decir, replicación de datos, copia de datos estáticos, etc. Entonces, la lógica de replicación suele ser muy compleja y, por lo tanto, la complejidad total del sistema puede ser no 2, sino 3, 5, 10 veces mayor.
Segunda trampa: cuando construimos sistemas complejos realmente grandes, fantaseamos con lo que queremos conseguir al final. Listo: queremos obtener un sistema súper confiable que funcione sin tiempo de inactividad, cambie en medio segundo (o mejor aún, instantáneamente) y comencemos a hacer realidad los sueños. Pero aquí también hay un matiz: cuanto más corto es el tiempo de conmutación deseado, más compleja se vuelve la lógica del sistema. Cuanto más compleja tengamos que hacer esta lógica, más a menudo el sistema colapsará. Y puedes acabar en una situación muy desagradable: estamos intentando con todas nuestras fuerzas reducir el tiempo de inactividad, pero en realidad lo estamos complicando todo, y cuando algo sale mal, el tiempo de inactividad acabará siendo más largo. Aquí a menudo te sorprendes pensando: bueno... sería mejor no hacer reserva. Sería mejor si funcionara solo y con un tiempo de inactividad comprensible.
¿Cómo puedes luchar contra esto? Necesitamos dejar de mentirnos a nosotros mismos, dejar de halagarnos pensando que vamos a construir una nave espacial aquí ahora, pero comprender adecuadamente cuánto tiempo puede durar el proyecto. Y durante este tiempo máximo, elegiremos qué métodos utilizaremos realmente para aumentar la confiabilidad de nuestro sistema.
Es hora de “historias de w”... de la vida, por supuesto.
Ejemplo número uno
Imagínese un sitio web de tarjeta de presentación de la Planta de Laminación de Tuberías No. 1 en la ciudad de N. Dice en letras grandes: PLANTA DE LAMINACIÓN DE TUBERÍAS No. 1. Justo debajo se encuentra el lema: "Nuestras tuberías son las más redondas de N". Y debajo está el número de teléfono del director ejecutivo y su nombre. Entendemos que necesita hacer una reserva: ¡esto es algo muy importante! Empecemos a descubrir en qué consiste. Html-statics: es decir, un par de imágenes en las que el director general, de hecho, está discutiendo algún tipo de próximo acuerdo en la mesa de la casa de baños con su socio. Empezamos a pensar en el tiempo de inactividad. Me viene a la mente: debes permanecer ahí acostado durante cinco minutos, no más. Y entonces surge la pregunta: ¿cuántas ventas hubo en este sitio nuestro en general? ¿Cuánto-cuánto? ¿Qué significa "cero"? Y eso significa: porque el general hizo las cuatro transacciones el año pasado en la misma mesa, con las mismas personas con las que va a la casa de baños y se sienta a la mesa. Y entendemos que incluso si el sitio permanece inactivo por un día, no sucederá nada terrible.
Según la información introductoria, hay un día para plantear esta historia. Empecemos a pensar en un plan de despido. Y elegimos el esquema de redundancia más ideal para este ejemplo: no utilizamos redundancia. Cualquier administrador puede plantear todo este asunto en media hora con pausas para fumar. Instale un servidor web, agregue archivos, eso es todo. Funcionará. No es necesario que estés atento a nada, no es necesario que prestes especial atención a nada. Es decir, la conclusión del ejemplo número uno es bastante obvia: los servicios que no necesitan reservarse no necesitan reservarse.
Ejemplo número dos
Blog de la empresa: allí escriben noticias personas especialmente formadas, participamos en tal o cual exposición, pero lanzamos otro producto nuevo, etc. Digamos que esto es PHP estándar con WordPress, una base de datos pequeña y un poco estática. Por supuesto, una vez más me viene a la mente que bajo ninguna circunstancia debes acostarte: “¡no más de cinco minutos!” Eso es todo. Pero pensemos más. ¿Qué hace este blog? La gente llega allí desde Yandex, desde Google en función de algunas consultas, de forma orgánica. Excelente. ¿Las ventas tienen algo que ver con eso? Epifanía: en realidad no. El tráfico publicitario va al sitio principal, que se encuentra en una máquina diferente. Empecemos a pensar en un plan de reserva. En el buen sentido, es necesario plantearlo en un par de horas y sería bueno prepararse para ello. Sería razonable tomar una máquina de otro centro de datos, instalarle el entorno, es decir, un servidor web, PHP, WordPress, MySQL, y dejarla allí. En el momento en que entendemos que todo está roto, debemos hacer dos cosas: desplegar el volcado de MySQL 50 metros, volará allí en un minuto y desplegar allí una cierta cantidad de imágenes de la copia de seguridad. Esto tampoco estará ahí por Dios sabe cuánto tiempo. Así, en media hora todo sube. Sin replicación, o Dios me perdone, conmutación por error automática. Conclusión: no es necesario realizar una copia de seguridad de lo que podemos implementar rápidamente a partir de una copia de seguridad.
Ejemplo número tres, más complicado
Tienda en línea. PhP con corazón abierto está un poco modificado, mysql con una base sólida. Bastante estática (después de todo, la tienda en línea tiene hermosas imágenes HD y todo eso), Redis para la sesión y Elasticsearch para la búsqueda. Empezamos a pensar en el tiempo de inactividad. Y aquí, por supuesto, es obvio que una tienda online no puede quedarse sin dolor durante un día. Después de todo, cuanto más tiempo permanece, más dinero perdemos. Vale la pena acelerar. ¿Cuánto cuesta? Creo que si nos tumbamos una hora nadie se volverá loco. Sí, perderemos algo, pero si empezamos a trabajar duro, sólo empeorará. Definimos un esquema de tiempo de inactividad permitido por hora.
¿Cómo se puede reservar todo esto? En cualquier caso necesitas un coche: una hora es bastante poco. Mysql: aquí ya necesitamos replicación, replicación en vivo, porque en una hora lo más probable es que no se agreguen 100 GB al volcado. Estática, imágenes: nuevamente, en una hora es posible que no tenga tiempo de agregar 500 GB. Por tanto, es mejor copiar las imágenes de inmediato. Redis: aquí es donde las cosas se ponen interesantes. En Redis, las sesiones se almacenan; no podemos simplemente tomarlas y enterrarlas. Porque esto no será muy bueno: se cerrará la sesión de todos los usuarios, se vaciarán sus cestas, etc. Las personas se verán obligadas a volver a ingresar su nombre de usuario y contraseña, y muchas personas pueden romper y no completar la compra. Nuevamente, las conversiones disminuirán. Por otro lado, Redis se actualiza directamente, y probablemente tampoco se necesiten los últimos usuarios que iniciaron sesión. Y un buen compromiso es tomar Redis y restaurarlo desde una copia de seguridad de ayer o, si lo hace cada hora, de hace una hora. Afortunadamente, restaurarlo desde una copia de seguridad significa copiar un archivo. Y la historia más interesante es Elasticsearch. ¿Quién ha aprendido alguna vez a replicar MySQL? ¿Quién ha utilizado alguna vez la replicación de Elasticsearch? ¿Y para quién funcionó normalmente después? Lo que quiero decir es que vemos una determinada entidad en nuestro sistema. Parece útil, pero es complejo.
Complejo en el sentido de que nuestros compañeros ingenieros no tienen experiencia trabajando con él. O hay una experiencia negativa. O entendemos que ésta es todavía una tecnología bastante nueva con matices o crudeza. Pensamos... Joder, elastic también está sano, además lleva mucho tiempo restaurarlo desde una copia de seguridad, ¿qué debo hacer? Entendemos que el elástico en nuestro caso se utiliza para la búsqueda. ¿Cómo vende nuestra tienda online? Acudimos a los especialistas en marketing y preguntamos de dónde viene la gente. Responden: "El 90% de Yandex Market llega directamente a la ficha del producto". Y o lo compran o no. Por lo tanto, el 10% de los usuarios necesita realizar búsquedas. Y mantener una replicación elástica, especialmente entre diferentes centros de datos en diferentes zonas, realmente tiene muchos matices. ¿Qué salida? Tomamos elástico de un sitio reservado y no hacemos nada con él. Si el asunto se prolonga, probablemente lo plantearemos algún día, pero no es seguro. En realidad, la conclusión es la misma, más o menos: nosotros, nuevamente, no reservamos servicios que no afecten el dinero. Para mantener el diagrama más simple.
Ejemplo número cuatro, aún más difícil
Integrador: vender flores, llamar a un taxi, vender mercancías, en general, cualquier cosa. Algo serio que funciona 24 horas al día, 7 días a la semana para una gran cantidad de usuarios. Con una pila interesante en toda regla, donde hay bases interesantes, soluciones, mucha carga y, lo más importante, duele estar acostado durante más de 5 minutos. No sólo y no tanto porque la gente no quiera comprar, sino porque verán que esto no funciona, se enojarán y es posible que no vuelvan en absoluto.
DE ACUERDO. Cinco minutos. ¿Qué vamos a hacer al respecto? En este caso, nosotros, como adultos, usamos todo el dinero para construir un sitio de respaldo real, con replicación de todo, y tal vez incluso automatizar el cambio a este sitio tanto como sea posible. Y además de esto, debes recordar hacer una cosa importante: redactar las normas de conmutación. La normativa, aunque tengas todo automatizado, puede ser muy sencilla. De la serie "ejecute tal o cual script ansible", "haga clic en tal o cual casilla de verificación en la ruta 53", etc., pero esta debe ser una especie de lista exacta de acciones.
Y todo parece claro. Cambiar la replicación es una tarea trivial, o se cambiará sola. Reescribir un nombre de dominio en DNS es de la misma serie. El problema es que cuando un proyecto de este tipo fracasa, comienza el pánico, e incluso los administradores más fuertes y barbudos pueden ser susceptibles a él. Sin instrucciones claras "abre la terminal, ven aquí, la dirección de nuestro servidor sigue siendo esta", es difícil cumplir con el límite de tiempo de 5 minutos asignado para la reanimación. Bueno, además, cuando utilizamos estas regulaciones, es fácil registrar algunos cambios en la infraestructura, por ejemplo, y cambiar las regulaciones en consecuencia.
Bueno, si el sistema de reservas es muy complejo y en algún momento cometimos un error, entonces podemos destruir nuestro sitio de respaldo y, además, convertir los datos en una calabaza en ambos sitios; esto será completamente triste.
Ejemplo número cinco, hardcore completo.
Un servicio internacional con cientos de millones de usuarios en todo el mundo. Todos los husos horarios que hay, mucha carga a máxima velocidad, no te puedes tumbar para nada. Un minuto y será triste. ¿Qué hacer? Reserva, de nuevo, según el programa completo. Hicimos todo lo que hablé en el ejemplo anterior y un poco más. Un mundo ideal, y nuestra infraestructura está de acuerdo con todos los conceptos de IaaC devops. Es decir, todo está en git y solo presionas el botón.
¿Qué está faltando? Uno: ejercicios. Es imposible sin ellos. Parece que todo va perfecto entre nosotros, generalmente lo tenemos todo bajo control. Presionamos el botón, todo sucede. Incluso si esto es así -y entendemos que no sucede así- nuestro sistema interactúa con algunos otros sistemas. Por ejemplo, este es dns de la ruta 53, almacenamiento s3, integración con alguna API. No podremos preverlo todo en este experimento especulativo. Y hasta que realmente accionemos el interruptor, no sabremos si funcionará o no.
Probablemente eso sea todo. No seas perezoso ni te excedas. ¡Y que el tiempo de actividad te acompañe!
Fuente: habr.com