Una mirada al interior de la fiabilidad de los servicios de Facebook

Ingenieros de produccion

2009. SRE

2010. SRO y AppOps

2012. Ingenieros de producción

2014. SRO de cierre

• Siempre estamos integrados en equipos. No tenemos búsqueda SRE en general, como en Google, es para cada servicio de búsqueda por separado.
• No estamos en los productos , solo en la infraestructura que el producto administra por sí mismo.
• Estamos en llamada junto con los desarrolladores.
• Tenemos un poco más de experiencia en sistemas y redes, por lo que nos enfocamos en monitorear y extinguir los servicios cuando se queman brillantemente. Solucionamos los errores de antemano que podrían provocar bloqueos e influir en la arquitectura de los nuevos servicios desde el principio, para que luego funcionen sin problemas en la producción.

Supervisión

ENCIMA

ATOP es hermoso, lo usamos constantemente.

Malloc HTTP

Thrift message
HTTP/1.1 400
"HTTP" == 0x48545450

malloc("HTTP")
pid = fork(); // errno = ENOMEM

malloc("HTTP")
pid = fork(); // errno = ENOMEM

// 0: heuristic overcommit
vm.overcommit_memory = 0

FB303

Service FacebookService {
    map<string, i64> getCounters()
}

incrementCounter(string& key);

setCounter(string& key, int64_t value);

Observabilidad

Escafandra autónoma

• Una tabla que muestra las versiones de archivos binarios, paquetes, cuánta memoria se consume en millones de máquinas. En cada host, se realiza un PS una vez por hora y se envía a Scuba.
• Todos los dmesg, todos los volcados de memoria, se envían a otras tablas. Ejecutamos Perf una vez cada 10 minutos en cada máquina, por lo que sabemos qué rastros de pila tenemos en el núcleo y qué puede cargar la CPU global.

Depuración PHP

Tableros

Cómo funciona

Cuando Facebook yacía

Portal del administrador de incidentes

Prevención

• Bajo carga normal, la solicitud llega, se procesa y se devuelve al cliente.
• Con una carga alta, las solicitudes están esperando en una cola porque todos los subprocesos para procesar solicitudes están ocupados. La demora está aumentando, pero hasta ahora todo está bien.
• La línea está creciendo, la carga está aumentando. En algún momento, todo lo que el servidor ejecuta en el cliente termina con un tiempo de espera de respuesta y el cliente se cae con un error. En este punto, el resultado del servidor simplemente puede desecharse.

Herramientas

• Cubismo integrado en el sistema.
• FBAR es un "caballo de batalla" que viene y repara, por lo que nadie se preocupa por un auto roto. Esta es la tarea principal de la FBAR, pero ahora tiene aún más tareas.
• Coredumper , que escribimos con dos colegas . Supervisa los coredumps en todas las máquinas y los deja caer en un solo lugar junto con los rastros de la pila con toda la información del host: dónde se encuentra, cómo encontrar qué tamaño. Pero lo más importante, los seguimientos de pila son gratuitos, sin iniciar GDB utilizando programas BPF.

Centro

"La responsabilidad principal del software del sistema debe ser continuar ejecutándose. La prestación de servicios debe verse como un efecto secundario beneficioso de la operación continua »

• "¿Qué sucede si su sistema obtiene el 10% de la carga?" Cuando la gente piensa: "¿Pero realmente, qué?" - aparecen ideas y muchos incluso gobiernan sus sistemas. Anteriormente, no lo pensaban, pero después de la pregunta hay una razón.
• "¿Quién es el primero en notar problemas con su servicio, usted o sus usuarios?" Los desarrolladores comienzan a recordar cuándo sucedió esto y: "... Tal vez necesites agregar alertas".
• "¿Cuál es tu mayor dolor en la llamada?" Esto es inusual para los desarrolladores, especialmente para los nuevos. Inmediatamente dicen: “¡Tenemos muchas alertas! Vamos a limpiarlos y eliminar aquellos que no son el caso ".
• "¿Qué tan frecuentes son sus lanzamientos?" Primero recuerdan que lo están lanzando con sus manos, y luego tienen su propia implementación personalizada.

6-7 Saint HighLoad++, . (, , ).
telegram- . !