El 21 de mayo comenzará un curso intensivo de SRE en Slurme. Durante tres días completos, los participantes se sumergirán en la teoría y la práctica del apoyo a los servicios de alta carga. Sin tareas laborales, sin asuntos familiares, solo estudia. Debajo del corte, te contamos lo que te espera si decides unirte.
Ayuda SRE
Ingeniería de confiabilidad del sitio (SRE): asegura la confiabilidad de los sistemas de información. Este es un nuevo enfoque para respaldar sitios, servicios y aplicaciones con miles y millones de usuarios. El enfoque se originó en Google y ahora se está extendiendo por todo el mundo. En Rusia, SRE se ha implementado en Yandex, Mail.ru, Sberbank, Tinkoff, MTS, Megafon y otras empresas.
Los desarrolladores y administradores de sistemas experimentados se convierten en ingenieros de SRE: es importante un conocimiento profundo de los sistemas operativos de los servidores, el funcionamiento de la red, las herramientas de supervisión y las habilidades de programación. Todas estas habilidades duras se superponen a la metodología SRE: prácticas específicas que ayudan a garantizar una alta confiabilidad.
“La SRE no se trata tanto de alertas y autopsias. Se trata de que el código que socava de noche no llega a producción ”.
De la comunicación con ingenieros que implementaron SRE
Durante mucho tiempo, la principal fuente de conocimiento sobre SRE fue el libro del mismo nombre de Google. Ahora hay varios programas de formación en inglés y ruso. Uno de ellos es el intensivo SRE en Slurme.
Formato intensivo
El curso intensivo se lleva a cabo en línea y consta de conferencias y sesiones prácticas. Habrá una retransmisión en Zoom y chat de Telegram con ponentes.
Dos tipos de práctica. Los ejercicios prácticos son de dos tipos: personalización con el ejemplo y trabajo en tareas, cuya solución no está predeterminada. En el curso intensivo, se llaman casos .
Trabajo en equipo en un servicio real. Para trabajar los casos, los participantes del intensivo se unen en equipos de 5-8 personas. Cada equipo recibe un stand con una aplicación, varios VDS, que alberga un sitio web para solicitar entradas .
Un servicio de pedido de tickets, cuyo funcionamiento estable será asegurado por los participantes de la Simulación Intensiva de
Fallos.Durante el intensivo, se producirán varias fallas importantes en el trabajo del sitio, y la tarea del equipo es encontrar la causa, eliminar y prevenir su recurrencia. Los casos se basan en la experiencia real: los ponentes recopilaron los problemas que enfrentaron durante su práctica de SRE y crearon un entorno para simular estos problemas.
Oradores experimentados. El programa intensivo fue desarrollado y será conducido por:
- Ivan Kruglov, ingeniero de software de planta de Databricks.
- Artyom Artemiev, Lead SRE en TangoMe.
- Pavel Selivanov, ingeniero sénior de DevOps en Mail.ru Cloud Solutions.
Apoyo. Los curadores ayudarán a unirse en equipos y organizar el trabajo conjunto. Los oradores y los ingenieros de soporte técnico de Slurm lo ayudarán a resolver problemas complejos.
Formato remoto. Las conferencias se transmiten en Zoom, la discusión de las tareas se lleva a cabo en Slack. Todas las notas de las conferencias se conservarán y estarán disponibles después del intensivo, es útil volver a ellas después de un tiempo, ya en un ambiente más tranquilo.
Tres días de inmersión total. El intensivo está diseñado para tres días completos, de 10:00 a 18:00 hora de Moscú. Habrá breves pausas entre las conferencias y el almuerzo.
Comienza el 21 de mayo. Aún queda espacio.
Obtenga más información y regístrese
A continuación se muestra el programa intensivo completo.
Día 1: familiarización con la teoría de SRE, configuración de monitoreo y alerta
El primer día, se familiarizará con la teoría de SRE, aprenderá cómo configurar el monitoreo y la alerta, y también formará equipo con otros participantes en el intensivo.
Hablemos de las métricas SLO, SLI, SLA y cómo se relacionan con los requisitos comerciales. Compartiremos las mejores prácticas para configurar el monitoreo y las reglas para el cuerpo de bomberos. Daremos los primeros casos prácticos.
Tema 1: Monitoreo
- ¿Por qué necesita supervisión?
- Síntomas vs causas,
- Caja negra vs. Monitoreo de caja blanca,
- Señales de oro,
- Percentiles,
- Alertando,
- Observabilidad.
Práctica: Hacer un tablero básico y configurar las alertas necesarias.
Tema 2: Teoría SRE
- SLO, SLI, SLA,
- Durabilidad,
- Presupuesto de error.
Práctica: Agregar alertas SLO / SLI + al tablero.
Práctica: Primera carga del sistema.
Caso 1: adicción aguas abajo. En un sistema grande, hay muchos servicios interdependientes y no siempre funcionan igual de bien. Es especialmente ofensivo cuando su servicio está en orden, y el vecino, del que depende, se cae periódicamente. El proyecto de formación se encontrará en tales condiciones, y usted lo hará para que siga dando la calidad al más alto nivel posible.
Tema 3: Gestión de incidentes
- Ingeniería de resiliencia,
- Cómo se alinea la brigada de bomberos
- ¿Qué tan efectivo es su equipo en el incidente?
- 7 reglas para un líder de incidentes,
- 5 reglas para un bombero,
- HiPPO - la opinión de la persona mejor pagada. Líder de Comunicaciones.
Caso 2: adicción aguas arriba. Una cosa es cuando depende de un servicio con un SLO bajo. Es otra cuestión cuando su servicio es tal para otras partes del sistema. Esto sucede si no se acuerdan los criterios de evaluación: por ejemplo, responde a una solicitud en un segundo y la considera un éxito, pero el servicio dependiente espera solo 500 horas de Moscú y sale con un error. En este caso, discutiremos la importancia de la conciliación de métricas y aprenderemos a mirar la calidad a través de los ojos del cliente.
Tema 4: SRE incorporando un proyecto
En las grandes empresas, no es raro formar un equipo de SRE separado, que asume el apoyo de los servicios de otros departamentos. Pero no todos los servicios están listos para recibir soporte. Te diremos qué requisitos debe cumplir.
Día 2: resolución de problemas con el medio ambiente y la arquitectura
El segundo día se basa casi en su totalidad en la resolución de dos casos: problemas con el entorno (habrá un análisis detallado de Health Checking) y problemas con la arquitectura. Los oradores hablarán sobre cómo trabajar con autopsias y proporcionarán plantillas que puede utilizar en su equipo.
Tema 5: Comprobación de estado
- Verificación de estado en Kubernetes,
- ¿Nuestro servicio está vivo?
- Sondas de ejecución,
- initialDelaySeconds,
- Puerto de salud secundario,
- Servidor de salud Sidecar,
- Sonda sin cabeza,
- Sonda de hardware.
Caso 3: problemas medioambientales y el correcto Healthcheck. La tarea de Healthcheck es detectar un servicio de tiempo de inactividad y bloquear el tráfico para que los usuarios no se enfrenten a un problema. Y si cree que es suficiente rootear una solicitud al servicio y obtener una respuesta, entonces está equivocado: incluso si el servicio responde, esto no garantiza su rendimiento, puede haber problemas en el entorno. A través de este caso, aprenderá cómo configurar el Healthcheck correcto y no dejar que el tráfico vaya donde no se puede procesar.
Tema 6: Práctica de trabajo con autopsias : redactamos una autopsia basada en el caso anterior y la analizamos con los ponentes.
Tema 7: Solución de problemas de infraestructura
- Monitoreo de MySQL,
- SLO / SLI para MySQL,
- Detección de anomalías.
Caso 4: problemas con la base de datos. La base de datos también puede ser una fuente de problemas. Por ejemplo, si no supervisa el relé de replicación, la réplica quedará obsoleta y la aplicación devolverá datos antiguos. Además, es especialmente difícil depurar tales casos: ahora los datos son inconsistentes, pero después de unos segundos desaparecen y la causa del problema no está clara. A través del caso, sentirá todo el dolor de la depuración y aprenderá a prevenir tales problemas.
Día 3: blindaje de tráfico y lanzamientos canarios
Hay dos casos de alta disponibilidad de producción: blindaje de tráfico y despliegue canario. Aprenderá acerca de estos enfoques y aprenderá a aplicarlos. No estamos planeando un tuning hardcore a mano, aunque quién sabe.
Tema 8: Blindaje de tráfico
- comportamiento de las gráficas de crecimiento en el número de solicitudes y operaciones comerciales
- planificación de saturación y capacidad
- traffic shielding rate limiting
- sidecar rate-limiting 100
5: traffic shielding. ? , 100 , 1000. , , , . , .
9: Canary Deployment
- k8s (Rolling Update vs Recreate),
- canary blue-green ,
- blue-gree/canary release k8s,
- canary release GitLab CI/CD,
- canary release,
- .gitlab-ci.yml.
6: . ,
, - . , . Canary Deployment, .