Ĉu estas malfacile kompreni la ĉefan punkton kiam oni parolas pri DevOps? Ni kolektis por vi viglajn analogojn, frapajn formulojn kaj konsilojn de spertuloj, kiuj helpos eĉ ne-specialistojn atingi la punkton. Fine, la gratifiko estas DevOps de la dungitoj de Red Hat.
La termino DevOps ekestis antaŭ 10 jaroj kaj pasis de Twitter-haŝetikedo al potenca kultura movado en la IT-mondo, vera filozofio, kiu instigas programistojn fari aferojn pli rapide, eksperimenti kaj ripetadi antaŭen. DevOps fariĝis nedisigeble ligita kun la koncepto de cifereca transformo. Sed kiel ofte okazas kun IT-terminologio, dum la lastaj dek jaroj DevOps akiris multajn difinojn, interpretojn kaj miskomprenojn pri si mem.
Sekve, vi ofte povas aŭdi demandojn pri DevOps kiel, ĉu ĝi samas kiel lerta? Aŭ ĉu ĉi tio estas speciala metodaro? Aŭ ĉu ĝi estas nur alia sinonimo de la vorto "kunlaboro"?
DevOps inkluzivas multajn malsamajn konceptojn (kontinua livero, kontinua integriĝo, aŭtomatigo, ktp.), do distili tion gravan povas esti malfacila, precipe kiam vi estas pasia pri la temo. Tamen, ĉi tiu lerteco estas tre utila, negrave ĉu vi provas transdoni viajn ideojn al viaj superuloj aŭ simple rakonti al iu el via familio aŭ amikoj pri via laboro. Tial ni flankenlasu la terminologiajn nuancojn de DevOps nuntempe kaj koncentriĝu pri la granda bildo.
Kio estas DevOps: 6 Difinoj kaj Analogioj
Ni petis spertulojn klarigi la esencon de DevOps kiel eble plej simple kaj mallonge, por ke ĝia valoro evidentiĝu al legantoj kun ajna nivelo de teknika scio. Surbaze de la rezultoj de ĉi tiuj konversacioj, ni elektis la plej frapajn analogiojn kaj frapajn formulojn, kiuj helpos vin konstrui vian rakonton pri DevOps.
1. DevOps estas kultura movado
"DevOps estas kultura movado, en kiu ambaŭ partioj (programistoj kaj specialistoj pri operaciado de IT-sistemo) rekonas, ke programaro ne alportas realajn avantaĝojn ĝis iu komencas uzi ĝin: klientoj, klientoj, dungitoj, ne la afero," diras Eveline Oehrlich, altranga esploristo. analizisto ĉe la DevOps Instituto. "Sekve, ambaŭ ĉi tiuj partioj kune certigas rapidan kaj altkvalitan liveron de programaro."
2. DevOps temas pri povigi programistojn.
"DevOps rajtigas programistojn posedi aplikojn, ruli ilin kaj administri liveron de komenco ĝis fino."
"Tipe, DevOps estas parolata pri maniero akceli la liveron de aplikoj al produktado per konstruado kaj efektivigo de aŭtomataj procezoj," diras Jai Schniepp, direktoro de DevOps-platformoj ĉe asekura kompanio Liberty Mutual. "Sed por mi ĝi estas multe pli fundamenta afero." DevOps rajtigas programistojn posedi aplikojn aŭ specifajn programojn, ruli ilin kaj administri ilian liveron de komenco ĝis fino. DevOps forigas respondeckonfuzon kaj gvidas ĉiujn implikitajn en kreado de aŭtomatigita, programisto-movita infrastrukturo."
3. DevOps temas pri kunlaboro en kreado kaj liverado de aplikoj.
"Simple, DevOps estas aliro al programaro produktado kaj livero kie ĉiuj laboras kune," diras Gur Staf, prezidanto kaj estro de cifereca komerca aŭtomatigo ĉe BMC.
4. DevOps estas dukto
"Asembleo de transportilo estas ebla nur se ĉiuj partoj kongruas kune."
"Mi komparus DevOps kun aŭtomobila muntado," daŭrigas Gur Staff. – La ideo estas desegni kaj fari ĉiujn partojn anticipe, por ke ili tiam povu esti kunmetitaj sen individua alĝustigo. Transportilaro estas ebla nur se ĉiuj partoj kuniĝas. Tiuj, kiuj desegnas kaj konstruas motoron, devas konsideri kiel munti ĝin al la korpo aŭ kadro. Tiuj, kiuj faras la bremsojn, devas pensi pri la radoj, ktp. La sama devus esti vera kun programaro.
Programisto kreanta komercan logikon aŭ uzantinterfacon devas pensi pri la datumbazo, kiu stokas klientajn informojn, la sekurecajn mezurojn por protekti uzantajn datumojn, kaj kiel ĉio ĉi funkcios kiam la servo komencos servi grandan, eble eĉ multmilionan uzantan publikon. ."
"Igi homojn kunlabori kaj pensi pri la partoj de la laboro, kiujn aliaj faras, prefere ol koncentriĝi nur pri siaj propraj taskoj, estas la plej granda obstaklo por venki. Se vi povas fari tion, vi havas bonegan ŝancon por cifereca transformo, "aldonas Gur Staff.
5. DevOps estas la ĝusta kombinaĵo de homoj, procezoj kaj aŭtomatigo
Jayne Groll, plenuma direktoro de la Instituto DevOps, proponis bonegan analogon por klarigi DevOps. Laŭ ŝiaj vortoj, "DevOps estas kiel recepto kun tri ĉefaj kategorioj da ingrediencoj: homoj, procezo kaj aŭtomatigo. Plej multaj el ĉi tiuj ingrediencoj povas esti prenitaj de aliaj areoj kaj fontoj: Lean, Agile, SRE, CI/CD, ITIL, gvidado, kulturo, iloj. La sekreto de DevOps, kiel ĉiu bona recepto, estas kiel akiri la ĝustajn proporciojn kaj miksi ĉi tiujn ingrediencojn por pliigi la rapidecon kaj efikecon krei kaj liberigi aplikojn."
6. DevOps estas kiam programistoj laboras kiel Formulo 1-teamo
"La vetkuro ne estas planita de komenco ĝis fino, sed male, de fino ĝis komenco."
"Kiam mi parolas pri kio atendi de DevOps-iniciato, mi pensas pri NASCAR aŭ Formulo 1-vetkura teamo kiel ekzemplo," diras Chris Short, altranga manaĝero pri nuba platforma merkatado ĉe Red Hat kaj eldonisto de la novaĵletero de DevOps. – La gvidanto de tia teamo havas unu celon: preni la plej altan eblan lokon ĉe la fino de la vetkuro, konsiderante la rimedojn disponeblajn al la teamo kaj la defiojn kiuj trafis ĝin. En ĉi tiu kazo, la vetkuro estas planita ne de komenco ĝis fino, sed male, de fino ĝis komenco. Unue, ambicia celo estas fiksita, kaj tiam manieroj atingi ĝin estas determinitaj. Poste ili estas dividitaj en subtaskojn kaj delegitaj al teamanoj."
"La teamo pasigas la tutan semajnon antaŭ la vetkuro perfektigante la riparpaŭzejon. Li faras forton kaj kardiotrejnadon por resti en formo dum streĉa vetkura tago. Praktikoj laborantaj kune por solvi ajnajn problemojn kiuj povas ekesti dum la vetkuro. Same, la evolua teamo devus trejni la kapablon publikigi novajn versiojn ofte. Se vi havas tiajn kapablojn kaj bone funkciantan sekurecan sistemon, la lanĉo de novaj versioj en produktadon ankaŭ okazas pli ofte. En ĉi tiu mondkoncepto, pliigita rapideco signifas pliigitan sekurecon,” diras Short.
"Ne temas pri fari 'la ĝustan aferon'," Short aldonas, "ĝi temas pri forigi kiel eble plej multajn aferojn, kiuj malhelpas la deziratan rezulton. Kunlaboru kaj adaptu laŭ la sugestoj, kiujn vi ricevas en reala tempo. Estu preta por anomalioj kaj laboru por plibonigi kvaliton por minimumigi ilian efikon al progreso al via celo. Jen kio atendas nin en la mondo de DevOps."
Kiel grimpi DevOps: 10 konsiletoj de spertuloj
Estas nur, ke DevOps kaj amasa DevOps estas tute malsamaj aferoj. Ni diros al vi kiel venki barojn survoje de la unua al la dua.
Por multaj organizoj, la vojaĝo al DevOps komenciĝas facile kaj agrable. Malgrandaj pasiaj teamoj estas kreitaj, malnovaj procezoj estas anstataŭigitaj per novaj, kaj la unuaj sukcesoj ne longe venos.
Ve, ĉi tio estas nur falsa brilo, iluzio de progreso, diras Ben Grinnell, administra direktoro kaj estro de cifereca ĉe konsultejo North Highland. Fruaj venkoj certe estas kuraĝigaj, sed ili ne helpas atingi la finfinan celon de ĝeneraligita adopto de DevOps tra la organizo.
Estas facile vidi, ke la rezulto estas kulturo de divido inter "ni" kaj "ili".
"Ofte, organizoj lanĉas ĉi tiujn pionirajn projektojn pensante, ke ili pavimos la vojon al ĉefa DevOps, sen konsideri ĉu aliaj povos aŭ volos sekvi tiun vojon," klarigas Ben Grinnell. – Teamoj por efektivigi tiajn projektojn estas kutime varbitaj el memfidaj "Varanganoj", kiuj jam faris ion similan en aliaj lokoj, sed estas novaj al via organizo. Samtempe, ili estas kuraĝigitaj rompi kaj detrui la regulojn, kiuj restas devigaj por ĉiuj aliaj. Estas facile vidi, ke la rezulto estas kulturo de "ni" kaj "ili", kiu malhelpas la translokigon de scio kaj kapabloj."
"Kaj ĉi tiu kultura problemo estas nur unu el la kialoj, ke DevOps estas malfacile skali. DevOps-teamoj alfrontas pliigitajn teknikajn defiojn, kiuj estas karakterizaj por rapide kreskantaj IT-unuaj kompanioj, "diris Steve Newman, fondinto kaj prezidanto de Scalyr.
“En la moderna mondo, servoj ŝanĝiĝas tuj kiam la bezono ekestas. Estas bonege efektivigi kaj efektivigi novajn funkciojn senĉese, sed kunordigi ĉi tiun procezon kaj forigi problemojn kiuj aperas estas vera kapdoloro, aldonas Steve Newman. – En tre rapide kreskantaj organizoj, inĝenieroj en transfunkciaj teamoj luktas por konservi videblecon en ŝanĝon kaj la dependec-nivelajn kaskadajn efikojn kiujn ĝi kreas. Krome, inĝenieroj ne estas feliĉaj kiam ili estas senigitaj de ĉi tiu ŝanco kaj, kiel rezulto, fariĝas pli malfacile por ili kompreni la esencon de la problemoj kiuj ekestas."
Kiel venki ĉi tiujn defiojn priskribitajn supre kaj moviĝi al amasa adopto de DevOps en granda organizo? Fakuloj instigas paciencon, eĉ se via fina celo estas akceli vian programaran disvolvan ciklon kaj komercajn procezojn.
1. Memoru, ke kultura ŝanĝo bezonas tempon.
Jayne Groll, Administra Direktoro, DevOps Institute: "Laŭ mi, la ekspansio de DevOps devus esti same pliiga kaj ripeta kiel lerta evoluo (kaj same tuŝanta kulturon). Agile kaj DevOps emfazas malgrandajn teamojn. Sed dum ĉi tiuj teamoj kreskas en nombro kaj integriĝo, ni finas kun pli da homoj adoptantaj novajn labormanierojn, kaj kiel rezulto estas masiva kultura transformo."
2. Pasigu sufiĉe da tempo planante kaj elektante platformon
Eran Kinsbruner, Ĉefa Teknika Evangeliisto ĉe Perfecto: "Por skalo por funkcii, DevOps-teamoj unue devas lerni kombini tradiciajn procezojn, ilojn kaj kapablojn, kaj poste malrapide nutri kaj stabiligi ĉiun individuan fazon de DevOps. Ĉio komenciĝas per zorgema planado de uzantrakontoj kaj valorfluoj, sekvataj de verkado de programaro kaj versio-kontrolo per trunk-bazita evoluo aŭ aliaj aliroj plej taŭgaj por disbranĉigo kaj kunfandado de kodo."
"Tiam venas la integriĝo kaj testa stadio, kie skalebla platformo por aŭtomatigo jam estas postulata. Ĉi tie gravas por DevOps-teamoj elekti la ĝustan platformon, kiu konvenas al ilia lerteco kaj al la finaj celoj de la projekto.
La sekva fazo estas deplojo al produktado kaj ĉi tio devus esti plene aŭtomatigita uzante instrumentajn ilojn kaj ujojn. Gravas havi virtualigitajn mediojn en ĉiuj stadioj de DevOps (produktadsimulilo, QA-medio kaj reala produktadmedio) kaj ĉiam uzi nur la plej novajn datumojn por provoj por akiri koncernajn konkludojn. Analytics devas esti inteligenta kaj kapabla prilabori grandajn datumojn kun rapidaj kaj ageblaj sugestoj."
3. Prenu la kulpon el respondeco.
Gordon Haff, RedHat Evangeliisto: "Krei sistemon kaj atmosferon, kiuj permesas kaj instigas eksperimentadon, permesas tion, kio estas konataj kiel sukcesaj fiaskoj en lerta programaro. Ĉi tio ne signifas, ke neniu alia respondecas pri malsukcesoj. Fakte, identigi kiu respondecas fariĝas eĉ pli facila, ĉar "esti respondeca" ne plu signifas "kaŭzi akcidenton". Tio estas, la esenco de respondeco ŝanĝiĝas kvalite. Kvar faktoroj iĝas kritikaj: la amplekso de interrompo, aliroj, produktadaj procezoj kaj instigoj." (Vi povas legi pli pri ĉi tiuj faktoroj en la artikolo de Gordon Huff "DevOps-lecionoj: 4 Aspektoj de sanaj eksperimentoj.")
4. Forigu la vojon antaŭen
Ben Grinnell, administra direktoro kaj estro de cifereca ĉe konsultejo North Highland: "Por atingi skalon, mi rekomendas lanĉi programon de "vojpurigo" kune kun pioniraj projektoj. La celo de ĉi tiu programo estas purigi la rubon, kiun la pioniroj de DevOps postlasas, kiel malmodernaj reguloj kaj tiaj aferoj, por ke la vojo antaŭen restu klara."
"Donu al homoj organizan subtenon kaj impeton per komunikado, kiu iras multe preter la pionira grupo, vaste festante la sukcesojn de novaj labormanieroj. Trejnu homojn kiuj estas implikitaj en la sekva ondo de DevOps-projektoj kaj estas nervozaj pri uzado de DevOps por la unua fojo. Kaj memoru, ke ĉi tiuj homoj estas tre malsamaj de la pioniroj.”
5. Demokratiigi ilojn
Steve Newman, fondinto kaj prezidanto de Scalyr: “Iloj ne estu kaŝitaj de homoj, kaj ili devus esti relative facile lerneblaj por iu ajn volanta enmeti tempon. Se la kapablo pridemandi protokolojn estas limigita al tri homoj "atestitaj" por uzi ilon, vi ĉiam havos maksimume tri homojn disponeblaj por trakti la problemon, eĉ se vi havas tre grandan komputikmedion. Alivorte, ekzistas botelkolo ĉi tie, kiu povas konduki al gravaj (komercaj) sekvoj."
6. Kreu idealajn kondiĉojn por teama laboro
Tom Clark, estro de Komuna Platformo ĉe ITV: “Vi povas fari ion ajn, sed ne ĉion samtempe. Do starigu grandajn celojn, komencu malgrande kaj antaŭeniru per rapidaj ripetoj. Kun la tempo, vi disvolvos reputacion por fari aferojn, do aliaj ankaŭ volos uzi viajn metodojn. Kaj ne zorgu pri konstruado de tre efika teamo. Anstataŭe, provizi homojn per idealaj laborkondiĉoj kaj efikeco sekvos."
7. Ne forgesu pri la Leĝo de Conway kaj Kanban-tabuloj
Logan Daigle, Direktoro de Programaro Livero kaj DevOps Strategio ĉe CollabNetVersionOne: “Estas grave kompreni la sekvojn de la Leĝo de Conway. En mia loza parafrazo, ĉi tiu leĝo deklaras, ke la produktoj, kiujn ni kreas kaj la procezoj, kiujn ni uzas por fari tion, inkluzive de DevOps, rezultas strukturitaj same kiel nia organizo."
"Se estas multaj siloj en organizo, kaj kontrolo ŝanĝas manojn multfoje dum planado, konstruado kaj eldonado de programaro, la efiko de skalado estos nula aŭ mallongdaŭra. Se organizo konstruas transfunkciajn teamojn ĉirkaŭ produktoj kiuj estas financitaj kun merkata fokuso, tiam la ŝancoj de sukceso pliiĝas draste."
"Alia grava aspekto de skalo estas montri ĉiun laboron en progreso (WIP, laborprogreso) sur Kanban-tabuloj. Kiam organizo havas lokon kie homoj povas vidi ĉi tiujn aferojn, ĝi tre instigas kunlaboron, kiu havas pozitivan efikon al skalo."
8. Serĉu malnovajn cikatrojn
Manuel Pais, DevOps-konsultisto kaj kunaŭtoro de Team Topologies: "Preni DevOps-praktikojn preter Dev kaj Ops mem kaj provi apliki ilin al aliaj funkcioj estas apenaŭ optimuma aliro. Ĉi tio certe havos iom da efiko (ekzemple, aŭtomatigante manan kontrolon), sed multe pli povas esti atingita se ni komencos per kompreno de la liveraj kaj retrosciigprocezoj."
"Se estas malnovaj cikatroj en la IT-sistemo de organizo - proceduroj kaj administraj mekanismoj kiuj estis efektivigitaj kiel rezulto de pasintaj okazaĵoj, sed perdis sian gravecon (pro ŝanĝoj en produktoj, teknologioj aŭ procezoj) - tiam ili certe devas esti forigitaj. aŭ glatigita, prefere ol aŭtomatigi malefikajn aŭ nenecesajn procezojn."
9. Ne bredu DevOps-opciojn
Anthony Edwards, Direktoro de Operacioj ĉe Eggplant: "DevOps estas tre neklara termino, do ĉiu teamo finas kun sia propra versio de DevOps. Kaj estas nenio pli malbona kiam organizo subite havas 20 variojn de DevOps, kiuj ne tre bone interkonsentas kune. Estas neeble por ĉiu el la tri evoluigaj teamoj havi sian propran specialan interfacon inter evoluado kaj produkta administrado. Nek produktoj devus havi siajn proprajn unikajn atendojn por pritraktado de retrosciigo kiam transdonitaj al produktadsimulilo. Alie, vi neniam povos grimpi DevOps."
10. Prediku la komercan valoron de DevOps
Steve Newman, fondinto kaj prezidanto de Scalyr: "Laboru por rekoni la valoron de DevOps. Lernu kaj bonvolu paroli pri la avantaĝoj de tio, kion vi faras. DevOps estas nekredebla tempo- kaj monŝparado (nur pensu: malpli da malfunkcio, pli mallonga meza tempo al reakiro), kaj DevOps-teamoj devas senlace emfazi (kaj prediki) la gravecon de ĉi tiuj iniciatoj al komerca sukceso. Tiel vi povas vastigi la rondon de adeptoj kaj pliigi la influon de DevOps en la organizo."
BONUS
En Nia propra DevOps alvenos la 13-an de septembro - jes, Red Hat, kiel softvarproduktanto, havas siajn proprajn DevOps-teamojn kaj praktikojn.
Nia inĝeniero Mark Birger, kiu disvolvas internajn aŭtomatigajn servojn por aliaj grupoj tra la tuta organizo, rakontos sian propran historion en pura rusa - kiel la Red Hat DevOps-teamo migris aplikojn de Hat Virtualization virtualaj medioj administritaj de Ansible al plenrajta ujoformato sur la OpenShift platformo.
Sed tio ne estas ĉio:
Post kiam organizoj movis laborŝarĝojn al ujoj, tradiciaj aplikaj monitoraj metodoj eble ne funkcias. En la dua prelego ni klarigos nian instigon por ŝanĝi la manieron kiel ni ensalutas kaj montros la daŭrigon de la vojo, kiu kondukis nin al modernaj registradaj kaj monitoraj metodoj.
fonto: www.habr.com