Co je DevOps a jaké úkoly provádí technik DevOps
Termín DevOps (vývojové operace nebo operace uvnitř
Bohatý arzenál postupů přináší DevOps blíže ostatnímpopulární v IT sféře pomocí metody Agile. Jedná se o iterativní designový přístup, který vám umožní přizpůsobit se měnícím se požadavkům. Specialista DevOps se proto snaží vylepšit produkt a obchodní procesy předvídatelnější a transparentnější. Zlepšuje také obchodní metriky, jako je zkrácení doby do uvedení na trh. To je doba od začátku vývoje produktu po uvedení na trh. Znalost faktorů, které prodlužují čas potřebný k vytvoření softwaru, a systémový přístup umožňují technikovi DevOps umožnit nepřetržitou a rychlou výrobu. Aby to bylo jasnější, můžete nakreslit analogii s dopravníkem pro montáž automobilů. Všechny díly jsou navrženy předem, aby během montáže do sebe perfektně zapadaly. Inženýři, kteří navrhují motor, přemýšlejí o tom, jak funguje ve spojení s koly, brzdami atd. DevOps dělá totéž: přebírá odpovědnost za více produktů než vývojář a zajišťuje spolupráci všech týmů.
Pink Pony World: Race for Fashion Philosophy
Ne všechny společnosti však DevOps potřebují.Například v týmech bez již existujících IT oddělení, která se nepodílejí na výrobě digitálního produktu, filozofie DevOps vůbec neplatí. Mezi tyto oblasti patří společnosti, jejichž zisk přímo nezávisí na tom, jak jsou zákazníci spokojeni s produktem IT, se kterým interagují. Navíc často není vhodný pro malé podniky. Metodika vyžaduje změny v mnoha zavedených podnikových procesech a dokonce i ve firemní kultuře. Malé společnosti nemusí takové změny z hlediska projektové ekonomiky jednoduše tolerovat.
Módní nemocí digitální transformace je častotýká se vedoucích těchto společností. Ve snaze o nekonečnou optimalizaci zapomínají na další faktory, které ovlivňují podnikání. Výsledkem je, že společnosti přicházejí o peníze, efektivitu a v nejhorším případě o obchodní procesy, které se v průběhu let budovaly. Další věcí jsou IT giganti, banky, velké obchodní a průmyslové akce. Pro ně může být DevOps velmi přínosný. Podle výroční zprávy Alfa-Bank za rok 2017 nám tedy zavedení metodiky umožnilo urychlit vývoj a implementaci až 60krát.
Místo workshopu Stakhanovite-mnogostanochnik
Taková rozsáhlá funkčnost je samozřejmě těžkáprovádí jeden zaměstnanec, takže v ideálním případě je do DevOps zapojen celý křížově funkční tým. Zahrnuje profesionály v rolích a procesních a produktových manažerech, vývojáře infrastruktury, inženýra a mnoho dalších rolí. V ruské praxi se však specialista DevOps může často stát módním způsobem, jak ušetřit peníze na tvorbě produktu. K této situaci obvykle dochází poté, co vrcholový manažer společnosti rozhodne, že nastal čas pro digitální transformaci. Společnost naléhavě přijímá nové odborníky nebo rozšiřuje seznam odpovědností stávajících vývojářů a správců systému. Ve výsledku náborové služby nevytvářejí volná místa pro inženýry DevOps, ale pro zaměstnance s více stanicemi.
Takového zaměstnance lze zavázat individuálněnastavovat servery, pokládat kabeláž a poté sledovat chyby, nastavovat databáze a hostovat projekty atd. Tento příklad je extrémní, ale skutečný. V důsledku toho zaměstnanci rychle shoří a implementace metodiky do práce společnosti selhává. Zacházení se specialistou DevOps jako s kouzelníkem, který dokáže současně zvládnout velké množství úkolů, spolu s monitorováním provozu celého systému, nepřinese podnikání zisk.
Další běžný problém souvisí srozdělení týmu do dvou skupin, které spolu nemohou vyjít. Představte si, že IT společnost má oddělení DevOps, které může měnit obvyklé pracovní postupy. Tato pravidla však zůstávají závazná pro ostatní vývojáře. V tomto případě samozřejmě není třeba hovořit o spolupráci a „plynulosti“ práce. Oba týmy se začnou střetávat a produktivita klesá.
Sud s práškem v nákladovém prostoru: DevOps nejsou jen dovednosti
Jedním z úkolů oddělení DevOps je zavéstkomunikace mezi různými IT specialisty společnosti. Inženýři DevOps by měli nejen implementovat technologie a ladit procesy, ale také ponořit vývojový tým do průběhu věcí - sdílet odpovědnosti, pomáhat zvyšovat kompetence. Tito odborníci se nicméně často zabývají čistě technickými úkoly, obvykle kvůli banálnímu nedostatku času, a to jak pro ně, tak pro ty, jejichž kompetence je třeba zvýšit.
Jako výsledek, vzhledem k tomu, že představil módníKaždý používá technologie a znalosti a dovednosti jsou soustředěny do jednoho oddělení, vznikají problematické situace, včetně katastrofických. Nová řešení vytvořená inženýry DevOps, bez dobře koordinované práce různých oddělení, mohou přinést tolik problémů, kolik by měli původně vyřešit, což neznamená, že by specialisté DevOps měli vytvářet firemní kulturu od nuly, jak si domácí často myslí. vůdci. Jednota digitálního produkčního potrubí a podpora přenosu nových dovedností a komunikace musí pocházet od vůdců společnosti. Bez toho se i tým DevOps bude vyvíjet špatně a nebude s týmem sdílet znalosti.
Ani outsourcing DevOps, anikonzultace s odborníkem zvenčí. V prvním případě se externí tým neřídí potřebami klientské společnosti, ale standardní sadou technologií nabízených na trhu. Pro klienta je to loterie: outsourcovaní zaměstnanci používají nejasné znalosti DevOps na trhu. Výsledkem je, že se obchodní procesy stávají stále složitějšími, ale to nepřináší obchodnímu prospěchu žádné výhody. Společnosti tento přístup často podporují - například je žádají, aby neměnily své vývojové procesy. Je jasné, že je to v rozporu se samotným konceptem DevOps.
Dlouhé, drahé, problematické: drsné DevOps v ruštině
Místo použití filozofie DevOps nau všech obchodních procesů domácí společnosti často upřednostňují práci na nástrojích, které neovlivní rychlost práce. Jedním z výsledků je například „cihlová zeď“ - operace, tj. Tým správců systému, zůstává izolovaný a vývojáři na ně jednoduše hodí aplikace. Výsledkem je samozřejmě stále se zlepšující sada nástrojů. K zásadním změnám však nedochází, transparentnost se nezvyšuje a spolupráce týmu IT se nezlepšuje.
Další zádrhel, na který narazímanažerů při implementaci DevOps - nedostatek podnikových znalostních bází. Podle zprávy DORA za rok 2019 byly týmy, které využívaly interní informační zdroje společnosti, 1,73krát efektivnější než ostatní. Tento problém opět souvisí s uzavřenou kulturou mnoha ruských společností, ve kterých tým nesdílí znalosti. Kvůli této uzavřenosti začínají společnosti hromadit technický dluh. Nástroje zastarávají, artefakty se neodstraňují, dokumentace se neaktualizuje.
Objektivní obchodní potřeba stability výroby, a tedy zisku, spolu se zastaralou technologickou základnou a technickým dluhem vedou k neúspěšnému používání DevOps.
To vše často vede k tomu, že po dlouhém trápení jsou nová řešení nabízená týmem DevOps jednoduše zahozena a procesy jsou „vráceny zpět“.
Každá společnost má svou vlastní cestu digitální transformace.Ve většině případů to opravdu změní způsob, jakým je váš kód vyvíjen a nasazován k lepšímu. To znamená, že DevOps v Rusku stále existuje: každý měsíc se na trhu objevuje spousta volných pracovních míst souvisejících s touto metodikou. Další věc je, že jsou za nimi různé definice speciálních a praktických úkolů. Společnosti by však měly přestat pronásledovat přízračně ideální IT systémy a být kritické k přijetí moderní, ale ne nutně ziskové filozofie, upřednostňující své vlastní potřeby.
Viz také:
V černých dírách mohou být vesmíry. Řekneme vám o novém objevu
Ve 3. dni nemoci většina pacientů COVID-19 ztratí čich a často trpí rýmou.
Výzkum: 15 milionů tun mikroplastů nalezených na dně oceánu