🏣 👩‍❤️‍👩 ⬇️ Operar un sistema distribuido grande: lo que aprendí ◾️ 🐄 🔩

Al leer varios canales y boletines, a menudo me encuentro con artículos sobre "dolores" específicos y problemas que surgen cuando una empresa crece, cuando la fiabilidad y la escalabilidad se destacan. Este articulo es diferente. No hay un análisis detallado de soluciones arquitectónicas específicas o una guía paso a paso para cambiar la cultura de la ingeniería. Más bien, es una vista superior de los desafíos que surgen al operar sistemas distribuidos, y un punto de partida que lo ayudará a navegar el flujo de términos, abreviaturas y tecnologías.

Les traigo una traducción de un artículo escrito por un ingeniero de Uber.

* * *

En los últimos años, he creado y mantenido un gran sistema de pago distribuido en Uber . Durante este tiempo, aprendí mucho sobre los conceptos de arquitecturas distribuidas.y por mi propia experiencia descubrí lo difícil que es crear y mantener sistemas altamente cargados con alta disponibilidad. Construir dicho sistema es un trabajo interesante. Me gusta planificar cómo el sistema manejará el crecimiento del tráfico de 10 a 100 veces, para garantizar la confiabilidad de los datos independientemente de las fallas de hardware. Sin embargo, operar un sistema distribuido grande me dio una experiencia inesperada .

Cuanto más grande sea el sistema, más probable es que se encuentre con una manifestación de la ley de Murphy: " Todo lo que puede salir mal, saldrá mal ". La probabilidad es especialmente alta con lanzamientos frecuentes, cuando muchos desarrolladores implementan código, cuando usan varios centros de datos y con una gran audiencia de usuarios en todo el mundo. En los últimos años, me he encontrado con varios bloqueos del sistema, muchos de los cuales me sorprendieron: desde problemas predecibles, como bloqueos de hardware o errores inocentes, hasta roturas de cables que conectan los centros de datos a numerosos bloqueos en cascada que ocurren simultáneamente. Pasé por docenas de fallas en las que partes del sistema no funcionaban correctamente, lo que afectó en gran medida al negocio.

Este artículo resume las técnicas que se han beneficiado al operar un sistema grande en Uber. Mi experiencia no es única: otros trabajan con sistemas del mismo tamaño y pasan por las mismas aventuras. Hablé con ingenieros de Google, Facebook y Netflix, quienes enfrentaron situaciones similares y propusieron soluciones similares. Muchas de las ideas y procesos descritos aquí se pueden aplicar a sistemas de la misma escala, independientemente de si funcionan en centros de datos propiedad de la empresa (como suele ser el caso con Uber) o en la nube (donde Uber a veces escala ). Sin embargo, estos consejos pueden ser redundantes para sistemas no tan grandes o importantes para la empresa.

Hablaremos sobre tales temas:

Supervisión
Servicio (de guardia), detección de anomalías y notificación.
Fallos y gestión de incidentes.
Post Mortems, análisis de incidentes y una cultura de mejora continua.
Conmutación por error, planificación de recursos y pruebas de blackbox.
SLO, SLA e informes sobre ellos.
SRE como un equipo independiente.
La fiabilidad como inversión permanente.
Materiales utiles.

Supervisión

Para entender si el sistema es saludable, debemos responder la pregunta: “¿ Funciona correctamente? ". Para esto, es vital recopilar información sobre partes críticas del sistema. Y cuando tiene sistemas distribuidos que consisten en varios servicios en múltiples servidores y en diferentes centros de datos, puede ser difícil decidir qué puntos clave realmente necesita rastrear.

