Repasemos brevemente algunas de las operaciones de AWS como un SRE de inicio de AIGC, espero que pueda ayudar a todos Desde el comienzo de la incorporación para descubrir que nuestro clúster principal era USE1, comencé a hacer algunos preparativos. Estas son las principales cosas que hago 1. Se ha realizado una copia de seguridad de varias de nuestras bases de datos principales en varios lugares, formando copias de seguridad de USE1, Tokyo y SG. De esta forma, en casos extremos, perdemos parte de los datos, pero también podemos asegurar la continuidad del servicio 2. Reconstruya nuestro clúster de prueba SG desde el EC2 original K3S a un clúster estándar de AWS EKS. Esto le permite preparar rápidamente un clúster en caso de desastre y reutilizar los componentes de AWS existentes. Minimizar el costo de los cambios de manifiesto 3. Resuelva brevemente un SOP, incluidos los anuncios de usuario, el cambio de DNS, el bloqueo de versiones, etc. Hoy, unos 10 minutos después del incidente de AWS, descubrí que había nuevos pods en nuestros contenedores que no se podían configurar. Después de confirmar con AWS Support que se trataba de un problema de USE1, me di cuenta de que los eventos de ECR deben estar relacionados con el resto de los eventos, así que decidí comenzar a manejar eventos de nivel de nivel 1 de acuerdo con mi propio plan (para SRE, este tipo de cosas es mejor equivocarse que perderse) T + 0 min, emití un anuncio de todo el personal y comencé a entrar en modo de emergencia. Organicé una reunión pública de todos. Todas las personas pueden unirse en cualquier momento T+2 min, confirmé que el evento se estaba expandiendo gradualmente como esperaba, y emití dos instrucciones, 1. Prohibir cualquier fusión/confirmación de código en todos los ámbitos (principalmente para evitar que los recursos recién creados provoquen que la rotación de pods afecte al tráfico), 2. Por favor, prepare un anuncio para los estudiantes de la operación T + 3 min, comencé a seguir el SOP, comencé la recuperación de la base de datos en la región SG y me conecté en cascada para crear dependencias como OpenSearch / Redis, etc T + 5 min, comenzamos a confirmar oficialmente los problemas específicos de las dependencias ascendentes y descendentes, y confirmamos que un servicio central recién lanzado se vio afectado A + 10 minutos, se emitirá nuestro anuncio de suspensión del servicio y el anuncio afectado para el resto de los servicios T + 10min, le pedí a otras dos personas que ayudaran a configurar el nuevo ECR y limpiar los recursos existentes en el entorno de prueba al mismo tiempo, y sincronizar el CTO, en casos extremos, podemos tener la decisión de preservar la experiencia y perder datos. T + 15min, finalmente confirmamos que los recursos creados hasta ahora y la dirección del tráfico entrante no se verán muy afectados. El cambio está pendiente, pero seguimos preparando los recursos pertinentes T+30min, nuestra primera base de datos está restaurada T+40min, nuestra segunda base de datos está restaurada T + 1h, todas nuestras infraestructuras centrales asociadas, RDS / ES / Redis están en espera, y las opciones de optimización como maestro-esclavo se configuran de acuerdo con la arquitectura de producción. Al mismo tiempo, también estamos comenzando a lanzar nuevos servicios en nuevos clústeres Afortunadamente, al final, la caída de AWS no afectó a todos nuestros servicios. No tenemos que lidiar con trabajos complejos de reparación de datos después de cambiar el tráfico Después de aproximadamente T + 2h a T + 3h, notifiqué oficialmente a todo el personal y se levantó el estado de emergencia. Para estar seguros, todavía estaremos cerrados para presentar esta noche. Mirando hacia atrás en todo el incidente, podría haber hecho más 1. Revelar el SOP del caso extremo que preparé para mí mismo a todos los empleados. Esto asegura que incluso si no estoy en línea, alguien puede tomar mi lugar 2. Podemos hacer algunos simulacros avanzados 3. Los pedidos pueden ser más decisivos Eso es casi todo, un poco de compartir, espero que pueda ayudar a todos