Die derde konferensie is op 7 Desember gehou , georganiseer deur die Moskou DevOps-gemeenskap met die ondersteuning van Mail.ru Cloud Solutions. Benewens aanbiedings deur vooraanstaande DevOps-praktisyns, kon deelnemers kort motiverende Weerligpraatjies, werkswinkels bywoon en in oop ruimtes kommunikeer.
Ons het belangrike insigte uit ses toesprake versamel en onderhoude met verskeie sprekers gevoer om uit te vind wat agter die verslae gelaat is.
Binne:
- Baruch Sadogursky, JFrog: "Laat die sagteware soos vloeistof van verkoper na gebruiker vloei"
- Pavel Selivanov, Southbridge: "Dev en Ops het een algemene taak - om 'n produk te maak wat werk"
- Vladimir Utratenko, X5 Retail Group: "DevOps in Enterprise is ontwikkeling sonder pyn en brande"
- Sergey Puzyrev, Facebook: "Produksie-ingenieur gee om vir die diens as geheel: sodat beide gebruikers en ontwikkelaars 'n goeie tyd het"
- Mikhail Chinkov, AMBOSS: "Een departement kan nie die DevOps-pad volg nie, die hele maatskappy moet dit volg"
- DevOps-entoesiaste van Rosbank: "1000 dae om DevOps in 'n bloedige onderneming te implementeer"
1. Baruch Sadogursky, JFrog: "Laat die sagteware soos vloeistof van verkoper na gebruiker vloei"
Sagteware-opdateringsfoute gebeur uurliks en vir almal. Hier is net een gruwelverhaal uit die toespraak: Knight Capital het $440 miljoen in 'n uur verloor ná 'n onsuksesvolle opdatering.
Baruch het gepraat oor DevOps-patrone van deurlopende opdaterings wat sal help om mislukkings en gebruikershaat te vermy:
Plaaslike terugrol - hou die vorige weergawe van die sagteware op jou toestel om terug te rol as iets gebeur. Dit sal jou beskerm as dinge so erg raak dat jy nie 'n pleister oor die lug kan stuur nie.
Oor die lug opdaterings - beter deurlopend. Andersins sal dit wees soos met die Jaguar-ontwikkelaars: weens 'n fout in die remstelsel, wat nie oor die lug opgedateer kon word nie, moes die motors van verkoop herroep word. Dit was pynlik en duur.
Deurlopende opdaterings - werk die sagteware voortdurend op sodra 'n nuwe kenmerk gereed is. Met seldsame opdaterings word kenmerke saam gegroepeer; 'n kritieke opdatering kan wag vir nie-kritiese opdaterings. Soos in Tesla, het 'n opdatering wat veronderstel was om ewekansige remming reg te stel, gewag vir 'n opdatering van die skaakspel.
Outomatiese ontplooiing - vervang mense met masjiene, aangesien mense sleg is om roetine-aksies uit te voer.
Gereelde opdaterings - help jou om 'n gewoonte te ontwikkel en ontslae te raak van vrees. Skaars opdaterings verander in noodgevalle.
Ken die toestand van die toestel - toets opdaterings, nie installasie van nuuts af nie. Dit is belangrik omdat opdaterings anders kan optree, afhangende van die toestand van die toestel.
Kanarie vrystellings - ontplooi opdaterings aan 'n klein aantal gebruikers en neem waar. Dit verminder die skade as iets verkeerd loop.
Opdaterings sonder onbeskikbaarheid - laat kliënte net nuwe kenmerke opmerk, en moenie vir 'n paar weke sonder diens gelaat word terwyl jy 'n opdatering uitrol nie.
Ons het met Baruch Sadogursky gesels oor hoe die siening van DevOps in Russiese en Westerse IT verskil, of Cloud binnekort alles vir ons sal doen en of alle sagtewaredienste in die aaS-skema sal inskuif - kyk na die onderhoud:
2. Pavel Selivanov, Southbridge: "Dev en Ops het een algemene taak - om 'n produk te maak wat werk"
Die implementering van Kubernetes sal nie help om DevOps te bereik nie, en inteendeel, dit kan alles breek. Pavel het verduidelik hoekom tegnologie (selfs die coolste) nie al jou probleme kan oplos nie:
Die kompleksiteit van die projek het verby die kode beweeg. Voorheen was daar 'n komplekse toepassing: interaksie binne die projek en komplekse ontwikkeling, maar 'n eenvoudige struktuur - die administrateur het dit ontplooi, alles werk. Ons het na mikrodienste oorgegaan: elke diens is 'n eenvoudige toepassing, kommunikasie met behulp van standaardprotokolle en vinnige ontwikkeling, maar die projekstruktuur het meer kompleks geword. Die kompleksiteit van 'n projek met 'n mikrodiensargitektuur het nie verdwyn nie - dit het verby die kode beweeg. Nou is die DevOps-ingenieur daarvoor verantwoordelik.
Ontwikkelaars wil nie veranderinge hê nadat hulle DevOps geïmplementeer het nie. Gevolglik bly werkvloei met Kubernetes lyk soos om take van Dev na Ops oor 'n muur te gooi, net nie 'n metaforiese een nie - Git word so 'n muur. Die ontwikkelaar plaas die kode daar en werk soos voorheen, en die admins het Kubernetes, CI/CD en alles anders.
Ontwikkelaars moet egter die veranderinge aanvaar. Die situasie wanneer ontwikkelaars nie weet wat admins doen nie, en admins nie weet wat met ontwikkelaars aangaan nie, skep probleme.
As niks vir die ontwikkelaars verander het nie, besef hulle nie dat die werking van die toepassing hul verantwoordelikheid is nie – verskeie tegniese truuks sal nie werk nie.
Met die koms van DevOps en Kubernetes sal baie in ontwikkeling verander. Ontwikkelaars moet bevoeg wees in Ops en omgekeerd. Hierdie spesialiste het hul eie spesifieke vaardighede, maar hulle moet bewus wees van mekaar se werk. Dev en Ops moet vriende wees voordat jy Kubernetes implementeer, anders sal jy breek wat jy het.
Pavel Selivanov het gepraat oor wat oor 5 jaar met Kubernetes gaan gebeur en waarop 'n moderne beginonderneming 'n tegnologiestapel moet bou - kyk na die onderhoud:
3. Vladimir Utratenko, X5 Retail Group: "DevOps in Enterprise is ontwikkeling sonder pyn en brande"
Maatskappye kom na DevOps-transformasie wanneer hulle besef dat ontwikkeling te stadig is en nie aan realiteite voldoen nie, hulle het 'n begeerte om beter te ontwikkel en vinniger uit te rol.
Vladimir het verduidelik hoe dit gebeur en wat die vangs is:
- Eerstens huur maatskappye 'n DevOps-ingenieur. Dit is 'n Senior Stelseladministrateur, hy is betrokke by die implementering van 'n vrystelling na produksie, die standaardisering van die ontwikkelingsomgewing, die opstel van infrastruktuur, die opsporing en regstelling van verskeie probleme, die outomatisering van prosesse en ander tegniese take.
- Dan is een DevOps-ingenieur nie meer genoeg nie, en die maatskappy huur 'n DevOps-span. Dit is 'n bevoegdheidsentrum wat die pogings van uiteenlopende ingenieurs organiseer en hulle in een rigting laat konsentreer.
- Trouens, DevOps-ingenieur en DevOps-spanne is anti-patrone van DevOps-transformasie. Aangesien DevOps oor praktyke en kultuur gaan, is daar boonop implementering van DevOps in tegnologiemaatskappye (SRE, Production Engineering).
Wat om te doen? Huur 'n tydelike DevOps-span wat sal help om DevOps-transformasie te implementeer, praktyke uit te voer, 'n ontwikkelingskultuur en 'n tegnologiese kultuur te kweek.
Wanneer 'n besigheid ter sprake kom en in DevOps belê, is verskeie scenario's moontlik: alles sal uitmekaar val met opstyg; sal aanbly as SRE/Production Engineering of Embedded Ops; sal na BizOps skuif wanneer prosesse op besigheidsstatistieke gebaseer is.
Vladimir Utratenko het ons vertel hoe “bloedig” DevOps in 'n onderneming werklik is en hoe praktyke in groot kleinhandel geïmplementeer word - kyk na die onderhoud:
4. Sergey Puzyrev, Facebook: "Produksie-ingenieur gee om vir die diens as geheel: sodat beide gebruikers en ontwikkelaars 'n goeie tyd het"
Facebook is 'n groot maatskappy, met 'n groot aantal komponente, bedieners, mense en datasentrums. Ten spyte van sy groot grootte, is dit baie vinnig - ontwikkelaars kan dienste baie keer per dag ontplooi. Facebook groei ook vinnig, en dit is nie net die aantal gebruikers en bedieners wat groei nie, die aantal ontwikkelaars neem ook toe, wat die prosesse meer kompleks maak.
Sergey het op Facebook vertel wat 'n produksie-ingenieur doen:
- 'n Produksie-ingenieur kodeer baie, hy moet stelselkennis hê: bedryfstelsels, lêerstelsels, databasisse, netwerke en dies meer. Moet ondervinding hê om met verspreide stelsels en Betroubaarheidsingenieurswese te werk, dit wil sê om produkbetroubaarheid te ondersteun. Dit moet op oproep wees, dit wil sê, te eniger tyd beskikbaar om te bel.
- Produksie-ingenieur verskil van sagteware-ingenieur deur gevorderde vaardighede in werking te hê, maar is in werklikheid 'n subspesie van sagteware-ingenieur. Sagteware-ingenieurs kodeer meer; hulle kan bykomende vaardighede hê wat byvoorbeeld met dataverwerking verband hou. Op Facebook moet sulke spesialiste ook op diens wees, wat vir baie as ’n onaangename verrassing kom.
- Die behoeftepiramide van 'n Produksie-ingenieur in 'n maatskappy begin met die monitering van bedieners en hul lewensiklus, dit wil sê die verkryging van nuwe hardeware, die opstel daarvan, in werking stel. Die volgende vlak is dieselfde op die diensvlak: monitering van dienste en hul lewensiklus. Dan kom naatlose skaal en gevorderde monitering. Hulle skakel oor na outoskaling nadat die dienslewensiklus geoutomatiseer is. En op die ou end is dit nodig om tuning te doen sodat skaal effektief is en die maatskappy geld en hulpbronne bespaar.
5. Mikhail Chinkov, AMBOSS: "Een departement kan nie die DevOps-pad volg nie, die hele maatskappy moet dit volg"
Mikhail glo dat DevOps deurlopende ontwikkeling is. Jy kan nie sommige gereedskap bekendstel en daar stop nie. Watter probleme verhoed maatskappye om DevOps te word en hoe om praktyke te implementeer?
Verskil in die begrip van DevOps. Kanonieke devops, soos evangeliste dit sien, rus op 5 pilare:
- kultuur - fokus op mense en samewerking;
- outomatisering - delegering van roetine na werkvloei;
- lean - klem op die lewering van waarde aan die gebruiker;
- deel - voortdurende uitruil van kennis;
- metrieke en ontvang terugvoer deur dit te gebruik.
Maatskappye fokus gewoonlik net op outomatisering en die lewering van waarde aan die gebruiker. Maar kultuur, kennisdeling en DevOps-statistieke om ontwikkeling op te spoor vervaag op die agtergrond.
DevOps Standaardisering Uitdagings. Produkdoelwitte verskil vir alle maatskappye en kan nie gestandaardiseer word nie. Die toestand van DevOps in 'n maatskappy hang af van die maatskappy self, maar baie verstaan dit nie en glo dat dit genoeg is om 'n DevOps-ingenieur aan te stel.
Hoekom is ons nog nie DevOps nie? Daar is twee sleutelprobleme. In Enterprise is daar 'n stadige ontwikkeling van die organisasie, probleme met die verandering van die vektor in die gedagtes van duisende werknemers. By beginners is daar 'n gebrek aan bronne van kennis en 'n probleem met die toekenning van hulpbronne vir transformasie.
Stadiums van DevOps-ontwikkeling in 'n maatskappy:
- die eerste is infrastruktuur in die wolk, maar niemand weet hoe dit werk nie, behalwe een of twee admins;
- tweedens is die infrastruktuur deursigtig en verstaanbaar vir alle ingenieurs, maar die prosesse is nie vaartbelyn nie;
- derde - ingenieurs loods en herstel onafhanklik lewendige dienste;
- vierde - ingenieurs sal opsioneel bydra tot die kerninfrastruktuur, deursigtige kode in die wolk, ontplooiing per knoppie.
Die ideale skema is dat almal dieselfde toegang tot die infrastruktuur het, alle ingenieurs het toegang tot die produk en verstaan wat hulle doen.
Nadat alle kulturele en tegniese gestalts gesluit is, sal die maatskappy se DevOps-transformasie terugvoer van sake- en platformstatistieke in ag neem.
6. DevOps-entoesiaste van Rosbank: "1000 dae om DevOps in 'n bloedige onderneming te implementeer"
Yuri Bulich, Dina Maltseva, Evgeny Pankov van Rosbank het vertel hoe hulle in drie jaar na DevOps gekom het. Daar was twee doelwitte: om spesifieke probleme in spesifieke spanne op te los en om gesentraliseerde gereedskap te implementeer.
Hier is die resultate wat behaal is:
Resultate vir produkspanne: 30 keer vinniger montering, 6 keer vinniger installasie, tot 30% besparing op die volle siklus. Ons het nou die vermoë om 'n knoppie te druk om na produktiwiteit te gaan
Resultate vir platformopdragte: 10 keer vinniger montering en installasie, 87% verhoogde aantal installasies, 46% outotoets dekking. Die integrasiespan is nie meer 'n bottelnek nie
So, hoe om DevOps-praktyke in 'n bloedige onderneming te implementeer?
Implementeer eers 'n loodsprojek: Kies spanne, besluit hoe om die argitektuur te implementeer en kies gereedskap. Ons het gereedskap gekies met 'n oop lisensie, met installasie in die bank en kundigheid om daarmee te werk. Rosbank het gelyktydig 'n private wolk saam met die DevOps-platform ontplooi, en dit het aan die begin gehelp. In die wolk was dit moontlik om die nodige hulpbronne binne 15 minute met die druk van 'n knoppie te kry; voorheen kon so 'n proses 'n week neem.
In banke en ander ondernemings is dit nodig om die beperkings vooraf saam met die inligtingsekuriteitspan uit te werk en 'n oplossing te vind wat sal toelaat dat die veranderinge geïmplementeer kan word.
Na die loods moet 'n suksesvolle oplossing opgeskaal word.
- Dit is belangrik om die pyplyn soveel as moontlik te "reguit" deur onnodige skakels daaruit uit te skakel, waardeverskaffers uit te lig en die oorblywende komponente te verwyder. Tussenprodukte is antipatrone. Byvoorbeeld, by Rosbank het 'n aantal spanne nie interne ontwikkeling ontwikkel nie, wat slegs eksterne ontwikkeling oorbly. Dit het gelei tot die ontstaan van 'n toegewyde DevOps-span, wat die oordrag van kode van eksterne na interne ontwikkelaars verseker het. Die probleem is opgelos deur eksterne ontwikkeling in CI/CD te integreer, sodat hulle nie net die kode van hulself na die bank sou oordra nie, maar ook vir die sukses daarvan verantwoordelik sou wees.
- Die volwassenheidsmodel het elemente van DevOps-praktyke, gelyste gereedskap ingesluit en die kenmerke van werk met eksterne verskaffers in ag geneem – dit het in die toekoms gehelp om die agterstand van take vinnig af te sny wanneer dit in nuwe spanne geïmplementeer is.
- Ons het Regering nodig in die vorm van sagte beheer en aanbevelings. 'n DevOps-handboek wat goed werk, is 'n stel organisatoriese en gereedskapseienskappe wat spanne help om die platform korrek te gebruik.
- U moet dadelik aandag gee aan kultuur, dan sal baie veranderinge vinniger en makliker plaasvind. Kweek jou interne gemeenskap, hou ontmoetings, tegniese werkswinkels, opleidings en prettige aktiwiteite. Dit werp vrugte af: mense deel praktyke, kyk wie wat gedoen het, weet waar om te draai, daar is ophef en gesonde mededinging binne die maatskappy.
- Daar is geen sin om met diegene te werk wat nie by die proses betrokke is nie, met spanne wat nie volwasse is nie; dit is beter om in belangstellende spanne en lojale mense te belê.
- Die gekose oplossing moet gerieflik wees vir daardie ingenieurs wat dit gebruik.
- Eksterne ontwikkeling is nie 'n blokkering nie; praktyke kan ook daar geïmplementeer word, die belangrikste ding is dat die span self die begeerte het.
'n Bietjie meer voordeel
Lys van boeke wat die moeite werd is om te lees vir diegene in DevOps, van Alexander Chistyakov, vdsina.ru:
- Irina Yakutenko "Wil en selfbeheersing."
- Daniel Kahneman "Dink, vinnig en stadig".
- Barbara Oakley "A Mind for Numbers".
- Maxim Dorofeev "Jedi-tegnieke".
- Viktor Frankl "Die mens se soeke na betekenis".
Bly ingeskakel
Ons is ook mal oor DevOps. Volg die reeksaankondigings en @Kubernetes, sowel as ander Mail.ru Cloud Solutions-geleenthede, in ons Telegram-kanaal:
Bron: will.com