Monitoreo del estado de la infraestructura.Si una o más máquinas / máquinas virtuales están sobrecargadas, algunas partes del sistema distribuido pueden degradar su rendimiento. Las métricas de estado de las máquinas en las que se ejecuta el servicio (el consumo de recursos del procesador y la memoria) son los parámetros básicos que deben monitorearse. Existen plataformas que inicialmente rastrean estas métricas y escalan automáticamente las instancias. Uber tiene un gran equipo de infraestructura central , que por defecto proporciona monitoreo y alertas. Independientemente del método de implementación, debe tener información de que las instancias, la infraestructura o los servicios individuales tienen problemas.

Monitoreo del estado del servicio: tráfico, errores, demoras . A menudo necesitas tener la respuesta a la pregunta "¿El backend funciona bien? ". El monitoreo de métricas como la cantidad de tráfico entrante, la proporción de errores y el retraso en la respuesta brinda información valiosa sobre el estado del servicio. Prefiero hacer paneles para todas estas métricas. Cuando crea un nuevo servicio, el uso de las respuestas HTTP correctas y el monitoreo de los códigos correspondientes pueden informar mucho sobre el estado del sistema. Si está seguro de que los códigos 4xx se devuelven por errores del cliente y los códigos 5xx se devuelven por errores del servidor, le será fácil crear e interpretar dicha supervisión.

Hay algo más que decir sobre el seguimiento de los retrasos en la respuesta. El objetivo de los servicios de producción es que la mayoría de los usuarios finales disfruten de su uso. Y medir el retraso promedio no es la mejor solución, porque el valor promedio puede ocultar una pequeña cantidad de solicitudes con un gran retraso. Es mucho mejor medir p95, p99 o p999: el retraso para el percentil 95, 99 o 99,9 de las solicitudes. Estos números ayudan a responder preguntas como, " ¿Qué tan rápido será la solicitud para el 99% de los visitantes?" "(P99) o" ¿Qué tan lenta será la solicitud para un visitante de cada 1000? "(P999). Si está interesado en los detalles, puede leer este artículo .

Gráfico para p95 y p99. Tenga en cuenta que el retraso promedio para este punto final es inferior a 1 segundo, y el 1% de las solicitudes tarda 2 segundos. y más: esto no se ve al medir el valor promedio.

El tema del monitoreo y la observabilidad es mucho más profundo. Recomiendo leer el libro de Google SRE y la sección Cuatro señales de oro sobre el monitoreo de sistemas distribuidos. Si para un sistema con el que los usuarios interactúan, puede obtener solo cuatro métricas, luego centrarse en el tráfico, los errores, el retraso y la saturación. Hay menos material: el libro electrónico de Observabilidad de sistemas distribuidos , que describe herramientas útiles como los registros, así como las mejores prácticas para usar métricas y rastreo.

Monitoreo de métricas comerciales. Los servicios de monitoreo nos informan sobre su estado general. Pero de acuerdo con los datos de monitoreo solo, no podemos decir si los servicios funcionan correctamente, si todo se procesa correctamente desde el punto de vista comercial. En el caso del sistema de pago, la pregunta principal es: “ ¿Pueden las personas hacer viajes usando un método de pago específico? ". Uno de los pasos más importantes en el monitoreo es identificar y rastrear eventos de negocios que son creados y procesados por este servicio.

Mi equipo creó un monitoreo de las métricas comerciales después de una falla que no pudimos detectar de otras maneras. Todo parecía que los servicios funcionaban normalmente, pero de hecho la funcionalidad clave no funcionaba. Este tipo de monitoreo fue muy inusual para nuestra empresa y campo de actividad. Por lo tanto, tuvimos que hacer muchos esfuerzos para configurar este monitoreo por nosotros mismos, creando nuestro propio sistema .

Servicio, detección de anomalías y alerta

El monitoreo es una gran herramienta para verificar el estado actual del sistema. Pero este es solo un paso en el camino para detectar automáticamente fallas y alertar a aquellos que deberían hacer algo en este caso.

