En el verano, tanto la actividad de compra como la intensidad de los cambios en la infraestructura de los proyectos web disminuyen tradicionalmente, nos dice el Capitán Evidence. Solo porque incluso la gente de TI se va de vacaciones. Y CTO también. Es mucho más difícil para aquellos que permanecen en el puesto, pero no se trata de eso ahora: tal vez es por eso que el verano es el mejor momento para apresurar el esquema de reserva existente y hacer un plan para su mejora. Y en esto se beneficiará de la experiencia de Yegor Andreev de AdminDivision , de la que habló en la conferencia del día de actividad .Durante la construcción de sitios de reserva, durante la reserva hay varias trampas en las que puede caer. Y caer en ellos es absolutamente imposible. Y arruinándonos en todo esto, así como en muchas otras cosas, perfeccionismo y ... pereza. Estamos tratando de hacer todo, todo, todo es perfecto, ¡pero no tienes que hacerlo a la perfección! Solo es necesario hacer ciertas cosas, pero hacerlas correctamente, llevarlas hasta el final, para que funcionen normalmente.
La conmutación por error no es una especie de cosa divertida "divertida de tener"; 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?
La primera trampa : cuando construimos grandes sistemas confiables y hacemos copias de seguridad, reducimos la cantidad de accidentes. Esta es una falacia terrible. Cuando hacemos copias de seguridad, lo más probable es que aumentemos la cantidad de accidentes. Y si hacemos todo bien, juntos reduciremos el tiempo de inactividad. Habrá más accidentes, pero ocurrirán a un costo menor. Después de todo, ¿qué es la redundancia? Es una complicación del sistema. Cualquier complicación es mala: obtenemos más engranajes, más engranajes, en una palabra, más elementos y, por lo tanto, una mayor probabilidad de avería. Y realmente se rompen. Y se romperán más a menudo. Un ejemplo simple: digamos que tenemos un sitio web con PHP, MySQL. Y necesita urgentemente ser reservado.
Shtosh (c) Tomamos el segundo sitio, construimos un sistema idéntico ... La complejidad se vuelve el doble: tenemos dos entidades. Y también desarrollamos cierta lógica de transferencia de datos de una plataforma a otra desde arriba, es decir, replicación de datos, copia de estadísticas, etc. Por lo tanto, la lógica de la replicación suele ser muy compleja y, por lo tanto, la complejidad total del sistema puede no ser 2, sino 3, 5, 10 veces más.
La segunda trampa : cuando construimos sistemas complejos verdaderamente grandes, fantaseamos con lo que queremos obtener al final. Voila: queremos obtener un sistema súper confiable que funcione sin ningún tiempo de inactividad, cambie en medio segundo (o mejor en general al instante) y comience a convertir los sueños en realidad. Pero también hay un matiz: cuanto más corto es el tiempo de conmutación deseado, más compleja resulta la lógica del sistema. Cuanto más difícil sea hacer esta lógica, más a menudo el sistema se romperá. Y puede entrar en una situación muy desagradable: estamos haciendo todo lo posible para reducir el tiempo de inactividad, pero de hecho complicamos las cosas, y cuando algo sale mal, el tiempo de inactividad será más largo. Aquí a menudo te encuentras pensando: aquí ... sería mejor si no hubieran sido reservados. Sería mejor si funcionara solo con un tiempo de inactividad comprensible.
¿Cómo lidiar con esto? Debemos dejar de mentirnos a nosotros mismos, dejar de halagarnos de que vamos a construir una nave espacial aquí, pero para comprender adecuadamente cuánto puede tumbarse el proyecto. Y para este tiempo máximo, elegiremos con qué métodos, de hecho, aumentaremos la confiabilidad de nuestro sistema.
Es hora de "historias de w" ... de la vida, por supuesto.
Ejemplo número uno
Imagine la tarjeta del sitio de la planta de laminación de tuberías No. 1 de la ciudad N. Está escrita con letras grandes: PLANTA DE TUBERÍAS No. 1. Un poco más abajo - el eslogan: "Nuestras tuberías son las tuberías más redondas en N". Y debajo del número de teléfono del CEO y su nombre. Entendemos que debe reservar, ¡esto es algo muy importante! Comenzamos a entender en qué consiste. Html-statics, es decir, un par de imágenes en las que el general, de hecho, en la mesa en el baño con su compañero está discutiendo el próximo trato. Comenzamos a pensar en el tiempo de inactividad. Me viene a la mente: debes permanecer acostado allí durante cinco minutos, no más. Y luego la pregunta es: ¿cuántas ventas de este sitio fueron en general? Cuanto cuanto ¿Qué significa cero? Y eso significa: porque el general hizo las cuatro transacciones durante el año pasado en la misma mesa, con las mismas personas con las que van a la casa de baños a sentarse a la mesa. Y entendemos que incluso si el sitio permanece inactivo por un día, no habrá nada terrible.
Según la introducción, hay un día para plantear esta historia. Comenzamos a pensar en el esquema de respaldo. Y seleccionamos el esquema de copia de seguridad más ideal para este ejemplo: no utilizamos redundancia. Todo esto se eleva por cualquier administrador durante media hora con pausas de humo. Poner un servidor web, poner archivos es todo. Funcionará No tiene que seguir nada, no necesita prestar especial atención a nada. Es decir, la conclusión del ejemplo número uno es bastante obvia: los servicios que no necesita reservar no son necesarios.
Ejemplo número dos
Blog de la empresa: hay personas especialmente capacitadas que escriben noticias allí, por lo que participamos en tal o cual exposición, pero aquí lanzamos otro producto nuevo y así sucesivamente. Digamos que esto es PHP estándar con WordPress, una pequeña base de datos y un poco de estática. Por supuesto, me viene a la mente otra vez que nunca debes mentir: "¡no más de cinco minutos!", Eso es todo. Pero pensemos más. ¿Qué está haciendo este blog? Vienen allí desde Yandex, desde Google en algunas solicitudes, en productos orgánicos. Wow ¿Y las ventas están de alguna manera relacionadas con él? Insight: en realidad no. El tráfico publicitario va al sitio principal, que está en otra máquina. Comenzamos a pensar en el esquema de reserva de folletos. En el buen sentido, debe levantarse en un par de horas, y sería bueno prepararse para esto. Sería razonable llevar una máquina a otro centro de datos, dirigir el entorno hacia ella, es decir, un servidor web, PHP, WordPress, MySQL, y dejarla acostada. En el momento en que entendemos que todo está roto, hay que hacer dos cosas: rodar el volcado de mysql a 50 metros, volará allí en un minuto y rodará algunas imágenes de la copia de seguridad allí. Esto tampoco es una buena noticia. Por lo tanto, en media hora todo esto se levanta. No hay repeticiones, o Dios me perdone, la conmutación por error automática. Conclusión: lo que podemos implementar rápidamente de la copia de seguridad no es necesario reservar.
Ejemplo número tres, más complicado.
Tienda en linea. PhP con corazón abierto está un poco archivado, mysql con una base sólida. Bastante estática (después de todo, la tienda en línea tiene hermosas imágenes en HD y todo ese jazz), Redis para la sesión y Elasticsearch para la búsqueda. Comenzamos a pensar en el tiempo de inactividad. Y aquí, por supuesto, es obvio que una tienda en línea no puede revolcarse el día sin dolor. Después de todo, cuanto más tiempo mienta, más dinero perderemos. Vale la pena acelerar. Cuanto? Creo que si nos acostamos durante una hora, nadie se volverá loco. Sí, perderemos algo, pero si empezamos a hacer celo, solo empeorará. Determinamos el tiempo de inactividad permitido por hora.
¿Cómo se puede reservar todo esto? En cualquier caso, se necesita un automóvil: una hora de tiempo es bastante. Mysql: replicación, la replicación en vivo ya es necesaria aquí, porque en una hora 100 GB en un volcado, lo más probable es que no se vierta. Estática, imágenes: nuevamente, en una hora, 500 GB pueden no tener tiempo para fusionarse. Por lo tanto, es mejor copiar imágenes de inmediato. Redis: más interesante aquí. Las sesiones son en Redis, simplemente no podemos tomarlo y enterrarlo. Porque no será muy bueno: se cerrará la sesión de todos los usuarios, se vaciarán las cestas, etc. Las personas se verán obligadas a volver a ingresar su nombre de usuario y contraseña, y muchas personas pueden separarse y no completar la compra. Nuevamente, la conversión caerá. Por otro lado, Redis es directamente uno a uno relevante, con los últimos usuarios registrados, probablemente, tampoco es necesario. Y un buen compromiso es tomar Redis y restaurarlo desde la copia de seguridad ayer, o, si lo hace cada hora, hace una hora. El beneficio de restaurarlo desde la copia de seguridad es copiar un archivo. Y la historia más interesante es Elasticsearch. ¿Quién ha planteado la replicación MySQL? ¿Quién ha planteado la replicación Elasticsearch? ¿Y con quién trabajaba normalmente después? Qué estoy haciendo: vemos una cierta entidad en nuestro sistema. Parece ser útil, pero es complicado.
Complejo en el sentido de que nuestros compañeros ingenieros no tienen experiencia trabajando con él. O hay una experiencia negativa. O entendemos que hasta ahora esta es una tecnología bastante nueva con matices o humedad. Creemos ... Maldición, el elástico también es saludable, también lleva mucho tiempo restaurarlo desde la copia de seguridad, ¿qué debo hacer? Entendemos que el elástico en nuestro caso se utiliza para la búsqueda. ¿Y cómo se vende nuestra tienda en línea? Vamos a los vendedores, preguntamos, ¿de dónde viene la gente? Responden: "El 90% del mercado Yandex viene directamente a la tarjeta del producto". Y ya sea comprar o no. Por lo tanto, el 10% de los usuarios necesitan una búsqueda. Y para mantener una réplica elástica, especialmente entre diferentes centros de datos en diferentes zonas, realmente hay muchos matices. ¿Cuál es la salida? Tomamos elástico en un sitio reservado y no hacemos nada con él. Si el caso se prolonga, algún día probablemente lo plantearemos, pero esto no es seguro. En realidad, la conclusión más o menos es la misma: nuevamente, no reservamos servicios que no afecten el dinero. Para mantener el circuito más simple.
Ejemplo número cuatro, aún más difícil
Integrador: vender flores, llamar a un taxi, vender productos, en general, cualquier cosa. Una cosa seria que funciona 24/7 para una gran cantidad de usuarios. Con una pila interesante completa, donde hay bases interesantes, soluciones, una gran carga, y lo más importante, le duele mentir más de 5 minutos. No solo y no tanto porque la gente no comprará, sino porque la gente verá que esto no está funcionando, se enojarán y es posible que no vuelvan por segunda vez.
Esta bien Cinco minutos ¿Qué haremos con esto? En este caso, estamos en una forma adulta, con todo el dinero estamos construyendo un sitio de respaldo real, con replicación de todo y de todo, y tal vez incluso automaticemos el cambio máximo a este sitio. Y además de esto, uno no debe olvidar hacer una cosa importante: de hecho, escriba el horario de cambio. Las regulaciones, incluso si tiene todo automatizado, pueden ser muy simples. De la serie "ejecutar tal y tal secuencia de comandos ansible", "haga clic en tal o cual amanece en la ruta 53" y así sucesivamente, pero esta debería ser una lista exacta de acciones.
Y todo parece estar claro. Cambiar la replicación es una tarea trivial, o se cambiará a sí mismo. Reescribe un nombre de dominio en dns, de la misma serie. El problema es que cuando un proyecto similar se bloquea, comienza el pánico e incluso los administradores barbudos más poderosos pueden ser propensos a ello. Sin una instrucción clara "abra una terminal, vaya aquí, la dirección en nuestro servidor sigue siendo así", el plazo de 5 minutos asignado para la reanimación es difícil de mantener. Bueno, además, cuando usamos estas regulaciones, es fácil corregir algunos cambios en la infraestructura, por ejemplo, y cambiar las regulaciones en consecuencia.
Bueno, si el sistema de respaldo es muy complejo y en algún momento cometimos un error, entonces también podemos poner nuestro sitio de reserva y, además, convertir los datos en una calabaza en ambos sitios, será realmente triste.
Ejemplo número cinco, hardcore completo
Un servicio internacional con cientos de millones de usuarios en todo el mundo. Todas las zonas horarias, que solo existen, de alta carga a la velocidad máxima, no debe mentir en absoluto. Un minuto, y será triste. Que hacer Reserva, de nuevo, en su totalidad. Hicieron todo lo que se mencionó en el ejemplo anterior, y un poco más. Un mundo ideal y nuestra infraestructura: es, según todos los conceptos de IaaC devopa. Es decir, todo en general en git, y solo haga clic en el botón.
Lo que falta Una son las enseñanzas. No puedes prescindir de ellos. Parece que todo es perfecto con nosotros, todo está bajo control en general. Presionamos el botón, todo sucede. Incluso si esto es así, y entendemos que esto no sucede, nuestro sistema interactúa con otros sistemas. Por ejemplo, estos son dns de la ruta 53, almacenamiento s3, integración con alguna api. No podremos prever todo en este experimento especulativo. Y hasta que realmente hagamos el cambio, no sabremos si funcionará o no.
Eso es probablemente todo. No seas perezoso y no te excedas. ¡Y que el tiempo de actividad esté contigo!