És difícil entendre el punt principal quan es parla de DevOps? Hem recollit per a tu vívids analogies, formulacions sorprenents i consells d'experts que ajudaran fins i tot als no especialistes a arribar al punt. Al final, la bonificació és el DevOps propi dels empleats de Red Hat.
El terme DevOps es va originar fa 10 anys i ha passat d'un hashtag de Twitter a un poderós moviment cultural al món de les TI, una autèntica filosofia que anima els desenvolupadors a fer les coses més ràpidament, experimentar i iterar endavant. DevOps s'ha vinculat inextricablement amb el concepte de transformació digital. Però, com passa sovint amb la terminologia informàtica, durant els últims deu anys DevOps ha adquirit moltes definicions, interpretacions i idees errònies sobre si mateix.
Per tant, sovint podeu escoltar preguntes sobre DevOps com, és el mateix que àgil? O és una metodologia especial? O és només un sinònim més de la paraula "col·laboració"?
DevOps inclou molts conceptes diferents (entrega contínua, integració contínua, automatització, etc.), de manera que destil·lar allò que és important pot ser un repte, sobretot quan us apassiona el tema. No obstant això, aquesta habilitat és molt útil, tant si estàs intentant transmetre les teves idees als teus superiors com si simplement li parles de la teva feina a algú de la teva família o amics. Per tant, deixem de banda els matisos terminològics de DevOps de moment i centrem-nos en el panorama general.
Què és DevOps: 6 definicions i analogies
Hem demanat als experts que expliquin l'essència de DevOps de la manera més senzilla i breu possible perquè el seu valor quedi clar per als lectors amb qualsevol nivell de coneixement tècnic. A partir dels resultats d'aquestes converses, hem seleccionat les analogies i les formulacions més sorprenents que us ajudaran a construir la vostra història sobre DevOps.
1. DevOps és un moviment cultural
"DevOps és un moviment cultural en el qual ambdues parts (desenvolupadors de programari i especialistes en operacions de sistemes informàtics) reconeixen que el programari no aporta beneficis reals fins que algú comença a utilitzar-lo: clients, clients, empleats, no la qüestió", diu Eveline Oehrlich, investigadora sènior. analista del DevOps Institute. "Per tant, ambdues parts garanteixen conjuntament un lliurament ràpid i d'alta qualitat del programari".
2. DevOps tracta de potenciar els desenvolupadors.
"DevOps permet als desenvolupadors a posseir aplicacions, executar-les i gestionar el lliurament de principi a fi".
"En general, es parla de DevOps com una manera d'accelerar el lliurament d'aplicacions a la producció mitjançant la creació i implementació de processos automatitzats", diu Jai Schniepp, director de plataformes DevOps de la companyia d'assegurances Liberty Mutual. "Però per a mi és una cosa molt més fonamental". DevOps permet als desenvolupadors posseir aplicacions o peces de programari específiques, executar-les i gestionar-ne el lliurament de principi a fi. DevOps elimina la confusió de responsabilitat i guia tots els implicats en la creació d'una infraestructura automatitzada, impulsada pels desenvolupadors".
3. DevOps tracta de la col·laboració en la creació i el lliurament d'aplicacions.
"En poques paraules, DevOps és un enfocament de la producció i lliurament de programari on tothom treballa junts", diu Gur Staf, president i cap d'automatització empresarial digital de BMC.
4. DevOps és un pipeline
"El muntatge de la cinta transportadora només és possible si totes les peces encaixen juntes".
"Compararia DevOps amb una línia de muntatge de cotxes", continua Gur Staff. – La idea és dissenyar i fabricar totes les peces amb antelació perquè després es puguin muntar sense ajustament individual. El muntatge de la cinta transportadora només és possible si totes les peces encaixen. Els que dissenyen i construeixen un motor han de plantejar-se com muntar-lo a la carrosseria o al marc. Els que fan els frens han de pensar en les rodes, etc. El mateix hauria de passar amb el programari.
Un desenvolupador que crea una lògica de negoci o una interfície d'usuari ha de pensar en la base de dades que emmagatzema la informació del client, les mesures de seguretat per protegir les dades dels usuaris i com funcionarà tot això quan el servei comenci a servir una gran audiència d'usuaris, potser fins i tot multimilionària. ."
“Aconseguir que la gent col·labori i pensi en les parts de la feina que fan els altres, en lloc de centrar-se només en les seves pròpies tasques, és el major obstacle a superar. Si pots fer-ho, tens una excel·lent oportunitat de transformació digital", afegeix Gur Staff.
5. DevOps és la combinació adequada de persones, processos i automatització
Jayne Groll, directora executiva de l'Institut DevOps, va oferir una gran analogia per explicar DevOps. Segons les seves paraules, "DevOps és com una recepta amb tres categories principals d'ingredients: persones, procés i automatització. La majoria d'aquests ingredients es poden extreure d'altres àrees i fonts: Lean, Agile, SRE, CI/CD, ITIL, lideratge, cultura, eines. El secret de DevOps, com qualsevol bona recepta, és com obtenir les proporcions adequades i barrejar aquests ingredients per augmentar la velocitat i l'eficiència de la creació i el llançament d'aplicacions".
6. DevOps és quan els programadors treballen com un equip de Fórmula 1
"La cursa no està planificada de principi a fi, sinó al contrari, de final a principi".
"Quan parlo de què esperar d'una iniciativa de DevOps, penso en un equip de carreres de NASCAR o de Fórmula 1 com a exemple", diu Chris Short, director sènior de màrqueting de plataformes al núvol de Red Hat i editor del butlletí de DevOps. – El líder d'un equip d'aquest tipus té un objectiu: ocupar el lloc més alt possible al final de la cursa, tenint en compte els recursos de què disposa l'equip i els reptes que li van sorgir. En aquest cas, la cursa es planifica no de principi a fi, sinó al contrari, de final a començament. En primer lloc, s'estableix un objectiu ambiciós i després es determinen les maneres d'aconseguir-lo. Després es divideixen en subtasques i es deleguen als membres de l'equip".
“L'equip es passa tota la setmana abans de la cursa perfeccionant la parada en boxes. Fa entrenament de força i cardio per mantenir-se en forma durant un dia de cursa esgotador. Pràctiques de treball conjunt per resoldre els problemes que puguin sorgir durant la cursa. De la mateixa manera, l'equip de desenvolupament hauria d'entrenar l'habilitat de llançar noves versions amb freqüència. Si teniu aquestes habilitats i un sistema de seguretat que funciona bé, el llançament de noves versions a la producció també passa amb més freqüència. En aquesta visió del món, augmentar la velocitat significa augmentar la seguretat", diu Short.
"No es tracta de fer el" correcte ", afegeix Short, "es tracta d'eliminar tantes coses com sigui possible que s'oposin al resultat desitjat. Col·labora i adapta en funció dels comentaris que rebeu en temps real. Estigueu preparat per a les anomalies i treballeu per millorar la qualitat per minimitzar el seu impacte en el progrés cap al vostre objectiu. Això és el que ens espera al món de DevOps".
Com escalar DevOps: 10 consells d'experts
És només que DevOps i DevOps massius són coses completament diferents. T'explicarem com superar barreres en el camí de la primera a la segona.
Per a moltes organitzacions, el viatge cap a DevOps comença de manera fàcil i agradable. Es creen petits equips apassionats, es substitueixen processos antics per nous i els primers èxits no es fan esperar.
Per desgràcia, això és només un fals brillantor, una il·lusió de progrés, diu Ben Grinnell, director general i cap de digital de la consultoria North Highland. Les primeres victòries són certament encoratjadores, però no ajuden a assolir l'objectiu final d'adopció generalitzada de DevOps a tota l'organització.
És fàcil veure que el resultat és una cultura de divisió entre “nosaltres” i “ells”.
"Sovint, les organitzacions llancen aquests projectes pioners pensant que obriran el camí per a DevOps convencionals, sense considerar si altres podran o estaran disposats a seguir aquest camí", explica Ben Grinnell. – Els equips per implementar aquest tipus de projectes solen ser reclutats entre "varangs" segurs que ja han fet alguna cosa semblant en altres llocs, però que són nous a la vostra organització. Al mateix temps, se'ls anima a trencar i destruir les regles que segueixen sent vinculants per a tots els altres. És fàcil veure que el resultat és una cultura de "nosaltres" i "ells" que inhibeix la transferència de coneixements i habilitats".
"I aquest problema cultural és només una de les raons per les quals DevOps és difícil d'escalar. Els equips de DevOps s'enfronten a reptes tècnics creixents que són típics de les empreses de primeres TI de ràpid creixement", va dir Steve Newman, fundador i president de Scalyr.
“En el món modern, els serveis canvien tan bon punt sorgeix la necessitat. És fantàstic implementar i implementar noves funcions constantment, però coordinar aquest procés i eliminar els problemes que sorgeixen és un veritable maldecap, afegeix Steve Newman. – A les organitzacions de creixement molt ràpid, els enginyers dels equips multifuncionals lluiten per mantenir la visibilitat del canvi i dels efectes en cascada a nivell de dependència que genera. A més, els enginyers no estan contents quan se'ls priva d'aquesta oportunitat i, com a conseqüència, els resulta més difícil entendre l'essència dels problemes que sorgeixen”.
Com superar aquests reptes descrits anteriorment i passar a l'adopció massiva de DevOps en una gran organització? Els experts demanen paciència, fins i tot si el vostre objectiu final és accelerar el cicle de desenvolupament de programari i els processos de negoci.
1. Recordeu que el canvi de cultura requereix temps.
Jayne Groll, directora executiva, DevOps Institute: "En la meva opinió, l'expansió de DevOps hauria de ser tan incremental i iterativa com el desenvolupament àgil (i igualment afectant la cultura). Agile i DevOps posen èmfasi en equips petits. Però a mesura que aquests equips creixen en nombre i integració, acabem amb més persones adoptant noves maneres de treballar i, com a resultat, hi ha una transformació cultural massiva”.
2. Dedica prou temps a planificar i triar una plataforma
Eran Kinsbruner, evangelista tècnic principal de Perfecto: "Per tal que funcioni, els equips de DevOps primer han d'aprendre a combinar processos, eines i habilitats tradicionals, i després nodrir i estabilitzar lentament cada fase individual de DevOps. Tot comença amb una planificació acurada de les històries d'usuari i els fluxos de valor, seguit de l'escriptura de programari i control de versions mitjançant el desenvolupament basat en troncs o altres enfocaments més adequats per a ramificar i combinar codi".
"Després ve l'etapa d'integració i prova, on ja es requereix una plataforma escalable per a l'automatització. Aquí és on és important que els equips de DevOps triïn la plataforma adequada que s'adapti al seu nivell d'habilitat i als objectius finals del projecte.
La següent fase és el desplegament a producció i això s'hauria d'automatitzar completament mitjançant eines i contenidors d'orquestració. És important tenir entorns virtualitzats en totes les etapes de DevOps (simulador de producció, entorn de control de qualitat i entorn de producció real) i utilitzar sempre només les dades més recents per a les proves per obtenir conclusions rellevants. L'anàlisi ha de ser intel·ligent i capaç de processar grans dades amb comentaris ràpids i útils".
3. Treu la culpa de la responsabilitat.
Gordon Haff, evangelista de RedHat: "La creació d'un sistema i una atmosfera que permetin i fomentin l'experimentació permeten el que es coneix com a fracassos d'èxit en el desenvolupament àgil de programari. Això no vol dir que ningú més sigui responsable dels fracassos. De fet, identificar qui és el responsable es fa encara més fàcil, ja que "ser responsable" ja no significa "provocar un accident". És a dir, l'essència de la responsabilitat canvia qualitativament. Quatre factors esdevenen crítics: l'abast de la interrupció, els enfocaments, els processos de producció i els incentius". (Podeu llegir més sobre aquests factors a l'article de Gordon Huff "Lliçons de DevOps: 4 aspectes dels experiments saludables").
4. Netegeu el camí cap endavant
Ben Grinnell, director general i cap de digital de la consultoria North Highland: "Per assolir l'escala, recomano llançar un programa de neteja de camins juntament amb projectes pioners. L'objectiu d'aquest programa és netejar les escombraries que els pioners de DevOps deixen enrere, com ara regles obsoletes i coses com aquestes, perquè el camí a seguir quedi clar".
“Donar suport i impuls organitzatiu a la gent mitjançant una comunicació que va molt més enllà del grup pioner celebrant àmpliament els èxits de les noves maneres de treballar. Entrena persones que estan involucrades en la propera onada de projectes DevOps i estan nervioses per utilitzar DevOps per primera vegada. I recordeu que aquesta gent és molt diferent dels pioners”.
5. Democratitzar les eines
Steve Newman, fundador i president de Scalyr: "Les eines no s'han d'amagar a la gent i haurien de ser relativament fàcils d'aprendre per a qualsevol que vulgui dedicar-hi el temps. Si la capacitat de consultar els registres està restringida a tres persones "certificades" per utilitzar una eina, sempre tindreu un màxim de tres persones disponibles per gestionar el problema, fins i tot si teniu un entorn informàtic molt gran. En altres paraules, aquí hi ha un coll d'ampolla que pot tenir conseqüències (de negocis) greus".
6. Crear les condicions ideals per al treball en equip
Tom Clark, cap de Common Platform a ITV: "Pots fer qualsevol cosa, però no tot alhora. Així que establiu grans objectius, comenceu de petit i avança en iteracions ràpides. Amb el pas del temps, desenvoluparàs una reputació per fer les coses, de manera que els altres també voldran utilitzar els teus mètodes. I no us preocupeu per crear un equip altament eficaç. En comptes d'això, proporcioneu a la gent condicions de treball ideals i l'eficiència seguirà".
7. No us oblideu de la Llei de Conway i els taulers Kanban
Logan Daigle, director de lliurament de programari i estratègia DevOps a CollabNetVersionOne: "És important entendre les conseqüències de la llei de Conway. En la meva paràfrasis fluixa, aquesta llei estableix que els productes que creem i els processos que fem servir per fer-ho, inclòs DevOps, resulten estar estructurats de la mateixa manera que la nostra organització".
"Si hi ha moltes sitges en una organització i el control canvia de mans moltes vegades quan es planifica, construeix i llança programari, l'efecte de l'escala serà nul o de curta durada. Si una organització crea equips multifuncionals al voltant de productes finançats amb un focus de mercat, les possibilitats d'èxit augmenten dràsticament".
"Un altre aspecte important de l'escala és mostrar tot el treball en curs (WIP, work inprogress) als taulers Kanban. Quan una organització té un lloc on la gent pot veure aquestes coses, fomenta molt la col·laboració, la qual cosa té un impacte positiu en l'escala".
8. Busca cicatrius velles
Manuel Pais, consultor de DevOps i coautor de Team Topologies: "Prendre les pràctiques de DevOps més enllà de Dev i Ops i intentar aplicar-les a altres funcions no és gaire un enfocament òptim. Sens dubte, això tindrà un cert impacte (per exemple, automatitzant el control manual), però es pot aconseguir molt més si comencem per comprendre els processos de lliurament i retroalimentació".
“Si hi ha cicatrius antigues en el sistema informàtic d'una organització (procediments i mecanismes de gestió que es van implementar com a conseqüència d'incidents passats, però que han perdut la seva rellevància (a causa dels canvis en els productes, tecnologies o processos)), sens dubte s'han d'eliminar. o suavitzat, en lloc d'automatitzar processos ineficients o innecessaris".
9. No genereu opcions DevOps
Anthony Edwards, director d'operacions d'Eggplant: "DevOps és un terme molt vague, de manera que cada equip acaba amb la seva pròpia versió de DevOps. I no hi ha res pitjor quan una organització té de sobte 20 varietats de DevOps que no es porten gaire bé juntes. És impossible que cadascun dels tres equips de desenvolupament tingui la seva pròpia interfície especial entre desenvolupament i gestió de productes. Tampoc els productes haurien de tenir les seves pròpies expectatives úniques per a la gestió dels comentaris quan es transfereixen a un simulador de producció. En cas contrari, mai podreu escalar DevOps".
10. Prediqui el valor empresarial de DevOps
Steve Newman, fundador i president de Scalyr: "Treballeu per reconèixer el valor de DevOps. Apreneu i no dubteu a parlar sobre els beneficis del que feu. DevOps és un increïble estalvi de temps i diners (pensa: menys temps d'inactivitat, menys temps mitjà per a la recuperació) i els equips de DevOps han d'emfatitzar (i predicar) incansablement la importància d'aquestes iniciatives per a l'èxit empresarial. D'aquesta manera podeu ampliar el cercle d'adherents i augmentar la influència de DevOps a l'organització".
PRIMA
En El nostre propi DevOps arribarà el 13 de setembre; sí, Red Hat, com a fabricant de programari, té els seus propis equips i pràctiques de DevOps.
El nostre enginyer Mark Birger, que desenvolupa serveis d'automatització interna per a altres grups de l'organització, explicarà la seva pròpia història en rus pur: com l'equip de Red Hat DevOps va migrar aplicacions dels entorns virtuals de virtualització de Hat gestionats per Ansible a un format de contenidor complet a la plataforma OpenShift.
Però això no és tot:
Un cop les organitzacions hagin traslladat les càrregues de treball als contenidors, és possible que els mètodes tradicionals de supervisió d'aplicacions no funcionin. En la segona xerrada explicarem la nostra motivació per canviar la manera de registrar i mostrar la continuació del camí que ens va portar als mètodes moderns de registre i seguiment.
Font: www.habr.com