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 tradución do capítulo 6 do mesmo libro sobre os obxectivos do nivel de servizo.
Tradución por cat. Disfruta da lectura!
É imposible xestionar un servizo se non se entende que indicadores realmente importan e como medilos e avalialos. Para iso, definimos e proporcionamos un certo nivel de servizo aos nosos usuarios, independentemente de que utilicen unha das nosas API internas ou un produto público.
Usamos a nosa intuición, experiencia e comprensión do desexo dos usuarios de comprender os indicadores de nivel de servizo (SLI), os obxectivos de nivel de servizo (SLO) e os acordos de nivel de servizo (SLA). Estas dimensións describen as principais métricas que queremos supervisar e ás que reaccionaremos se non podemos ofrecer a calidade de servizo esperada. En definitiva, elixir as métricas correctas axuda a guiar as accións correctas se algo sae mal e tamén dá ao equipo SRE confianza na saúde do servizo.
Este capítulo describe o enfoque que usamos para combater os problemas de modelado métrico, selección de métricas e análise de métricas. A maior parte da explicación será sen exemplos, polo que utilizaremos o servizo Shakespeare descrito no seu exemplo de implementación (busca de obras de Shakespeare) para ilustrar os puntos principais.
Terminoloxía do nivel de servizo
Moitos lectores probablemente estean familiarizados co concepto de SLA, pero os termos SLI e SLO merecen unha definición coidadosa porque, en xeral, o termo SLA está sobrecargado e ten varios significados dependendo do contexto. Para claridade, queremos separar estes valores.
Indicadores
O SLI é un indicador de nivel de servizo: unha medida cuantitativa coidadosamente definida dun aspecto do nivel de servizo prestado.
Para a maioría dos servizos, o SLI clave considérase que é a latencia da solicitude: o tempo que leva devolver unha resposta a unha solicitude. Outros SLI comúns inclúen a taxa de erros, a miúdo expresada como unha fracción de todas as solicitudes recibidas, e o rendemento do sistema, medido normalmente en solicitudes por segundo. As medicións adoitan agregarse: primeiro recóllense os datos en bruto e despois convértense nunha taxa de cambio, media ou percentil.
Idealmente, SLI mide directamente o nivel de servizo de interese, pero ás veces só se pode medir unha métrica relacionada porque a orixinal é difícil de obter ou interpretar. Por exemplo, a latencia do cliente adoita ser unha métrica máis adecuada, pero hai momentos nos que a latencia só se pode medir no servidor.
Outro tipo de SLI que é importante para os SRE é a dispoñibilidade, ou a parte de tempo durante a que se pode usar un servizo. Moitas veces defínese como a taxa de solicitudes exitosas, ás veces chamada rendemento. (A vida útil (a probabilidade de que os datos se conserven durante un período prolongado de tempo) tamén é importante para os sistemas de almacenamento de datos.) Aínda que non é posible o 100 % de dispoñibilidade, a miúdo pódese conseguir unha dispoñibilidade próxima ao 100 %; os valores de dispoñibilidade exprésanse como o número de "nove" » porcentaxe de dispoñibilidade. Por exemplo, a dispoñibilidade do 99 % e do 99,999 % podería etiquetarse como "2 nove" e "5 nove". O obxectivo actual de dispoñibilidade de Google Compute Engine é "tres nove e medio" ou 99,95 %.
Obxectivos
Un SLO é un obxectivo de nivel de servizo: un valor obxectivo ou rango de valores para un nivel de servizo que se mide polo SLI. Un valor normal para SLO é "SLI ≤ Target" ou "Lower Limit ≤ SLI ≤ Upper Limit". Por exemplo, podemos decidir que devolveremos os resultados da busca de Shakespeare "rápido" configurando o SLO nunha latencia media de consulta de busca inferior a 100 milisegundos.
Elixir o SLO correcto é un proceso complexo. En primeiro lugar, non sempre pode escoller un valor específico. Para as solicitudes HTTP entrantes externas ao teu servizo, a métrica de Consulta por segundo (QPS) está determinada principalmente polo desexo dos usuarios de visitar o teu servizo e non podes establecer un SLO para iso.
Por outra banda, pode dicir que quere que a latencia media para cada solicitude sexa inferior a 100 milisegundos. Establecer tal obxectivo pode obrigarche a escribir o teu frontend cunha latencia baixa ou mercar equipos que proporcionen esa latencia. (100 milisegundos é obviamente un número arbitrario, pero é mellor ter números de latencia aínda máis baixos. Hai evidencias que suxiren que as velocidades rápidas son mellores que as lentas e que a latencia no procesamento de solicitudes dos usuarios por riba de determinados valores obriga ás persoas a manterse lonxe. do seu servizo.)
De novo, isto é máis ambiguo do que podería parecer a primeira vista: non debes excluír completamente a QPS do cálculo. O feito é que o QPS e a latencia están moi relacionados entre si: un QPS máis elevado adoita levar a latencias máis altas, e os servizos adoitan experimentar unha forte diminución do rendemento cando alcanzan un determinado limiar de carga.
A selección e publicación dun SLO establece as expectativas dos usuarios sobre como funcionará o servizo. Esta estratexia pode reducir as queixas infundadas contra o propietario do servizo, como un rendemento lento. Sen un SLO explícito, os usuarios adoitan crear as súas propias expectativas sobre o rendemento desexado, que poden non ter nada que ver coas opinións das persoas que deseñan e xestionan o servizo. Esta situación pode provocar un aumento das expectativas do servizo, cando os usuarios cren erróneamente que o servizo será máis accesible do que realmente é, e provocar desconfianza cando os usuarios cren que o sistema é menos fiable do que realmente é.
Acordos
Un acordo de nivel de servizo é un contrato explícito ou implícito cos teus usuarios que inclúe as consecuencias de cumprir (ou non cumprir) os SLO que conteñen. As consecuencias recoñécense máis facilmente cando son económicas (un desconto ou unha multa), pero poden adoptar outras formas. Unha forma sinxela de falar sobre a diferenza entre os SLO e os SLA é preguntar "que pasa se non se cumpren os SLO?" Se non hai consecuencias claras, case seguro que estás mirando un SLO.
O SRE normalmente non participa na creación de SLA porque os SLA están estreitamente vinculados ás decisións comerciais e dos produtos. O SRE, con todo, está implicado en axudar a mitigar as consecuencias dos SLO fallidos. Tamén poden axudar a determinar o SLI: Obviamente, debe haber unha forma obxectiva de medir o SLO no acordo ou haberá desacordo.
A Busca de Google é un exemplo dun servizo importante que non ten un SLA público: queremos que todos usen a Busca da forma máis eficiente posible, pero non asinamos ningún contrato co mundo. Non obstante, aínda hai consecuencias se a busca non está dispoñible: a indisponibilidade provoca unha caída na nosa reputación e unha redución dos ingresos publicitarios. Moitos outros servizos de Google, como Google for Work, teñen acordos explícitos de nivel de servizo cos usuarios. Independentemente de que un servizo en particular teña un SLA, é importante definir o SLI e o SLO e utilizalos para xestionar o servizo.
Tanta teoría - agora a experimentar.
Indicadores na práctica
Dado que chegamos á conclusión de que é importante seleccionar as métricas adecuadas para medir o nivel de servizo, como sabe agora cales son as métricas importantes para un servizo ou sistema?
Que che importa a ti e aos teus usuarios?
Non precisa utilizar todas as métricas como un SLI que pode rastrexar nun sistema de monitorización; Comprender o que queren os usuarios dun sistema axudarache a seleccionar varias métricas. Escoller demasiados indicadores dificulta centrarse nos indicadores importantes, mentres que escoller un número pequeno pode deixar desatendidos grandes partes do seu sistema. Normalmente usamos varios indicadores clave para avaliar e comprender a saúde dun sistema.
Os servizos xeralmente pódense dividir en varias partes en termos de SLI que sexan relevantes para eles:
- Sistemas front-end personalizados, como as interfaces de busca para o servizo Shakespeare do noso exemplo. Deben estar dispoñibles, non ter atrasos e ter suficiente ancho de banda. En consecuencia, pódense facer preguntas: podemos responder á solicitude? Canto tempo tardou en responder á solicitude? Cantas solicitudes se poden tramitar?
- Sistemas de almacenamento. Valoran a baixa latencia de resposta, dispoñibilidade e durabilidade. Preguntas relacionadas: canto tempo leva ler ou escribir datos? Podemos acceder aos datos previa solicitude? Os datos están dispoñibles cando o necesitamos? Consulte o Capítulo 26 Integridade dos datos: o que le é o que escribe para unha discusión detallada destes problemas.
- Os sistemas de big data, como as canalizacións de procesamento de datos, dependen do rendemento e da latencia de procesamento de consultas. Preguntas relacionadas: Cantos datos se procesan? Canto tempo tardan en viaxar os datos desde a recepción dunha solicitude ata a emisión dunha resposta? (Algunhas partes do sistema tamén poden ter atrasos en determinadas etapas).
Recollida de indicadores
Moitos indicadores de nivel de servizo recóllense de forma máis natural no lado do servidor, utilizando un sistema de vixilancia como Borgmon (ver máis abaixo). ) ou Prometheus, ou simplemente analizando periodicamente os rexistros, identificando as respostas HTTP co estado 500. Non obstante, algúns sistemas deberían estar equipados con recollida de métricas do lado do cliente, xa que a falta de seguimento do lado do cliente pode levar a perder unha serie de problemas que afectan usuarios, pero non afectan as métricas do servidor. Por exemplo, centrarse na latencia de resposta do backend da nosa aplicación de proba de busca de Shakespeare pode producir latencia no lado do usuario debido a problemas de JavaScript: neste caso, medir o tempo que tarda o navegador en procesar a páxina é unha métrica mellor.
Agregación
Por simplicidade e facilidade de uso, moitas veces agregamos medicións en bruto. Isto debe facerse con coidado.
Algunhas métricas parecen sinxelas, como as solicitudes por segundo, pero incluso esta medida aparentemente sinxela agrega datos implícitamente ao longo do tempo. A medición recíbese especificamente unha vez por segundo ou promedia o número de solicitudes por minuto? Esta última opción pode ocultar un número instantáneo moito maior de solicitudes que só duran uns segundos. Considere un sistema que atende 200 solicitudes por segundo con números pares e 0 o resto do tempo. Non é o mesmo unha constante en forma de valor medio de 100 solicitudes por segundo e o dobre da carga instantánea. Do mesmo xeito, a media das latencias de consulta pode parecer atractiva, pero oculta un detalle importante: é posible que a maioría das consultas sexan rápidas, pero haberá moitas consultas lentas.
A maioría dos indicadores vense mellor como distribucións que como medias. Por exemplo, para a latencia SLI, algunhas solicitudes procesaranse rapidamente, mentres que algunhas sempre tardarán máis, ás veces moito máis. Unha media simple pode ocultar estes longos atrasos. A figura mostra un exemplo: aínda que unha solicitude típica tarda aproximadamente 50 ms en servir, o 5 % das solicitudes son 20 veces máis lentas. O seguimento e as alertas baseadas só na latencia media non mostran cambios no comportamento ao longo do día, cando en realidade hai cambios notables no tempo de procesamento dalgunhas solicitudes (liña superior).
Latencia do sistema porcentual 50, 85, 95 e 99. O eixe Y está en formato logarítmico.
O uso de percentiles para os indicadores permite ver a forma da distribución e as súas características: un nivel percentil alto, como 99 ou 99,9, mostra o peor valor, mentres que o percentil 50 (tamén coñecido como mediana) mostra o estado máis frecuente de a métrica. Canto maior sexa a dispersión do tempo de resposta, máis as solicitudes de longa duración afectan a experiencia do usuario. O efecto realízase baixo carga elevada e en presenza de colas. A investigación sobre a experiencia do usuario mostrou que a xente xeralmente prefire un sistema máis lento con alta variación do tempo de resposta, polo que algúns equipos de SRE céntranse só en puntuacións porcentuais altas, baseándose en que se o comportamento dunha métrica no percentil 99,9 é bo, a maioría dos usuarios non experimentarán problemas. .
Nota sobre erros estatísticos
Xeralmente preferimos traballar con percentiles antes que coa media (media aritmética) dun conxunto de valores. Isto permítenos considerar valores máis dispersos, que a miúdo teñen características significativamente diferentes (e máis interesantes) que a media. Debido á natureza artificial dos sistemas informáticos, os valores métricos adoitan estar sesgados, por exemplo, ningunha solicitude pode recibir unha resposta en menos de 0 ms, e un tempo de espera de 1000 ms significa que non pode haber respostas exitosas con valores maiores. que o tempo de espera. Como resultado, non podemos aceptar que a media e a mediana poidan ser iguais ou próximas unha á outra!
Sen probas previas, e a menos que se cumpran determinadas suposicións e aproximacións estándar, temos coidado de non concluír que os nosos datos se distribúen normalmente. Se a distribución non é a esperada, o proceso de automatización que soluciona o problema (por exemplo, cando ve valores atípicos, reinicia o servidor con altas latencias de procesamento de solicitudes) pode estar a facelo con demasiada frecuencia ou non o suficiente (ambos non son moi ben).
Normalizar os indicadores
Recomendamos estandarizar as características xerais para SLI para que non teñas que especular sobre elas cada vez. Calquera característica que satisfaga os patróns estándar pode excluírse da especificación dun SLI individual, por exemplo:
- Intervalos de agregación: "promedio de máis de 1 minuto"
- Áreas de agregación: "Todas as tarefas do clúster"
- Con que frecuencia se toman medidas: "Cada 10 segundos"
- Que solicitudes se inclúen: "HTTP GET de traballos de vixilancia da caixa negra"
- Como se obteñen os datos: "Grazas ao noso seguimento medido no servidor"
- Latencia de acceso a datos: "Tempo ata o último byte"
Para aforrar esforzo, cree un conxunto de modelos SLI reutilizables para cada métrica común; tamén facilitan que todos entendan o que significa un determinado SLI.
Obxectivos na práctica
Comeza por pensar (ou descubrir!) o que lles importa aos teus usuarios, non o que podes medir. Moitas veces o que lles importa aos teus usuarios é difícil ou imposible de medir, polo que acabas achegándote ás súas necesidades. Non obstante, se comezas co que é fácil de medir, acabarás con SLO menos útiles. Como resultado, ás veces descubrimos que identificar inicialmente os obxectivos desexados e despois traballar con indicadores específicos funciona mellor que escoller indicadores e logo acadar os obxectivos.
Define obxectivos
Para a máxima claridade, debería definirse como se miden os SLO e as condicións nas que son válidos. Por exemplo, poderiamos dicir o seguinte (a segunda liña é a mesma que a primeira, pero usa os valores predeterminados de SLI):
- O 99 % (promedio de máis de 1 minuto) das chamadas Get RPC completarase en menos de 100 ms (medido en todos os servidores backend).
- O 99 % das chamadas Get RPC completaranse en menos de 100 ms.
Se a forma das curvas de rendemento é importante, pode especificar varios SLO:
- O 90 % das chamadas Obter RPC completáronse en menos de 1 ms.
- O 99 % das chamadas Obter RPC completáronse en menos de 10 ms.
- O 99.9 % das chamadas Obter RPC completáronse en menos de 100 ms.
Se os seus usuarios xeran cargas de traballo heteroxéneas: procesamento masivo (para o que o rendemento é importante) e procesamento interactivo (para o que a latencia é importante), pode valer a pena definir obxectivos separados para cada clase de carga:
- O 95% das solicitudes dos clientes requiren un rendemento. Establece o reconto de chamadas RPC executadas <1 s.
- O 99% dos clientes preocúpase pola latencia. Establece o reconto de chamadas RPC con tráfico <1 KB e en execución <10 ms.
Non é realista e indesexable insistir en que os SLO se cumprirán o 100 % das veces: isto pode reducir o ritmo de introdución de novas funcionalidades e implantación e requirir solucións caras. Pola contra, é mellor permitir un orzamento de erro -a porcentaxe de tempo de inactividade do sistema permitido- e supervisar este valor diaria ou semanalmente. A alta dirección pode querer avaliacións mensuais ou trimestrais. (O orzamento de erro é simplemente un SLO para comparalo con outro SLO).
A porcentaxe de infraccións do SLO pódese comparar co orzamento de erros (consulte o capítulo 3 e a sección ), co valor da diferenza usado como entrada para o proceso que decide cando despregar as novas versións.
Selección de valores obxectivo
A selección de valores de planificación (SLO) non é unha actividade puramente técnica debido aos intereses do produto e do negocio que deben reflectirse nos SLI, SLO (e posiblemente SLA) seleccionados. Así mesmo, pode ter que intercambiar información sobre cuestións relacionadas co persoal, o tempo de comercialización, a dispoñibilidade de equipos e o financiamento. SRE debería formar parte desta conversa e axudar a comprender os riscos e a viabilidade das diferentes opcións. Creamos algunhas preguntas que poden axudar a garantir unha discusión máis produtiva:
Non elixas un obxectivo baseado no rendemento actual.
Aínda que comprender os puntos fortes e os límites dun sistema é importante, adaptar métricas sen razoar pode impedir o mantemento do sistema: requirirá esforzos heroicos para acadar obxectivos que non se poden acadar sen un rediseño significativo.
Sexa sinxelo
Os cálculos complexos de SLI poden ocultar cambios no rendemento do sistema e dificultar atopar a causa do problema.
Evita os absolutos
Aínda que é tentador ter un sistema que poida xestionar unha carga indefinidamente crecente sen aumentar a latencia, este requisito non é realista. Un sistema que se aproxime a tales ideais probablemente requirirá moito tempo para deseñar e construír, será caro de operar e será demasiado bo para as expectativas dos usuarios que farían con algo menos.
Use o menor número posible de SLO
Seleccione un número suficiente de SLO para garantir unha boa cobertura dos atributos do sistema. Protexa os SLO que escolla: se nunca pode gañar unha discusión sobre prioridades especificando un SLO específico, probablemente non valga a pena considerar ese SLO. Non obstante, non todos os atributos do sistema son susceptibles de SLO: é difícil calcular o nivel de satisfacción do usuario usando SLO.
Non persigas a perfección
Sempre pode refinar as definicións e obxectivos dos SLO ao longo do tempo a medida que aprende máis sobre o comportamento do sistema baixo carga. É mellor comezar cun obxectivo flotante que vai perfeccionando co paso do tempo que elixir un obxectivo demasiado estrito que ten que relaxarse cando cre que é inalcanzable.
Os SLO poden e deben ser un motor clave para priorizar o traballo dos SRE e dos desenvolvedores de produtos porque reflicten unha preocupación para os usuarios. Un bo SLO é unha ferramenta de aplicación útil para un equipo de desenvolvemento. Pero un SLO mal deseñado pode levar a un traballo despilfarrador se o equipo fai esforzos heroicos para lograr un SLO excesivamente agresivo, ou un produto deficiente se o SLO é demasiado baixo. SLO é unha poderosa panca, utilízaa con sabedoría.
Controla as túas medidas
SLI e SLO son elementos clave utilizados para xestionar sistemas:
- Monitorizar e medir sistemas SLI.
- Compare SLI con SLO e decida se é necesaria unha acción.
- Se é necesaria unha acción, descubra o que ten que pasar para acadar o obxectivo.
- Completa esta acción.
Por exemplo, se o paso 2 mostra que a solicitude está a esgotar e romperá o SLO nunhas poucas horas se non se fai nada, o paso 3 pode implicar probar a hipótese de que os servidores están ligados á CPU e engadir máis servidores distribuirá a carga . Sen un SLO, non saberías se (ou cando) tomar medidas.
Establecer SLO; entón estableceranse as expectativas do usuario
A publicación dun SLO establece as expectativas dos usuarios para o comportamento do sistema. Os usuarios (e usuarios potenciais) moitas veces queren saber que esperar dun servizo para entender se é adecuado para o seu uso. Por exemplo, as persoas que queiran utilizar un sitio web para compartir fotos poden querer evitar usar un servizo que prometa lonxevidade e baixo custo a cambio dunha dispoñibilidade lixeiramente menor, aínda que o mesmo servizo pode ser ideal para un sistema de xestión de rexistros de arquivo.
Para establecer expectativas realistas para os teus usuarios, utiliza unha das seguintes tácticas ou as dúas:
- Manter unha marxe de seguridade. Use un SLO interno máis estrito que o que se anuncia aos usuarios. Isto darache a oportunidade de reaccionar aos problemas antes de que sexan visibles externamente. O búfer SLO tamén permite ter unha marxe de seguridade ao instalar versións que afectan o rendemento do sistema e garantir que o sistema sexa fácil de manter sen ter que frustrar aos usuarios co tempo de inactividade.
- Non supere as expectativas dos usuarios. Os usuarios baséanse no que ofreces, non no que dis. Se o rendemento real do teu servizo é moito mellor que o SLO indicado, os usuarios confiarán no rendemento actual. Pode evitar a dependencia excesiva apagando intencionadamente o sistema ou limitando o rendemento con cargas leves.
Entender o que un sistema cumpre coas expectativas axuda a decidir se investir en acelerar o sistema e facelo máis accesible e resistente. Alternativamente, se un servizo está a funcionar demasiado ben, parte do tempo do persoal debería dedicarse a outras prioridades, como pagar a débeda técnica, engadir novas funcións ou introducir novos produtos.
Acordos na práctica
A creación dun SLA require que os equipos empresariais e legais definan as consecuencias e as sancións por violalo. O papel do SRE é axudalos a comprender os probables desafíos para cumprir os SLO contidos no SLA. A maioría das recomendacións para crear SLO tamén se aplican aos SLA. É prudente ser conservador no que prometes aos usuarios porque canto máis teñas, máis difícil será cambiar ou eliminar SLA que parecen pouco razoables ou difíciles de cumprir.
Grazas por ler a tradución ata o final. Subscríbete á miña canle de Telegram sobre seguimento и .
Fonte: www.habr.com