Er erfitt að átta sig á aðalatriðinu þegar talað er um DevOps? Við höfum safnað fyrir þig skærum hliðstæðum, sláandi samsetningum og ráðleggingum frá sérfræðingum sem munu hjálpa jafnvel sérfræðingum að komast að efninu. Í lokin er bónusinn eigin DevOps starfsmanna Red Hat.
Hugtakið DevOps er upprunnið fyrir 10 árum síðan og hefur breyst frá Twitter hashtag til öflugrar menningarhreyfingar í upplýsingatækniheiminum, sannkölluð heimspeki sem hvetur forritara til að gera hlutina hraðar, gera tilraunir og endurtaka sig áfram. DevOps hefur orðið órjúfanlega tengt hugmyndinni um stafræna umbreytingu. En eins og oft gerist með hugtök í upplýsingatækni hefur DevOps á undanförnum tíu árum öðlast margar skilgreiningar, túlkanir og ranghugmyndir um sjálft sig.
Þess vegna geturðu oft heyrt spurningar um DevOps eins og, er það það sama og lipur? Eða er þetta einhver sérstök aðferðafræði? Eða er það bara annað samheiti yfir orðið „samvinna“?
DevOps inniheldur mörg mismunandi hugtök (sífelld afhending, samfelld samþætting, sjálfvirkni osfrv.), Þannig að það getur verið krefjandi að eima það sem er mikilvægt, sérstaklega þegar þú hefur brennandi áhuga á viðfangsefninu. Hins vegar er þessi færni mjög gagnleg, sama hvort þú ert að reyna að koma hugmyndum þínum á framfæri við yfirmenn þína eða einfaldlega að segja einhverjum úr fjölskyldu þinni eða vinum frá vinnunni þinni. Þess vegna skulum við leggja til hliðar hugtakalitbrigði DevOps í bili og einblína á heildarmyndina.
Hvað er DevOps: 6 skilgreiningar og hliðstæður
Við báðum sérfræðinga um að útskýra kjarna DevOps eins einfaldlega og stuttlega og mögulegt er svo gildi þess verði ljóst fyrir lesendur með hvaða stigi tækniþekkingar sem er. Byggt á niðurstöðum þessara samtöla höfum við valið mest sláandi hliðstæður og sláandi samsetningar sem munu hjálpa þér að byggja upp sögu þína um DevOps.
1. DevOps er menningarhreyfing
„DevOps er menningarhreyfing þar sem báðir aðilar (hugbúnaðarhönnuðir og sérfræðingar í upplýsingatæknikerfum) viðurkenna að hugbúnaður hefur ekki raunverulegan ávinning fyrr en einhver byrjar að nota hann: viðskiptavinir, viðskiptavinir, starfsmenn, ekki málið,“ segir Eveline Oehrlich, yfirrannsóknarstjóri. sérfræðingur hjá DevOps Institute. „Þess vegna tryggja báðir þessir aðilar í sameiningu hraða og hágæða afhendingu hugbúnaðar.
2. DevOps snýst um að styrkja þróunaraðila.
"DevOps gerir forriturum kleift að eiga forrit, keyra þau og stjórna afhendingu frá upphafi til enda."
„Venjulega er talað um DevOps sem leið til að flýta fyrir afhendingu forrita til framleiðslu með því að byggja og innleiða sjálfvirka ferla,“ segir Jai Schniepp, forstöðumaður DevOps kerfa hjá tryggingafélaginu Liberty Mutual. "En fyrir mér er þetta miklu grundvallaratriði." DevOps gerir forriturum kleift að eiga forrit eða ákveðinn hugbúnað, keyra þau og stjórna afhendingu þeirra frá upphafi til enda. DevOps útilokar ábyrgðarrugl og leiðbeinir öllum sem taka þátt í að búa til sjálfvirkan, þróunardrifinn innviði.
3. DevOps snýst um samvinnu við að búa til og afhenda forrit.
„Einfaldlega sagt, DevOps er nálgun við hugbúnaðarframleiðslu og afhendingu þar sem allir vinna saman,“ segir Gur Staf, forseti og yfirmaður stafrænnar viðskiptasjálfvirkni hjá BMC.
4. DevOps er leiðsla
„Samsetning færibanda er aðeins möguleg ef allir hlutar passa saman.“
„Ég myndi bera DevOps saman við bílasamsetningarlínu,“ heldur Gur Staff áfram. – Hugmyndin er að hanna og smíða alla hlutana fyrirfram þannig að hægt sé að setja þá saman án sérstakrar aðlögunar. Samsetning færibanda er aðeins möguleg ef allir hlutar passa saman. Þeir sem hanna og smíða vél verða að íhuga hvernig á að festa hana á yfirbyggingu eða grind. Þeir sem búa til bremsur verða að hugsa um hjólin og svo framvegis. Sama ætti að gilda um hugbúnað.
Hönnuður sem býr til viðskiptarök eða notendaviðmót verður að hugsa um gagnagrunninn sem geymir upplýsingar um viðskiptavini, öryggisráðstafanir til að vernda notendagögn og hvernig allt þetta mun virka þegar þjónustan byrjar að þjóna stórum, jafnvel milljón dollara notendahópi. ."
„Að fá fólk til að vinna saman og hugsa um þá hluta starfsins sem aðrir eru að sinna, frekar en að einblína eingöngu á eigin verkefni, er mesta hindrunin sem þarf að yfirstíga. Ef þú getur þetta hefurðu mikla möguleika á stafrænni umbreytingu,“ bætir Gur Staff við.
5. DevOps er rétt blanda af fólki, ferlum og sjálfvirkni
Jayne Groll, framkvæmdastjóri DevOps Institute, bauð upp á frábæra hliðstæðu til að útskýra DevOps. Í orðum hennar, „DevOps er eins og uppskrift með þremur meginflokkum innihaldsefna: fólk, ferli og sjálfvirkni. Flest þessara innihaldsefna er hægt að taka frá öðrum sviðum og heimildum: Lean, Agile, SRE, CI/CD, ITIL, forystu, menningu, verkfæri. Leyndarmálið við DevOps, eins og allar góðar uppskriftir, er hvernig á að fá rétt hlutföll og blanda af þessum hráefnum til að auka hraða og skilvirkni við að búa til og gefa út forrit.“
6. DevOps er þegar forritarar vinna eins og Formúlu 1 lið
„Hlaupið er ekki skipulagt frá upphafi til enda, heldur þvert á móti, frá enda til upphafs.
„Þegar ég tala um hvers ég á að búast við af DevOps frumkvæði, hugsa ég um NASCAR eða Formúlu 1 kappaksturslið sem dæmi,“ segir Chris Short, yfirmaður markaðssetningar á skýjapöllum hjá Red Hat og útgefandi DevOps fréttabréfsins. – Leiðtogi slíks liðs hefur eitt markmið: að ná hæsta mögulega sæti í lok hlaups, að teknu tilliti til þess fjármagns sem liðið hefur til ráðstöfunar og þeirra áskorana sem því fylgdu. Í þessu tilviki er keppnin ekki skipulögð frá upphafi til enda, heldur þvert á móti, frá enda til upphafs. Fyrst er metnaðarfullt markmið sett og síðan ákvarðaðar leiðir til að ná því. Síðan er þeim skipt niður í undirverkefni og þeim úthlutað til liðsmanna.“
„Liðið eyðir heilu vikunni fyrir keppnina í að fullkomna pitstopið. Hann stundar styrktarþjálfun og hjartalínurit til að halda sér í formi fyrir erfiðan keppnisdag. Æfir að vinna saman að því að leysa öll vandamál sem upp kunna að koma í hlaupinu. Sömuleiðis ætti þróunarteymið að þjálfa færni til að gefa út nýjar útgáfur oft. Ef þú hefur slíka kunnáttu og vel virkt öryggiskerfi, þá gerist það líka oftar að nýjar útgáfur séu settar í framleiðslu. Í þessari heimsmynd þýðir aukinn hraði aukið öryggi,“ segir Short.
„Þetta snýst ekki um að gera það „rétta“,“ bætir Short við, „það snýst um að útrýma eins mörgum hlutum og mögulegt er sem standa í vegi fyrir tilætluðum árangri. Samvinna og aðlagast út frá endurgjöfinni sem þú færð í rauntíma. Vertu tilbúinn fyrir frávik og vinndu að því að bæta gæði til að lágmarka áhrif þeirra á framfarir í átt að markmiði þínu. Þetta er það sem bíður okkar í heimi DevOps.“
Hvernig á að skala DevOps: 10 ráð frá sérfræðingum
Það er bara að DevOps og massa DevOps eru allt öðruvísi hlutir. Við munum segja þér hvernig á að yfirstíga hindranir á leiðinni frá fyrsta til annars.
Fyrir margar stofnanir byrjar ferðin til DevOps auðveldlega og skemmtilega. Lítil ástríðufull teymi verða til, gömlum ferlum er skipt út fyrir nýja og fyrstu árangurinn er ekki lengi að koma.
Því miður, þetta er bara falskur glampi, tálsýn um framfarir, segir Ben Grinnell, framkvæmdastjóri og yfirmaður stafrænna mála hjá ráðgjafafyrirtækinu North Highland. Snemma sigrar eru vissulega uppörvandi, en þeir hjálpa ekki til við að ná lokamarkmiðinu um víðtæka upptöku DevOps um stofnunina.
Það er auðvelt að sjá að niðurstaðan er menning um skiptingu milli „okkar“ og „þeirra“.
„Oft hefja stofnanir þessar brautryðjendaverkefni og halda að þau muni ryðja brautina fyrir almenna DevOps, án þess að íhuga hvort aðrir geti eða vilji fara þá leið,“ útskýrir Ben Grinnell. – Teymi til að framkvæma slík verkefni eru venjulega ráðin frá sjálfsöruggum „Varangians“ sem hafa þegar gert eitthvað svipað á öðrum stöðum, en eru nýir í fyrirtækinu þínu. Jafnframt eru þeir hvattir til að brjóta og eyðileggja reglur sem eru áfram bindandi fyrir alla aðra. Það er auðvelt að sjá að niðurstaðan er menning „okkar“ og „þeirra“ sem hamlar yfirfærslu þekkingar og færni.“
„Og þetta menningarvandamál er bara ein af ástæðunum fyrir því að erfitt er að stækka DevOps. DevOps teymi standa frammi fyrir auknum tæknilegum áskorunum sem eru dæmigerðar fyrir ört vaxandi upplýsingatæknifyrirtæki,“ sagði Steve Newman, stofnandi og stjórnarformaður Scalyr.
„Í nútíma heimi breytist þjónusta um leið og þörf er á. Það er frábært að innleiða og innleiða stöðugt nýja eiginleika, en að samræma þetta ferli og útrýma vandamálum sem upp koma er algjör höfuðverkur, bætir Steve Newman við. – Í mjög ört vaxandi stofnunum eiga verkfræðingar í þvervirkum teymum í erfiðleikum með að viðhalda sýnileika í breytingum og ósjálfstæðisáhrifum sem það skapar. Þar að auki eru verkfræðingar ekki ánægðir þegar þeir eru sviptir þessu tækifæri og þar af leiðandi verður erfiðara fyrir þá að skilja kjarna vandamálanna sem upp koma.“
Hvernig á að sigrast á þessum áskorunum sem lýst er hér að ofan og fara yfir í fjöldaupptöku DevOps í stórri stofnun? Sérfræðingar hvetja til þolinmæði, jafnvel þó að lokamarkmið þitt sé að flýta fyrir hugbúnaðarþróunarferlinu og viðskiptaferlum.
1. Mundu að menningarbreyting tekur tíma.
Jayne Groll, framkvæmdastjóri, DevOps Institute: „Að mínu mati ætti útvíkkun DevOps að vera jafn stigvaxandi og endurtekinn og lipur þróun (og jafnt snerta menningu). Agile og DevOps leggja áherslu á lítil teymi. En eftir því sem þessum teymum fjölgar og sameinast, endum við með því að fleiri tileinka sér ný vinnubrögð og þar af leiðandi verða mikil menningarleg umbreyting.“
2. Eyddu nægum tíma í að skipuleggja og velja vettvang
Eran Kinsbruner, aðal tækniboði hjá Perfecto: „Til þess að stærðarstærð virki verða DevOps teymi fyrst að læra að sameina hefðbundna ferla, verkfæri og færni og síðan hægt að hlúa að og koma á stöðugleika í hverjum einstökum áfanga DevOps. Þetta byrjar allt með vandaðri skipulagningu notendasagna og gildisstrauma, fylgt eftir með því að skrifa hugbúnað og útgáfustýringu með því að nota trunk-undirstaða þróun eða aðrar aðferðir sem henta best fyrir greiningu og sameiningu kóða.
„Svo kemur samþættingar- og prófunarstigið, þar sem nú þegar er þörf á skalanlegum vettvangi fyrir sjálfvirkni. Þetta er þar sem það er mikilvægt fyrir DevOps teymi að velja réttan vettvang sem hentar hæfileikastigi þeirra og lokamarkmiðum verkefnisins.
Næsti áfangi er dreifing í framleiðslu og þetta ætti að vera fullkomlega sjálfvirkt með því að nota hljómsveitarverkfæri og ílát. Það er mikilvægt að hafa sýndarumhverfi á öllum stigum DevOps (framleiðsluhermir, QA umhverfi og raunverulegt framleiðsluumhverfi) og nota alltaf aðeins nýjustu gögnin fyrir prófanir til að fá viðeigandi niðurstöður. Greining verður að vera snjöll og geta unnið stór gögn með hröðum og aðgerðalausum endurgjöf.“
3. Taktu sektarkennd af ábyrgð.
Gordon Haff, RedHat boðberi: „Að búa til kerfi og andrúmsloft sem leyfir og hvetur til tilrauna gerir ráð fyrir því sem kallast farsæl mistök í lipri hugbúnaðarþróun. Þetta þýðir ekki að enginn annar beri ábyrgð á mistökum. Reyndar verður enn auðveldara að bera kennsl á hver er ábyrgur þar sem „að vera ábyrgur“ þýðir ekki lengur „að valda slysi“. Það er, kjarni ábyrgðar breytist eigindlega. Fjórir þættir verða mikilvægir: umfang truflana, nálgun, framleiðsluferli og hvatningar.“ (Þú getur lesið meira um þessa þætti í grein Gordon Huff „DevOps kennslustundir: 4 þættir heilbrigðra tilrauna.“)
4. Hreinsaðu leiðina áfram
Ben Grinnell, framkvæmdastjóri og yfirmaður stafrænna upplýsinga hjá ráðgjafafyrirtækinu North Highland: „Til að ná umfangi mæli ég með því að setja af stað „brautahreinsun“ forrit ásamt brautryðjendaverkefnum. Markmiðið með þessu forriti er að hreinsa upp sorpið sem frumkvöðlar DevOps skilja eftir sig, eins og úreltar reglur og svoleiðis, þannig að leiðin fram á við sé áfram skýr.“
„Gefðu fólki skipulagslegan stuðning og kraft með samskiptum sem fara langt út fyrir brautryðjendahópinn með því að fagna vel árangri nýrra vinnubragða. Þjálfa fólk sem tekur þátt í næstu bylgju DevOps verkefna og er kvíðið fyrir því að nota DevOps í fyrsta sinn. Og mundu að þetta fólk er mjög ólíkt brautryðjendunum.“
5. Lýðræðisvæddu verkfæri
Steve Newman, stofnandi og stjórnarformaður Scalyr: „Tól ætti ekki að vera falið fyrir fólki og það ætti að vera tiltölulega auðvelt að læra á þau fyrir alla sem eru tilbúnir að leggja á sig tíma. Ef möguleikinn á að spyrjast fyrir um annála er takmörkuð við þrjá einstaklinga sem eru „vottaðir“ til að nota tól, muntu alltaf hafa að hámarki þrjá menn tiltæka til að takast á við vandamálið, jafnvel þótt þú hafir mjög stórt tölvuumhverfi. Hér er með öðrum orðum flöskuháls sem getur haft alvarlegar (viðskipta)afleiðingar.“
6. Skapaðu kjöraðstæður fyrir teymisvinnu
Tom Clark, yfirmaður Common Platform hjá ITV: „Þú getur gert hvað sem er, en ekki allt í einu. Settu þér því stór markmið, byrjaðu smátt og farðu áfram í hröðum endurtekningum. Með tímanum muntu þróa orðspor fyrir að láta hlutina gera, svo aðrir vilja líka nota aðferðir þínar. Og ekki hafa áhyggjur af því að byggja upp mjög árangursríkt lið. Í staðinn skaltu veita fólki kjöraðstæður og skilvirkni mun fylgja í kjölfarið.“
7. Ekki gleyma Conway's Law og Kanban borðum
Logan Daigle, forstöðumaður hugbúnaðarafhendingar og DevOps stefnu hjá CollabNetVersionOne: „Það er mikilvægt að skilja afleiðingar laga Conway. Í lauslegri orðræðu minni segir þessi lög að vörurnar sem við búum til og ferlarnir sem við notum til þess, þar á meðal DevOps, reynist vera byggð upp á sama hátt og stofnunin okkar.“
„Ef það er mikið af sílóum í stofnun og stjórnun skiptir oft um hendur við skipulagningu, smíði og útgáfu hugbúnaðar, verða áhrif stærðarskala engin eða skammvinn. Ef stofnun byggir upp þvervirk teymi í kringum vörur sem eru fjármagnaðar með markaðsáherslu, þá aukast líkurnar á árangri verulega.
„Annar mikilvægur þáttur í mælikvarða er að sýna alla vinnu sem er í vinnslu (WIP, workinprogress) á Kanban töflum. Þegar stofnun hefur stað þar sem fólk getur séð þessa hluti, hvetur það mjög til samstarfs, sem hefur jákvæð áhrif á mælikvarða.“
8. Leitaðu að gömlum örum
Manuel Pais, DevOps ráðgjafi og meðhöfundur Team Topologies: „Að taka DevOps æfingar út fyrir Dev og Ops sjálft og reyna að beita þeim á aðrar aðgerðir er varla ákjósanleg nálgun. Þetta mun vissulega hafa einhver áhrif (til dæmis með því að gera sjálfvirka handstýringu), en miklu meira er hægt að ná ef við byrjum á því að skilja afhendingu og endurgjöf.
„Ef það eru gömul ör í upplýsingatæknikerfi fyrirtækisins - verklagsreglur og stjórnunaraðferðir sem voru innleiddar vegna fyrri atvika, en hafa glatað mikilvægi sínu (vegna breytinga á vörum, tækni eða ferlum) - þá þarf vissulega að fjarlægja þau eða jafnað út, frekar en að gera sjálfvirkan óhagkvæma eða óþarfa ferla.“
9. Ekki rækta DevOps valkosti
Anthony Edwards, rekstrarstjóri Eggplant: „DevOps er mjög óljóst hugtak, þannig að hvert lið endar með sína eigin útgáfu af DevOps. Og það er ekkert verra þegar stofnun hefur skyndilega 20 afbrigði af DevOps sem fara ekki mjög vel saman. Það er ómögulegt fyrir hvert þróunarteymið þriggja að hafa sitt sérstaka viðmót milli þróunar og vörustjórnunar. Vörur ættu heldur ekki að hafa sínar einstöku væntingar til að meðhöndla endurgjöf þegar þær eru fluttar í framleiðsluhermi. Annars muntu aldrei geta stækkað DevOps.
10. Boðaðu viðskiptalegt gildi DevOps
Steve Newman, stofnandi og stjórnarformaður Scalyr: „Vinnaðu að því að viðurkenna gildi DevOps. Lærðu og ekki hika við að tala um kosti þess sem þú gerir. DevOps er ótrúlegur tíma- og peningasparnaður (hugsaðu bara: minni niður í miðbæ, styttri meðaltími til bata) og DevOps teymi verða óþreytandi að leggja áherslu á (og prédika) mikilvægi þessara verkefna fyrir velgengni fyrirtækja. Þannig geturðu stækkað hóp fylgismanna og aukið áhrif DevOps í stofnuninni.“
Bónus
Á Okkar eigin DevOps mun koma 13. september - já, Red Hat, sem hugbúnaðarframleiðandi, hefur sín eigin DevOps teymi og starfshætti.
Verkfræðingur okkar Mark Birger, sem þróar innri sjálfvirkniþjónustu fyrir aðra hópa um allt skipulagsheildina, mun segja sína eigin sögu á skýrri rússnesku - hvernig Red Hat DevOps teymið flutti forrit frá Hat Virtualization sýndarumhverfi sem stjórnað er af Ansible yfir í fullgild gámasnið á OpenShift pallinum.
En það er ekki allt:
Þegar stofnanir hafa fært vinnuálag yfir í gáma gætu hefðbundnar eftirlitsaðferðir forrita ekki virka. Í seinni erindinu munum við útskýra hvata okkar til að breyta því hvernig við skráum okkur og sýna framhaldið á þeirri leið sem leiddi okkur að nútíma skógarhöggs- og eftirlitsaðferðum.
Heimild: www.habr.com