El reloj es un tema extenso. Increment Magazine hizo un excelente trabajo al destacar muchos de los problemas en el tema de guardia . En mi opinión, el deber es una continuación lógica del enfoque de "usted creó - usted posee". Los servicios son propiedad de los equipos que los crearon, y también poseen un sistema de alerta y respuesta a incidentes. Mi equipo poseía dicho sistema para el servicio de pago que creamos. Y cuando llega la alerta, el ingeniero de turno debe responder y descubrir qué está sucediendo. Pero, ¿cómo pasamos del monitoreo a las alertas?

Determinar anomalías basadas en datos de monitoreo es una tarea difícil , y el aprendizaje automático debería manifestarse completamente aquí. Existen muchos servicios de terceros para detectar anomalías. Afortunadamente para mi equipo, nuestra empresa tiene su propio grupo de aprendizaje automático para resolver los problemas que enfrenta Uber. El equipo de Nueva York escribió un artículo útil sobre cómo funciona la detección de anomalías en Uber . Desde el punto de vista de mi equipo, solo transmitimos datos de monitoreo a esta tubería y recibimos alertas con diversos grados de confianza. Y luego decidimos si informarle al ingeniero al respecto.

¿Cuándo necesito enviar una alerta? La pregunta es interesante. Si hay muy pocas alertas, entonces podemos perder una falla importante. Si es demasiado, entonces la gente no dormirá por la noche.El seguimiento y la clasificación de alertas, así como la medición de la relación señal / ruido, desempeña un papel importante en la configuración de un sistema de alerta . Un buen paso hacia una rotación constante de ingenieros de servicio será analizar las alertas, clasificar los eventos como "que requieren acción" y "que no requieren", y luego reducir la cantidad de alertas que no requieren acción.

Un ejemplo de un panel de Call Duty creado por el equipo de Uber Developer Experience en Vilnius.

El equipo de Uber para crear herramientas de desarrollo de Vilnius ha creado una pequeña herramienta que usamos para comentar alertas y visualizar turnos de trabajo. Nuestro equipo genera un informe semanal sobre el trabajo del último turno de servicio, analiza las debilidades y mejora la metodología del deber.

Gestión de fallos e incidentes.

Imagínese: usted es ingeniero de servicio durante una semana. En medio de la noche despiertas un mensaje en el buscapersonas. Está comprobando si se ha producido un error de producción. Maldición, parece que parte del sistema se ha bloqueado. ¿Ahora que? El monitoreo y las alertas simplemente funcionaron.

Las fallas pueden no ser particularmente problemáticas para sistemas pequeños cuando el ingeniero de turno puede entender lo que sucedió y por qué. Por lo general, en dichos sistemas, puede identificar rápidamente las causas y deshacerse de ellas. Pero en el caso de sistemas complejos que contienen muchos (micro) servicios, cuando muchos ingenieros envían el código a la operación, la razón de la falla es bastante difícil. Y el cumplimiento de varios procedimientos estándar puede ser de gran ayuda.

La primera línea de defensa son los runbooks de procedimientos de respuesta estándar.que describen pasos simples de solución de problemas. Si la compañía tiene tales listas y recibe apoyo activo, es poco probable que una idea superficial del ingeniero de servicio sobre el sistema sea un problema. Las listas deben mantenerse actualizadas, actualizadas y procesadas para nuevas formas de resolver problemas.

Informar sobre fallas de otros empleadosSe vuelve muy importante si varios equipos están involucrados en la implementación de un servicio. En el entorno en el que trabajo, los servicios, según sea necesario, son implementados por miles de ingenieros, con una frecuencia de cientos de lanzamientos por hora. Y el despliegue aparentemente inocuo de un servicio puede afectar a otro. En tal situación, la estandarización de los informes de fallas y los canales de comunicación juega un papel importante. Tuve muchos casos en que la alerta no fue como cualquier otra cosa, y me di cuenta de que para otros equipos esto también se ve extraño. Al comunicarnos en un chat general sobre fallas, identificamos el servicio responsable de la falla y eliminamos rápidamente las consecuencias. Juntos logramos hacer esto mucho más rápido que cualquiera de nosotros individualmente.

