SRE (Site Reliability Engineering) é un enfoque para garantir a dispoñibilidade de proxectos web. Considérase un marco para DevOps e fala sobre como lograr o éxito na aplicación das prácticas de DevOps. Tradución neste artigo libros de Google. Eu preparei esta tradución e confiei na miña propia experiencia para comprender os procesos de seguimento. Na canle de telegram и Tamén publiquei unha ligazón á tradución do capítulo 4 do mesmo libro sobre os obxectivos do nivel de servizo.
Tradución por cat. Disfruta da lectura!
Os equipos de SRE de Google teñen principios básicos e prácticas recomendadas para crear sistemas de supervisión e notificación exitosos. Este capítulo ofrece orientación sobre os problemas que pode atopar un visitante dunha páxina web e como resolver os problemas que dificultan a visualización das páxinas web.
Definicións
Non se utiliza un vocabulario único para tratar temas relacionados co seguimento. Mesmo en Google, os termos que aparecen a continuación non se usan habitualmente, pero enumeraremos as interpretacións máis comúns.
Seguimento
Recollida, tratamento, agregación e visualización de datos cuantitativos en tempo real sobre o sistema: número de solicitudes e tipos de solicitudes, número de erros e tipos de erros, tempo de procesamento de solicitudes e tempo de funcionamento do servidor.
Monitorización de caixa branca
Monitorización baseada nas métricas que mostran os compoñentes internos do sistema, incluídos os rexistros, as métricas de perfís de Java Virtual Machine ou as métricas do controlador HTTP que xeran estatísticas internas.
Monitorización de caixa negra
Proba o comportamento da aplicación dende o punto de vista do usuario.
Panel de control
Unha interface (xeralmente web) que ofrece unha visión xeral dos principais indicadores de saúde dos servizos. O panel pode ter filtros, a posibilidade de seleccionar os indicadores mostrados, etc. A interface está deseñada para identificar os indicadores que son máis importantes para os usuarios. O panel tamén pode mostrar información para o persoal de soporte técnico: unha cola de solicitudes, unha lista de erros de alta prioridade e un enxeñeiro asignado para unha determinada área de responsabilidade.
Alerta (notificación)
Notificacións destinadas a ser recibidas por unha persoa por correo electrónico ou outros medios, que poden ser desencadeadas por erros ou por un aumento da fila de solicitudes. As notificacións clasifícanse en: entradas, alertas por correo electrónico e mensaxes de mensaxería instantánea.
Causa raíz
Un defecto de software ou erro humano que, unha vez corrixido, non debería volver ocorrer. O problema pode ter varias causas principais: insuficiente automatización do proceso, defecto do software, elaboración insuficiente da lóxica da aplicación. Cada un destes factores pode ser a causa raíz, e cada un deles debe ser eliminado.
Nodo e máquina (nodo e máquina)
Termos intercambiables para referirse a unha única instancia dunha aplicación en execución nun servidor físico, máquina virtual ou contedor. Unha máquina pode albergar varios servizos. Os servizos poden ser:
- conectados entre si: por exemplo, un servidor de caché e un servidor web;
- servizos non relacionados nunha única peza de hardware: por exemplo, un repositorio de código e un asistente para un sistema de configuración, como ou .
Empuxe
Calquera cambio na configuración do software.
Por que é necesario un seguimento?
Hai varias razóns polas que é necesario supervisar as aplicacións:
Análise de tendencias a longo prazo
Que tamaño ten a base de datos e qué tan rápido crece? Como cambia o número diario de usuarios?
Comparación de rendemento
Son as solicitudes máis rápidas en Acme Bucket of Bytes 2.72 en comparación con Ajax DB 3.14? Canto mellor son as solicitudes almacenadas na memoria caché despois da aparición dun nodo adicional? O sitio funciona máis lento en comparación coa semana pasada?
Alerta (notificacións)
Algo está roto e alguén ten que arranxalo. Ou algo romperá pronto e alguén debe revisalo pronto.
Creación de paneis
Os paneis deben responder preguntas básicas e incluír algo de — atrasos (latencia), tráfico (tráfico), erros (erros) e tamaño de carga (saturación).
Realización de análises retrospectivas (depuración)
O atraso no procesamento de solicitudes aumentou, pero que máis pasou ao mesmo tempo?
Os sistemas de monitorización son útiles como fonte de datos para os sistemas de intelixencia empresarial e para facilitar a análise de incidentes de seguridade. Dado que este libro céntrase en áreas de enxeñería nas que os SRE teñen experiencia, non discutiremos aquí as técnicas de monitorización.
A vixilancia e as alertas permiten que o sistema che indique cando se avaria ou está a piques de avariar. Cando un sistema non pode repararse automaticamente, queremos que un humano analice a alerta, determine se o problema aínda está activo, o resolva e determine a causa raíz. Se non audita os compoñentes do sistema, nunca recibirá unha alerta simplemente porque "algo parece un pouco estraño".
Cargar unha persoa con notificacións é un uso bastante caro do tempo dun empregado. Se o traballador está traballando, a alerta interrompe o proceso de traballo. Se o empregado está na casa, a alerta interrompe o tempo persoal e posiblemente durmir. Cando as alertas se producen con demasiada frecuencia, os empregados as repasan, apáganas ou ignoran as alertas entrantes. De cando en vez ignoran a alerta real, que está enmascarada por eventos de ruído. As interrupcións do servizo poden durar longos períodos de tempo xa que os eventos de ruído impiden que o problema se diagnostique e corrixa rapidamente. Os sistemas de aviso eficaces teñen unha boa relación sinal-ruído.
Establecer expectativas razoables para o sistema de vixilancia
Configurar a supervisión dunha aplicación complexa é unha tarefa de enxeñería complexa en si mesma. Aínda cunha infraestrutura importante de ferramentas de recollida, visualización e alerta, un equipo de Google SRE de entre 10 e 12 membros normalmente inclúe unha ou dúas persoas cuxo obxectivo principal é crear e manter sistemas de monitorización. Este número diminuíu co paso do tempo a medida que consolidamos e centralizamos a infraestrutura de vixilancia, pero cada equipo de SRE normalmente ten polo menos unha persoa dedicada exclusivamente á vixilancia. Temos que dicir que, aínda que os paneis de control do sistema son bastante interesantes de ver, os equipos SRE evitan coidadosamente as situacións que requiren que alguén mire unha pantalla para supervisar os problemas.
En xeral, Google pasou a sistemas de vixilancia sinxelos e rápidos con ferramentas de análise posterior ao feito óptimas. Evitamos os sistemas "máxicos" que tentan predicir limiares ou detectar automaticamente a causa raíz. Os sensores que detectan contido non desexado nas solicitudes dos usuarios finais son o único contraexemplo; Mentres estes sensores sigan sendo simples, poden detectar rapidamente as causas de anomalías graves. Outros formatos para utilizar datos de seguimento, como a planificación da capacidade ou a previsión de tráfico, son máis complexos. A observación durante un período de tempo moi longo (meses ou anos) cunha taxa de mostraxe baixa (horas ou días) revelará unha tendencia a longo prazo.
O equipo de Google SRE tivo un éxito mixto con xerarquías de dependencia complexas. Raramente usamos regras como "se descubro que a base de datos é lenta, recibo unha alerta de que a base de datos é lenta, se non, recibo unha alerta de que o sitio é lento". As regras baseadas na dependencia normalmente fan referencia a partes inmutables do noso sistema, como o sistema para filtrar o tráfico dos usuarios ao centro de datos. Por exemplo, "se o filtrado de tráfico ao centro de datos está configurado, non me avises sobre atrasos no procesamento das solicitudes dos usuarios" é unha regra xeral para as alertas do centro de datos. Poucos equipos de Google admiten xerarquías de dependencia complexas porque a nosa infraestrutura ten unha taxa constante de refactorización continua.
Algunhas das ideas descritas neste capítulo seguen sendo relevantes: sempre hai unha oportunidade de pasar máis rápido do síntoma á causa raíz, especialmente nos sistemas en constante cambio. Polo tanto, aínda que este capítulo describe algúns obxectivos dos sistemas de monitorización e como lograr eses obxectivos, é importante que os sistemas de monitorización sexan sinxelos e comprensibles para todos os membros do equipo.
Así mesmo, para manter os niveis de ruído baixos e os niveis de sinal altos, os enfoques para controlar os activos alertados deben ser moi sinxelos e fiables. As regras que xeran avisos para as persoas deben ser fáciles de entender e presentar un problema claro.
Síntomas versus causas
O seu sistema de seguimento debería responder a dúas preguntas: "o que se rompeu" e "por que se rompeu".
"O que rompeu" fala do síntoma e "por que rompeu" fala da causa. A táboa seguinte mostra exemplos de tales conexións.
Un síntoma
Motivo
Obtención do erro HTTP 500 ou 404
Os servidores de bases de datos rexeitan conexións
Respostas lentas do servidor
Alta utilización da CPU ou cable Ethernet danado
Os usuarios da Antártida non están recibindo GIF de gatos
O teu CDN odia aos científicos e aos gatos, polo que algúns enderezos IP acabaron na lista negra
O contido privado está dispoñible en todas partes
O lanzamento dunha nova versión de software fixo que o firewall esquecese todas as ACL e permitise entrar a todos
"Que" e "por que" son algúns dos elementos máis importantes para crear un bo sistema de vixilancia co máximo sinal e o mínimo ruído.
Caixa negra vs caixa branca
Combinamos unha ampla supervisión de caixa branca coa monitorización modesta de caixa negra para métricas críticas. A forma máis sinxela de comparar a caixa negra coa caixa branca é que a caixa negra está centrada nos síntomas e é reactiva en lugar de monitorizar proactivamente: "o sistema non funciona correctamente agora mesmo". A caixa branca depende das capacidades de verificación interna dos sistemas: rexistros de eventos ou servidores web. Así, White-box permite detectar problemas inminentes, fallos que parecen ser unha retransmisión dunha solicitude, etc.
Teña en conta que nun sistema multicapa, un síntoma na área de responsabilidade dun enxeñeiro é un síntoma na área de responsabilidade doutro enxeñeiro. Por exemplo, o rendemento da base de datos diminuíu. As lecturas lentas da base de datos son un síntoma do SRE da base de datos que as detecta. Non obstante, para un SRE front-end que observa un sitio web lento, a causa da mesma lectura lenta da base de datos é unha base de datos lenta. Polo tanto, a vixilancia da caixa branca está ás veces centrada nos síntomas e ás veces na causa, dependendo da extensión que sexa.
Ao recoller a telemetría para a depuración, é necesario o seguimento da caixa branca. Se os servidores web tardan en responder ás consultas da base de datos, cómpre saber a rapidez con que se comunica o servidor web coa base de datos e a rapidez con que responde. En caso contrario, non poderás diferenciar entre un servidor de base de datos lento e un problema de rede entre o servidor web e a base de datos.
A vixilancia da caixa negra ten unha vantaxe fundamental ao enviar alertas: activas a notificación ao destinatario cando o problema xa provocou síntomas reais. Por outra banda, a vixilancia non serve para un problema de caixa negra que aínda non xurdiu pero que é inminente.
Catro sinais de ouro
Os catro sinais de vixilancia dourados son a latencia, o tráfico, os erros e a saturación. Se só podes medir catro métricas do sistema de usuarios, concéntrate nesas catro.
Atraso
O tempo necesario para tramitar a solicitude. É importante distinguir entre a latencia de solicitudes exitosas e non exitosas. Por exemplo, un erro HTTP 500 causado por unha perda de conexión a unha base de datos ou outro backend pódese diagnosticar moi rapidamente, pero un erro HTTP 500 pode indicar unha solicitude fallida. Determinar o impacto dun erro 500 na latencia xeral pode levar a conclusións erróneas. Por outra banda, un erro lento é mesmo un erro rápido! Polo tanto, é importante supervisar a latencia dos erros en lugar de simplemente filtrar os erros.
tráfico
O número de solicitudes ao teu sistema mídese en métricas do sistema de alto nivel. Para un servizo web, esta medida normalmente representa o número de solicitudes HTTP por segundo, dividido pola natureza das solicitudes (por exemplo, contido estático ou dinámico). Para un sistema de transmisión de audio, esta medida pode centrarse na velocidade de E/S da rede ou no número de sesións simultáneas. Para un sistema de almacenamento de clave-valor, esta medición pode ser transaccións ou resultados de busca por segundo.
Erros
Esta é a taxa de solicitudes erradas que son explícitas (por exemplo, HTTP 500), implícitas (por exemplo, HTTP 200 pero combinadas con contido non válido) ou políticas (por exemplo, "Se capturou unha resposta nun segundo, calquera segundo é un erro"). Se os códigos de resposta HTTP non son suficientes para expresar todas as condicións de fallo, poden ser necesarios protocolos secundarios (internos) para detectar fallos parciales. O seguimento de todas esas solicitudes erradas pode non ser informativo, mentres que as probas do sistema de extremo a extremo axudarán a detectar que estás procesando contido incorrecto.
Saturación
A métrica mostra a intensidade de uso do teu servizo. Esta é unha medida de monitorización do sistema que identifica os recursos que están máis restrinxidos (por exemplo, nun sistema con restricións de memoria, mostra a memoria, nun sistema con restricións de E/S, mostra o número de E/S). Teña en conta que moitos sistemas degradan o rendemento antes de acadar o 100 % de utilización, polo que é importante ter un obxectivo de utilización.
En sistemas complexos, a saturación pódese complementar con medicións de carga de nivel superior: pode o seu servizo xestionar correctamente o dobre tráfico, xestionar só un 10 % máis de tráfico ou xestionar aínda menos tráfico do que o fai actualmente? Para servizos sinxelos que non teñen parámetros que cambien a complexidade da solicitude (por exemplo, "Non me deas nada" ou "Necesito un único número enteiro monotónico único"), que raramente cambian de configuración, un valor de proba de carga estática pode ser adecuado. Non obstante, como se comentou no parágrafo anterior, a maioría dos servizos deben utilizar sinais indirectos como a utilización da CPU ou o ancho de banda da rede, que teñen un límite superior coñecido. O aumento da latencia adoita ser un indicador principal de saturación. Medir o tempo de resposta do percentil 99 nunha pequena ventá (por exemplo, un minuto) pode proporcionar un sinal de saturación moi precoz.
Finalmente, a saturación tamén se asocia con predicións sobre a saturación inminente, por exemplo: "Parece que a túa base de datos encherá o teu disco duro en 4 horas".
Se mide os catro sinais de ouro e cando hai un problema cunha das métricas (ou, no caso de saturación, un problema próximo), avisas a unha persoa, o teu servizo estará máis ou menos cuberto pola monitorización.
Preocupacións pola "cola" (ou instrumentación e rendemento)
Ao crear un sistema de monitorización desde cero, existe a tentación de desenvolver un sistema baseado en valores medios: latencia media, utilización media da CPU dos nodos ou plenitude media da base de datos. O perigo dos dous últimos exemplos é obvio: os procesadores e as bases de datos son eliminados dun xeito moi imprevisible. O mesmo aplícase ao atraso. Se executas un servizo web cunha latencia media de 100 ms con 1000 solicitudes por segundo, o 1 % das solicitudes pode tardar 5 segundos. Se os usuarios dependen de varios destes servizos web, o percentil 99 dun backend pode converterse facilmente no tempo medio de resposta do frontend.
A forma máis sinxela de diferenciar a media lenta e a cola moi lenta das solicitudes é recoller medicións das solicitudes expresadas en estatísticas (unha boa ferramenta para mostrar son os histogramas) en lugar de latencias reais: cantas solicitudes atendeu o servizo que levaron entre 0 ms. e 10 ms, entre 10 ms e 30 ms, entre 30 ms e 100 ms, entre 100 ms e 300 ms, etc. Ampliar os límites do histograma de forma aproximadamente exponencial (por un factor aproximado de 3) adoita ser un xeito sinxelo de visualizar a distribución. de solicitudes.
Selección do nivel de detalle adecuado para as medicións
Distintos elementos do sistema deben medirse en diferentes niveis de detalle. Por exemplo:
- O seguimento da utilización da CPU durante un período de tempo non mostrará picos a longo prazo que conduzan a altas latencias.
- Por outra banda, para un servizo web que teña como obxectivo non máis de 9 horas de inactividade ao ano (99,9 % de tempo de actividade anual), é probable que a comprobación dunha resposta HTTP 200 máis dunha ou dúas veces por minuto sexa innecesariamente frecuente.
- Do mesmo xeito, probabelmente non sexa necesario comprobar o espazo do disco duro para comprobar a dispoñibilidade do 99,9 % máis dunha vez cada 1-2 minutos.
Teña coidado na forma en que estruturas a granularidade das túas medidas. Recoller a carga da CPU unha vez por segundo pode proporcionar datos interesantes, pero as medicións tan frecuentes poden ser moi caras de recoller, almacenar e analizar. Se o teu obxectivo de seguimento require unha granularidade elevada e non require unha alta capacidade de resposta, podes reducir estes custos configurando a recollida de métricas no servidor e, a continuación, configurando un sistema externo para recoller e agregar esas métricas. Poderías:
- Mida a carga da CPU cada segundo.
- Reducir o detalle ao 5%.
- Agrega métricas cada minuto.
Esta estratexia permitirache recoller datos cunha granularidade elevada sen incorrer en grandes gastos de análise e almacenamento.
O máis sinxelo posible, pero non máis sinxelo
A superposición de diferentes requisitos uns sobre outros pode dar lugar a un sistema de vixilancia moi complexo. Por exemplo, o seu sistema pode ter os seguintes elementos complicados:
- Alertas segundo distintos limiares de latencia de tramitación de solicitudes, en distintos percentiles, para todo tipo de distintos indicadores.
- Escribir código adicional para detectar e identificar posibles causas.
- Crea paneis relacionados para cada unha das posibles causas dos problemas.
As fontes de posibles complicacións non terminan nunca. Como todos os sistemas de software, a supervisión pode chegar a ser tan complexa que se fai fráxil e difícil de cambiar e manter.
Polo tanto, deseña o teu sistema de monitorización para simplificalo o máximo posible. Ao elixir o que facer un seguimento, teña en conta o seguinte:
- As regras que adoitan capturar incidentes reais deben ser o máis sinxelas, previsibles e fiables posible.
- Débese eliminar a configuración para a recollida, agregación e alertas de datos que se realizan con pouca frecuencia (por exemplo, con periodicidade inferior ao trimestre para algúns equipos de SRE).
- As métricas que se recompilan pero que non se mostran en ningún panel de vista previa ou que se usan por ningunha alerta son candidatas á eliminación.
En Google, a recollida e agregación de métricas básicas, combinadas con alertas e paneis de control, funcionan ben como un sistema relativamente autónomo (o sistema de vixilancia de Google en realidade está dividido en varios subsistemas, pero a xente normalmente coñece todos os aspectos destes subsistemas). Pode ser tentador combinar a vixilancia con outras técnicas para examinar sistemas complexos: perfís de sistemas detallados, depuración de procesos, seguimento de detalles sobre excepcións ou fallos, probas de carga, recollida e análise de rexistros ou inspección de tráfico. Aínda que a maioría destas cousas teñen en común coa vixilancia básica, mesturalas producirá demasiados resultados e creará un sistema complexo e fráxil. Como ocorre con moitos outros aspectos do desenvolvemento de software, a mellor estratexia é soportar diferentes sistemas con puntos de integración claros, sinxelos e pouco acoplados (por exemplo, usar unha API web para recuperar datos agregados nun formato que poida permanecer consistente durante un longo período de tempo). ).
Unir os principios
Os principios que se analizan neste capítulo pódense combinar nunha filosofía de seguimento e alerta que avalan e seguen os equipos de Google SRE. Adherirse a esta filosofía de seguimento é desexable, é un bo punto de partida para crear ou revisar a súa metodoloxía de alerta e pode axudarche a facer as preguntas correctas da súa función de operacións, independentemente do tamaño da súa organización ou da complexidade do servizo ou sistema.
Ao crear regras de seguimento e alerta, facer as seguintes preguntas pode axudarche a evitar falsos positivos e alertas innecesarias:
- Detecta esta regra un estado indetectable do sistema que é urxente, que chama á acción e que inevitablemente afecta ao usuario?
- Podo ignorar esta advertencia sabendo que é benigna? Cando e por que podo ignorar esta advertencia e como podo evitar este escenario?
- Significa esta alerta que os usuarios están sendo afectados negativamente? Hai situacións nas que os usuarios non se ven afectados negativamente, como a través do filtrado de tráfico ou cando se usan sistemas de proba para os que se deben filtrar as alertas?
- Podo tomar medidas en resposta a esta alerta? Son estas medidas urxentes ou poden esperar á mañá? Pódese automatizar unha acción de forma segura? Esta acción será unha solución a longo prazo ou unha solución a curto prazo?
- Algunhas persoas reciben varias alertas por este problema, entón hai algunha forma de reducir o número de alertas?
Estas preguntas reflicten a filosofía fundamental dos sistemas de alertas e avisos:
- Cada vez que chega unha alerta, teño que reaccionar inmediatamente. Podo reaccionar con urxencia varias veces ao día antes de que me canse.
- Cada alerta debe ser relevante.
- Toda resposta a unha alerta debe requirir a intervención humana. Se a notificación se pode procesar automaticamente, non debería chegar.
- As alertas deben tratarse dun novo problema ou evento que non existía antes.
Este enfoque difumina certas distincións: se a alerta cumpre as catro condicións anteriores, non importa se a alerta se envía desde un sistema de monitorización de caixa branca ou caixa negra. Este enfoque tamén reforza certas diferenzas: é mellor dedicar moito máis esforzo á identificación dos síntomas que ás causas; cando se trata de causas, só hai que preocuparse polas causas inevitables.
Seguimento a longo prazo
Nos entornos de produtividade actuais, os sistemas de monitorización monitorizan un sistema de produción en constante evolución cunha arquitectura de software, características de carga de traballo e obxectivos de rendemento cambiantes. As alertas que actualmente son difíciles de automatizar poden chegar a ser habituais, quizais ata merecen a pena abordalas. Neste punto, alguén debe atopar e eliminar as causas raíz do problema; se tal resolución non é posible, a resposta á alerta require unha automatización total.
É importante que as decisións de seguimento se tomen tendo en conta obxectivos a longo prazo. Cada alerta que se executa hoxe distrae a unha persoa de mellorar o sistema de mañá, polo que adoita producirse unha redución na dispoñibilidade ou o rendemento dun sistema produtivo durante o tempo necesario para mellorar o sistema de vixilancia a longo prazo. Vexamos dous exemplos para ilustrar este fenómeno.
Bigtable SRE: A Tale of Over-Alert
A infraestrutura interna de Google adoita aprovisionarse e medirse en función dun nivel de servizo (SLO). Hai moitos anos, o servizo SLO de Bigtable baseábase no rendemento medio dunha transacción sintética que simulaba un cliente en directo. Debido a problemas en Bigtable e aos niveis máis baixos da pila de almacenamento, o rendemento medio foi impulsado por unha cola "gran": o peor 5 % das consultas adoitaba ser significativamente máis lenta que o resto.
Enviáronse notificacións por correo electrónico cando se achegaba ao limiar do SLO e enviáronse alertas de mensaxería cando se superaba o SLO. Ambos tipos de alertas enviáronse con bastante frecuencia, consumindo cantidades inaceptables de tempo de enxeñería: o equipo pasou unha cantidade significativa de tempo clasificando as alertas para atopar as poucas que eran realmente relevantes. Moitas veces perdemos un problema que realmente afectaba aos usuarios porque só algunhas das alertas eran para ese problema específico. Moitas das alertas non eran urxentes por problemas comprensibles na infraestrutura e tramitáronse de forma normalizada, ou non se tramitaron en absoluto.
Para remediar a situación, o equipo adoptou un enfoque de tres liñas: mentres traballamos duro para mellorar o rendemento de Bigtable, establecemos temporalmente o noso obxectivo de SLO para que sexa o percentil 75 para a latencia de resposta ás consultas. Tamén desactivamos as alertas por correo electrónico porque había tantas que era imposible pasar o tempo diagnosticándoas.
Esta estratexia permitiunos comezar a solucionar problemas a longo prazo en Bigtable e nos niveis máis baixos da pila de almacenamento, en lugar de solucionar problemas tácticos constantemente. Os enxeñeiros poderían realmente facer o traballo sen ser bombardeados con alertas todo o tempo. En definitiva, o aprazamento temporal do procesamento de alertas permitiunos mellorar a calidade do noso servizo.
Gmail: respostas humanas algorítmicas e previsibles
No seu inicio, Gmail construíuse sobre un sistema de xestión de procesos de Workqueue modificado que foi deseñado para procesar por lotes partes dun índice de busca. Workqueue adaptouse a procesos de longa duración e aplicouse posteriormente a Gmail, pero algúns erros no código opaco do programador resultaron moi difíciles de corrixir.
Nese momento, a vixilancia de Gmail estruturábase para que as alertas se activasen cando se cancelasen tarefas individuais mediante Workqueue. Este enfoque non era o ideal, porque mesmo naquel momento, Gmail realizaba moitos miles de tarefas, cada unha das cales era proporcionada a unha fracción dun por cento dos nosos usuarios. Preocupábamos moito ofrecer aos usuarios de Gmail unha boa experiencia de usuario, pero o manexo de tantas alertas estaba fóra do alcance.
Para solucionar este problema, Gmail SRE creou unha ferramenta para axudar a depurar o planificador o mellor posible para minimizar o impacto nos usuarios. O equipo tivo algunhas discusións sobre se simplemente automatizar o ciclo completo desde o descubrimento do problema ata a solución ata que se atopaba unha solución a longo prazo, pero algúns estaban preocupados de que esa solución atrasaría realmente a solución do problema.
Esta tensión era común no equipo e moitas veces reflectía unha falta de confianza na autodisciplina: mentres que algúns membros do equipo queren dar tempo para a corrección correcta, outros temen que a solución definitiva se esqueza e a corrección temporal levará para sempre. Este problema merece atención porque é demasiado fácil solucionar os problemas temporalmente en lugar de facer a situación permanente. Os xestores e o persoal técnico xogan un papel fundamental na implementación de correccións a longo prazo, apoiando e priorizando as solucións potencialmente a longo prazo mesmo despois de que a "dor" inicial diminúa.
As alertas regulares e repetitivas e as respostas algorítmicas deberían ser unha bandeira vermella. A reticencia do teu equipo a automatizar estas alertas significa que o equipo non confía en poder confiar nos algoritmos. Este é un problema grave que hai que abordar.
Largo prazo
Un tema común vincula os exemplos de Bigtable e Gmail: a competencia entre a dispoñibilidade a curto prazo e a longo prazo. Moitas veces, un forte esforzo pode axudar a que un sistema fráxil consiga unha alta dispoñibilidade, pero este camiño adoita ser de curta duración, cheo de esgotamento do equipo e dependencia dun pequeno número de membros dese mesmo equipo heroico.
A redución controlada e a curto prazo da dispoñibilidade adoita ser dolorosa, pero estratexicamente importante para a estabilidade a longo prazo do sistema. É importante non mirar cada alerta de forma illada, senón considerar se o nivel global de volume de alerta conduce a un sistema saudable e debidamente accesible, cun equipo viable e un prognóstico favorable. Analizamos as estatísticas de frecuencia de alertas (xeralmente expresadas como incidentes por quenda, onde un incidente pode consistir en múltiples incidentes relacionados) en informes trimestrais á dirección, o que permite aos responsables de tomar decisións ter unha visión continua da carga do sistema de alertas e da saúde xeral do equipo.
Conclusión
O camiño cara a un seguimento e alerta saudables é sinxelo e claro. Céntrase nos síntomas do problema que desencadean as alertas e o seguimento da causa serve como axuda para depurar problemas. O seguimento dos síntomas é máis sinxelo canto máis alto estea na pila que controla, aínda que o seguimento da carga e do rendemento da base de datos debería facerse directamente na propia base de datos. As notificacións por correo electrónico teñen unha utilidade moi limitada e tenden a converterse facilmente en ruído; en vez diso, deberías usar un panel de control que supervisa todos os problemas actuais que desencadean alertas por correo electrónico. O panel tamén se pode vincular cun rexistro de eventos para analizar as correlacións históricas.
A longo prazo, é necesario conseguir unha rotación exitosa de alertas sobre síntomas e problemas reais inminentes, adaptando os obxectivos para garantir que o seguimento admita un diagnóstico rápido.
Grazas por ler a tradución ata o final. Subscríbete á miña canle de Telegram sobre seguimento и .
Fonte: www.habr.com