Kedysi sme zákazníkovi dodali elektronický systém správy dokumentov v jednej prevádzke. A potom k inému objektu. A ešte jeden. A na štvrtom a na piatom. Nechali sme sa tak uniesť, že sme dosiahli 10 rozmiestnených objektov. Ukázalo sa to mocne... najmä keď sme sa dostali k zmenám. V rámci dodávky do výrobného okruhu si 5 scenárov testovacieho systému nakoniec vyžiadalo 10 hodín a 6-7 zamestnancov. Takéto náklady nás nútili robiť dodávky čo najmenej. Po troch rokoch fungovania sme to nevydržali a rozhodli sme sa projekt okoreniť štipkou DevOps.
Teraz všetko testovanie prebieha za 3 hodiny a zúčastňujú sa na ňom 3 ľudia: inžinier a dvaja testeri. Vylepšenia sú jasne vyjadrené v číslach a vedú k zníženiu tak obľúbeného TTM. Podľa našich skúseností existuje oveľa viac zákazníkov, ktorí môžu ťažiť z DevOps, ako tých, ktorí o tom vôbec vedia. Preto, aby sme priblížili DevOps ľuďom, vyvinuli sme jednoduchý konštruktor, o ktorom si podrobnejšie povieme v tomto príspevku.
Teraz vám to povieme podrobnejšie. Jedna energetická spoločnosť zavádza systém správy technických dokumentov v 10 veľkých zariadeniach. Nie je ľahké orientovať sa v projektoch tohto rozsahu bez DevOps, pretože veľký podiel ručnej práce značne oneskoruje prácu a tiež znižuje kvalitu – všetka manuálna práca je plná chýb. Na druhej strane sú projekty, kde je len jedna inštalácia, ale všetko musí fungovať automaticky, neustále a bez zlyhania – napríklad rovnaké systémy toku dokumentov vo veľkých monolitických organizáciách. V opačnom prípade niekto urobí nastavenia ručne, zabudne na pokyny na nasadenie - a výsledkom je, že vo výrobe sa nastavenia stratia a všetko sa zrúti.
Väčšinou pracujeme so zákazníkom prostredníctvom zmluvy a v tomto prípade sa naše záujmy mierne rozchádzajú. Zákazník sa na projekt pozerá striktne v rámci rozpočtu a technických špecifikácií. Môže byť ťažké vysvetliť mu výhody rôznych postupov DevOps, ktoré nie sú zahrnuté v technických špecifikáciách. Čo ak má záujem o rýchle vydania s pridanou obchodnou hodnotou alebo o vybudovanie automatizačného potrubia?
Bohužiaľ, pri práci s vopred schválenými nákladmi sa tento záujem nie vždy nájde. V našej praxi sa vyskytol prípad, keď sme museli vyzdvihnúť vývoj bezohľadného a neopatrného dodávateľa. Bolo to hrozné: neexistovali žiadne aktuálne zdrojové kódy, kódová základňa toho istého systému bola na rôznych inštaláciách odlišná, dokumentácia čiastočne chýbala a čiastočne mala hroznú kvalitu. Zákazník samozrejme nemal kontrolu nad zdrojovým kódom, zostavou, vydaniami atď.
Zatiaľ o DevOps nie každý vie, no akonáhle sa bavíme o jeho výhodách, o reálnej úspore zdrojov, všetkým zákazníkom sa rozžiaria oči. Počet žiadostí, ktoré zahŕňajú DevOps, sa teda časom zvyšuje. Aby sme so zákazníkmi mohli jednoducho hovoriť rovnakým jazykom, musíme rýchlo prepojiť obchodné problémy a postupy DevOps, ktoré pomôžu vybudovať vhodný vývojový kanál.
Takže na jednej strane máme súbor problémov, na druhej strane máme znalosti, postupy a nástroje DevOps. Prečo sa nepodeliť o skúsenosti so všetkými?
Vytvorenie konštruktora DevOps
Agile má svoj vlastný manifest. ITIL má svoju vlastnú metodiku. DevOps má menej šťastia – zatiaľ nezískalo šablóny a štandardy. Hoci určiť vyspelosť spoločností na základe posúdenia ich vývoja a prevádzkových postupov.
Našťastie známa spoločnosť Gartner v roku 2014 a analyzovali kľúčové postupy DevOps a vzťahy medzi nimi. Na základe toho som zverejnil infografiku:
Brali sme to ako základ pre náš . Každá zo štyroch oblastí má sadu nástrojov – zhromaždili sme ich do databázy, identifikovali tie najobľúbenejšie, identifikovali integračné body a vhodné optimalizačné mechanizmy. Celkovo sa ukázalo 36 postupov a 115 nástrojov, z ktorých štvrtinu tvorí open source alebo slobodný softvér. Ďalej si povieme, čo sme v jednotlivých oblastiach dosiahli a ako príklad to bolo implementované v projekte tvorby technickej správy dokumentov, s ktorým sme príspevok začali.
procesy
V notoricky známom projekte EDMS bol systém riadenia technickej dokumentácie nasadený podľa rovnakej schémy na každom z 10 objektov. Inštalácia obsahuje 4 servery: databázový server, aplikačný server, fulltextové indexovanie a správu obsahu. V inštalácii fungujú v rámci jedného uzla a sú umiestnené v dátovom centre v zariadeniach. Všetky objekty sa mierne líšia v infraštruktúre, čo však nezasahuje do globálnej interakcie.
Najprv sme podľa postupov DevOps zautomatizovali infraštruktúru lokálne, potom sme dodávku priviedli na testovací okruh a potom na produkt zákazníka. Každý proces bol vypracovaný krok za krokom. Nastavenia prostredia sú pevné v systéme zdrojového kódu, pričom sa berie do úvahy, ktorý distribučný kit je zostavený na automatickú aktualizáciu. V prípade zmien konfigurácie musia inžinieri jednoducho vykonať príslušné zmeny v systéme správy verzií - a potom prebehne automatická aktualizácia bez problémov.
Vďaka tomuto prístupu sa proces testovania výrazne zjednodušil. Predtým mal projekt testerov, ktorí nerobili nič iné, len manuálne aktualizovali stojany. Teraz len prídu, vidia, že všetko funguje a robia užitočnejšie veci. Každá aktualizácia sa testuje automaticky – od povrchovej úrovne až po automatizáciu podnikových scenárov. Výsledky sú zverejnené ako samostatné správy v TestRail.
Kultúra
Nepretržité experimentovanie sa najlepšie vysvetľuje na príklade návrhu testu. Testovanie systému, ktorý ešte neexistuje, je kreatívna práca. Pri písaní plánu testovania musíte pochopiť, ako správne testovať a ktoré vetvy máte nasledovať. A tiež nájsť rovnováhu medzi časom a rozpočtom, aby ste určili optimálny počet kontrol. Dôležité je vybrať presne potrebné testy, zamyslieť sa nad tým, ako bude používateľ so systémom interagovať, vziať do úvahy prostredie a možné vonkajšie faktory. Bez neustáleho experimentovania sa to nezaobíde.
Teraz o kultúre interakcie. Predtým existovali dve protichodné strany – inžinieri a vývojári. Vývojári povedali: „Je nám jedno, ako to bude spustené. Ste inžinieri, ste chytrí, uistite sa, že to funguje bez porúch“. Inžinieri odpovedali: „Vy, vývojári, ste príliš neopatrní. Buďme opatrnejší a vaše vydania budeme prehrávať menej často. Pretože zakaždým, keď nám dáte deravý kód, nie je nám jasné, ako máme interagovať.“. Ide o problém kultúrnej interakcie, ktorý je z pohľadu DevOps inak štruktúrovaný. Tu sú inžinieri aj vývojári súčasťou jedného tímu, ktorý je zameraný na neustále sa meniaci, no zároveň spoľahlivý softvér.
V rámci toho istého tímu sú špecialisti odhodlaní navzájom si pomáhať. Ako to bolo predtým? Napríklad sa pripravovali hrubé pokyny na nasadenie, asi 50 strán. Inžinier si to prečítal, niečomu nerozumel, nadával a o tretej ráno požiadal vývojára, aby sa vyjadril. Developer komentoval a aj nadával – nakoniec sa nikto netešil. Okrem toho sa samozrejme vyskytli nejaké chyby, pretože si nemôžete zapamätať všetko v pokynoch. A teraz inžinier spolu s vývojárom píše skript pre automatizované nasadenie infraštruktúry aplikačného softvéru. A rozprávajú sa medzi sebou prakticky rovnakým jazykom.
Ľudia
Veľkosť tímu je určená rozsahom aktualizácie. Tím sa prijíma počas formovania dodávky, zahŕňa záujemcov zo všeobecného projektového tímu. Potom sa s tými, ktorí sú zodpovední za každú fázu, napíše plán aktualizácie a tím informuje o postupe. Všetci členovia tímu sú zameniteľní. V rámci tímu máme aj záložného vývojára, ktorý sa však takmer nikdy nemusí pripájať.
Technológia
V technologickom diagrame je zvýraznených niekoľko bodov, ale pod nimi je veľa technológií - môžete vydať celú knihu s ich popisom. Vyzdvihneme teda to najzaujímavejšie.
Infraštruktúra ako kód
Teraz pravdepodobne tento koncept nikoho neprekvapí, ale predtým popisy infraštruktúr zostávali veľmi požadované. , testovacie prostredia boli jedinečné, vážili si ich a zveľaďovali, odfukovali z nich prachové častice.
V dnešnej dobe sa nikto nebojí experimentovať. Existujú základné obrazy virtuálnych strojov a pripravené scenáre pre nasadzovanie prostredí. Všetky šablóny a skripty sú uložené v systéme správy verzií a sú okamžite aktualizované. Predtým, keď bolo potrebné doručiť balík na stojan, objavila sa konfiguračná medzera. Teraz stačí pridať riadok do zdrojového kódu.
Okrem infraštruktúrnych skriptov a kanálov sa na dokumentáciu používa aj prístup Documentation as a Code. Vďaka tomu je jednoduché pripojiť nových ľudí do projektu, uviesť ich do systému na základe funkcií opísaných napríklad v pláne testovania a tiež opätovne použiť testovacie prípady.
Nepretržité dodávanie a monitorovanie
o DevOps sme hovorili o tom, ako sme vyberali nástroje na implementáciu kontinuálneho doručovania a monitorovania. Často nie je potrebné nič prepisovať - stačí použiť predtým napísané skripty, správne vybudovať integráciu medzi komponentmi a vytvoriť spoločnú konzolu na správu. A všetky procesy je možné spustiť pomocou jedného tlačidla alebo plánu.
V angličtine existujú rôzne pojmy, Continuous Delivery a Continuous Deployment. Obe sa dajú preložiť ako „nepretržité doručovanie“, ale v skutočnosti je medzi nimi malý rozdiel. V našom projekte pre tok technických dokumentov distribuovanej energetickej spoločnosti sa skôr používa Dodávka - keď sa inštalácia pre výrobu uskutoční na príkaz. V nasadení sa inštalácia vykoná automaticky. Nepretržité doručovanie v tomto projekte sa vo všeobecnosti stalo centrálna časť DevOps.
Vo všeobecnosti môžete zhromaždením určitých parametrov jasne pochopiť, prečo sú postupy DevOps užitočné. A povedzte to manažmentu, ktorý naozaj miluje čísla. Celkový počet spustení, čas vykonávania fáz skriptu, podiel úspešných spustení - to všetko priamo ovplyvňuje obľúbený čas uvedenia na trh každého, teda čas od odovzdania systému na správu verzií po vydanie verzie na serveri výrobného prostredia. Po implementácii potrebných nástrojov dostanú inžinieri cenné ukazovatele poštou a projektový manažér ich vidí na palubnej doske. Takto môžete okamžite vyhodnotiť výhody nových nástrojov. A môžete si ich vyskúšať vo svojej infraštruktúre pomocou návrhára DevOps.
Kto bude potrebovať naše ?
Nepredstierajme: na začiatok sa nám stal užitočným. Ako sme už povedali, so zákazníkom sa musíte rozprávať rovnakým jazykom a s pomocou dizajnéra DevOps dokážeme rýchlo načrtnúť základ pre takúto konverzáciu. Obchodní špecialisti budú môcť sami posúdiť, čo potrebujú, a tak sa rýchlejšie rozvíjať. Snažili sme sa, aby bol dizajnér čo najpodrobnejší, pridali sme kopu popisov, aby každý používateľ pochopil, čo si vyberá.
Formát dizajnéra vám umožňuje zohľadniť existujúci vývoj spoločnosti v oblasti procesov budov a automatizácie. Nie je potrebné všetko búrať a prestavovať, ak si môžete vybrať len riešenia, ktoré sa dobre integrujú s existujúcimi procesmi a ktoré môžu jednoducho vyplniť medzery.
Možno sa váš vývoj už posunul na vyššiu úroveň a náš nástroj sa vám bude zdať príliš „kapitánsky“. Ale považujeme to za užitočné pre seba a dúfame, že to bude užitočné pre niektorých čitateľov. Pripomíname vám projektantovi - ak niečo, diagram dostanete ihneď po zadaní počiatočných údajov. Budeme vďační za vašu spätnú väzbu a doplnenie.
Zdroj: hab.com