Elimine las consecuencias ahora y descifre mañana. En medio de un accidente, a menudo me sobrecogía una ola de adrenalina debido al deseo de corregir los errores. A menudo, la causa del problema fue implementar un código incorrecto con un error obvio. Anteriormente, habría renunciado a todo y comenzado a corregir errores, enviar una solución y revertir el código fallido. Pero arreglar la causa en medio de un accidente es una idea terrible . Con una solución rápida, puede lograr poco y perder mucho . Dado que la solución debe hacerse rápidamente, debe probarse en la batalla. Y este es el camino hacia un nuevo error, o un nuevo error, además del existente. Vi cómo esto causó una serie de fallas. Solo enfóquese en arreglar las consecuencias, no se sienta tentado a arreglar el código o encontrar la causa. La investigación esperará hasta mañana.

Post Mortems, análisis de incidentes y una cultura de mejora continua

Un informe de incidente es una característica importante de cómo un equipo hace frente a las consecuencias de una falla. ¿La situación preocupa a la gente? ¿Investigan un poco o dedican un esfuerzo increíble a la observación, detienen el producto y hacen correcciones?

La autopsia escrita correctamente es uno de los elementos principales de la construcción de sistemas sostenibles. No condena a nadie y no busca a los culpables, este es un estudio y análisis cuidadoso del incidente. Con el tiempo, nuestras plantillas para tales informes evolucionaron, aparecieron secciones con conclusiones finales, evaluación de impacto, cronología de eventos, análisis de la razón principal, lecciones aprendidas y una lista detallada de elementos para observación adicional.

Usé este patrón de manejo de errores en Uber.

En una buena autopsia, la causa de la falla se investiga a fondo y se proponen medidas para prevenir, detectar o eliminar rápidamente las consecuencias de fallas similares. Y cuando digo "profundamente", me refiero a que los autores no se detienen en el hecho de que la razón fue el lanzamiento de código con un error que el revisor no notó. Los autores deben aplicar la metodología Five Why para llegar a una conclusión más útil. Por ejemplo:

¿Por que hay un problema? -> El error se cargó como parte del código.
¿Por qué nadie atrapó un error? -> El que realizó la revisión no se dio cuenta de que cambiar el código podría provocar ese problema.
, ? --> .
? --> .
? --> .
: . , .

El análisis de incidentes es una herramienta complementaria importante para trabajar en errores. Mientras que algunos equipos trabajan con cuidado en los errores, otros pueden beneficiarse de datos adicionales y realizar mejoras preventivas. También es importante que los equipos se consideren responsables y capaces de realizar las mejoras que proponen a nivel de sistema.

En organizaciones que toman en serio la confiabilidad, los incidentes más serios son analizados y eliminados por ingenieros experimentados. También es necesario gestionar la ingeniería a nivel de la empresa para garantizar que se puedan realizar correcciones, especialmente si requieren mucho tiempo o interfieren con otros trabajos. No se puede crear un sistema confiable en una noche: se requerirán iteraciones constantes. Iteraciones resultantes de una cultura de mejora continua de la empresa basada en las lecciones aprendidas de los incidentes.

Conmutación por error, planificación de recursos y pruebas de caja negra

Existen varios procedimientos regulares que requieren una inversión significativa, pero que son críticos para mantener un sistema distribuido grande. Llegué a estas ideas por primera vez en Uber, no necesitaba aplicarlas a otras empresas debido a la menor escala y la falta de disponibilidad de la infraestructura. Considere una

conmutación por error estúpida en el centro de datos (conmutación por error) hasta que me encontré con esto. Inicialmente, creía que el diseño de un sistema distribuido estable es la estabilidad de los centros de datos para caer. ¿Por qué debería probarse regularmente si todo debería funcionar teóricamente ? La respuesta depende de escalar y probar la capacidad de los servicios para manejar eficientemente el aumento inesperado del tráfico en el nuevo centro de datos.

