O seminario web ten un audio deficiente, polo que o transcribimos.
Chámome Medvedev Eduard. Hoxe falarei sobre o que é SRE, como apareceu SRE, cales son os criterios de traballo dos enxeñeiros de SRE, un pouco sobre os criterios de fiabilidade, un pouco sobre o seu seguimento. Camiñaremos polas cimas, porque non podes dicir moito nunha hora, pero darei materiais para unha revisión adicional e todos agardámoste. . en Moscova a finais de xaneiro.
En primeiro lugar, imos falar sobre o que é SRE - Site Reliability Engineering. E como apareceu como unha posición separada, como unha dirección separada. Todo comezou co feito de que nos círculos de desenvolvemento tradicionais, Dev e Ops son dous equipos completamente diferentes, normalmente con dous obxectivos completamente diferentes. O obxectivo do equipo de desenvolvemento é lanzar novas funcións e satisfacer as necesidades da empresa. O obxectivo do equipo de Operacións é asegurarse de que todo funciona e non se rompe nada. Obviamente, estes obxectivos se contradín directamente: para que todo funcione e nada se rompa, implemente novas funcións o menos posible. Debido a isto, hai moitos conflitos internos que a metodoloxía que agora se chama DevOps está intentando resolver.
O problema é que non temos unha definición clara de DevOps e unha implementación clara de DevOps. Falei nunha conferencia en Ekaterimburgo hai 2 anos, e ata agora a sección DevOps comezaba co informe "Que é DevOps". En 2017, Devops ten case 10 anos, pero aínda estamos discutindo cal é. E esta é unha situación moi estraña que Google intentou resolver hai uns anos.
En 2016, Google publicou un libro chamado Site Reliability Engineering. E de feito, con este libro comezou o movemento SRE. SRE é unha implementación específica do paradigma DevOps nunha empresa específica. Os enxeñeiros de SRE comprométense a garantir que os sistemas funcionen de forma fiable. Na súa maioría proveñen de desenvolvedores, ás veces de administradores cunha sólida formación en desenvolvemento. E fan o que adoitaban facer os administradores de sistemas, pero unha sólida formación no desenvolvemento e coñecemento do sistema en termos de código leva ao feito de que estas persoas non están inclinadas ao traballo administrativo rutineiro, senón á automatización.
Resulta que o paradigma DevOps nos equipos SRE está implementado polo feito de que hai enxeñeiros SRE que resolven problemas estruturais. Aquí está, a mesma conexión entre Dev e Ops da que a xente leva 8 anos falando. O papel dun SRE é semellante ao dun arquitecto en que os recén chegados non se converten en SRE. As persoas ao comezo da súa carreira non teñen aínda ningunha experiencia, non teñen o coñecemento necesario. Porque SRE require un coñecemento moi sutil de exactamente o que e cando pode saír mal. Polo tanto, aquí é necesaria algunha experiencia, por norma, tanto dentro como fóra da empresa.
Preguntan se se describirá a diferenza entre SRE e devops. Acaba de ser descrita. Podemos falar do lugar da SRE na organización. A diferenza deste enfoque clásico de DevOps, onde Ops aínda é un departamento separado, SRE forma parte do equipo de desenvolvemento. Están implicados no desenvolvemento do produto. Incluso hai un enfoque onde SRE é un papel que pasa dun programador a outro. Participan nas revisións de código do mesmo xeito que, por exemplo, os deseñadores de UX, os propios desenvolvedores, ás veces os xestores de produtos. Os SRE traballan ao mesmo nivel. Hai que aprobalos, hai que revisalos, de xeito que para cada implantación SRE diga: “Está ben, este despregamento, este produto non afectará negativamente á fiabilidade. E se o fai, dentro duns límites aceptables. Tamén falaremos disto.
En consecuencia, a SRE ten un veto para cambiar o código. E, en xeral, isto tamén leva a algún tipo de pequeno conflito se o SRE se implementa incorrectamente. No mesmo libro sobre Enxeñaría de Fiabilidade do Sitio, moitas partes, nin sequera unha, contan como evitar estes conflitos.
Preguntan como se relaciona SRE coa seguridade da información. SRE non está directamente implicado na seguridade da información. Basicamente, nas grandes empresas, isto faise por particulares, probadores, analistas. Pero SRE tamén interactúa con eles no sentido de que algunhas operacións, algúns compromisos, algúns despregamentos que afectan á seguridade tamén poden afectar á dispoñibilidade do produto. Polo tanto, SRE no seu conxunto ten interacción con calquera equipo, incluídos os equipos de seguridade, incluídos os analistas. Polo tanto, os SRE son principalmente necesarios cando intentan implementar DevOps, pero ao mesmo tempo, a carga para os desenvolvedores faise demasiado grande. É dicir, o propio equipo de desenvolvemento xa non pode facer fronte ao feito de que agora tamén teñen que ser responsables de Ops. E hai un papel separado. Este papel está previsto no orzamento. Ás veces, este papel está establecido no tamaño do equipo, aparece unha persoa separada, ás veces un dos desenvolvedores convértese nel. Así aparece o primeiro SRE do equipo.
A complexidade do sistema que se ve afectado pola SRE, a complexidade que afecta á fiabilidade da operación, é necesaria e accidental. A complexidade necesaria é cando a complexidade dun produto aumenta na medida en que o requiren as novas características do produto. A complexidade aleatoria é cando a complexidade do sistema aumenta, pero a función do produto e os requisitos comerciais non afectan directamente a isto. Acontece que ou o desenvolvedor cometeu un erro nalgún lugar, ou o algoritmo non é óptimo ou introdúcense algúns intereses adicionais que aumentan a complexidade do produto sen necesidade especial. Un bo SRE sempre debería cortar esta situación. É dicir, calquera commit, calquera despregamento, calquera solicitude de extracción, onde a dificultade aumente debido á adición aleatoria, debería bloquearse.
A pregunta é por que non só contratar un enxeñeiro, un administrador de sistemas con moito coñecemento no equipo. Un desenvolvedor no papel dun enxeñeiro, dinnos, non é a mellor solución de persoal. Un desenvolvedor no papel dun enxeñeiro non sempre é a mellor solución de persoal, pero o punto aquí é que un programador que se dedica a Operacións ten un pouco máis de desexo de automatización, ten un pouco máis de coñecemento e de habilidades para implementar esta automatización. E en consecuencia, reducimos non só o tempo para algunhas operacións específicas, non só a rutina, senón tamén parámetros empresariais tan importantes como MTTR (Mean Time To Recovery, tempo de recuperación). Así, e disto tamén falaremos un pouco máis adiante, aforramos para a organización.
Agora imos falar dos criterios para o funcionamento do SRE. E en primeiro lugar sobre a fiabilidade. En pequenas empresas, startups, adoita suceder que a xente asume que se o servizo está ben escrito, se o produto está escrito ben e correctamente, funcionará, non se romperá. Iso é todo, escribimos un bo código, polo que non hai nada que romper. O código é moi sinxelo, non hai nada que romper. Son case as mesmas persoas que din que non necesitamos probas, porque, mira, estes son os tres métodos VPI, por que romper aquí.
Todo isto está mal, por suposto. E estas persoas son moitas veces mordidas por tal código na práctica, porque as cousas rompen. As cousas rompen ás veces das formas máis imprevisibles. Ás veces a xente di que non, que nunca pasará. E pasa todo o tempo. Ocorre con suficiente frecuencia. E é por iso que ninguén se esforza por conseguir o 100 % de dispoñibilidade, porque o 100 % de dispoñibilidade nunca ocorre. Esta é a norma. E por iso, cando falamos da dispoñibilidade dun servizo, sempre falamos de nove. 2 nove, 3 nove, 4 nove, 5 nove. Se traducimos isto en tempo de inactividade, entón, por exemplo, 5 nove, entón isto é un pouco máis de 5 minutos de tempo de inactividade ao ano, 2 nove son 3,5 días de tempo de inactividade.
Pero é obvio que nalgún momento hai unha diminución do POI, retorno do investimento. Pasar de dous nove a tres nove significa menos tempo de inactividade en máis de 3 días. Pasar de catro nove a cinco reduce o tempo de inactividade en 47 minutos ao ano. E resulta que para os negocios pode non ser crítico. E, en xeral, a fiabilidade requirida non é un problema técnico, en primeiro lugar, é un problema comercial, é un problema de produto. Que nivel de tempo de inactividade é aceptable para os usuarios do produto, que esperan, canto pagan, por exemplo, canto diñeiro perden, canto diñeiro perde o sistema.
Unha cuestión importante aquí é cal é a fiabilidade dos compoñentes restantes. Porque a diferenza entre 4 e 5 nove non será visible nun teléfono intelixente con 2 nove de fiabilidade. En liñas xerais, se algo se rompe nun teléfono intelixente do teu servizo 10 veces ao ano, o máis probable é que 8 veces a avaría ocorrese no lado do sistema operativo. O usuario está afeito a isto e non lle prestará atención unha vez máis ao ano. É necesario correlacionar o prezo de aumentar a fiabilidade e aumentar os beneficios.
Só no libro sobre SRE hai un bo exemplo de pasar de 4 nove a 3 nove. Resulta que o incremento da dispoñibilidade é algo menos do 0,1%. E se os ingresos do servizo son de 1 millón de dólares ao ano, entón o aumento dos ingresos é de 900 dólares. Se nos custa menos de 900 dólares ao ano aumentar a accesibilidade en nove, o aumento ten sentido financeiro. Se custa máis de 900 dólares ao ano, xa non ten sentido, porque o aumento dos ingresos simplemente non compensa os custos laborais, os custos dos recursos. E 3 nove serán suficientes para nós.
Este é, por suposto, un exemplo simplificado onde todas as solicitudes son iguais. E pasar de 3 nove a 4 nove é bastante sinxelo, pero ao mesmo tempo, por exemplo, pasar de 2 nove a 3, isto xa supón un aforro de 9 mil dólares, pode ter sentido financeiro. Naturalmente, en realidade, o fracaso da solicitude de rexistro é peor que a falla de visualización da páxina, as solicitudes teñen diferentes pesos. Poden ter un criterio completamente diferente desde o punto de vista empresarial, pero de todos os xeitos, por regra xeral, se non falamos dalgúns servizos específicos, esta é unha aproximación bastante fiable.
Recibimos unha pregunta sobre se SRE é un dos coordinadores á hora de escoller unha solución arquitectónica para o servizo. Digamos en canto á integración na infraestrutura existente, para que non se perda a súa estabilidade. Si, os SRE, do mesmo xeito que as solicitudes de pull, commits, releases afectan á arquitectura, á introdución de novos servizos, microservizos, á implantación de novas solucións. Por que dixen antes de que se necesita experiencia, que se necesitan cualificacións. De feito, SRE é unha das voces de bloqueo en calquera solución arquitectónica e de software. En consecuencia, un SRE como enxeñeiro debe, en primeiro lugar, non só comprender, senón tamén comprender como afectarán algunhas decisións específicas á fiabilidade, a estabilidade e comprender como isto se relaciona coas necesidades empresariais e desde que punto de vista pode ser aceptable e aceptable. que non.
Polo tanto, agora só podemos falar de criterios de fiabilidade, que tradicionalmente se definen en SRE como SLA (Service Level Agreement). Probablemente un termo coñecido. SLI (indicador de nivel de servizo). SLO (Obxectivo de nivel de servizo). Acordo de nivel de servizo quizais sexa un termo simbólico, especialmente se traballou con redes, con provedores, con hospedaxe. Este é un acordo xeral que describe o rendemento de todo o teu servizo, sancións, algunhas penalizacións por erros, métricas e criterios. E SLI é a propia métrica de dispoñibilidade. É dicir, o que pode ser o SLI: o tempo de resposta do servizo, o número de erros en porcentaxe. Podería ser ancho de banda se é algún tipo de hospedaxe de ficheiros. Cando se trata de algoritmos de recoñecemento, o indicador pode ser, por exemplo, mesmo a corrección da resposta. O SLO (Service Level Objective) é, respectivamente, unha combinación do indicador SLI, o seu valor e período.
Digamos que o SLA podería ser así. O servizo está dispoñible o 99,95% do tempo durante todo o ano. Ou 99 tickets de soporte crítico pecharanse nun prazo de 3 horas por trimestre. Ou o 85 % das consultas recibirán respostas en 1,5 segundos cada mes. É dicir, pouco a pouco imos entendendo que os erros e fallos son bastante normais. Esta é unha situación aceptable, estámolo planeando, incluso contamos con ela en certa medida. É dicir, SRE constrúe sistemas que poden cometer erros, que deben responder con normalidade aos erros, que deben telos en conta. E sempre que sexa posible, deberían manexar os erros de forma que o usuario non os note, ou ben se decate, pero hai algún tipo de solución, grazas á cal non todo caerá completamente.
Por exemplo, se cargas un vídeo a YouTube e YouTube non pode convertelo inmediatamente, se o vídeo é demasiado grande, se o formato non é óptimo, a solicitude naturalmente non fallará cun tempo de espera, YouTube non dará un erro 502. , YouTube dirá: "Creamos todo, o teu vídeo estase procesando. Estará listo nuns 10 minutos". Este é o principio de degradación graciosa, que é familiar, por exemplo, desde o desenvolvemento front-end, se xa fixeches isto.
Os seguintes termos dos que falaremos, moi importantes para traballar con fiabilidade, con erros, con expectativas, son MTBF e MTTR. MTBF é o tempo medio entre fallos. MTTR Mean Time To Recovery, tempo medio para a recuperación. É dicir, canto tempo pasou desde o momento en que se descubriu o erro, desde o momento en que apareceu o erro ata o momento en que se restablece o servizo ao seu funcionamento normal. MTBF correspóndese principalmente co traballo na calidade do código. É dicir, o feito de que os SRE poidan dicir "non". E cómpre entender de todo o equipo que cando o SRE di "non", o di non porque sexa prexudicial, non porque sexa malo, senón porque se non todo o mundo sufrirá.
De novo, hai moitos artigos, moitos métodos, moitas formas incluso no propio libro ao que me refiro tantas veces, como asegurarme de que outros desenvolvedores non comecen a odiar SRE. MTTR, por outra banda, trata de traballar nos teus SLO (Obxectivo de Nivel de Servizo). E é principalmente automatización. Porque, por exemplo, o noso SLO é un tempo de actividade de 4 nove por trimestre. Isto significa que en 3 meses podemos permitir 13 minutos de inactividade. E resulta que o MTTR non pode ser máis de 13 minutos. Se respondemos a polo menos 13 tempo de inactividade en 1 minutos, isto significa que xa esgotamos todo o orzamento do trimestre. Estamos rompendo o SLO. 13 minutos para reaccionar e arranxar un accidente son moito para unha máquina, pero moi curtos para un humano. Porque ata que unha persoa recibe unha alerta, ata que reacciona, ata que entende o erro, xa son varios minutos. Ata que unha persoa entende como solucionalo, que é exactamente, que facer, entón isto son uns minutos máis. E, de feito, aínda que só necesites reiniciar o servidor, como resulta, ou crear un novo nodo, o MTTR manualmente xa é duns 7-8 minutos. Ao automatizar o proceso, MTTR a miúdo alcanza un segundo, ás veces milisegundos. Google adoita falar de milisegundos, pero en realidade, por suposto, non todo é tan bo.
Idealmente, o SRE debería automatizar o seu traballo case por completo, porque isto afecta directamente ao MTTR, ás súas métricas, ao SLO de todo o servizo e, en consecuencia, ao beneficio empresarial. Se se supera o tempo, pregúntanos se SRE ten a culpa. Afortunadamente, ninguén ten a culpa. E esta é unha cultura separada chamada postmortem sen bálsamo, da que non falaremos hoxe, pero si a analizaremos en Slurm. Este é un tema moi interesante do que se pode falar moito. A grandes liñas, se se supera o tempo asignado por trimestre, a culpa é un pouco de todos, o que quere dicir que botarlle a culpa a todos non é produtivo, imos, en cambio, se cadra non culpar a ninguén, senón corrixir a situación e traballar co que temos. Segundo a miña experiencia, este enfoque é un pouco alleo á maioría dos equipos, especialmente en Rusia, pero ten sentido e funciona moi ben. Por iso, recomendarei ao final do artigo e da literatura que poidas ler sobre este tema. Ou ven a Slurm SRE.
Déixame explicar. Se se supera o tempo SLO por trimestre, se o tempo de inactividade non foi de 13 minutos, senón de 15, quen pode ser o culpable disto? Por suposto, SRE pode ter a culpa, porque claramente fixo algún tipo de mala comisión ou despregamento. O administrador do centro de datos pode ser o culpable disto, porque puido realizar algún tipo de mantemento non programado. Se o culpable disto é o administrador do centro de datos, entón é a persoa de Ops, que non calculou o mantemento cando coordinou o SLO. O xerente, o director técnico ou alguén que asinou o contrato do centro de datos e non prestou atención ao feito de que o SLA do centro de datos non está deseñado para o tempo de inactividade necesario é o culpable diso. En consecuencia, todos pouco a pouco nesta situación teñen a culpa. E quere dicir que non ten sentido botarlle a culpa a ninguén nesta situación. Pero, por suposto, hai que corrixilo. Por iso hai autopsias. E se le, por exemplo, as autopsias de GitHub, e esta sempre é unha historia moi interesante, pequena e inesperada en cada caso, pode substituír que ninguén di nunca que esa persoa en concreto tivese a culpa. A culpa sempre se lle dá a procesos imperfectos específicos.
Pasemos á seguinte pregunta. Automatización. Cando falo de automatización noutros contextos, refírome a miúdo a unha táboa que che indica canto tempo podes traballar na automatización dunha tarefa sen tardar máis tempo en automatizala do que realmente gardas. Hai un inconveniente. O problema é que cando os SRE automatizan unha tarefa, non só aforran tempo, senón que aforran cartos, porque a automatización afecta directamente a MTTR. Aforran, por así dicilo, a moral dos empregados e dos desenvolvedores, que tamén é un recurso esgotable. Reducen a rutina. E todo isto repercute positivamente no traballo e, en consecuencia, nos negocios, aínda que pareza que a automatización non ten sentido en termos de custos de tempo.
De feito, case sempre o fixo, e hai moi poucos casos nos que algo non debería automatizarse no papel de SRE. A continuación falaremos do que se denomina orzamento de erros, o orzamento de erros. De feito, resulta que, se todo é moito mellor para ti que o SLO que che estableces, isto tampouco é moi bo. Isto é bastante malo, porque SLO funciona non só como un límite inferior, senón tamén como un límite superior aproximado. Cando te fixas un SLO do 99% de dispoñibilidade e, de feito, tes o 99,99%, resulta que tes un espazo para experimentos que non prexudicarán en absoluto ao negocio, porque ti mesmo o determinaches todo xunto e estás este espazo non use. Tes un orzamento para erros, que no teu caso non se esgota.
Que facemos con el. Usámolo para literalmente todo. Para probas en condicións de produción, para lanzar novas funcións que poidan afectar o rendemento, para lanzamentos, para mantemento, para os tempos de inactividade previstos. Tamén se aplica a regra inversa: se se esgota o orzamento, non podemos estrear nada novo, porque se non superaremos o SLO. O orzamento xa está esgotado, liberamos algo se repercute negativamente no rendemento, é dicir, se non se trata dunha corrección que en si mesma aumente directamente o SLO, entón imos máis aló do orzamento, e esta é unha mala situación. , debe ser analizado , post mortem e, posiblemente, algunhas correccións de procesos.
É dicir, resulta que se o servizo en si non funciona ben, e SLO gástase e o orzamento non se gasta en experimentos, nin en algúns lanzamentos, senón por si só, entón en lugar de algunhas correccións interesantes, en lugar de funcións interesantes, en lugar de lanzamentos interesantes. En lugar de calquera traballo creativo, terás que xestionar correccións estúpidas para recuperar o orzamento ou editar o SLO, e este tamén é un proceso que non debería ocorrer con demasiada frecuencia.
Polo tanto, resulta que nunha situación na que temos máis orzamento para erros, todos están interesados: tanto SRE como desenvolvedores. Para os desenvolvedores, un gran orzamento para erros significa que podes xestionar lanzamentos, probas e experimentos. Para os SRE, un orzamento para erros e ingresar ese orzamento significa que están facendo ben o seu traballo directamente. E isto afecta á motivación dalgún tipo de traballo conxunto. Se escoitas os teus SRE como desenvolvedores, terás máis espazo para un bo traballo e moito menos rutina.
Resulta que os experimentos na produción son unha parte bastante importante e case integrante da SRE en grandes equipos. E normalmente chámase enxeñería do caos, que vén do equipo de Netflix que lanzou unha utilidade chamada Chaos Monkey.
Chaos Monkey conéctase á canalización CI/CD e bloquea o servidor de forma aleatoria en produción. De novo, na estrutura SRE, estamos a falar do feito de que un servidor caído non é malo en si mesmo, é de esperar. E se está dentro do orzamento, é aceptable e non prexudica o negocio. Iso si, Netflix dispón de servidores redundantes suficientes, de replicación suficiente, para que todo isto se poida arranxar, e para que o usuario no seu conxunto nin se decate, e máis aínda ninguén deixa un servidor por ningún orzamento.
Netflix tivo unha serie completa de tales utilidades durante un tempo, unha das cales, Chaos Gorilla, apaga por completo unha das zonas de dispoñibilidade de Amazon. E tales cousas axudan a revelar, en primeiro lugar, as dependencias ocultas, cando non está do todo claro o que afecta a que, o que depende de que. E isto, se estás a traballar cun microservizo e a documentación non é perfecta, quizais che resulte familiar. E, de novo, isto axuda moito a detectar erros no código que non podes detectar na posta en escena, porque calquera posta en escena non é exactamente unha simulación exacta, debido ao feito de que a escala de carga é diferente, o patrón de carga é diferente, o equipo é diferente. tamén, moi probablemente, outros. Os picos de carga tamén poden ser inesperados e imprevisibles. E tales probas, que de novo non van máis aló do orzamento, axudan moi ben a detectar erros na infraestrutura que nunca atraparán a posta en escena, as probas automáticas, o pipeline CI/CD. E sempre que estea todo incluído no teu orzamento, non importa que o teu servizo baixase alí, aínda que parecería moi asustado, o servidor caeu, que pesadelo. Non, iso é normal, iso é bo, iso axuda a atrapar erros. Se tes un orzamento, podes gastalo.
P: Que literatura podo recomendar? Lista ao final. Hai moita literatura, aconsellarei algúns informes. Como funciona, e funciona SRE en empresas sen produto de software propio ou cun desenvolvemento mínimo. Por exemplo, nunha empresa onde a actividade principal non é o software. Nunha empresa, onde a actividade principal non é o software, SRE funciona exactamente igual que en calquera outro lugar, porque nunha empresa tamén cómpre usar, aínda que non estea desenvolvido, produtos de software, cómpre lanzar actualizacións, cómpre cambiar a infraestrutura, hai que crecer, hai que escalar. E os SRE axudan a identificar e predecir posibles problemas nestes procesos e controlalos despois de que comeza algún crecemento e cambian as necesidades empresariais. Porque non é absolutamente necesario estar involucrado no desenvolvemento de software para ter un SRE se tes polo menos uns poucos servidores e espérase que teñas polo menos algún crecemento.
O mesmo ocorre cos pequenos proxectos, pequenas organizacións, porque as grandes empresas teñen o orzamento e o espazo para experimentar. Pero ao mesmo tempo, todos estes froitos dos experimentos pódense usar en calquera lugar, é dicir, SRE, por suposto, apareceu en Google, en Netflix, en Dropbox. Pero ao mesmo tempo, as pequenas empresas e startups xa poden ler material condensado, ler libros, ver informes. Empezan a escoitar falar con máis frecuencia, miran exemplos concretos, creo que está ben, pode ser realmente útil, tamén necesitamos isto, é xenial.
É dicir, todo o traballo principal de estandarización destes procesos xa está feito por vostede. Queda por determinar o papel da SRE específicamente na súa empresa e comezar a implementar realmente todas estas prácticas, que, de novo, xa foron descritas. É dicir, a partir de principios útiles para pequenas empresas, esta é sempre a definición de SLA, SLI, SLO. Se non está involucrado no software, entón estes serán SLA internos e SLO internos, un orzamento interno para erros. Isto case sempre leva a algunhas discusións interesantes dentro do equipo e dentro da empresa, porque pode resultar que gastas en infraestruturas, en algún tipo de organización de procesos ideais, o pipeline ideal é moito máis do necesario. E estes 4 nove que tes no departamento de TI, realmente non os necesitas agora. Pero ao mesmo tempo, pode gastar tempo, gastar o orzamento para erros noutra cousa.
En consecuencia, o seguimento e organización do seguimento é útil para unha empresa de calquera tamaño. E en xeral, esta forma de pensar, onde os erros son algo aceptable, onde hai orzamento, onde hai Obxectivos, volve ser útil para unha empresa de calquera tamaño, empezando por startups para 3 persoas.
O último dos matices técnicos dos que falar é o seguimento. Porque se falamos de SLA, SLI, SLO, non podemos entender sen controlar se nos axustamos ao orzamento, se cumprimos os nosos Obxectivos e como influímos no SLA final. Vin tantas veces que o seguimento ocorre así: hai algún valor, por exemplo, o tempo dunha solicitude ao servidor, o tempo medio ou o número de solicitudes á base de datos. Ten un estándar determinado por un enxeñeiro. Se a métrica se desvía da norma, chega un correo electrónico. Todo isto é absolutamente inútil, por regra xeral, porque leva a un exceso de alertas, un exceso de mensaxes de seguimento, cando unha persoa, en primeiro lugar, debe interpretalas cada vez, é dicir, determinar se o valor da métrica significa a necesidade de algunha acción. E en segundo lugar, simplemente deixa de notar todas estas alertas, cando basicamente non se lle require ningunha acción. Esa é unha boa regra de vixilancia e a primeira regra cando se implementa SRE é que a notificación só debe chegar cando se require acción.
No caso estándar, hai 3 niveis de eventos. Hai alertas, hai entradas, hai rexistros. As alertas son calquera cousa que require que tomes medidas inmediatas. É dicir, todo está roto, hai que arranxalo agora mesmo. As entradas son as que requiren unha acción atrasada. Si, tes que facer algo, tes que facer algo manualmente, a automatización fallou, pero non tes que facelo durante os próximos minutos. Os rexistros son calquera cousa que non require acción e, en xeral, se as cousas van ben, ninguén os lerá nunca. Só terás que ler os rexistros cando, retrospectivamente, descubriuse que algo se rompeu durante algún tempo, non o sabíamos. Ou tes que investigar. Pero, en xeral, todo o que non require ningunha acción vai aos rexistros.
Como efecto secundario de todo isto, se definimos que eventos requiren accións e describimos ben cales deben ser estas accións, isto significa que a acción pode ser automatizada. É dicir, o que pasa. Imos de alerta. Imos á acción. Imos á descrición desta acción. E despois pasamos á automatización. É dicir, calquera automatización comeza cunha reacción a un evento.
Do seguimento, pasamos a un termo chamado Observabilidade. Tamén houbo un pouco de bombo ao redor desta palabra nos últimos anos. E poucas persoas entenden o que significa fóra de contexto. Pero o principal é que a observabilidade é unha métrica para a transparencia do sistema. Se algo saíu mal, con que rapidez pode determinar o que fallou exactamente e cal era o estado do sistema nese momento. En termos de código: que función fallou, que servizo fallou. Cal era o estado de, por exemplo, as variables internas, a configuración. En termos de infraestrutura, esta é en que zona de dispoñibilidade ocorreu o fallo e, se tes algún Kubernetes, entón en que pod se produciu o fallo, cal era o estado do pod. E en consecuencia, Observability ten unha relación directa con MTTR. Canto maior sexa a Observabilidade do servizo, máis fácil será identificar o erro, máis fácil será corrixilo, máis fácil será automatizar o erro, menor será o MTTR.
Pasando de novo ás pequenas empresas, é moi común preguntarse, aínda agora, como tratar co tamaño do equipo e se un equipo pequeno necesita contratar un SRE separado. Xa falamos disto un pouco antes. Nas primeiras etapas de desenvolvemento dunha startup ou, por exemplo, dun equipo, isto non é para nada necesario, porque a SRE pódese converter nun papel transitorio. E isto revivirá un pouco o equipo, porque polo menos hai certa diversidade. E ademais preparará a xente para o feito de que co crecemento, en xeral, as responsabilidades da SRE cambiarán de forma moi significativa. Se contratas unha persoa, entón, por suposto, ten algunhas expectativas. E estas expectativas non cambiarán co paso do tempo, pero os requisitos cambiarán moito. Polo tanto, como contratar un SRE é bastante difícil nas etapas iniciais. Crecer o teu é moito máis sinxelo. Pero paga a pena pensalo.
A única excepción, quizais, é cando hai requisitos de crecemento moi estritos e ben definidos. É dicir, no caso dunha startup, isto pode ser algún tipo de presión dos investidores, algún tipo de previsión de crecemento varias veces á vez. Entón a contratación dun SRE está basicamente xustificada porque se pode xustificar. Temos esixencias para o crecemento, necesitamos unha persoa que sexa responsable de que con tal crecemento nada se romperá.
Unha pregunta máis. Que facer cando varias veces os desenvolvedores cortan unha función que supera as probas, pero rompe a produción, carga a base, rompe outras funcións, que proceso implementar. En consecuencia, neste caso, é o orzamento por erros que se introduce. E algúns dos servizos, algunhas das funcións xa se están probando na produción. Pode ser canario, cando só un número reducido de usuarios, pero xa en produción, se desprega unha función, pero xa coa expectativa de que se algo rompe, por exemplo, para a metade por cento de todos os usuarios, aínda cumprirá o orzamento para erros. En consecuencia, si, haberá un erro, para algúns usuarios romperase todo, pero xa dixemos que isto é normal.
Houbo unha pregunta sobre as ferramentas SRE. É dicir, hai algo en particular que os SRE usarían que os demais non. De feito, hai algunhas utilidades altamente especializadas, hai algún tipo de software que, por exemplo, simula cargas ou se dedica a probas A/B canarias. Pero basicamente o conxunto de ferramentas SRE é o que xa están a usar os teus desenvolvedores. Porque SRE interactúa directamente co equipo de desenvolvemento. E se tes diferentes ferramentas, resultará que leva tempo sincronizar. Sobre todo se os SRE traballan en grandes equipos, en grandes empresas onde pode haber varios equipos, é a estandarización de toda a empresa a que vai axudar moito aquí, porque se se usan 50 utilidades diferentes en 50 equipos, isto significa que a SRE debe coñecelas. todos. E, por suposto, isto nunca sucederá. E a calidade do traballo, a calidade do control de polo menos algúns dos equipos vai diminuír significativamente.
O noso webinar está chegando ao seu fin. Conseguín contar algunhas cousas básicas. Por suposto, nada sobre SRE se pode dicir e entender nunha hora. Pero espero que conseguín transmitir esta forma de pensar, os principais puntos clave. E despois será posible, se che interesa, afondar no tema, aprender pola túa conta, ver como se está a implantar por outras persoas, noutras empresas. E en consecuencia, a principios de febreiro, ven a nós en Slurm SRE.
O Slurm SRE é un curso intensivo de tres días de duración que falará do que agora falo, pero con moita máis profundidade, con casos reais, con práctica, todo o intensivo vai dirixido ao traballo práctico. As persoas dividiranse en equipos. Todos estaredes traballando en casos reais. En consecuencia, temos os instrutores de Booking.com Ivan Kruglov e Ben Tyler. Temos un marabilloso Eugene Barabbas de Google, de San Francisco. E eu tamén che direi algo. Así que non deixes de visitarnos.
Entón, a bibliografía. Hai referencias sobre SRE. sobre o mesmo libro, ou máis ben sobre 2 libros sobre SRE, escritos por Google. Outro , onde os termos e a súa aplicación son algo máis detallados. Os 3 seguintes son informes sobre SRE en diferentes empresas. Primeira - , esta é unha conferencia de Ben Trainer de Google. segundo - . O terceiro é de novo . Cuarto informe de , que ten só 5 empregados clave de SRE en 190 países. É moi interesante ver todo isto, porque do mesmo xeito que DevOps significa cousas moi diferentes para diferentes empresas e incluso para diferentes equipos, SRE ten responsabilidades moi diferentes, mesmo en empresas de tamaños similares.
2 ligazóns máis sobre os principios da enxeñaría do caos: , . E ao final hai 3 listas da serie Awesome Lists about , sobre e aproximadamente . A lista de SRE é incriblemente enorme, non é necesario repasala todo, hai uns 200 artigos. Recomendo encarecidamente artigos de alí sobre a planificación da capacidade e sobre a autopsia sen culpa.
Artigo interesante:
Grazas por escoitarme todo este tempo. Espero que aprendiches algo. Espero que teñas material suficiente para aprender aínda máis. E vémonos. Esperemos que en febreiro.
O seminario web foi organizado por Eduard Medvedev.
PD: para os que lles guste ler, Eduard deu unha lista de referencias. Os que prefiren entender na práctica son benvidos .
Fonte: www.habr.com