Cynhaliwyd y drydedd gynhadledd ar 7 Rhagfyr , a drefnwyd gan gymuned Moscow DevOps gyda chefnogaeth Mail.ru Cloud Solutions. Yn ogystal â chyflwyniadau gan ymarferwyr blaenllaw DevOps, gallai cyfranogwyr fynychu Sgyrsiau Mellt byr ysgogol, gweithdai a chyfathrebu mewn mannau agored.
Casglwyd mewnwelediadau pwysig o chwe araith a chynhaliwyd cyfweliadau â nifer o siaradwyr i ddarganfod beth oedd ar ôl yn yr adroddiadau.
Y tu mewn:
- Baruch Sadogursky, JFrog: “Gadewch i'r meddalwedd lifo o werthwr i ddefnyddiwr fel hylif”
- Pavel Selivanov, Southbridge: “Mae gan Dev ac Ops un dasg gyffredin - gwneud cynnyrch sy'n gweithio”
- Vladimir Utratenko, Grŵp Manwerthu X5: “Datblygiad heb boen a thanau yw DevOps in Enterprise”
- Sergey Puzyrev, Facebook: “Mae Peiriannydd Cynhyrchu yn poeni am y gwasanaeth yn ei gyfanrwydd: fel bod defnyddwyr a datblygwyr yn cael amser da”
- Mikhail Chinkov, AMBOSS: “Ni all un adran ddilyn llwybr DevOps, rhaid i’r cwmni cyfan ei ddilyn”
- Selogion DevOps o Rosbank: “1000 o ddiwrnodau i weithredu DevOps mewn menter waedlyd”
1. Baruch Sadogursky, JFrog: “Gadewch i'r meddalwedd lifo o werthwr i ddefnyddiwr fel hylif”
Mae methiannau diweddaru meddalwedd yn digwydd bob awr ac i bawb. Dyma un stori arswyd yn unig o'r araith: collodd Knight Capital $440 miliwn mewn awr ar ôl diweddariad aflwyddiannus.
Siaradodd Baruch am batrymau DevOps o ddiweddariadau parhaus a fydd yn helpu i osgoi methiannau a chasineb defnyddwyr:
Dychweliad lleol — cadwch y fersiwn flaenorol o'r feddalwedd ar eich dyfais i rolio'n ôl os bydd rhywbeth yn digwydd. Bydd hyn yn eich diogelu os aiff pethau mor ddrwg fel na allwch anfon darn dros yr awyr.
Diweddariadau dros yr awyr - gwell parhaus. Fel arall, bydd yn debyg i ddatblygwyr Jaguar: oherwydd nam yn y system brêc, na ellid ei ddiweddaru dros yr awyr, bu'n rhaid galw'r ceir yn ôl rhag cael eu gwerthu. Roedd yn boenus ac yn ddrud.
Diweddariadau parhaus - diweddaru'r feddalwedd yn barhaus cyn gynted ag y bydd nodwedd newydd yn barod. Gyda diweddariadau prin, mae nodweddion yn cael eu grwpio gyda'i gilydd; efallai y bydd diweddariad critigol yn aros am rai nad ydynt yn hanfodol. Fel yn Tesla, roedd diweddariad a oedd i fod i drwsio brecio ar hap yn aros am ddiweddariad i'r gêm gwyddbwyll.
Defnydd awtomataidd - disodli pobl â pheiriannau, gan fod pobl yn ddrwg am berfformio gweithredoedd arferol.
Diweddariadau aml - eich helpu i ddatblygu arferiad a chael gwared ar ofn. Mae diweddariadau prin yn troi'n ddigwyddiadau brys.
Gwybod cyflwr y ddyfais - diweddariadau prawf, nid gosod o'r dechrau. Mae hyn yn bwysig oherwydd gall diweddariadau ymddwyn yn wahanol yn dibynnu ar gyflwr y ddyfais.
Caneri yn rhyddhau — cyflwyno diweddariadau i nifer fach o ddefnyddwyr ac arsylwi. Mae hyn yn lleihau'r difrod os aiff rhywbeth o'i le.
Diweddariadau heb ddim ar gael - gadewch i gwsmeriaid sylwi ar nodweddion newydd yn unig, a pheidiwch â chael eu gadael heb wasanaeth am sawl wythnos wrth i chi gyflwyno diweddariad.
Buom yn siarad â Baruch Sadogursky am sut mae'r farn ar DevOps yn wahanol mewn TG Rwsiaidd a Gorllewinol, a fydd Cloud yn gwneud popeth i ni cyn bo hir ac a fydd yr holl wasanaethau meddalwedd yn llithro i'r cynllun aaS - gwyliwch y cyfweliad:
2. Pavel Selivanov, Southbridge: “Mae gan Dev ac Ops un dasg gyffredin – gwneud cynnyrch sy’n gweithio”
Ni fydd gweithredu Kubernetes yn helpu i gyflawni DevOps, ac i'r gwrthwyneb, gall dorri popeth. Esboniodd Pavel pam na all technoleg (hyd yn oed y rhai mwyaf cŵl) ddatrys eich holl broblemau:
Mae cymhlethdod y prosiect wedi symud y tu hwnt i'r cod. Yn flaenorol, roedd cais cymhleth: rhyngweithio o fewn y prosiect a datblygiad cymhleth, ond strwythur syml - mae'r gweinyddwr yn ei ddefnyddio, mae popeth yn gweithio. Symudasom i ficrowasanaethau: mae pob gwasanaeth yn gymhwysiad syml, cyfathrebu gan ddefnyddio protocolau safonol a datblygiad cyflym, ond mae strwythur y prosiect wedi dod yn fwy cymhleth. Nid yw cymhlethdod prosiect gyda phensaernïaeth microwasanaeth wedi diflannu - mae wedi symud y tu hwnt i'r cod. Nawr mae peiriannydd DevOps yn gyfrifol amdano.
Nid yw datblygwyr eisiau newidiadau ar ôl gweithredu DevOps. O ganlyniad, mae llif gwaith gyda Kubernetes yn parhau i edrych fel taflu tasgau o Dev i Ops dros wal, dim ond nid un drosiadol - mae Git yn dod yn wal o'r fath. Mae'r datblygwr yn rhoi'r cod yno ac yn gweithio fel o'r blaen, ac mae gan y gweinyddwyr Kubernetes, CI / CD a phopeth arall.
Fodd bynnag, mae angen i ddatblygwyr dderbyn y newidiadau. Mae'r sefyllfa pan nad yw datblygwyr yn gwybod beth mae gweinyddwyr yn ei wneud, a gweinyddwyr ddim yn gwybod beth sy'n digwydd gyda datblygwyr, yn creu problemau.
Os nad oes unrhyw beth wedi newid i'r datblygwyr, nid ydynt yn sylweddoli mai eu cyfrifoldeb nhw yw gweithrediad y cais - ni fydd triciau technegol amrywiol yn gweithio.
Gyda dyfodiad DevOps a Kubernetes, bydd llawer yn newid mewn datblygiad. Rhaid i feddygon ddatblygu fod yn gymwys mewn Gweithrediadau ac i'r gwrthwyneb. Mae gan yr arbenigwyr hyn eu sgiliau penodol eu hunain, ond rhaid iddynt fod yn ymwybodol o waith ei gilydd. Mae angen i Dev ac Ops fod yn ffrindiau cyn gweithredu Kubernetes, fel arall byddwch chi'n torri'r hyn sydd gennych chi.
Siaradodd Pavel Selivanov am yr hyn fydd yn digwydd i Kubernetes mewn 5 mlynedd a beth ddylai cwmni newydd modern adeiladu pentwr technoleg arno - gwyliwch y cyfweliad:
3. Vladimir Utratenko, Grŵp Manwerthu X5: “Datblygiad heb boen a thanau yw DevOps in Enterprise”
Daw cwmnïau i drawsnewidiad DevOps pan sylweddolant fod datblygiad yn rhy araf ac nad yw'n cwrdd â realiti, mae ganddynt awydd i ddatblygu'n well a'i gyflwyno'n gyflymach.
Esboniodd Vladimir sut mae hyn yn digwydd a beth yw'r dalfa:
- Yn gyntaf, mae cwmnïau'n llogi peiriannydd DevOps. Mae hwn yn Uwch Weinyddwr Systemau, mae'n ymwneud â rhyddhau i gynhyrchu, safoni'r amgylchedd datblygu, sefydlu seilwaith, canfod a thrwsio problemau amrywiol, awtomeiddio prosesau a thasgau technegol eraill.
- Yna nid yw un peiriannydd DevOps yn ddigon bellach, ac mae'r cwmni'n llogi tîm DevOps. Mae hon yn ganolfan gymhwysedd sy'n trefnu ymdrechion peirianwyr gwahanol ac yn caniatáu iddynt gael eu crynhoi mewn un cyfeiriad.
- Mewn gwirionedd, mae peirianwyr DevOps a thimau DevOps yn wrth-batrwm o drawsnewid DevOps. Gan fod DevOps yn ymwneud ag arferion a diwylliant, yn ogystal, mae DevOps yn cael eu gweithredu mewn cwmnïau technoleg (SRE, Peirianneg Cynhyrchu).
Beth i'w wneud? Llogi tîm DevOps dros dro a fydd yn helpu i weithredu trawsnewid DevOps, cynnal arferion, meithrin diwylliant datblygu a diwylliant technolegol.
Pan fydd busnes yn dod i rym ac yn buddsoddi mewn DevOps, mae sawl senario yn bosibl: bydd popeth yn disgyn yn ddarnau wrth esgyn; yn parhau i fod yn ARhPh/Peirianneg Cynhyrchu neu Weithrediadau Embedded; yn symud i BizOps, pan fydd prosesau'n seiliedig ar fetrigau busnes.
Dywedodd Vladimir Utratenko wrthym pa mor “waedlyd” yw DevOps mewn menter mewn gwirionedd a sut mae arferion yn cael eu gweithredu o fewn manwerthu mawr - gwyliwch y cyfweliad:
4. Sergey Puzyrev, Facebook: “Mae Peiriannydd Cynhyrchu yn poeni am y gwasanaeth yn ei gyfanrwydd: fel bod defnyddwyr a datblygwyr yn cael amser da”
Mae Facebook yn gwmni enfawr, gyda nifer fawr o gydrannau, gweinyddwyr, pobl, a chanolfannau data. Er gwaethaf ei faint enfawr, mae'n gyflym iawn - gall datblygwyr gyflwyno gwasanaethau lawer gwaith y dydd. Hefyd, mae Facebook yn tyfu'n gyflym, ac nid dim ond nifer y defnyddwyr a'r gweinyddwyr sy'n tyfu, mae nifer y datblygwyr hefyd yn cynyddu, sy'n gwneud y prosesau'n fwy cymhleth.
Dywedodd Sergey beth mae Peiriannydd Cynhyrchu yn ei wneud ar Facebook:
- Mae Peiriannydd Cynhyrchu yn codio llawer, rhaid iddo feddu ar wybodaeth system: systemau gweithredu, systemau ffeiliau, cronfeydd data, rhwydweithiau ac ati. Rhaid bod â phrofiad o weithio gyda systemau gwasgaredig a Pheirianneg Dibynadwyedd, hynny yw, cefnogi dibynadwyedd cynnyrch. Rhaid iddo fod ar alwad, hynny yw, ar gael i'w alw unrhyw bryd.
- Mae Peiriannydd Cynhyrchu yn wahanol i Beiriannydd Meddalwedd gan fod ganddo sgiliau uwch ar waith, ond, mewn gwirionedd, mae'n isrywogaeth o Beiriannydd Meddalwedd. Mae Peirianwyr Meddalwedd yn codio mwy; efallai y bydd ganddynt sgiliau ychwanegol yn ymwneud â phrosesu data, er enghraifft. Ar Facebook, rhaid i arbenigwyr o'r fath fod ar alwad hefyd, sy'n dod yn syndod annymunol i lawer.
- Mae pyramid anghenion Peiriannydd Cynhyrchu mewn cwmni yn dechrau gyda monitro gweinyddwyr a'u cylch bywyd, hynny yw, cael caledwedd newydd, ei osod, ei roi ar waith. Mae'r lefel nesaf yr un peth ar lefel y gwasanaeth: monitro gwasanaethau a'u cylch bywyd. Yna daw graddio di-dor a monitro uwch. Maent yn newid i raddfa awtomataidd ar ôl i gylch bywyd y gwasanaeth gael ei awtomeiddio. Ac yn y diwedd, mae angen tiwnio fel bod graddio yn effeithiol a bod y cwmni'n arbed arian ac adnoddau.
5. Mikhail Chinkov, AMBOSS: “Ni all un adran ddilyn llwybr DevOps, rhaid i'r cwmni cyfan ei ddilyn”
Mae Mikhail yn credu bod DevOps yn ddatblygiad parhaus. Ni allwch gyflwyno rhai offer a stopio yno. Pa broblemau sy'n atal cwmnïau rhag dod yn DevOps a sut i weithredu arferion?
Gwahaniaeth mewn Deall DevOps. Mae devops canonaidd, fel y mae efengylwyr yn ei weld, yn gorwedd ar 5 piler:
- culture - canolbwyntio ar bobl a chydweithio;
- awtomeiddio - dirprwyo trefn arferol i lif gwaith;
- lean - pwyslais ar gyflwyno gwerth i'r defnyddiwr;
- rhannu - cyfnewid gwybodaeth yn barhaus;
- metrigau a derbyn adborth gan eu defnyddio.
Mae cwmnïau fel arfer yn canolbwyntio ar awtomeiddio yn unig a darparu gwerth i'r defnyddiwr. Ond mae diwylliant, rhannu gwybodaeth, a metrigau DevOps i olrhain datblygiad yn pylu i'r cefndir.
Heriau Safoni DevOps. Mae nodau cynnyrch yn wahanol i bob cwmni ac ni ellir eu safoni. Mae cyflwr DevOps mewn cwmni yn dibynnu ar y cwmni ei hun, ond nid yw llawer yn deall hyn ac yn credu ei fod yn ddigon i logi peiriannydd DevOps.
Pam nad ydym ni'n DevOps eto? Mae dwy broblem allweddol. Yn Menter mae datblygiad araf y sefydliad, anawsterau gyda newid y fector ym meddyliau miloedd o weithwyr. Mewn busnesau newydd, mae diffyg ffynonellau gwybodaeth a phroblem wrth ddyrannu adnoddau ar gyfer trawsnewid.
Camau datblygiad DevOps mewn cwmni:
- y cyntaf yw seilwaith yn y cwmwl, ond nid oes neb yn gwybod sut mae'n gweithio ac eithrio un neu ddau o weinyddwyr;
- yn ail, mae'r seilwaith yn dryloyw ac yn ddealladwy i bob peiriannydd, ond nid yw'r prosesau wedi'u symleiddio;
- trydydd - peirianwyr yn lansio ac yn atgyweirio gwasanaethau byw yn annibynnol;
- pedwerydd - bydd peirianwyr yn ddewisol yn cyfrannu at y seilwaith craidd, cod tryloyw yn y cwmwl, defnyddio trwy botwm.
Y cynllun delfrydol yw bod gan bawb yr un mynediad i’r seilwaith, bod gan bob peiriannydd fynediad at y cynnyrch a’u bod yn deall yr hyn y maent yn ei wneud.
Ar ôl cau'r holl gestalts diwylliannol a thechnegol, bydd trawsnewid DevOps y cwmni yn ystyried adborth o fetrigau busnes a llwyfan.
6. selogion DevOps o Rosbank: “1000 o ddiwrnodau i weithredu DevOps mewn menter waedlyd”
Dywedodd Yuri Bulich, Dina Maltseva, Evgeny Pankov o Rosbank sut y daethant i DevOps mewn tair blynedd. Roedd dau nod: datrys problemau penodol mewn timau penodol a gweithredu offer canolog.
Dyma’r canlyniadau a gyflawnwyd:
Canlyniadau ar gyfer Timau Cynnyrch: cynulliad 30 gwaith yn gyflymach, gosod 6 gwaith yn gyflymach, hyd at 30% o arbedion ar y cylch llawn. Bellach mae gennym y gallu i wasgu botwm i fynd i gynhyrchiant
Canlyniadau ar gyfer gorchmynion platfform: 10 gwaith cydosod a gosod yn gyflymach, 87% wedi cynyddu nifer y gosodiadau, 46% o sylw awtotest. Nid yw'r tîm integreiddio bellach yn dagfa
Felly, sut i weithredu arferion DevOps mewn menter waedlyd?
Rhoi prosiect peilot ar waith yn gyntaf: Dewiswch dimau, penderfynwch sut i weithredu'r bensaernïaeth, a dewis offer. Fe wnaethom ddewis offer gyda thrwydded agored, gyda gosod yn y banc ac arbenigedd mewn gweithio gyda nhw. Ar yr un pryd, defnyddiodd Rosbank gwmwl preifat ynghyd â llwyfan DevOps, a helpodd hyn ar y dechrau. Yn y cwmwl, roedd yn bosibl cael yr adnoddau angenrheidiol trwy wasgu botwm mewn 15 munud; yn flaenorol, gallai proses o'r fath gymryd wythnos.
Mewn banciau a mentrau eraill, mae angen gweithio allan y cyfyngiadau ymlaen llaw gyda'r tîm diogelwch gwybodaeth a dod o hyd i ateb a fydd yn caniatáu i'r newidiadau gael eu gweithredu.
Ar ôl y peilot, mae angen cynyddu datrysiad llwyddiannus.
- Mae'n bwysig “sythu” y biblinell gymaint â phosibl, gan ddileu cysylltiadau diangen ohoni, tynnu sylw at ddarparwyr gwerth, a chael gwared ar y cydrannau sy'n weddill. Gwrth-batrwm yw canolradd. Er enghraifft, yn Rosbank, ni wnaeth nifer o dimau ddatblygu datblygiad mewnol, gan adael dim ond datblygiad allanol. Arweiniodd hyn at ymddangosiad tîm DevOps pwrpasol, a sicrhaodd bod cod yn cael ei drosglwyddo o ddatblygwyr allanol i ddatblygwyr mewnol. Datryswyd y broblem trwy integreiddio datblygiad allanol i CI/CD, fel y byddent nid yn unig yn trosglwyddo'r cod oddi wrthynt eu hunain i'r banc, ond hefyd yn gyfrifol am ei lwyddiant.
- Roedd y model aeddfedrwydd yn cynnwys elfennau o arferion DevOps, offer rhestredig, ac yn ystyried nodweddion gweithio gyda chyflenwyr allanol - yn y dyfodol, roedd hyn yn helpu i leihau'r ôl-groniad o dasgau yn gyflym wrth eu gweithredu mewn timau newydd.
- Mae angen Llywodraethu arnom ar ffurf rheolaeth feddal ac argymhellion. Mae Llawlyfr DevOps sy'n gweithio'n dda yn set o nodweddion sefydliadol ac offer sy'n helpu timau i ddefnyddio'r platfform yn gywir.
- Dylech roi sylw i ddiwylliant ar unwaith, yna bydd llawer o newidiadau yn digwydd yn gyflymach ac yn haws. Tyfwch eich cymuned fewnol, cynhaliwch gyfarfodydd, gweithdai technegol, sesiynau hyfforddi a gweithgareddau hwyliog. Mae hyn yn dwyn ffrwyth: mae pobl yn rhannu arferion, gweld pwy wnaeth beth, gwybod ble i droi, mae hype a chystadleuaeth iach o fewn y cwmni.
- Nid oes diben gweithio gyda’r rhai nad ydynt yn ymwneud â’r broses, gyda thimau nad ydynt wedi aeddfedu; mae’n well buddsoddi mewn timau sydd â diddordeb a phobl deyrngar.
- Rhaid i'r ateb a ddewisir fod yn gyfleus i'r peirianwyr hynny sy'n ei ddefnyddio.
- Nid yw datblygiad allanol yn rhwystr; gellir gweithredu arferion yno hefyd, y prif beth yw bod gan y tîm ei hun yr awydd.
Ychydig mwy o fudd
Rhestr o lyfrau sy'n werth eu darllen i'r rhai yn DevOps, gan Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko “Ewyllys a hunanreolaeth.”
- Daniel Kahneman "Meddwl, Cyflym ac Araf".
- Barbara Oakley "Meddwl am Rifau".
- Maxim Dorofeev “technegau Jedi”.
- Viktor Frankl "Chwilio Dyn am Ystyr".
Arhoswch diwnio
Rydyn ni'n caru DevOps hefyd. Dilynwch gyhoeddiadau'r gyfres a @Kubernetes, yn ogystal â digwyddiadau Cloud Solutions eraill Mail.ru, yn ein sianel Telegram:
Ffynhonnell: hab.com