El escenario de falla más común que encontré es que el servicio no tiene suficientes recursos en el nuevo centro de datos para manejar el tráfico global en caso de una conmutación por error. Suponga que el servicio A funciona en un centro de datos y el servicio B en otro. Deje que el consumo de recursos sea del 60%: decenas o cientos de máquinas virtuales giran en cada centro de datos y se activan alertas cuando se alcanza un umbral del 70%. Todo el tráfico desde el centro de datos A al centro de datos B falló. El segundo centro de datos no puede hacer frente a tal aumento de carga sin implementar nuevas máquinas. Sin embargo, esto puede llevar mucho tiempo, por lo que las solicitudes comienzan a acumularse y desaparecer. El bloqueo comienza a afectar a otros servicios, provocando una falla en cascada de otros sistemas que no están relacionados con la conmutación por error primaria.

Una posible situación en la que la conmutación por error genera problemas.

Otro escenario de falla popular involucra problemas a nivel de enrutamiento, problemas con el ancho de banda de la red o contrapresión . La conmutación por error de los centros de datos es un desarrollo que cualquier sistema distribuido confiable debe realizar sin ningún impacto en los usuarios. Enfatizo - se debe , este desarrollo es uno de los ejercicios más útil para comprobar la fiabilidad de los sistemas distribuidos web.

Ejercicios de tiempo de inactividad programadosUna excelente manera de probar la estabilidad de un sistema completo. También es una gran herramienta para detectar dependencias ocultas o usos inapropiados / inesperados de un sistema en particular. Los ejercicios de tiempo de inactividad programados pueden ser relativamente fáciles de realizar con servicios con los que los clientes interactúan y tienen dependencias poco conocidas. Sin embargo, si estamos hablando de sistemas críticos para los cuales se permite un tiempo de inactividad muy corto o del que dependen muchos otros sistemas, entonces será difícil llevar a cabo tales ejercicios. Pero, ¿qué sucede si tal sistema deja de estar disponible algún día? Es mejor responder esta pregunta en un experimento controlado para que todos los equipos estén advertidos y listos.

Prueba de Blackbox(el método del "recuadro negro") es una forma de evaluar la corrección del sistema en una situación lo más cercana posible a la interacción con el usuario final. Esto es similar a las pruebas de extremo a extremo, excepto por el hecho de que para la mayoría de los productos, la prueba correcta de blackbox requiere una inversión propia. Los buenos candidatos para tales pruebas son los procesos y escenarios clave del usuario que involucran la interacción del usuario: para probar el sistema, asegúrese de que se puedan iniciar en cualquier momento.

Usando Uber como ejemplo, una prueba de caja negra obvia es verificar la interacción conductor-pasajero a nivel de la ciudad: ¿puede un pasajero encontrar un conductor y hacer un viaje a pedido específico? Después de automatizar este escenario, la prueba se puede ejecutar regularmente, emulando diferentes ciudades. Un sistema confiable de prueba de caja negra facilita la verificación del funcionamiento correcto del sistema o sus partes. También ayuda mucho con las pruebas de conmutación por error: la forma más rápida de obtener comentarios de conmutación es ejecutar pruebas de blackbox.

Un ejemplo de prueba de blackbox durante la conmutación por error y la reversión manual.

Planeación de recursosjuega un papel particularmente importante para grandes sistemas distribuidos. En términos generales, me refiero a aquellos en los que el costo de la computación y el almacenamiento se calcula en decenas o cientos de miles de dólares por mes. A esta escala, puede ser más barato tener un número fijo de implementaciones que usar soluciones de nube auto escalables. En casos extremos, las implementaciones fijas deben manejar el tráfico que es característico del "negocio normal", con escalado automático solo en cargas máximas. Pero, ¿cuál es el número mínimo de instancias para aplicar el próximo mes? ¿En los próximos tres meses? ¿El próximo año?

