A definición de DevOps é moi complexa, polo que temos que comezar a discusión sobre iso de novo cada vez. Só sobre Habré hai mil publicacións sobre este tema. Pero se estás lendo isto, probablemente saibas o que é DevOps. Porque non o son. Ola, chámome Alexander Titov (@), e só falaremos de DevOps e compartirei a miña experiencia.
Levo moito tempo pensando en como facer útil a miña historia, polo que haberá moitas preguntas aquí: as que me fago a min mesmo e as que fago aos clientes da nosa empresa. Ao responder a estas preguntas, a comprensión faise mellor. Vouche dicir por que se necesita DevOps desde o meu punto de vista, o que é, de novo, desde o meu punto de vista e como entender que estás avanzando cara a DevOps de novo dende o meu punto de vista. O último punto será a través de preguntas. Contestándoas por ti mesmo, podes entender se a túa empresa está a avanzar cara a DevOps ou se hai problemas dalgún xeito.
Nun tempo estiven montando as ondas de fusións e adquisicións. En primeiro lugar, traballei para unha pequena startup chamada Qik, despois comprouna unha empresa un pouco maior chamada Skype, que logo foi comprada por unha empresa un pouco maior chamada Microsoft. Nese momento, comecei a ver como se estaba transformando a idea de DevOps en empresas de diferentes tamaños. Despois diso, intereseime a mirar DevOps desde o punto de vista do mercado, e os meus compañeiros e eu fundamos a empresa Express 42. Desde hai 6 anos seguimos avanzando polas ondas do mercado.
Entre outras cousas, son un dos organizadores da comunidade DevOps Moscow e o organizador dos DevOps-Days 2017, pero non organizei 2018. Express 42 funciona con moitas empresas. Alí cultivamos DevOps, observamos como ocorre, extraemos conclusións, analizamos, contamos a todos as nosas conclusións e formamos a xente nas prácticas de DevOps. En xeral, estamos facendo todo o posible para aumentar a nosa experiencia e coñecementos neste sentido.
Por que DevOps
A primeira pregunta que persegue a todos e sempre é: por que? Moita xente pensa que DevOps é só automatización ou algo semellante que xa tiñan todas as empresas.
— Tivemos integración continua; isto significa que xa tiñamos DevOps, e por que se necesitan todas estas cousas? Están a divertirse no estranxeiro, pero impiden que traballemos!
Ao longo de 9 anos de desenvolvemento da comunidade e da metodoloxía, xa quedou claro que aínda non se trata de comercializar brillo, pero aínda non está do todo claro por que é necesario. Como calquera ferramenta e proceso, DevOps ten obxectivos específicos que finalmente consegue.
Todo isto débese a que o mundo está cambiando. Afástase do enfoque empresarial, cando as empresas avanzan directamente cara a un soño, como cantaba o noso clásico de San Petersburgo, do punto A ao punto B segundo unha determinada estratexia, cunha determinada estrutura construída para iso.
En principio, todo en TI debería construírse segundo este enfoque. Aquí a TI utilízase exclusivamente para automatizar procesos.
A automatización non cambia a miúdo, porque cando unha empresa cae por un rodeiro ben pisado, que hai que cambiar? Funciona, non o toques. Agora os enfoques no mundo están cambiando, e o chamado Agile suxire que o punto final B non é inmediatamente visible.
Cando unha empresa pasa polo mercado, traballa cun cliente, explora constantemente o mercado e cambia o punto final B. Ademais, cantas máis veces a empresa cambie de dirección, máis éxito terá ao final, porque escolle máis mercado. nichos.
A estratexia é demostrada por unha empresa interesante da que souben recentemente. One Box Shave é un servizo de entrega por subscrición de navallas e accesorios de afeitado nunha caixa. Eles saben como personalizar a súa "caixa" para diferentes clientes. Isto faise mediante un determinado software, que despois envía o pedido á fábrica coreana que produce o produto.
Este produto foi comprado por Unilever por 1 millóns de dólares. Agora compite con Gillette e quitou unha parte importante dos consumidores no mercado estadounidense. One Box Shave di:
- 4 láminas? Estás en serio? Por que precisa isto - non mellora a calidade do afeitado. Unha crema especialmente seleccionada, unha fragrancia e unha navalla de alta calidade con dúas follas solucionan moitos máis problemas que esas estúpidas follas de 4 Gillette. Chegaremos pronto ás 10?
Así cambia o mundo. Unilever afirma que teñen un sistema informático xenial que che permite facelo. Ao final parece un concepto Tempo de comercialización, do que xa ninguén falou.
O punto de Time-to-market non é a frecuencia con que nos implementamos. Moitas veces podes implementar, pero os ciclos de lanzamento serán longos. Se os ciclos de lanzamento de tres meses se superpoñen uns aos outros, mudándoos nunha semana, resulta que a compañía parece estar implantándose unha vez á semana. E dende a idea ata a posta en marcha definitiva leva 3 meses.
O tempo de comercialización consiste en minimizar o tempo desde a idea ata a implementación final.
Neste caso, o software interactúa co mercado. Así é como interactúa o sitio web de One Box Shave co cliente. Non teñen vendedores, só un sitio web onde os visitantes fan clic e deixan desexos. En consecuencia, algo novo debe publicarse constantemente no sitio e actualizarse de acordo cos desexos. Por exemplo, en Corea do Sur afeitan de forma diferente que en Rusia, e gústalles o cheiro non a piñeiro, senón, por exemplo, a cenoria e a vainilla.
Dado que é necesario cambiar rapidamente o contido do sitio, o desenvolvemento de software cambia moito. A través do software debemos descubrir o que quere o cliente. Anteriormente, aprendemos isto a través dalgunhas formas indirectas, por exemplo, a través da xestión empresarial. Despois deseñamos, introducimos os requisitos no sistema informático e todo foi xenial. Agora é diferente: o software está deseñado por todos os que participan no proceso, incluídos os enxeñeiros, porque a través das especificacións técnicas aprenden como funciona o mercado e tamén comparten as súas ideas coa empresa.
Por exemplo, en Qik de súpeto decatámonos de que á xente lle gustaba moito cargar listas de contactos ao servidor e proporcionáronnos unha aplicación. Nun principio non pensamos niso. Nunha empresa clásica, todo o mundo decidira que se trataba dun erro, xa que a especificación non dicía que debería funcionar moi ben e xeralmente se implementaba no xeonllo, desactivarían a función e dixeron: "Ninguén necesita isto, o máis importante é que funcione a funcionalidade principal.” . E a empresa tecnolóxica ve isto como unha oportunidade e comeza a cambiar o software de acordo con isto.
En 1968, un tipo visionario, Melvin Conway, formulou a seguinte idea.
A organización que crea o sistema está restrinxida por un deseño que replica a estrutura de comunicación desa organización.
Máis polo miúdo, para producir sistemas de distinto tipo, tamén hai que ter unha estrutura de comunicación dentro dunha empresa de distinto tipo. Se a túa estrutura de comunicación é xerárquica superior, isto non che permitirá crear sistemas que poidan proporcionar un indicador de tempo de comercialización moi elevado.
Ler unha lata . É importante para comprender a cultura ou a filosofía DevOps porque o único que cambia fundamentalmente en DevOps é a estrutura da comunicación entre os equipos.
Desde o punto de vista do proceso, antes do DevOps, todas as etapas: análise, desenvolvemento, probas, operación, eran lineais.
No caso de DevOps, todos estes procesos ocorren simultaneamente.
Time-to-market é a única forma en que se pode facer. Para as persoas que traballaron no proceso antigo, isto parece algo cósmico e, en xeral, así.
Entón, por que necesitas DevOps?
Para o desenvolvemento de produtos dixitais. Se a túa empresa non ten un produto dixital, DevOps non é necesario; é moi importante.
DevOps supera as limitacións de velocidade da produción de software secuencial. Nela todos os procesos ocorren simultaneamente.
A dificultade aumenta. Cando os evanxelistas de DevOps che din que che facilitará o lanzamento de software, isto é unha tontería.
Con DevOps, as cousas só se complicarán.
Na conferencia no stand de Avito, puideches ver como era despregar un contedor Docker, unha tarefa pouco realista. A complexidade vólvese prohibitiva; tes que facer malabarismos con moitas bólas ao mesmo tempo.
DevOps cambia completamente o proceso e a organización da empresa — máis precisamente, non é DevOps o que cambia, senón o produto dixital. Para chegar a DevOps, aínda debes cambiar completamente este proceso.
Preguntas para un especialista
Que é o que tes? Preguntas que podes facerte mentres traballas nunha empresa e desenvolves como especialista.
Tes unha estratexia para crear un produto dixital? Se o hai, iso xa é bo. Isto significa que a túa empresa está avanzando cara a DevOps.
A túa empresa xa está a crear un produto dixital? Isto significa que pode subir outro nivel e facer as cousas de forma máis interesante, de novo dende o punto de vista de DevOps. Só falo desde este punto de vista.
A súa empresa é un dos líderes no nicho de produtos dixitais? Spotify, Yandex e Uber son empresas que están agora no pico do progreso tecnolóxico.
Fai estas preguntas e, se todas as respostas son negativas, quizais non deberías facer DevOps nesta empresa. Se o tema de DevOps é realmente interesante para ti, quizais... deberías mudarte a outra empresa? Se a túa empresa quere entrar en DevOps, pero respondeches "Non" a todas as preguntas, entón é como ese fermoso rinoceronte que nunca cambiará.
Organización
Como dixen, segundo a Lei de Conway, a organización dunha empresa cambia. Comezarei polo que impide que DevOps penetre dentro da empresa desde o punto de vista organizativo.
O problema dos "pozos"
A palabra inglesa "Silo" tradúcese aquí ao ruso como "ben". O punto deste problema é que non hai intercambio de información entre equipos. Cada equipo afonda na súa experiencia, sen construír un mapa común para navegar.
Dalgunha maneira isto lémbrame a unha persoa que acaba de chegar a Moscova e aínda non sabe como navegar polo mapa do metro. Os moscovitas adoitan coñecer moi ben a súa zona e por toda Moscova poden navegar usando o mapa do metro. Cando chegas a Moscova por primeira vez, non tes esta habilidade e estás desorientado.
DevOps suxire superar este momento de desorientación e que todos os departamentos traballen xuntos para construír un mapa de interacción común.
Dous factores impiden isto.
Consecuencia do sistema de xestión corporativo. Está construído en "pozos" xerárquicos separados. Por exemplo, hai certos KPI en empresas que admiten este sistema. Por outra banda, o cerebro dunha persoa á que lle custa ir máis aló dos límites da súa experiencia e navegar por todo o sistema intervén. É simplemente incómodo. Imaxina que estás no aeroporto de Bangkok: non atoparás o camiño rapidamente. DevOps tamén é difícil de navegar, e por iso a xente din que necesitas atopar unha guía para chegar alí.
Pero o máis importante é que o problema dos "pozos" para un enxeñeiro que está imbuído do espírito de DevOps, leu a Fowler e unha morea de libros máis, exprésase no feito de que os "pozos" non che permiten facer cousas "obvias".. Moitas veces reunímonos despois de DevOps Moscow, falamos entre nós e a xente quéixase:
— Só queriamos lanzar CI, pero resultou que a dirección non o necesitaba.
Isto ocorre precisamente porque CI и Proceso de entrega continua están na fronteira de moitos exames. Simplemente sen superar o problema dos “pozos” a nivel organizativo, non poderás seguir adiante, fagas o que fagas e por moi triste que sexa.
Cada participante no proceso na empresa: desenvolvedores de backend e frontend, probas, DBA, operación, rede, cava na súa propia dirección, e ninguén ten un mapa común agás o xestor, que dalgún xeito os supervisa e xestiona mediante o "divide". método e conquista”.
A xente loita por algunhas estrelas ou bandeiras, todo o mundo está cavando a súa experiencia.
Como resultado, cando xorde a tarefa de conectar todo isto e construír un oleoduto común, e xa non hai necesidade de loitar polas estrelas e bandeiras, xorde a pregunta: que facer de todos os xeitos? Necesitamos chegar a un acordo dalgún xeito, pero ninguén nos ensinou como facelo na escola. Ensináronnos dende o colexio: oitavo de primaria - vaia! - en comparación co sétimo curso! Aquí pasa o mesmo.
É o mesmo na súa empresa?
Para comprobalo, podes facerte as seguintes preguntas.
Os equipos usan ferramentas comúns e contribúen a cambios nestas ferramentas comúns?
Cantas veces se reorganizan os equipos: algúns especialistas dun equipo pasan a outro? É nun ambiente DevOps onde isto se fai normal, porque ás veces unha persoa simplemente non pode entender o que está a facer outra área de especialización. Trasládase a outro departamento, traballa alí dúas semanas para crearse un mapa de orientación e interacción con este departamento.
É posible formar unha comisión de cambio e cambiar as cousas? Ou precisa da man forte da máis alta dirección e dirección? Recentemente escribín en Facebook como un banco pouco coñecido está a implementar ferramentas a través de pedidos: escribimos un pedido, implementámolo durante un ano e vemos que pasa. Isto, por suposto, é longo e triste.
Que importante é que os directivos reciban logros persoais sen ter en conta os logros da empresa?
Se respondes a estas preguntas por ti mesmo, quedará máis claro se tes tal problema na túa empresa.
Infraestrutura como código
Despois de superar este problema, a primeira práctica importante, sen a cal é difícil avanzar máis en DevOps infraestrutura como código.
Na maioría das veces, a infraestrutura como código percíbese do seguinte xeito:
— Imos automatizar todo en bash, cubrirnos con scripts para que os administradores teñan menos traballo manual!
Pero iso non é certo.
A infraestrutura como código significa que describes o sistema informático co que traballas en forma de código para comprender constantemente o seu estado.
Xunto con outros equipos, creas un mapa en forma de código que todos poden entender e poden navegar e navegar. Non importa o que se faga: Chef, Ansible, Salt ou usando ficheiros YAML en Kubernetes, non hai diferenza.
Na conferencia, un colega de 2GIS contou como fixeron a súa propia cousa interna para Kubernetes, que describe a estrutura dos sistemas individuais. Para describir 500 sistemas, necesitaban unha ferramenta separada que xerase esta descrición. Cando hai esta descrición, todos poden comprobar entre si, supervisar os cambios, como cambialo e melloralo, o que falta.
De acordo, os scripts bash individuais normalmente non proporcionan esta comprensión. Nunha das empresas nas que traballei, incluso había un nome para o guión de "só escribir", cando o guión está escrito, pero xa non é posible lelo. Creo que isto tamén che é familiar.
A infraestrutura como é o código código que describe o estado actual da infraestrutura. Moitos equipos de produtos, infraestruturas e servizos traballan xuntos neste código e, o máis importante, todos teñen que entender como funciona este código.
O código mantense segundo as mellores prácticas de código: desenvolvemento conxunto, revisión de código, programación XP, probas, solicitudes de extracción, CI para infraestruturas de código: todo isto é adecuado e pódese usar.
O código convértese nunha linguaxe común para todos os enxeñeiros.
Cambiar a infraestrutura no código non leva moito tempo. Si, o código de infraestrutura tamén pode ter débeda técnica. Normalmente os equipos atópanse ano e medio despois de comezar a implementar "infraestrutura como código" en forma de scripts ou mesmo Ansible, que escriben como código espagueti, e tamén botan scripts bash á mestura.
É importante: Se aínda non probaches estas cousas, lembra Ansible non é bash! Le con atención a documentación, estuda o que escriben sobre ela.
A infraestrutura como código é a separación do código da infraestrutura en capas separadas.
Na nosa empresa, distinguimos 3 capas básicas, que son moi claras e sinxelas, pero pode haber máis delas. Podes mirar o teu código de infraestrutura e dicir se tes esta condición ou non. Se non se resalta ningunha capa, cómpre levar un tempo e refactorizar un pouco.
capa base - así se configuran o sistema operativo, as copias de seguridade e outras cousas de baixo nivel, por exemplo, como se desprega Kubernetes no nivel básico.
Nivel de servizo - Estes son os servizos que ofrece ao programador: rexistro como servizo, seguimento como servizo, base de datos como servizo, equilibrador como servizo, cola como servizo, Entrega continua como servizo: unha morea de servizos que os equipos individuais pode proporcionar ao desenvolvemento. Todo isto debe describirse en módulos separados no seu sistema de xestión de configuración.
A capa onde se realizan as aplicacións e describe como se desenvolverán sobre as dúas capas anteriores.
Preguntas de control
A súa empresa ten un repositorio de infraestrutura común? Estás xestionando a débeda técnica na túa infraestrutura? Utiliza prácticas de desenvolvemento nun repositorio de infraestruturas? A túa infraestrutura está dividida en capas? Podes consultar o diagrama Base-service-APP. Que difícil é facer un cambio?
Se experimentaches que tardou un día e medio en facer cambios, isto significa que tes unha débeda técnica e necesitas traballar con ela. Acabas de tropezar cunha débeda técnica no teu código de infraestrutura. Lembro moitas historias deste tipo cando, para cambiar algún CCTL, cómpre reescribir a metade do código da infraestrutura, porque a creatividade e o desexo de automatizar todo levaron a que todo está corroído por todas partes, todos os tiradores foron eliminados e é necesario refactorizar.
Entrega continua
Comparemos o débito co crédito. Primeiro vén unha descrición da infraestrutura, que pode ser bastante básica. Non tes que describir todo en detalle, pero é necesaria algunha descrición básica para que poidas traballar con ela. En caso contrario, non está claro que facer coa entrega continua. Todas estas prácticas desenvólvense simultáneamente cando chegas a DevOps, pero comeza por comprender o que tes e como xestionalo. Esta é precisamente a práctica da infraestrutura como código.
Unha vez que queda claro que o tes e como xestionalo, comezas a descubrir como enviar o código de desenvolvedor á produción o máis rápido posible. Quero dicir, xunto co desenvolvedor, recordamos o problema dos "pozos", é dicir, non son persoas individuais as que se lles ocorren, senón un equipo.
Cando estamos con Vania Evtukhovich vin o primeiro libro Jez Humilde e grupos de autores "Entrega continua", que foi lanzado en 2009, pensamos durante moito tempo en como traducir o seu título ao ruso. Querían traducilo como "Entrega constantemente", pero, por desgraza, traduciuse como "Entrega continua". Paréceme que hai algo ruso no noso nome, con presión.
Entregando medios constantemente
O código que está no repositorio de produtos sempre se pode descargar en produción. Quizais non estea desinflado, pero sempre está preparado para iso. En consecuencia, sempre escribes código cunha sensación de ansiedade difícil de explicar baixo o coxis. Moitas veces aparece cando lanzas código de infraestrutura. Esta sensación de certa ansiedade debería estar presente: desencadea procesos cerebrais que che permiten escribir código un pouco diferente. Isto debe ser rexistrado nas regras dentro do desenvolvemento.
Para entregar de forma consistente, necesitas un formato de artefacto que se execute nunha plataforma de infraestrutura. Se tiras "residuos vitais" de diferentes formatos nunha plataforma de infraestrutura, entón se unifica, é difícil de manter e xorde o problema da débeda técnica. Hai que aliñar o formato do artefacto; esta tamén é unha tarefa colectiva: todos necesitamos reunirnos, facer ruxir os nosos cerebros e crear este formato.
O artefacto mellórase continuamente e cambia para adaptarse ao ambiente de produción a medida que se move pola canalización de entrega. Cando un artefacto se move ao longo da canalización, atopa constantemente algunhas cousas inconvenientes para el, que son similares ás que atopa o artefacto que puxo en produción. Se no desenvolvemento clásico faino un administrador do sistema que fai o lanzamento, entón no proceso DevOps isto ocorre todo o tempo: aquí probárono con algunhas probas, aquí lanzárono a un clúster de Kubernetes, que é máis ou menos semellante. á produción, de súpeto comezaron a probar a carga.
Isto é unha reminiscencia do xogo Pac-Man: o artefacto pasa por algún tipo de historia. Ao mesmo tempo, é importante controlar se o código realmente atravesa a historia e se está relacionado dalgún xeito coa túa produción. As historias da produción pódense arrastrar ao proceso de Entrega Continua: foi así cando algo caeu, agora imos programar este escenario dentro do sistema. Cada vez que o código pasará por este escenario tamén, e non atoparás este problema a próxima vez. Aprenderá sobre iso moito antes do que chegue ao seu cliente.
Diferentes estratexias de implantación. Por exemplo, usa probas AB ou implementacións canarias para probar o código de forma diferente en diferentes clientes, obter información sobre como funciona o código e moito antes que cando se lanza a 100 millóns de usuarios.
"Entregar constantemente" ten este aspecto.
O proceso de entrega Dev, CI, Test, PreProd, Prod non é un ambiente separado, son etapas ou estacións con sumas a proba de lume polas que pasa o teu artefacto.
Se tes código de infraestrutura que se describe como APP de servizo base, entón axuda non esquezas todos os guións, e escríbeos como código para este artefacto, promover artefacto e cámbiao a medida que vaias.
Preguntas de autotest
O tempo desde a descrición da función ata o lanzamento en produción no 95 % dos casos é de menos dunha semana? Mellora a calidade do artefacto en cada etapa da canalización? Hai algunha historia pola que pasa? Utilizas diferentes estratexias de implantación?
Se todas as respostas son afirmativas, estás incriblemente xenial! Escribe as túas respostas nos comentarios - estarei feliz).
realimentación
Esta é a práctica máis difícil de todas. Na conferencia DevOpsConf, un colega de Infobip, falando sobre iso, estaba un pouco confuso nas súas palabras, porque esta é realmente unha práctica moi complexa sobre o feito de que hai que supervisar todo!
Por exemplo, hai moito tempo, cando traballaba en Qik e decatámonos de que necesitabamos vixiar todo. Fixemos isto e agora temos 150 elementos en Zabbix, que son monitorizados constantemente. Daba medo, o director técnico torceu o dedo na tempe:
- Rapaces, por que violas o servidor con algo pouco claro?
Pero entón ocorreu un incidente que demostrou que esta é realmente unha estratexia moi xenial.
Un dos servizos comezou a fallar constantemente. Inicialmente, non fallou, o que é interesante, o código non se engadiu alí, porque era un corredor básico, que practicamente non tiña ningunha funcionalidade comercial: simplemente enviaba mensaxes entre servizos individuais. O servizo non cambiou durante 4 meses e, de súpeto, comezou a fallar co erro "Fallo de segmentación".
Quedamos impresionados, abrimos os nosos gráficos en Zabbix e resultou que hai unha semana e media o comportamento das solicitudes no servizo API que usa este corredor cambiou moito. A continuación vimos que a frecuencia de envío dun determinado tipo de mensaxe cambiara. Máis tarde descubrimos que se trataba de clientes de Android. Preguntamos:
— Rapaces, que vos pasou hai semana e media?
Como resposta, escoitamos unha historia interesante sobre como redeseñaran a IU. É pouco probable que alguén diga inmediatamente que cambiou a biblioteca HTTP. Para os clientes de Android, é como cambiar o xabón no baño: simplemente non se lembran. Como resultado, despois de 40 minutos de conversa, descubrimos que cambiaran a biblioteca HTTP e que os seus horarios predeterminados cambiaran. Isto levou a que o comportamento do tráfico no servidor da API cambiase, o que provocou unha situación que provocou unha carreira dentro do corredor e comezou a fallar.
Sen un seguimento profundo xeralmente é imposible abrir isto. Se a organización aínda ten o problema dos "pozos", cando todos se botan cartos uns aos outros, isto pode vivir durante anos. Simplemente reinicia o servidor porque é imposible resolver o problema. Cando monitorizas, rastrexas, rastrexas todos os eventos que tes e utilizas a monitorización como proba: escribe código e indica inmediatamente como supervisalo, tamén en forma de código (xa temos a infraestrutura como código), todo queda claro como na palma da man. Mesmo problemas tan complexos son facilmente rastrexados.
Recolle toda a información sobre o que acontece co artefacto en cada etapa do proceso de entrega, non na produción.
Cargue a vixilancia a CI, e algunhas cousas básicas xa estarán visibles alí. Máis tarde verás en Test, PredProd e probas de carga. Recolle información en todas as fases, non só métricas, estatísticas, senón tamén rexistros: como se implementou a aplicación, anomalías: recolle todo.
Se non, será difícil descifralo. Xa dixen que DevOps é máis complexo. Para facer fronte a esta complexidade, cómpre ter unha análise normal.
Preguntas para o autocontrol
O teu seguimento e rexistro é a ferramenta de desenvolvemento para ti? Ao escribir código, os seus desenvolvedores, incluído vostede, pensan en como supervisalo?
Escoita falar dos problemas dos clientes? Entendes mellor ao cliente dende o seguimento e o rexistro? Entendes mellor o sistema a partir do seguimento e do rexistro? Cambias o sistema simplemente porque viste que a tendencia no sistema está a medrar e entendes que en outras 3 semanas morrerá todo?
Unha vez que teñas estes tres compoñentes, podes pensar que tipo de plataforma de infraestrutura tes na túa empresa.
Plataforma de infraestruturas
A cuestión non é que sexa un conxunto de ferramentas dispares que ten todas as empresas.
O punto dunha plataforma de infraestrutura é que todos os equipos utilicen estas ferramentas e desenvolvan conxuntamente.
Está claro que hai equipos separados que se encargan do desenvolvemento de pezas individuais da plataforma de infraestruturas. Pero ao mesmo tempo, cada enxeñeiro é responsable do desenvolvemento, rendemento e promoción da plataforma de infraestrutura. A nivel interno convértese nunha ferramenta común.
Todos os equipos desenvolven a plataforma de infraestrutura e trátana con coidado como o seu propio IDE. No teu IDE instalas diferentes complementos para que todo sexa agradable e rápido, e configuras as teclas de acceso rápido. Cando abres Sublime, Atom ou Visual Studio Code, aparecen erros de código e dás conta de que é imposible traballar en absoluto, sentes tristeza inmediatamente e corres para arranxar o teu IDE.
Trata a túa plataforma de infraestrutura do mesmo xeito. Se entendes que hai algo mal, deixa unha solicitude se non podes solucionalo por ti mesmo. Se hai algo sinxelo, edítao ti mesmo, envía unha solicitude de extracción, os mozos considerarano e engadirán. Este é un enfoque lixeiramente diferente das ferramentas de enxeñería na cabeza do programador.
A plataforma de infraestrutura garante a transferencia do artefacto do desenvolvemento ao cliente cunha mellora continua da calidade. O IP está programado cun conxunto de historias que suceden co código en produción. Ao longo dos anos de desenvolvemento, hai moitas destas historias, algunhas delas son únicas e só se relacionan contigo; non se poden buscar en Google.
Neste punto, a plataforma de infraestrutura convértese na túa vantaxe competitiva, porque ten algo incorporado que non está na ferramenta do competidor. Canto máis profunda sexa a súa IP, maior será a súa vantaxe competitiva en termos de Time-to-market. Aparece aquí problema de bloqueo do vendedor: Podes tomar a plataforma doutra persoa, pero usando a experiencia doutra persoa, non entenderás o relevante que é para ti. Si, non todas as empresas poden construír unha plataforma como Amazon. Esta é unha liña difícil na que a experiencia da empresa é relevante para a súa posición no mercado e non pode usar un bloqueo de provedor alí. Isto tamén é importante pensar.
O esquema
Este é un diagrama básico dunha plataforma de infraestrutura que che axudará a configurar todas as prácticas e procesos nunha empresa DevOps.
Vexamos en que consiste.
Sistema de orquestración de recursos, que proporciona CPU, memoria, disco a aplicacións e outros servizos. Ademais disto - servizos de baixo nivel: monitorización, rexistro, motor CI/CD, almacenamento de artefactos, infraestrutura como código do sistema.
Servizos de nivel superior: base de datos como servizo, colas como servizo, Balance de carga como servizo, redimensionamento da imaxe como servizo, Big Data factory como servizo. Ademais disto - pipeline que entrega código modificado constantemente ao seu cliente.
Recibes información sobre como funciona o teu software para o cliente, cámbiao, proporcionas este código de novo, recibes información, polo que desenvolves constantemente tanto a plataforma de infraestrutura como o teu software.
No diagrama, a canalización de entrega consta de moitas etapas. Pero este é un diagrama esquemático que se dá como exemplo, non é necesario repetilo un por un. As etapas interactúan cos servizos coma se fosen servizos: cada ladrillo da plataforma leva a súa propia historia: como se asignan os recursos, como se lanza a aplicación, como funciona cos recursos, como se supervisa e como cambia.
É importante entender que cada parte da plataforma leva unha historia e pregúntate que historia leva este ladrillo, quizais debería tiralo e substituílo por un servizo de terceiros. Por exemplo, é posible instalar Okmeter en lugar dun ladrillo? Quizais os rapaces xa desenvolveron esta experiencia moito máis que nós. Pero quizais non, quizais teñamos unha experiencia única, necesitamos instalar Prometheus e desenvolvelo aínda máis.
Creación da plataforma
Este é un proceso de comunicación complexo. Cando tes prácticas básicas, comezas a comunicación entre diferentes enxeñeiros e especialistas que desenvolven requisitos e estándares e cambialos constantemente a diferentes ferramentas e enfoques. A cultura que temos en DevOps é importante aquí.
Coa cultura todo é moi sinxelo - trátase de colaboración e comunicación, é dicir, o desexo de traballar nun campo común entre si, o desexo de manexar un instrumento xuntos. Aquí non hai ciencia de foguetes: todo é moi sinxelo, banal. Por exemplo, todos vivimos na entrada e mantemos limpo - tal nivel de cultura.
Que é o que tes?
De novo, preguntas que podes facerte.
A plataforma de infraestrutura está dedicada? Quen é o responsable do seu desenvolvemento? Entendes as vantaxes competitivas da túa plataforma de infraestruturas?
Debes facerte estas preguntas constantemente. Se se pode transferir algo a servizos de terceiros, debería transferirse; se un servizo de terceiros comeza a bloquear o teu movemento, debes crear un sistema dentro de ti.
Entón, DevOps...
... este é un sistema complexo, debe ter:
- Produto dixital.
- Módulos empresariais que desenvolven este produto dixital.
- Equipos de produto que escriben código.
- Prácticas de entrega continua.
- Plataformas como servizo.
- Infraestrutura como servizo.
- Infraestrutura como código.
- Prácticas separadas para manter a fiabilidade, integradas en DevOps.
- Unha práctica de feedback que o describe todo.
Podes utilizar este diagrama, destacando nel o que xa tes na túa empresa dalgunha forma: desenvolveuse ou aínda hai que desenvolver.
Acabará nun par de semanas . como parte de RIT++. Ven á conferencia, onde atoparás moitos informes interesantes sobre a entrega continua, a infraestrutura como código e a transformación de DevOps. , o último prazo de prezos é o 20 de maio
Fonte: www.habr.com