Mynychais DevOpsForum 2019 yn ddiweddar, a gynhaliwyd gan Logrocon. Yn y gynhadledd hon, ceisiodd y cyfranogwyr ddod o hyd i atebion ac offer newydd ar gyfer rhyngweithio effeithiol rhwng busnes a datblygu a gwasanaethau technoleg gwybodaeth.
Roedd y gynhadledd yn llwyddiant: cafwyd llawer iawn o adroddiadau defnyddiol, fformatau cyflwyno diddorol a llawer o gyfathrebu gyda'r siaradwyr. Ac mae’n arbennig o bwysig nad oedd neb yn ceisio gwerthu dim byd i mi, rhywbeth y mae siaradwyr mewn cynadleddau mawr wedi bod yn euog ohono yn ddiweddar.
Detholiad o areithiau Raiffeisenbank, Alfastrakhovanie, profiad Mango Telecom wrth weithredu awtomeiddio a manylion eraill o dan y toriad.
Fy enw i yw Yana, rwy'n gweithio fel profwr, rwy'n gwneud awtomeiddio, yn ogystal â DevOps, ac rwyf wrth fy modd yn mynd i gynadleddau a chyfarfodydd. Dros y ddwy flynedd ddiwethaf, rwyf wedi bod i gynadleddau Oleg Bunin (HighLoad ++, TeamLead Conf), digwyddiadau Jwg (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
Yn gyntaf oll, tynnaf sylw at raglen y gynhadledd. Edrychaf lai ar yr hyn y bydd yr adroddiad yn sôn amdano, a mwy ar y siaradwr. Hyd yn oed os yw'r adroddiad yn troi allan i fod yn dechnolegol a diddorol iawn, nid yw'n ffaith y byddwch yn gallu cymhwyso rhai o'r arferion gorau o'r adroddiad yn eich cwmni. Ac yna mae angen siaradwr.
Golau ar ddiwedd y biblinell yn Raiffeisenbank
Fel arfer, rwy'n chwilio am siaradwyr ar y cyrion sydd o ddiddordeb i mi. Yn DevOpsForum 2019, daliodd siaradwr o Raiffeisenbank, Mikhail Bizhan, fy niddordeb. Yn ystod ei araith, soniodd am sut y maent yn raddol yn cael eu timau i wirioni ar DevOps, pam eu bod ei angen, a sut i werthu'r syniad o drawsnewid DevOps i fusnes. Wel, yn gyffredinol, siaradais am sut i weld y golau ar ddiwedd y biblinell.
Mikhail Bizhan, cyfarwyddwr awtomeiddio yn Raiffeisenbank
Nawr nid oes ganddyn nhw “DevOps” yn eu cwmni. Hynny yw, mae'n gweithio, ond nid ym mhob tîm. Wrth weithredu DevOps, maent yn dibynnu ar barodrwydd y timau, o ran peirianwyr penodol, ac o ran angen y cynnyrch ac aeddfedrwydd y llwyfan y mae'r cynnyrch hwn wedi'i adeiladu arno. Dywedodd Misha sut i esbonio i fusnes pam mae angen DevOps.
Mae gan y segment bancio nifer o yrwyr twf: cost gwasanaethau ac ehangu'r sylfaen cleientiaid. Nid yw cynyddu cost gwasanaethau yn yrrwr da iawn, ond mae tyfu sylfaen cleientiaid i'r gwrthwyneb. Os bydd cystadleuwyr yn rhyddhau cynnyrch sy'n cŵl yn wrthrychol, mae pob cwsmer yn mynd yno, yna dros amser mae'r farchnad yn gwastatáu. Felly, cyflwyno cynhyrchion newydd i'r farchnad a chyflymder eu cyflwyno yw'r prif beth y mae banciau'n canolbwyntio arno. Dyma'n union beth yw pwrpas DevOps, ac mae busnesau'n deall hyn.
Y nodyn pwysig nesaf: Nid yw DevOps bob amser yn lleihau amser i'r farchnad. Ni all DevOps weithio ar ei ben ei hun, dim ond rhan ydyw o'r broses o greu a dod â chynnyrch i'r farchnad o'i ddatblygiad i'w gynhyrchu (o'r cod i'r cwsmer). Ond nid yw popeth cyn y cod yn uniongyrchol gysylltiedig â DevOps. Hynny yw, gall marchnatwyr astudio'r farchnad am flynyddoedd a threulio eu hoes gyfan yn dal i fyny â chystadleuwyr. Mae angen deall yn gyflym beth sydd ei angen ar y cleient a chynllunio gweithrediad y nodwedd hon neu'r nodwedd honno - yn aml dyma'r hyn nad yw'n ddigon i DevOps weithio a'r cwmni i gyflawni ei nod. Felly, yn gyntaf oll, cytunodd Raiffeisenbank â busnes ei bod yn angenrheidiol dysgu sut i ddefnyddio DevOps. Ni fydd awtomeiddio er mwyn awtomeiddio yn helpu llawer yn y frwydr dros gwsmeriaid newydd.
Yn gyffredinol, mae Misha yn credu bod angen gweithredu DevOps, ond yn ddoeth. Ac mae'n rhaid i ni fod yn barod am y ffaith y bydd cynhyrchiant y tîm yn gostwng ar ddechrau'r trawsnewid, y bydd yn ennill llai o arian, ond yna bydd yn cael ei gyfiawnhau.
Awtomeiddio profi yn Mango Telecom
Cafwyd adroddiad diddorol arall i mi fel profwr gan Egor Maslov o Mango Telecom. Enw’r cyflwyniad oedd “Awtomeiddio’r cylch profi llawn mewn tîm SCRUM.” Mae Egor yn credu bod DevOps wedi'i greu yn benodol ar gyfer SCRUM, ond ar yr un pryd, mae cyflwyno DevOps i mewn i dîm SCRUM yn eithaf problemus. Mae hyn yn digwydd oherwydd bod tîm SCRUM bob amser yn rhedeg yn rhywle, nid oes amser i gael eich tynnu sylw gan arloesiadau ac ailadeiladu'r broses. Mae'r broblem hefyd yn gorwedd yn y ffaith nad yw SCRUM yn cynnwys gwahanu is-dimau yn y tîm (tîm profi, tîm datblygu, ac ati). Wel, ar wahân i, i awtomeiddio proses sy'n bodoli eisoes, mae angen dogfennaeth, ac yn SCRUM, gan amlaf nid oes dogfennaeth gyfan gwbl - "mae'r cynnyrch yn bwysicach na rhyw fath o ysgrifennu."
Ar ôl newid i SCRUM, dechreuodd profwyr ymgynghori â datblygwyr ar sut i brofi nodweddion. Yn raddol, cynyddodd maint y swyddogaeth, nid oedd unrhyw ddogfennaeth, a dechreuon nhw ddal llawer o fygiau yn y swyddogaeth nad oedd yn cael ei chwmpasu gan brofion ac yn gyffredinol nid oedd yn glir bellach pwy a'i profodd a phryd. Yn gryno - dryswch a vacillation. Fe wnaethom benderfynu newid i brofi awtomeiddio. Ond hyd yn oed wedyn bu methiant llwyr. Fe wnaethant gyflogi arbenigwyr awtomeiddio allanol a ysgrifennodd ar bentwr nad oedd yn hysbys i brofwyr mewnol. Gweithiodd y fframwaith ar gyfer awtobrofion, wrth gwrs, ond ar ôl i'r contractwyr allanol adael, fe barhaodd am bythefnos. Nesaf oedd ymgais i gyflwyno awtobrofi rhif dau. Dechreuodd gyda'r ffaith bod angen adeiladu popeth o fewn y cwmni, ar eich pen eich hun (y fector cywir: adeiladu arbenigedd yn fewnol), o fewn fframwaith SCRUM, a chreu dogfennaeth yn y broses. Dylai'r pentwr ar gyfer awtomeiddio fod yn hafal i bentwr y cynnyrch (dyma dwi'n ei ychwanegu, peidiwch â phrofi'ch prosiect JavaScript gydag unrhyw beth arall). Ar ddiwedd y sbrint, gwnaethant arddangosiad o sut mae'r autotest yn gweithio gyda'r tîm cyfan (defnyddiol). Felly, cynyddodd cyfranogiad holl aelodau'r tîm yn y broses awtomeiddio, yn ogystal ag ymddiriedaeth mewn awtobrofion a'r siawns y bydd yr awtobrawf hwn yn bendant yn cael ei ddefnyddio (ac na fydd yn cael sylw mewn mis oherwydd methiannau cyson).
Gyda llaw, yn DevOpsForum 2019 roedd meicroffon agored - fformat areithiau adnabyddus ac, yn fy marn i, yn ddefnyddiol. Rydych chi'n cerdded o gwmpas fel hyn, yn gwrando ar adroddiadau, ac yna'n penderfynu ei bod yn werth trafod pwnc neu broblem benodol yn y gynhadledd, gan rannu profiad perthnasol wrth ddatrys y broblem.
Sylwais hefyd fod y trefnwyr wedi gwneud llif o adroddiadau byr. Nid yw pob adroddiad yn para mwy na 10 munud, ac yna cwestiynau. Fel hyn gallwch ymdrin â llawer o bynciau ar unwaith a gofyn cwestiynau i siaradwyr sydd o ddiddordeb i chi.
Rhwng cyflwyniadau, cerddais o amgylch bythau partneriaid y gynhadledd a dwyn / ennill llawer o bethau. O, dwi'n caru'r daflen!
Materion bord gron a DevOps gyda'r cyfarwyddwr datblygu yn Alfastrakhovanie
Yr eisin ar gacen DevOpsForum 2019 i mi oedd y sesiwn lawn awr o hyd gydag arbenigwyr DevOps. Gwahoddwyd pedwar cyfranogwr sesiwn i edrych ar DevOps o wahanol onglau: Anton Isanin (Alfastrakhovanie, cyfarwyddwr datblygu), Nailya Zamashkina (Fintech Lab, cyfarwyddwr gweithredu), Oleg Egorkin (Rostelecom, hyfforddwr Agile) ac Anton Martyanov (arbenigwr annibynnol, yn edrych ar DevOps o safbwynt busnes).
Eisteddodd yr arbenigwyr yn agosach at y bobl ac yna dechreuodd pethau ddigwydd: am awr gyfan, gofynnodd cyfranogwyr o'r gynulleidfa eu cwestiynau, a chymerodd yr arbenigwyr y rap. Weithiau roedd dadleuon go iawn. Roedd y cwestiynau'n wahanol iawn, er enghraifft: a oes angen peirianwyr DevOps o gwbl, pam na allant gael eu hyfforddi fel gweinyddwyr system, pe bai DevOps yn cael ei gynnig i bawb, beth yw ei werth, ac ati.
Yna, siaradais ag Anton Isanin yn bersonol. Buom yn trafod yr angen i ddod â diwylliant DevOps i bob cartref a datgelwyd ochr dywyll trawsnewid DevOps.
Gadewch i ni ddychmygu bod pawb wedi dod at ei gilydd a phenderfynu bod angen DevOps gan y cynnyrch a'r busnes a'r tîm. Gadewch i ni fynd i'w weithredu. Gweithiodd popeth allan. Rydym yn anadlu allan. Mae DevOps wedi dod â ni'n agosach at y cleient, nawr gallwn gyflawni ei holl ddymuniadau yn gyflym. O ganlyniad, mae gennym adran Ops fawr gyda rheoliadau a gofynion llym, ac mae'n gyson yn canfod diffygion yn y cynnyrch ac yn creu criw o geisiadau. Ar ben hynny, rhoddir statws “brys” i bob diffyg, hyd yn oed os oedd y cleient yn annisgwyl eisiau lliwio'r botwm yn felyn yn lle gwyrdd. Mae'r prosiect yn tyfu, mae nifer y datganiadau yn tyfu ac, yn unol â hynny, mae nifer y diffygion a'r camddealltwriaeth o ymarferoldeb newydd gan gleientiaid. Mae Ops yn cyflogi 10 yn fwy o bobl i gadw i fyny ag adrodd am ddiffygion, ac mae datblygiad yn llogi 15 yn fwy i gadw i fyny â'u cau. Ac yn lle cyflwyno nodweddion newydd, mae'r tîm yn gweithio gyda SD diddiwedd, gan esbonio'r ymarferoldeb i'r defnyddiwr a chefnogaeth ar yr un pryd. O ganlyniad, mae Ops a datblygu yn gweithio, ond mae'r cleient a'r busnes yn anhapus: mae nodweddion newydd yn mynd yn sownd. Mae'n ymddangos bod DevOps yn bodoli, ond nid yw'n ymddangos ei fod yn bodoli.
O ran yr angen i weithredu DevOps, dywedodd Anton yn glir fod hyn yn dibynnu'n uniongyrchol ar faint y busnes. Os yw gwasanaethu un cleient y flwyddyn yn dod â biliwn i'r cwmni, nid oes angen DevOps (ar yr amod nad oes angen i chi gyflwyno newidiadau newydd i'r cleient hwn yn rheolaidd). Mae popeth wedi'i orchuddio â siocled. Ond os bydd y busnes yn tyfu a mwy o gleientiaid yn ymddangos, yna mae angen i chi gydymffurfio. Fel rheol, nid oes unrhyw Ops cŵl yn y cwmni i ddechrau. Yn gyntaf rydyn ni'n torri'r cynnyrch, a dim ond wedyn rydyn ni'n deall bod angen i ni gadw llygad ar y gweinyddwyr a monitro cyflenwadau er mwyn i'r cynnyrch weithio. Dyna pryd mae Ops yn dod i fodolaeth. Mae'n dal i gael ei ddeall y bydd Ops, fel adran ar wahân, yn dechrau gosod llawer o rwystrau i ddatblygiad a bydd pob cyflenwad yn dechrau arafu. Hynny yw, yn yr achos hwn, mae diwylliant DevOps eisoes yn berthnasol, ond rhaid inni beidio ag anghofio am ei ochr dywyll.
Ffynhonnell: hab.com