No es difícil predecir patrones de tráfico futuros para sistemas maduros con grandes volúmenes de estadísticas. Esto es importante para el presupuesto, la elección de los proveedores o para fijar los descuentos de los proveedores de la nube. Si su servicio genera grandes cuentas y no ha pensado en la planificación de recursos, entonces se está perdiendo una manera fácil de reducir costos y administrarlos.

SLO, SLA e informar sobre ellos

SLO significa Service Level Objective , una métrica para la disponibilidad del sistema. Es una buena práctica establecer los SLO en el nivel de servicio para el rendimiento, el tiempo de respuesta, la corrección y la disponibilidad. Estos SLO se pueden usar como umbrales de alerta. Ejemplo:

Métrica de SLO	Subcategoría	Valor del servicio
Actuación	Ancho de banda mínimo	500 solicitudes por segundo
		2 500
		50-90
	p99	500-800
		0,5 %
		99,9 %

SLO a nivel empresarial . o SLO funcionales, esto es una abstracción sobre los servicios. Cubren métricas personalizadas o comerciales. Por ejemplo, un SLO a nivel comercial podría ser esto: se espera que el 99.99% de los recibos se envíen por correo dentro de 1 minuto de completar un viaje. Este SLO se puede comparar con el SLO a nivel de servicio (por ejemplo, con el retraso del sistema de pago o el sistema de envío de cheques por correo), y se puede medir por separado.

SLA - Acuerdo de nivel de servicio . Este es un acuerdo más general entre un proveedor de servicios y su consumidor. Por lo general, múltiples SLO forman un SLA. Por ejemplo, la disponibilidad de un sistema de pago al nivel de 99.99% puede ser SLA, que se divide en SLO específicos para cada sistema correspondiente.

Después de determinar el SLO, debe medirlos y hacer un informe.El monitoreo y la presentación de informes automáticos sobre SLA y SLO a menudo es un proyecto complejo que ni los ingenieros ni las empresas desean priorizar. Los ingenieros no estarán interesados, porque ya tienen diferentes niveles de monitoreo para identificar fallas en tiempo real. Una empresa prioriza mejor la entrega de funcionalidad, en lugar de invertir en un proyecto complejo que no dará beneficios inmediatos.

Y esto nos lleva a otro tema: las organizaciones que operan grandes sistemas distribuidos, tarde o temprano necesitan asignar personas para garantizar la confiabilidad de estos sistemas. Hablemos del equipo de SRE: ingeniería de confiabilidad del sitio.

SRE como equipo independiente

El término Ingeniería de Confiabilidad del Sitio fue acuñado por Google alrededor de 2003, y hoy hay más de 1,500 ingenieros de SRE. A medida que la operación del entorno de producción se está convirtiendo en una tarea cada vez más compleja que requiere más automatización, pronto se convertirá en un trabajo completo. Esto sucede cuando las empresas se dan cuenta de que los ingenieros trabajan en la automatización del entorno de producción casi todo el día: cuanto más importante es el sistema y más fallas ocurren, más pronto el SRE se convierte en una posición separada.

Las compañías de tecnología de rápido crecimiento a menudo crean un equipo SRE desde el principio, que planifican por sí mismas. En Uber, dicho equipo fue creado en 2015.Su objetivo era gestionar la complejidad del sistema. En otras compañías, la asignación de equipos SRE puede asociarse con la creación de un equipo de infraestructura separado. Cuando la compañía crece a un nivel tal que garantizar la confiabilidad del servicio requiere la atención de un número significativo de ingenieros, entonces es hora de crear un equipo separado.

