Argumentar que el sitio siempre debe ser accesible es de mala educación y banalidad, pero el 100% de accesibilidad, aunque es un requisito previo, a menudo sigue siendo un ideal inaccesible. Ahora hay muchas soluciones en el mercado que prometen el máximo tiempo de actividad u ofrecen soluciones para aumentarlo, pero su aplicación no solo no siempre es útil, en algunos casos incluso puede conducir a mayores riesgos y a una menor accesibilidad a los proyectos. En este artículo, repasaremos los errores clásicos que encontramos constantemente. La mayoría de los problemas son elementales, pero la gente los permite una y otra vez.
Prefacio necesario: antes de intentar garantizar el tiempo de actividad máximo del proyecto, debe correlacionar los costos y el costo del tiempo de inactividad. Por lo general, esto es muy importante para las empresas cuyo trabajo depende del trabajo de otras empresas: soluciones B2B, servicios API, servicios de entrega. La inaccesibilidad por unos pocos minutos conducirá, al menos a la carga en el centro de llamadas de clientes insatisfechos. Para empresas de otro tipo, por ejemplo, una pequeña tienda en línea o una empresa cuyos clientes trabajan de 9 a 18 años, la inaccesibilidad, incluso durante varias horas, puede ser más barata que un sitio de respaldo completo.
1. Localización de todo el proyecto en un centro de datos / una zona de alojamiento en la nube
El marketing de alojamiento en la nube ha solucionado firmemente el concepto equivocado en las cabezas de las personas: el alojamiento en la nube no está vinculado al hardware y esto significa que la infraestructura de la nube no caerá. Tres bloqueos de Amazon Web Services de 24 horas, el reciente bloqueo de cloud4y y la pérdida de datos de cloudmouse mostraron que la localización de los datos y el proyecto en sí en un centro de datos es una forma garantizada de obtener muchas horas de tiempo de inactividad sin la capacidad de elevar fácilmente el proyecto a otro sitio. La ley de datos personales, a este respecto, crea problemas adicionales. Creemos que cualquier alojamiento en la nube debe pasar por varios accidentes importantes para aprender cómo prevenirlos (rayos que afectan a Amazon, problemas de configuración de red relacionados con el factor humano, etc.), y si el alojamiento en la nube occidental pasó por esta serie de desastres, entonces muchos sitios rusos aún no lo han hecho, y esto debe tenerse en cuenta.
La situación es aproximadamente la misma con los centros de datos "de hierro". A menudo vemos la configuración del cliente, donde se reservan varios servidores en un sitio, en caso de que uno de ellos falle, sin embargo, en nuestra experiencia, hay problemas de red cuando varios racks en un centro de datos o todo el centro de datos en su conjunto se vuelven inaccesibles suceden con mucha más frecuencia que los bloqueos de un solo servidor, y esto también debe tenerse en cuenta.
El flujo de trabajo del proyecto recomendado por AWS implica el uso de múltiples zonas de disponibilidad predeterminadas para lograr el máximo tiempo de actividad del proyecto.
2. Falta de duplicación adecuada en el sitio de reserva
Entonces, llegamos a la conclusión banal sobre la necesidad de tener un sitio de respaldo para lograr el máximo tiempo de actividad del proyecto, sin embargo, para cambiar a él, los datos deben ser adecuados para el sitio de producción. Lo importante aquí no es la creación inicial de la reserva; este es un procedimiento bastante simple y comprensible, la sincronización y el monitoreo de la sincronización de cambios adicionales es mucho más importante. En primer lugar, estamos hablando de:
- Configuración del clúster / sincronización de datos en el clúster cuando hablamos de un sitio complejo
- Sincronización de estructura de archivos y monitoreo del retraso de sincronización
- Rastree los cambios en la configuración del servidor
- Procesos depurados de monitoreo y adición a la sincronización de nuevos proyectos / servicios en el sitio.
- Seguimiento de la adición de nuevos servicios secundarios (nuevas colas, mecanismos de procesamiento e interacciones, etc.).
- Monitoreo continuo adecuado de todos estos procesos.
3. Falta de un plan de cambio y cambio regular a un sitio de respaldo
Cualquiera, incluso el mejor monitoreo, no puede garantizar que el sitio de respaldo estará listo para cambiar cuando sea realmente necesario. En nuestra experiencia, sucederá un accidente en el primer cambio a la reserva, y esto sucederá varias veces más. En sus informes, Stack Overflow dice que les llevó cerca de cinco cambios a la reserva, antes de que estuvieran convencidos de que ahora estaba completamente listo para aceptar el tráfico después del accidente. Por lo tanto, en el plan de trabajo para aumentar el tiempo de actividad del proyecto, es necesario incluir interruptores de prueba en la reserva y tener en cuenta que dichos cambios conducirán a un accidente. Después de trabajar y corregir el mecanismo de cambio en la documentación, debe continuar cambiando regularmente a la reserva para asegurarse de que todo sigue funcionando.
4. Localización del sitio de reserva en el mismo canal / en la misma región de la nube.
Si los sitios de producción y reserva se encuentran dentro de la misma empresa de alojamiento, es muy posible que, en caso de accidente, ambos sitios dejen de funcionar de inmediato. Varios accidentes importantes en AWS afectaron de inmediato a todas las zonas de disponibilidad de una región, Selectel cayó al mismo tiempo que los centros de datos en San Petersburgo y Moscú, las empresas pueden hablar sobre el aislamiento completo, pero el accidente cloud4y, que condujo a la inaccesibilidad completa de Bitrix24 sugiere que incluso en tales casos Hay grandes riesgos. Lo ideal, desde nuestro punto de vista, es una configuración en la que una configuración de respaldo se encuentra en la misma empresa de alojamiento (para usar medios regulares de cambio a una reserva, como VRRP ), y una plataforma de respaldo secundaria en otra empresa de alojamiento.
5. Colocación de versiones idénticas en los sitios principal y de reserva.
Incluso el uso de un sitio de reserva verificado y el uso de un sitio secundario en otro centro de datos no garantiza la disponibilidad de la reserva para hacerse cargo rápidamente de la carga de producción. Esto se debe a la esencia de la redundancia: una nueva versión del código que creó una carga fatal en el entorno de producción creará exactamente la misma carga en el sitio de respaldo, y el proyecto será completamente inaccesible. Como solución simple, debe haber un mecanismo para volver a la versión anterior, sin embargo, en la carrera comercial por lanzamientos, esto no siempre es posible, y luego comenzamos a pensar en otro sitio de respaldo con la versión anterior. También hay que hablar de la copia de seguridad : eliminación accidental de datos en la planta principal se reflejará en el sitio de copia de seguridad, por lo que debe considerar acerca de los retardados (15 minutos a una hora) la replicación, con el fin de ser capaz de cambiar a una base de datos, que aún no ha ocurrido Operación fatal.
6. Dependencia de los servicios externos a los que accede el proyecto.
Pero esto no es suficiente. Una gran cantidad de proyectos ahora utilizan servicios externos para proporcionar sus propios servicios. La mayoría de las personas usan SMS para la autenticación doble, las tiendas en línea calculan los tiempos de entrega utilizando los servicios de entrega, el pago se acepta a través de pasarelas de pago de terceros, y si estos servicios caen, no importa si hay una reserva o no, el proyecto aún no estará disponible. Raramente vemos la reserva de servicios externos, pero, mientras tanto, estos son exactamente los mismos proyectos que pueden tener problemas con el sitio de reserva, o puede que no haya ninguna reserva. Y si el servicio externo no está disponible, el servicio a sus clientes también será imposible. Recomendamos que duplique todos los sistemas externos críticos, controle su disponibilidad y tenga un plan para cambiarlos en caso de accidente.
Esto está lejos de todo, pero al menos cosas básicas. Discutimos esto con más detalle en las reuniones de uptime.community , la próxima será en octubre, pero por ahora puedes chatear en el grupo de telegramas .