La definició de DevOps és molt complexa, així que hem de començar la discussió de nou cada cop. Hi ha mil publicacions sobre aquest tema només sobre Habré. Però si esteu llegint això, probablement sabeu què és DevOps. Perquè no ho sóc. Hola el meu nom és Alexander Titov (@), i només parlarem de DevOps i compartiré la meva experiència.
He estat pensant durant molt de temps en com fer que la meva història sigui útil, així que hi haurà moltes preguntes aquí: les que em faig a mi mateix i les que faig als clients de la nostra empresa. En respondre aquestes preguntes, la comprensió es fa millor. Us explicaré per què es necessita DevOps des del meu punt de vista, què és, de nou, des del meu punt de vista, i com entendre que des del meu punt de vista torneu a avançar cap a DevOps. L'últim punt serà a través de preguntes. Si les responeu vosaltres mateixos, podreu entendre si la vostra empresa avança cap a DevOps o si hi ha problemes d'alguna manera.
En un moment, vaig estar cavalcant les onades de fusions i adquisicions. Primer, vaig treballar per a una petita startup anomenada Qik, després la va comprar una empresa una mica més gran anomenada Skype, que després va ser comprada per una empresa una mica més gran anomenada Microsoft. En aquell moment, vaig començar a veure com la idea de DevOps s'estava transformant en empreses de diferents mides. Després d'això, em vaig interessar per mirar DevOps des del punt de vista del mercat, i els meus companys i jo vam fundar l'empresa Express 42. Fa 6 anys que ens movem per les onades del mercat.
Entre altres coses, sóc un dels organitzadors de la comunitat DevOps Moscou i l'organitzador dels DevOps-Days 2017, però no vaig organitzar el 2018. Express 42 funciona amb moltes empreses. Creixem DevOps allà, observem com passa, extreu conclusions, analitzem, expliquem a tothom les nostres conclusions i formem persones en pràctiques de DevOps. En general, estem fent tot el possible per augmentar la nostra experiència i coneixements en aquest sentit.
Per què DevOps
La primera pregunta que persegueix a tothom i sempre és: per què? Molta gent pensa que DevOps és només automatització o una cosa semblant que totes les empreses ja tenien.
— Teníem integració contínua: això vol dir que ja teníem DevOps i per què calen totes aquestes coses? S'estan divertint a l'estranger, però ens impedeixen treballar!
Durant 9 anys de desenvolupament de la comunitat i la metodologia, ja ha quedat clar que encara no es tracta de màrqueting de purpurina, però encara no està del tot clar per què és necessari. Com qualsevol eina i procés, DevOps té objectius específics que finalment assoleix.
Tot això es deu al fet que el món està canviant. S'allunya de l'enfocament empresarial, quan les empreses avancen directament cap a un somni, com cantava el nostre clàssic de Sant Petersburg, del punt A al punt B segons una determinada estratègia, amb una certa estructura construïda per això.
En principi, tot en TI s'hauria de construir segons aquest enfocament. Aquí la TI s'utilitza exclusivament per automatitzar processos.
L'automatització no canvia sovint, perquè quan una empresa passa per un camí molt fressat, què hi ha per canviar? Funciona, no el toqueu. Ara els enfocaments al món estan canviant, i l'anomenat Agile suggereix que el punt final B no és visible immediatament.
Quan una empresa passa pel mercat, treballa amb un client, explora constantment el mercat i canvia el punt final B. A més, com més sovint l'empresa canvia de direcció, més èxit té al final, perquè tria més mercat. nínxols.
L'estratègia la demostra una empresa interessant de la qual vaig conèixer recentment. One Box Shave és un servei de lliurament de subscripció per a navalles i accessoris d'afaitar en una caixa. Saben com personalitzar la seva "caixa" per a diferents clients. Això ho fa un programari determinat, que després envia la comanda a la fàbrica coreana que produeix la mercaderia.
Aquest producte va ser comprat per Unilever per 1 milions de dòlars. Ara competeix amb Gillette i s'ha endut una part important dels consumidors del mercat americà. One Box Shave diu:
- 4 fulles? Ho dius en serio? Per què ho necessiteu: no millora la qualitat de l'afaitat. Una crema especialment seleccionada, una fragància i una navalla d'alta qualitat amb dues fulles resolen molts més problemes que aquestes estúpides 4 fulles Gillette! Aviat arribarem a les 10?
Així és com canvia el món. Unilever afirma que tenen un sistema informàtic fantàstic que us permet fer-ho. Al final sembla un concepte Hora d'anar al mercat, de la qual ningú ja n'ha parlat.
El punt del temps de llançament al mercat no és la freqüència amb què despleguem. Sovint es pot implementar, però els cicles de llançament seran llargs. Si els cicles de llançament de tres mesos se superposen entre si, canviant-los una setmana, resulta que l'empresa sembla que es desplega un cop per setmana. I des de la idea fins a la implementació final triguen 3 mesos.
El temps de llançament al mercat consisteix a minimitzar el temps des de la idea fins a la implementació final.
En aquest cas, el programari interactua amb el mercat. Així és com el lloc web de One Box Shave interactua amb el client. No tenen venedors, només un lloc web on els visitants fan clic i deixen desitjos. En conseqüència, alguna cosa nova s'ha de publicar constantment al lloc i actualitzar-se d'acord amb els desitjos. Per exemple, a Corea del Sud s'afaiten de manera diferent que a Rússia, i els agrada l'olor no del pi, sinó, per exemple, de la pastanaga i la vainilla.
Com que cal canviar ràpidament el contingut del lloc, el desenvolupament de programari canvia molt. Mitjançant el programari hem d'esbrinar què vol el client. Anteriorment, ho vam aprendre d'algunes maneres indirectes, per exemple, mitjançant la gestió empresarial. Després el vam dissenyar, vam posar els requisits al sistema informàtic i tot va ser genial. Ara és diferent: el programari està dissenyat per tots els que participen en el procés, inclosos els enginyers, perquè a través de les especificacions tècniques aprenen com funciona el mercat i també comparteixen els seus coneixements amb l'empresa.
Per exemple, a Qik vam saber de sobte que a la gent li agradava molt penjar llistes de contactes al servidor i ens van proporcionar una aplicació. Al principi no ens ho vam pensar. En una empresa clàssica, tothom hauria decidit que es tractava d'un error, ja que l'especificació no deia que hauria de funcionar molt bé i que generalment s'implementava al genoll, haurien desactivat la funció i diuen: "Ningú ho necessita, el més important és que funcioni la funcionalitat principal.” . I l'empresa tecnològica veu això com una oportunitat i comença a canviar el programari d'acord amb això.
El 1968, un noi visionari, Melvin Conway, va formular la següent idea.
L'organització que crea el sistema està limitada per un disseny que replica l'estructura de comunicació d'aquesta organització.
Amb més detall, per produir sistemes d'un altre tipus, també cal tenir una estructura de comunicació dins d'una empresa d'un altre tipus. Si la vostra estructura de comunicació és jeràrquica superior, això no us permetrà crear sistemes que puguin proporcionar un indicador de temps de comercialització molt elevat.
Llegeix un pot . És important per entendre la cultura o la filosofia DevOps perquè l'únic que canvia fonamentalment a DevOps és l'estructura de comunicació entre equips.
Des del punt de vista del procés, abans de DevOps, totes les etapes: anàlisi, desenvolupament, proves, operació eren lineals.
En el cas de DevOps, tots aquests processos es produeixen simultàniament.
El temps de llançament al mercat és l'única manera que es pot fer. Per a les persones que van treballar en el procés antic, això sembla una mica còsmic i, en general, és així.
Aleshores, per què necessiteu DevOps?
Per al desenvolupament de productes digitals. Si la vostra empresa no té un producte digital, DevOps no és necessari, és molt important.
DevOps supera les limitacions de velocitat de la producció de programari seqüencial. En ella tots els processos ocorren simultàniament.
La dificultat augmenta. Quan els evangelistes de DevOps us diuen que us facilitarà el llançament de programari, això és una tonteria.
Amb DevOps, les coses només es complicaran més.
A la conferència a l'estand d'Avito, es va poder veure com era desplegar un contenidor Docker, una tasca poc realista. La complexitat es torna prohibitiva; has de fer malabars amb moltes boles alhora.
DevOps canvia completament el procés i l'organització de l'empresa — Més precisament, no és DevOps el que canvia, sinó el producte digital. Per arribar a DevOps, encara heu de canviar completament aquest procés.
Preguntes per a un especialista
Que tens? Preguntes que et pots fer mentre treballes en una empresa i desenvolupa com a especialista.
Tens una estratègia per crear un producte digital? Si n'hi ha, ja està bé. Això vol dir que la vostra empresa avança cap a DevOps.
La teva empresa ja està creant un producte digital? Això vol dir que podeu pujar un altre nivell més i fer les coses de manera més interessant, de nou des del punt de vista de DevOps. Només parlo des d'aquest punt de vista.
La teva empresa és un dels líders del mercat en el nínxol de productes digitals? Spotify, Yandex, Uber són empreses que ara es troben al cim del progrés tecnològic.
Feu-vos aquestes preguntes i, si totes les respostes són no, potser no hauríeu de fer DevOps en aquesta empresa. Si el tema de DevOps us interessa realment, potser... hauríeu de traslladar-vos a una altra empresa? Si la vostra empresa vol entrar a DevOps, però heu respost "No" a totes les preguntes, és com aquell bell rinoceront que mai canviarà.
Organització
Com he dit, segons la Llei de Conway, l'organització d'una empresa canvia. Començaré pel que impedeix que DevOps penetri dins de l'empresa des del punt de vista organitzatiu.
El problema dels "pous"
La paraula anglesa "Silo" es tradueix aquí al rus com "bé". El punt d'aquest problema és que no hi ha intercanvi d'informació entre equips. Cada equip aprofundeix en la seva experiència, sense construir un mapa comú per navegar.
D'alguna manera això em recorda a una persona que acaba d'arribar a Moscou i encara no sap com navegar pel mapa del metro. Els moscovites acostumen a conèixer molt bé la seva zona, i per tot Moscou poden navegar mitjançant el mapa del metro. Quan véns a Moscou per primera vegada, no tens aquesta habilitat i només estàs desorientat.
DevOps suggereix superar aquest moment de desorientació i que tots els departaments treballin junts per construir un mapa d'interacció comú.
Dos factors ho dificulten.
Conseqüència del sistema de gestió corporatiu. Està construït en "pous" jeràrquics separats. Per exemple, hi ha certs KPI a les empreses que admeten aquest sistema. D'altra banda, el cervell d'una persona que té dificultats per anar més enllà dels límits de la seva experiència i navegar per tot el sistema s'interposa en el camí. Simplement és incòmode. Imagineu-vos que esteu a l'aeroport de Bangkok; no us trobareu ràpidament. DevOps també és difícil de navegar, i per això la gent diu que cal trobar una guia per arribar-hi.
Però el més important és que el problema dels "pous" per a un enginyer que està imbuït de l'esperit de DevOps, ha llegit Fowler i un munt d'altres llibres, s'expressa en el fet que Els "pous" no et permeten fer coses "òbvies".. Sovint ens reunim després de DevOps Moscou, parlem entre ells i la gent es queixa:
— Només volíem posar en marxa CI, però va resultar que la direcció no ho necessitava.
Això passa precisament perquè CI и Procés de lliurament continu estan a la frontera de molts exàmens. Simplement sense superar el problema dels “pous” a nivell organitzatiu, no podràs avançar, facis el que facis i per molt trist que sigui.
Cada participant en el procés a l'empresa: desenvolupadors backend i frontend, proves, DBA, operació, xarxa, excava en la seva pròpia direcció, i ningú té un mapa comú excepte el gestor, que d'alguna manera els supervisa i els gestiona mitjançant el "divide". i conquerir”.
La gent està lluitant per algunes estrelles o banderes, tothom està excavant la seva experiència.
Com a resultat, quan sorgeix la tasca de connectar tot això i construir un gasoducte comú, i ja no cal lluitar per estrelles i banderes, sorgeix la pregunta: què fer de totes maneres? Hem d'arribar a un acord d'alguna manera, però ningú ens va ensenyar com fer-ho a l'escola. Ens han ensenyat des de l'escola: vuitè de primària - vaja! - en comparació amb setè grau! Aquí és el mateix.
Passa el mateix a la teva empresa?
Per comprovar-ho, pots fer-te les preguntes següents.
Els equips utilitzen eines comunes i contribueixen als canvis en aquestes eines comunes?
Amb quina freqüència es reorganitzen els equips: alguns especialistes d'un equip es traslladen a un altre? És en un entorn DevOps on això es torna normal, perquè de vegades una persona simplement no pot entendre què està fent una altra àrea d'experiència. Es trasllada a un altre departament, hi treballa durant dues setmanes per crear-se un mapa d'orientació i interacció amb aquest departament.
És possible formar una comissió de canvi i canviar les coses? O requereix la mà forta de la màxima direcció i direcció? Fa poc vaig escriure a Facebook com un banc poc conegut està implementant eines a través de comandes: escrivim una comanda, la implementem durant un any i veiem què passa. Això, per descomptat, és llarg i trist.
Què tan important és que els directius rebin èxits personals sense tenir en compte els èxits de l'empresa?
Si responeu aquestes preguntes per vosaltres mateixos, quedarà més clar si teniu aquest problema a la vostra empresa.
Infraestructura com a codi
Un cop superat aquest problema, la primera pràctica important, sense la qual és difícil avançar més en DevOps, és infraestructura com a codi.
Molt sovint, la infraestructura com a codi es percep de la següent manera:
— Automatitzem-ho tot a bash, cobreix-nos amb scripts perquè els administradors tinguin menys feina manual!
Però això no és cert.
La infraestructura com a codi significa que descriu el sistema informàtic amb el qual treballeu en forma de codi per entendre constantment el seu estat.
Juntament amb altres equips, creeu un mapa en forma de codi que tothom pot entendre i pot navegar i navegar. No importa en què es faci: Chef, Ansible, Salt o utilitzar fitxers YAML a Kubernetes, no hi ha cap diferència.
A la conferència, un company de 2GIS va explicar com van fer la seva pròpia cosa interna per a Kubernetes, que descriu l'estructura dels sistemes individuals. Per descriure 500 sistemes, necessitaven una eina separada que generi aquesta descripció. Quan hi ha aquesta descripció, tothom pot consultar entre ells, controlar els canvis, com canviar-lo i millorar-lo, què falta.
D'acord, els scripts bash individuals normalment no proporcionen aquesta comprensió. En una de les empreses on vaig treballar, fins i tot hi havia un nom per al guió "només escriptura", quan s'escriu el guió, però ja no és possible llegir-lo. Crec que això també us és familiar.
La infraestructura com és el codi codi que descriu l'estat actual de la infraestructura. Molts equips de productes, infraestructures i serveis treballen junts en aquest codi i, el més important, tots han d'entendre com funciona realment aquest codi.
El codi es manté d'acord amb les millors pràctiques de codi: desenvolupament conjunt, revisió de codi, programació XP, proves, sol·licituds d'extracció, CI per a infraestructures de codi: tot això és adequat i es pot utilitzar.
El codi esdevé un llenguatge comú per a tots els enginyers.
Canviar la infraestructura en el codi no requereix gaire temps. Sí, el codi d'infraestructura també pot tenir deute tècnic. Normalment, els equips s'hi troben un any i mig després d'haver començat a implementar "infraestructura com a codi" en forma d'un munt d'scripts o fins i tot Ansible, que escriuen com a codi spaghetti, i també incorporen scripts bash a la barreja!
És important: Si encara no heu provat aquestes coses, recordeu-ho Ansible no és bash! Llegiu atentament la documentació, estudieu què escriuen sobre ella.
La infraestructura com a codi és la separació del codi d'infraestructura en capes separades.
A la nostra empresa, distingim 3 capes bàsiques, que són molt clares i senzilles, però poden ser-ne més. Podeu mirar el vostre codi d'infraestructura i dir si teniu aquesta condició o no. Si no hi ha capes ressaltades, haureu de prendre una mica de temps i refactoritzar una mica.
capa base - així és com es configuren el sistema operatiu, les còpies de seguretat i altres coses de baix nivell, per exemple, com es desplega Kubernetes al nivell bàsic.
Nivell de servei - aquests són els serveis que proporcioneu al desenvolupador: registre com a servei, seguiment com a servei, base de dades com a servei, equilibrador com a servei, cua com a servei, lliurament continu com a servei: un munt de serveis que els equips individuals pot aportar al desenvolupament. Tot això s'ha de descriure en mòduls separats al vostre sistema de gestió de configuració.
La capa on es fan les aplicacions i descriu com es desplegaran a sobre de les dues capes anteriors.
Preguntes de control
La vostra empresa té un repositori d'infraestructura comú? Esteu gestionant el deute tècnic de la vostra infraestructura? Utilitzeu pràctiques de desenvolupament en un repositori d'infraestructura? La vostra infraestructura està dividida en capes? Podeu consultar el diagrama Base-service-APP. Què tan difícil és fer un canvi?
Si heu experimentat que va trigar un dia i mig a fer canvis, això vol dir que teniu un deute tècnic i heu de treballar-hi. Acabeu de trobar un deute tècnic al vostre codi d'infraestructura. Recordo moltes històries d'aquest tipus quan, per canviar alguns CCTL, cal reescriure la meitat del codi d'infraestructura, perquè la creativitat i el desig d'automatitzar-ho tot van fer que tot estigui corroït a tot arreu, s'hagin eliminat totes les nanses i cal refactoritzar.
Lliurament continu
Comparem el dèbit amb el crèdit. Primer ve una descripció de la infraestructura, que pot ser força bàsica. No heu de descriure-ho tot amb detall, però cal una descripció bàsica perquè pugueu treballar-hi. En cas contrari, no està clar què fer amb el lliurament continu. Totes aquestes pràctiques es desenvolupen simultàniament quan arribeu a DevOps, però comença per comprendre què teniu i com gestionar-ho. Aquesta és precisament la pràctica de la infraestructura com a codi.
Un cop quedeu clar que el teniu i com gestionar-lo, comenceu a esbrinar com enviar el codi de desenvolupador a producció el més ràpidament possible. Vull dir que juntament amb el desenvolupador, recordem el problema dels "pous", és a dir, no són persones individuals les que ho fan, sinó un equip.
Quan estem amb Vania Evtukhovich vaig veure el primer llibre Jez Humble i grups d'autors "Enviament continu", que es va estrenar el 2009, vam pensar durant molt de temps com traduir el seu títol al rus. El volien traduir com a "Enviament constant", però, malauradament, es va traduir com "Enviament continu". Em sembla que hi ha alguna cosa de rus en el nostre nom, amb pressió.
Lliurament constant de mitjans
El codi que es troba al repositori del producte sempre es pot descarregar a producció. Potser no està desinflat, però sempre està preparat per a això. En conseqüència, sempre escriviu codi amb una sensació d'ansietat difícil d'explicar sota el coxis. Sovint apareix quan desplegueu el codi d'infraestructura. Aquesta sensació d'ansietat hauria d'estar present: desencadena processos cerebrals que us permeten escriure codi una mica diferent. Això s'ha de registrar a les normes dins del desenvolupament.
Per oferir-los de manera coherent, necessiteu un format d'artefacte que s'executi a través d'una plataforma d'infraestructura. Si llenceu "residus de vida" de diferents formats a través d'una plataforma d'infraestructura, aleshores s'unifica, és difícil de mantenir i sorgeix el problema del deute tècnic. El format de l'artefacte s'ha d'alinear; aquesta també és una tasca col·lectiva: tots ens hem d'ajuntar, ens hem d'enfonsar el cervell i arribar a aquest format.
L'artefacte es millora contínuament i canvia per adaptar-se a l'entorn de producció a mesura que es mou pel canal de lliurament. Quan un artefacte es mou al llarg de la canonada, es troba constantment amb algunes coses que li resulten inconvenients, que són similars a les que es troba l'artefacte que poseu en producció. Si en el desenvolupament clàssic ho fa un administrador del sistema que fa el llançament, aleshores en el procés DevOps això passa tot el temps: aquí ho van provar amb algunes proves, aquí ho van llançar a un clúster de Kubernetes, que és més o menys semblant. a la producció, de sobte van començar les proves de càrrega.
Això recorda una mica el joc Pac-Man: l'artefacte passa per algun tipus d'història. Al mateix temps, és important controlar si el codi realment passa per la història i si està relacionat d'alguna manera amb la vostra producció. Les històries de producció es poden arrossegar al procés de lliurament continu: va ser així quan va caure alguna cosa, ara només programem aquest escenari dins del sistema. Cada vegada que el codi també passarà per aquest escenari, i no trobareu aquest problema la propera vegada. Ho aprendràs molt abans que arribi al teu client.
Diferents estratègies de desplegament. Per exemple, utilitzeu proves AB o desplegaments canaris per provar el codi de manera diferent en diferents clients, obtenir informació sobre com funciona el codi i molt abans que quan es distribueix a 100 milions d'usuaris.
"Entrega constantment" té aquest aspecte.
El procés de lliurament Dev, CI, Test, PreProd, Prod no és un entorn separat, es tracta d'etapes o estacions amb sumes a prova de foc per on passa el vostre artefacte.
Si teniu codi d'infraestructura que es descriu com a APP de servei base, us ajudarà no us oblideu de tots els guions, i escriu-los com a codi per a aquest artefacte, promoure l'artefacte i canvieu-ho a mesura que aneu.
Preguntes d'autotest
El temps des de la descripció de la funció fins al llançament en producció en el 95% dels casos és inferior a una setmana? La qualitat de l'artefacte millora en cada etapa de la canonada? Hi ha alguna història per la qual passa? Utilitzeu diferents estratègies de desplegament?
Si totes les respostes són sí, aleshores ets increïblement genial! Escriu les teves respostes als comentaris, estaré encantat).
realimentació
Aquesta és la pràctica més difícil de totes. A la conferència DevOpsConf, un company d'Infobip, parlant-ne, es va mostrar una mica confús en les seves paraules, perquè realment és una pràctica molt complexa sobre el fet que cal controlar-ho tot!
Per exemple, fa molt de temps, quan treballava a Qik i ens vam adonar que calia controlar-ho tot. Vam fer això i ara tenim 150 articles a Zabbix, que es controlen constantment. Va fer por, el director tècnic es va girar el dit a la templa:
- Nois, per què violeu el servidor amb alguna cosa poc clara?
Però aleshores es va produir un incident que va demostrar que aquesta és realment una estratègia molt interessant.
Un dels serveis va començar a fallar constantment. Inicialment, no es va bloquejar, cosa que és interessant, el codi no s'hi va afegir, perquè era un corredor bàsic, que pràcticament no tenia cap funcionalitat empresarial: simplement enviava missatges entre serveis individuals. El servei no va canviar durant 4 mesos i, de sobte, va començar a fallar amb l'error "Falla de segmentació".
Ens va sorprendre, vam obrir els nostres gràfics a Zabbix i va resultar que fa una setmana i mitja, el comportament de les sol·licituds al servei API que utilitza aquest corredor va canviar molt. A continuació vam veure que la freqüència d'enviament d'un determinat tipus de missatge havia canviat. Més tard vam descobrir que es tractava de clients d'Android. Hem preguntat:
— Nois, què us va passar fa una setmana i mitja?
En resposta, vam escoltar una història interessant sobre com havien redissenyat la interfície d'usuari. És poc probable que algú digui immediatament que ha canviat la biblioteca HTTP. Per als clients d'Android, és com canviar el sabó al bany: simplement no ho recorden. Com a resultat, després de 40 minuts de conversa, vam saber que havien canviat la biblioteca HTTP i que els seus horaris predeterminats havien canviat. Això va provocar que el comportament del trànsit al servidor API canviés, cosa que va provocar una situació que va provocar una cursa dins del corredor i va començar a bloquejar-se.
Sense un seguiment profund, generalment és impossible obrir-lo. Si l'organització encara té el problema dels "pous", quan tothom es llença diners els uns als altres, això pot viure durant anys. Simplement reinicieu el servidor perquè és impossible resoldre el problema. Quan superviseu, feu un seguiment, feu un seguiment de tots els esdeveniments que teniu i utilitzeu el monitoratge com a prova: escriviu codi i indiqueu immediatament com controlar-lo, també en forma de codi (ja tenim la infraestructura com a codi), tot queda clar com al palmell. Fins i tot problemes tan complexos es poden rastrejar fàcilment.
Recull tota la informació sobre què passa amb l'artefacte en cada etapa del procés de lliurament, no en producció.
Carregueu el seguiment a CI i algunes coses bàsiques ja seran visibles allà. Més endavant els veureu a Test, PredProd i proves de càrrega. Recolliu informació en totes les etapes, no només mètriques, estadístiques, sinó també registres: com s'ha desplegat l'aplicació, anomalies: recull-ho tot.
En cas contrari, serà difícil esbrinar-ho. Ja he dit que DevOps és més complex. Per fer front a aquesta complexitat, cal tenir analítiques normals.
Preguntes per a l'autocontrol
El vostre seguiment i registre és l'eina de desenvolupament per a vosaltres? Quan escriu codi, els teus desenvolupadors, inclòs tu, pensen com controlar-lo?
Heu sentit parlar dels problemes dels clients? Enteneu millor el client mitjançant el seguiment i el registre? Enteneu millor el sistema a partir del seguiment i el registre? Canvies de sistema simplement perquè has vist que la tendència del sistema està creixent i entens que d'aquí a 3 setmanes tot es morirà?
Un cop tingueu aquests tres components, podeu pensar quin tipus de plataforma d'infraestructura teniu a la vostra empresa.
Plataforma d'infraestructures
La qüestió no és que es tracti d'un conjunt d'eines dispars que té cada empresa.
L'objectiu d'una plataforma d'infraestructura és que tots els equips utilitzen aquestes eines i les desenvolupen junts.
És evident que hi ha equips separats que s'encarreguen del desenvolupament de peces individuals de la plataforma d'infraestructura. Però al mateix temps, cada enginyer té la responsabilitat del desenvolupament, el rendiment i la promoció de la plataforma d'infraestructura. A nivell intern es converteix en una eina comuna.
Tots els equips desenvolupen la plataforma d'infraestructura i la tracten amb cura com el seu propi IDE. Al vostre IDE instal·leu diferents connectors perquè tot sigui agradable i ràpid, i configureu les tecles d'accés directe. Quan obriu Sublime, Atom o Visual Studio Code, hi arriben errors de codi i us adoneu que és impossible funcionar, de seguida et sents trist i corres per arreglar el teu IDE.
Tracteu la vostra plataforma d'infraestructura de la mateixa manera. Si enteneu que hi ha alguna cosa malament, deixeu una sol·licitud si no podeu solucionar-ho vosaltres mateixos. Si hi ha alguna cosa senzilla, editeu-la vosaltres mateixos, envieu una sol·licitud d'extracció, els nois ho tindran en compte i l'afegiran. Aquest és un enfocament lleugerament diferent de les eines d'enginyeria al cap del desenvolupador.
La plataforma d'infraestructura garanteix la transferència de l'artefacte del desenvolupament al client amb una millora contínua de la qualitat. La IP està programada amb un conjunt d'històries que succeeixen amb el codi en producció. Al llarg dels anys de desenvolupament, hi ha moltes d'aquestes històries, algunes d'elles són úniques i només es relacionen amb tu; no es poden buscar a Google.
En aquest punt, la plataforma d'infraestructura es converteix en el vostre avantatge competitiu, perquè té alguna cosa incorporada que no està a l'eina del competidor. Com més profunda sigui la vostra IP, més gran serà el vostre avantatge competitiu en termes de temps de sortida al mercat. Apareix aquí problema de bloqueig del proveïdor: Pots agafar la plataforma d'una altra persona, però utilitzant l'experiència d'una altra persona, no entendràs com de rellevant és per a tu. Sí, no totes les empreses poden crear una plataforma com Amazon. Aquesta és una línia difícil on l'experiència de l'empresa és rellevant per a la seva posició al mercat i no podeu utilitzar un bloqueig de proveïdor allà. Això també és important pensar-hi.
L'esquema
Aquest és un diagrama bàsic d'una plataforma d'infraestructura que us ajudarà a configurar totes les pràctiques i processos d'una empresa DevOps.
Vegem en què consisteix.
Sistema d'orquestració de recursos, que proporciona CPU, memòria, disc a aplicacions i altres serveis. A més d'això - serveis de baix nivell: monitorització, registre, motor CI/CD, emmagatzematge d'artefactes, infraestructura com a codi del sistema.
Serveis de nivell superior: base de dades com a servei, cues com a servei, Balanç de càrrega com a servei, redimensionament de la imatge com a servei, fàbrica de Big Data com a servei. A més d'això - pipeline que ofereix codi modificat constantment al vostre client.
Rebeu informació sobre com funciona el vostre programari per al client, el canvieu, torneu a subministrar aquest codi, rebeu informació i, per tant, desenvolupeu constantment tant la plataforma d'infraestructura com el vostre programari.
Al diagrama, la canalització de lliurament consta de moltes etapes. Però aquest és un diagrama esquemàtic que es posa com a exemple, no cal repetir-lo un per un. Les etapes interactuen amb els serveis com si fossin serveis: cada maó de la plataforma porta la seva pròpia història: com s'assignen els recursos, com s'inicia l'aplicació, com funciona amb els recursos, es controla i canvia.
És important entendre que cada part de la plataforma porta una història, i preguntar-se quina història porta aquest maó, potser s'hauria de llençar i substituir-lo per un servei de tercers. Per exemple, és possible instal·lar Okmeter en lloc d'un maó? Potser els nois ja han desenvolupat aquesta experiència molt més que nosaltres. Però potser no, potser tenim una experiència única, hem d'instal·lar Prometheus i desenvolupar-lo més.
Creació de la plataforma
Aquest és un procés de comunicació complex. Quan tens pràctiques bàsiques, inicies la comunicació entre diferents enginyers i especialistes que desenvolupen requisits i estàndards i els canvien constantment a diferents eines i enfocaments. La cultura que tenim a DevOps és important aquí.
Amb la cultura tot és molt senzill - es tracta de col·laboració i comunicació, és a dir, el desig de treballar en un camp comú entre ells, el desig de manejar un instrument junts. Aquí no hi ha ciència de coets: tot és molt senzill, banal. Per exemple, tots vivim a l'entrada i la mantenim neta, un nivell de cultura com aquest.
Que tens?
De nou, preguntes que us podeu fer.
La plataforma d'infraestructura està dedicada? Qui és el responsable del seu desenvolupament? Enteneu els avantatges competitius de la vostra plataforma d'infraestructura?
Heu de fer-vos constantment aquestes preguntes. Si es pot transferir alguna cosa a serveis de tercers, s'hauria de transferir; si un servei de tercers comença a bloquejar el vostre moviment, haureu de crear un sistema dins vostre.
Així, DevOps...
... aquest és un sistema complex, ha de tenir:
- Producte digital.
- Mòduls empresarials que desenvolupen aquest producte digital.
- Equips de producte que escriuen codi.
- Pràctiques de lliurament continu.
- Les plataformes com a servei.
- La infraestructura com a servei.
- Infraestructura com a codi.
- Pràctiques separades per mantenir la fiabilitat, integrades a DevOps.
- Una pràctica de retroalimentació que ho descriu tot.
Podeu utilitzar aquest diagrama, destacant-hi el que ja teniu a la vostra empresa d'alguna manera: s'ha desenvolupat o encara s'ha de desenvolupar.
S'acabarà d'aquí a un parell de setmanes . com a part de RIT++. Vine a la conferència, on trobaràs molts informes interessants sobre el lliurament continu, la infraestructura com a codi i la transformació de DevOps. , l'últim termini de preus és el 20 de maig
Font: www.habr.com