El equipo de SRE simplifica enormemente el mantenimiento de grandes sistemas distribuidos para todos los ingenieros. El equipo de SRE probablemente posee herramientas estándar de monitoreo y alertas. Probablemente estén comprando o creando herramientas de guardia y estén dispuestos a compartir su experiencia. Pueden facilitar el análisis de incidentes y crear sistemas que faciliten la detección de fallas, reduzcan sus consecuencias y las eviten en el futuro. El comando SRE ciertamente facilita las operaciones de conmutación por error. A menudo se usa para probar cajas negras y planificar el rendimiento. Los ingenieros de SRE administran la selección, personalización o creación de herramientas estándar para determinar y medir los SLO e informar sobre ellos.

Dado que todas las compañías tienen sus propios problemas, para cuya solución reclutan SRE, dichos equipos en diferentes compañías tienen diferentes estructuras. Incluso los nombres pueden variar: puede ser un servicio de operación, ingeniería de plataforma o servicio de infraestructura. Google ha publicado dos libros de lectura obligatoria para garantizar la fiabilidad de los servicios . Están disponibles gratuitamente y son una excelente fuente de información para un estudio más profundo del tema de SRE.

La fiabilidad como inversión permanente

Al crear cualquier producto, ensamblar la primera versión es solo el comienzo. Después de eso habrá nuevas iteraciones, con nuevas características. Si el producto es exitoso y rentable, entonces el trabajo continúa.

Los sistemas distribuidos tienen el mismo ciclo de vida, excepto que necesitan más inversión no solo en nuevas características, sino también en mantenerse al día con la escala. Cuando aumenta la carga en el sistema, debe almacenar más datos, más ingenieros trabajan en el sistema, debe cuidar constantemente su funcionamiento normal. Muchos de los que crean sistemas distribuidos por primera vez consideran que son algo así como una máquina: una vez que lo hace, es suficiente para llevar a cabo cierto mantenimiento cada pocos meses. Es difícil llegar a una comparación más lejos de la realidad.

, , . Para que el hospital funcione bien, se necesitan verificaciones constantes (monitoreo, alertas, pruebas de recuadro negro). Todo el tiempo que necesita para contratar personal y equipos nuevos: para hospitales, son enfermeras, médicos y dispositivos médicos, y para sistemas distribuidos, nuevos ingenieros y servicios. A medida que aumenta el número de empleados y servicios, los viejos métodos de trabajo se vuelven ineficaces: una pequeña clínica en el campo funciona de manera diferente que un gran hospital en una metrópoli. Lograr formas más efectivas de funcionamiento se convierte en un trabajo completo, y las mediciones y alertas son cada vez más importantes. Como un gran hospital requiere más personal, como contabilidad, recursos humanos y seguridad,y la operación de grandes sistemas distribuidos depende de equipos de servicio como infraestructura y SRE.

Para que el equipo mantenga un sistema distribuido confiable, la organización debe invertir constantemente en su funcionamiento, así como en el trabajo de las plataformas en las que se basa el sistema.

Materiales utiles

Aunque el artículo resultó ser largo, presenta solo los momentos más superficiales. Para obtener más información sobre las características de los sistemas operativos distribuidos, recomiendo estas fuentes:

Libros

Google SRE Book es un gran libro gratuito de Google. El capítulo sobre Supervisión de sistemas distribuidos es especialmente importante para este artículo .
Observabilidad de sistemas distribuidos , otro gran libro gratuito con excelentes consejos sobre el monitoreo de sistemas distribuidos.
Designing Data-Intensive Applications es el libro más práctico sobre el concepto de sistemas distribuidos que he encontrado. Sin embargo, no cubre los aspectos operativos que hemos examinado tan profundamente.

Sitios

Edición On-Call de Increment Magazine : una serie de artículos sobre procesos de respuesta a incidentes en Amazon, Dropbox, Facebook, Google y Netflix.
Aprendiendo a construir sistemas distribuidos : artículo de AWS Engineer que responde a la pregunta "¿Cómo aprender a crear grandes sistemas distribuidos?"

Vea los comentarios sobre este artículo en Hacker News .

Operar un sistema distribuido grande: lo que aprendí