Þriðja ráðstefnan var haldin 7. desember , skipulagt af Moskvu DevOps samfélaginu með stuðningi Mail.ru Cloud Solutions. Auk kynninga frá leiðandi DevOps iðkendum gátu þátttakendur sótt stutt hvetjandi eldingarviðræður, vinnustofur og átt samskipti í opnum rýmum.
Við söfnuðum mikilvægum innsýnum úr sex ræðum og tókum viðtöl við nokkra fyrirlesara til að komast að því hvað var skilið eftir í skýrslunum.
Inni:
- Baruch Sadogursky, JFrog: „Láttu hugbúnaðinn flæða frá seljanda til notanda eins og vökvi“
- Pavel Selivanov, Southbridge: „Dev og Ops hafa eitt sameiginlegt verkefni - að búa til vöru sem virkar“
- Vladimir Utratenko, X5 Retail Group: „DevOps in Enterprise er þróun án sársauka og elda“
- Sergey Puzyrev, Facebook: „Production Engineer hugsar um þjónustuna í heild sinni: þannig að bæði notendur og þróunaraðilar skemmti sér vel“
- Mikhail Chinkov, AMBOSS: „Ein deild getur ekki fylgt DevOps leiðinni, allt fyrirtækið verður að fylgja henni“
- DevOps-áhugamenn Rosbank: „1000 dagar til að innleiða DevOps í blóðugu fyrirtæki“
1. Baruch Sadogursky, JFrog: „Láttu hugbúnaðinn flæða frá söluaðila til notanda eins og vökvi“
Bilanir í hugbúnaðaruppfærslu gerast á klukkutíma fresti og fyrir alla. Hér er bara ein hryllingssaga úr ræðunni: Knight Capital tapaði 440 milljónum dala á klukkustund eftir misheppnaða uppfærslu.
Baruch talaði um DevOps mynstur stöðugra uppfærslu sem mun hjálpa til við að forðast mistök og hatur notenda:
Staðbundin afturköllun — Haltu fyrri útgáfu hugbúnaðarins í tækinu þínu til að snúa aftur ef eitthvað gerist. Þetta mun vernda þig ef hlutirnir verða svo slæmir að þú getur ekki sent plástur í loftið.
Uppfærslur í loftinu - betra samfellt. Annars verður þetta eins og hjá Jaguar-framleiðendum: Vegna galla í bremsukerfinu, sem ekki var hægt að uppfæra í loftinu, þurfti að innkalla bílana úr sölu. Það var sárt og dýrt.
Stöðugar uppfærslur — uppfærðu hugbúnaðinn stöðugt um leið og nýr eiginleiki er tilbúinn. Með sjaldgæfum uppfærslum eru eiginleikar flokkaðir saman; mikilvæg uppfærsla gæti beðið eftir þeim sem ekki eru mikilvægar. Eins og í Tesla beið uppfærsla sem átti að laga handahófskennda hemlun eftir uppfærslu á skákinni.
Sjálfvirk dreifing - skiptu fólki út fyrir vélar, þar sem fólk er lélegt í að framkvæma venjulegar aðgerðir.
Tíðar uppfærslur - hjálpa þér að þróa vana og losna við ótta. Sjaldgæfar uppfærslur breytast í neyðartilvik.
Að þekkja stöðu tækisins - prófa uppfærslur, ekki uppsetning frá grunni. Þetta er mikilvægt vegna þess að uppfærslur geta hegðað sér öðruvísi eftir ástandi tækisins.
Kanaríútgáfur - settu upp uppfærslur til fárra notenda og fylgdust með. Þetta minnkar skaðann ef eitthvað fer úrskeiðis.
Uppfærslur án þess að vera tiltækar - láttu viðskiptavini aðeins taka eftir nýjum eiginleikum og ekki vera án þjónustu í nokkrar vikur á meðan þú setur upp uppfærslu.
Við ræddum við Baruch Sadogursky um hvernig viðhorfið til DevOps er ólíkt í rússneskum og vestrænum upplýsingatækni, hvort Cloud muni brátt gera allt fyrir okkur og hvort öll hugbúnaðarþjónusta muni renna inn í aaS kerfið - horfðu á viðtalið:
2. Pavel Selivanov, Southbridge: "Dev og Ops hafa eitt sameiginlegt verkefni - að búa til vöru sem virkar"
Innleiðing Kubernetes mun ekki hjálpa til við að ná DevOps, og þvert á móti getur það brotið allt. Pavel útskýrði hvers vegna tækni (jafnvel sú flottasta) getur ekki leyst öll vandamál þín:
Flækjustig verkefnisins hefur færst út fyrir kóðann. Áður var flókið forrit: samspil innan verkefnisins og flókin þróun, en einföld uppbygging - stjórnandinn notaði það, allt virkar. Við færðum okkur yfir í örþjónustu: hver þjónusta er einföld forrit, samskipti með stöðluðum samskiptareglum og hröð þróun, en uppbygging verkefna er orðin flóknari. Flækjustig verkefnis með örþjónustuarkitektúr hefur ekki horfið - það hefur færst út fyrir kóðann. Nú ber DevOps verkfræðingurinn ábyrgð á því.
Hönnuðir vilja ekki breytingar eftir að hafa innleitt DevOps. Fyrir vikið heldur vinnuflæði með Kubernetes áfram að líta út eins og að henda verkefnum frá Dev til Ops yfir vegg, aðeins ekki myndlíkingu - Git verður slíkur veggur. Framkvæmdaraðilinn setur kóðann þar og virkar eins og áður, og admins eru með Kubernetes, CI/CD og allt hitt.
Hins vegar verða verktaki að samþykkja breytingarnar. Ástandið þegar forritarar vita ekki hvað stjórnendur eru að gera og stjórnendur vita ekki hvað er að gerast hjá forriturum skapar vandamál.
Ef ekkert hefur breyst fyrir hönnuði gera þeir sér ekki grein fyrir því að rekstur forritsins er á þeirra ábyrgð - ýmis tæknileg brellur munu ekki virka.
Með tilkomu DevOps og Kubernetes mun margt breytast í þróun. Devs verða að vera hæfir í Ops og öfugt. Þessir sérfræðingar hafa sína sértæku hæfileika, en þeir verða að vera meðvitaðir um vinnu hvers annars. Dev og Ops þurfa að vera vinir áður en þú innleiðir Kubernetes, annars brýtur þú það sem þú hefur.
Pavel Selivanov talaði um hvað verður um Kubernetes eftir 5 ár og á hverju nútíma sprotafyrirtæki ætti að byggja tæknibunka á - horfðu á viðtalið:
3. Vladimir Utratenko, X5 Retail Group: "DevOps in Enterprise er þróun án sársauka og elda"
Fyrirtæki koma að DevOps umbreytingu þegar þau átta sig á því að þróunin er of hæg og uppfyllir ekki raunveruleikann, þau hafa löngun til að þróast betur og rúlla út hraðar.
Vladimir útskýrði hvernig þetta gerist og hver veiðin er:
- Í fyrsta lagi ráða fyrirtæki DevOps verkfræðing. Þetta er yfirkerfisstjóri, hann tekur þátt í að dreifa útgáfu til framleiðslu, staðla þróunarumhverfið, setja upp innviði, greina og laga ýmis vandamál, sjálfvirka ferla og önnur tæknileg verkefni.
- Þá dugar einn DevOps verkfræðingur ekki lengur og fyrirtækið ræður DevOps teymi. Þetta er hæfnimiðstöð sem skipuleggur viðleitni ólíkra verkfræðinga og gerir þeim kleift að einbeita sér í eina átt.
- Reyndar eru DevOps verkfræðingur og DevOps teymi andstæðingur mynstur DevOps umbreytingar. Þar sem DevOps snýst um starfshætti og menningu, auk þess eru útfærslur á DevOps í tæknifyrirtækjum (SRE, Production Engineering).
Hvað skal gera? Ráðið tímabundið DevOps teymi sem mun hjálpa til við að innleiða DevOps umbreytingu, framkvæma starfshætti, rækta þróunarmenningu og tæknimenningu.
Þegar fyrirtæki kemur við sögu og fjárfestir í DevOps eru nokkrar aðstæður mögulegar: allt mun falla í sundur við flugtak; verður áfram sem SRE/Production Engineering eða Embedded Ops; mun flytja til BizOps, þegar ferlar eru byggðir á viðskiptamælingum.
Vladimir Utratenko sagði okkur frá því hversu „blóðug“ DevOps í fyrirtæki er í raun og veru og hvernig vinnubrögð eru innleidd í stórum smásölu - horfðu á viðtalið:
4. Sergey Puzyrev, Facebook: „Production Engineer er annt um þjónustuna í heild sinni: þannig að bæði notendur og þróunaraðilar skemmti sér vel“
Facebook er risastórt fyrirtæki, með mikinn fjölda íhluta, netþjóna, fólks og gagnavera. Þrátt fyrir mikla stærð er það mjög hratt - forritarar geta útbúið þjónustu oft á dag. Facebook er líka í örum vexti og það er ekki bara fjöldi notenda og netþjóna sem stækkar heldur fjölgar þróunaraðilum líka, sem gerir ferlana flóknari.
Sergey sagði hvað framleiðsluverkfræðingur gerir á Facebook:
- Framleiðsluverkfræðingur kóðar mikið, hann verður að hafa kerfisþekkingu: stýrikerfi, skráarkerfi, gagnagrunna, netkerfi og þess háttar. Verður að hafa reynslu af því að vinna með dreifð kerfi og áreiðanleikaverkfræði, það er að styðja áreiðanleika vöru. Það verður að vera á vakt, það er að segja hægt að hringja hvenær sem er.
- Framleiðsluverkfræðingur er frábrugðin hugbúnaðarverkfræðingi í því að hafa háþróaða færni í rekstri, en er í raun undirtegund hugbúnaðarverkfræðings. Hugbúnaðarverkfræðingar kóða meira; þeir kunna að hafa viðbótarkunnáttu sem tengist til dæmis gagnavinnslu. Á Facebook þurfa slíkir sérfræðingar líka að vera á vakt, sem kemur mörgum óþægilega á óvart.
- Þarfapýramídi framleiðsluverkfræðings í fyrirtæki byrjar með því að fylgjast með netþjónum og lífsferli þeirra, það er að fá nýjan vélbúnað, setja hann upp, setja hann í notkun. Næsta stig er það sama á þjónustustigi: eftirlit með þjónustu og líftíma þeirra. Síðan kemur óaðfinnanlegur mælikvarði og háþróað eftirlit. Þeir skipta yfir í sjálfvirka mælingu eftir að líftíma þjónustunnar er sjálfvirkur. Og á endanum er nauðsynlegt að stilla þannig að mælikvarðinn sé árangursríkur og fyrirtækið sparar peninga og fjármagn.
5. Mikhail Chinkov, AMBOSS: „Ein deild getur ekki fylgt DevOps leiðinni, allt fyrirtækið verður að fylgja henni“
Mikhail telur að DevOps sé stöðug þróun. Þú getur ekki kynnt nokkur verkfæri og stoppað þar. Hvaða vandamál koma í veg fyrir að fyrirtæki geti orðið DevOps og hvernig á að innleiða starfshætti?
Mismunur á að skilja DevOps. Canonical devops, eins og guðspjallamenn sjá það, hvílir á 5 stoðum:
- menning - áhersla á fólk og samvinnu;
- sjálfvirkni - framsal venja til vinnuflæðis;
- lean - áhersla á að skila virði til notandans;
- miðlun - stöðug miðlun þekkingar;
- mæligildi og fá endurgjöf með því að nota þær.
Fyrirtæki einbeita sér venjulega aðeins að sjálfvirkni og skila virði til notandans. En menning, þekkingarmiðlun og DevOps mælikvarðar til að fylgjast með þróun hverfa í bakgrunninn.
DevOps staðlaáskoranir. Vörumarkmið eru mismunandi fyrir öll fyrirtæki og ekki hægt að staðla þau. Staða DevOps í fyrirtæki fer eftir fyrirtækinu sjálfu en margir skilja þetta ekki og telja að það sé nóg að ráða DevOps verkfræðing.
Af hverju erum við ekki DevOps ennþá? Það eru tvö lykilvandamál. Í Enterprise er hæg þróun skipulagsins, erfiðleikar við að breyta vektornum í huga þúsunda starfsmanna. Í sprotafyrirtækjum er skortur á þekkingaruppsprettum og vandamál með að úthluta fjármagni til umbreytingar.
Stig DevOps þróunar í fyrirtæki:
- hið fyrsta er innviði í skýinu, en enginn veit hvernig það virkar nema einn eða tveir stjórnendur;
- í öðru lagi eru innviðirnir gagnsæir og skiljanlegir öllum verkfræðingum, en ferlarnir eru ekki straumlínulagaðir;
- þriðja - verkfræðingar sjálfstætt hefja og gera við lifandi þjónustu;
- í fjórða lagi - verkfræðingar munu mögulega leggja sitt af mörkum til kjarnainnviða, gagnsæs kóða í skýinu, dreifing með hnappi.
Hin fullkomna áætlun er að allir hafi sama aðgang að innviðunum, allir verkfræðingar hafi aðgang að vörunni og skilji hvað þeir eru að gera.
Eftir að hafa lokað öllum menningarlegum og tæknilegum gestaltum mun DevOps umbreyting fyrirtækisins taka mið af endurgjöf frá viðskipta- og vettvangsmælingum.
6. DevOps-áhugamenn Rosbank: „1000 dagar til að innleiða DevOps í blóðugu fyrirtæki“
Yuri Bulich, Dina Maltseva, Evgeny Pankov frá Rosbank sögðu frá því hvernig þau komu til DevOps á þremur árum. Það voru tvö markmið: að leysa ákveðin vandamál í sérstökum teymum og að innleiða miðstýrð verkfæri.
Hér eru niðurstöður sem náðst hafa:
Niðurstöður fyrir vöruteymi: 30 sinnum hraðari samsetning, 6 sinnum hraðari uppsetning, allt að 30% sparnaður á öllu ferlinu. Við höfum nú möguleika á að ýta á hnapp til að fara í framleiðni
Niðurstöður fyrir vettvangsskipanir: 10 sinnum hraðari samsetning og uppsetning, 87% aukinn fjöldi uppsetninga, 46% sjálfsprófun. Samþættingarteymið er ekki lengur flöskuháls
Svo, hvernig á að innleiða DevOps starfshætti í blóðugu fyrirtæki?
Innleiða fyrst tilraunaverkefni: Veldu teymi, ákveðið hvernig á að útfæra arkitektúrinn og veldu verkfæri. Við völdum verkfæri með opnu leyfi, með uppsetningu í bankanum og sérfræðiþekkingu í að vinna með þau. Rosbank dreifði samtímis einkaskýi ásamt DevOps pallinum og þetta hjálpaði í upphafi. Í skýinu var hægt að fá nauðsynleg úrræði með því að ýta á hnapp á 15 mínútum; áður gat slíkt ferli tekið viku.
Í bönkum og öðrum fyrirtækjum þarf að vinna úr takmörkunum fyrirfram með upplýsingaöryggishópnum og finna lausn sem gerir breytingarnar kleift að hrinda í framkvæmd.
Eftir tilraunina þarf að stækka farsæla lausn.
- Það er mikilvægt að „rétta“ leiðsluna eins mikið og mögulegt er, útrýma óþarfa hlekkjum úr henni, draga fram verðmætaveitendur og fjarlægja þá hluti sem eftir eru. Milliefni eru andmynstur. Til dæmis, hjá Rosbank, þróaði fjöldi teyma ekki innri þróun og skildi aðeins eftir ytri þróun. Þetta leiddi til þess að sérstakt DevOps teymi kom til, sem tryggði flutning kóða frá ytri til innri forritara. Vandamálið var leyst með því að samþætta ytri þróun inn í CI/CD, þannig að þeir myndu ekki bara flytja kóðann frá sjálfum sér til bankans, heldur bæru ábyrgð á árangri hans.
- Þroskalíkanið innihélt þætti í DevOps starfsháttum, skráðum verkfærum og tók tillit til eiginleika þess að vinna með utanaðkomandi birgjum - í framtíðinni hjálpaði þetta til við að skera fljótt niður eftirsótt verkefna við innleiðingu þeirra í nýjum teymum.
- Við þurfum stjórnarhætti í formi mjúkrar stjórnunar og tilmæla. DevOps handbók sem virkar vel er safn skipulags- og verkfæraeiginleika sem hjálpa teymum að nota vettvanginn rétt.
- Þú ættir strax að borga eftirtekt til menningu, þá munu margar breytingar gerast hraðar og auðveldara. Stækkaðu innra samfélag þitt, stundaðu fundi, tækninámskeið, þjálfun og skemmtileg verkefni. Þetta ber ávöxt: fólk deilir starfsháttum, sér hver gerði hvað, veit hvert það á að snúa sér, það er efla og heilbrigð samkeppni innan fyrirtækisins.
- Það þýðir ekkert að vinna með þeim sem ekki taka þátt í ferlinu, með teymum sem hafa ekki þroskast, það er betra að fjárfesta í áhugasömum teymum og tryggu fólki.
- Valin lausn verður að vera hentug fyrir þá verkfræðinga sem nota hana.
- Ytri þróun er ekki hindrun, þar er líka hægt að innleiða starfshætti, aðalatriðið er að liðið sjálft hafi löngunina.
Aðeins meiri ávinningur
Listi yfir bækur sem vert er að lesa fyrir þá sem eru í DevOps, frá Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Vilji og sjálfsstjórn."
- Daniel Kahneman „Að hugsa, hratt og hægt“.
- Barbara Oakley „A Mind for Numbers“.
- Maxim Dorofeev "Jedi tækni".
- Viktor Frankl "Leit mannsins að merkingu".
Fylgstu
Við elskum DevOps líka. Fylgstu með tilkynningum um röðina og @Kubernetes, auk annarra Mail.ru Cloud Solutions viðburða, í Telegram rásinni okkar:
Heimild: www.habr.com