Kultúra je často ignorovaná a nepochopená, je však kľúčovým faktorom zodpovedným za výkon spoločnosti. Ak nebudeme riadiť svoju kultúru, skončíme nesprávnymi postupmi, ktoré nakoniec ovplyvnia naše obchodné ciele.
Pochopenie súčasnej kultúry organizácie
Kultúra nám hovorí o hodnotách a normách v rámci skupiny alebo spoločnosti. Identifikuje, čo je dôležité, a tiež to, ako sa ľudia navzájom správajú a spolupracujú.
najnovšia technológia v oblasti umelej inteligencie
KULTÚRA = „Ako sa dajú veci inteligentne robiť pre úspech“
Zoberme si príklad z tímu zákazníckej podpory. Kultúra tohto tímu by mala byť taká, aby nakoniec dosiahol 97 - 98% spokojnosť zákazníkov.
Z hľadiska spokojnosti zákazníka je v prvom rade potrebné byť zdvorilý, aj v zložitých situáciách musia byť dobrými poslucháčmi, aby nedochádzalo k nedorozumeniam, podľa ktorých je potrebné uprednostniť prácu podľa požiadaviek.
Pozastavme sa na chvíľu a položme si niekoľko otázok:
- Aká je teraz kultúra mojej spoločnosti?
- Ako dobre je táto kultúra v súlade s mojimi obchodnými cieľmi alebo KRA?
- Aké problémy môžem očakávať v dôsledku vychýlenia?
Pre každú organizáciu zohrávajú 4C zásadnú úlohu
Pozrime sa teraz na kultúru organizácie vyvíjajúcej softvér. Na zostavení a údržbe jednej softvérovej jednotky je zapojených veľa tímov. Všetky tieto tímy majú samostatné ciele a samostatnú kultúru.
Tento proces začína po potvrdení požiadaviek klientom.
Vývojári sa riadia kódovacími pokynmi definovanými ich organizáciou a na generovanie kódu sa používajú programovacie nástroje, ako sú kompilátory, tlmočníci, debuggery atď. Na kódovanie sa používajú rôzne programovacie jazyky na vysokej úrovni, ako napríklad C, C ++, Pascal, Java a PHP.
Celý balík rozdelia na malé priečinky a podľa toho potom vyvíjajú malé kódy.
1. etapa : Tieto malé jednotky kódov sa potom spoja a vytvoria veľkú jednotku. Pri integrácii menších čipov je potrebné vykonať testovanie na úrovni projektu známe ako testovanie integrácie.
2. etapa : Po úspešnej integrácii je nasadený do fiktívneho systému. Tento fiktívny systém má podobnú konfiguráciu ako konfigurácia klientskeho počítača alebo stroja, na ktorom musí byť tento projekt konečne nasadený.
3. etapa : Nakoniec, po vyskúšaní všetkých funkcií v fiktívnom systéme sa projekt nasadí na produkčný server alebo do klientskeho počítača.
Aj keď sa tento proces javí ako veľmi plynulý a ľahký slovami, z technického hľadiska je veľmi ťažké ho dosiahnuť.
Pozrime sa, s akými problémami sa môžeme stretnúť:
1. etapa :
Klient neustále hľadá zmeny, aby zlepšil kvalitu produktu. Väčšinou, keď bola vykonaná prvá iterácia, klient navrhne niekoľko zmien. Keď vývojári dostanú zmeny, začnú ich začleňovať, čo ovplyvní integráciu vedúcu k rozbitým zostaveniam.
Fáza 2:
Testeri alebo iní prevádzkari väčšinou nebudú vedieť o nových zmenách, ktoré je potrebné vykonať. Hneď ako dostanú kód od vývojárov, začnú ich testovať. Zatiaľ čo sú vývojári v pozadí, vývojári stále robia zmeny.
Pretože nedostávajú dostatok času na implementáciu nových zmien, nakoniec vyvinú neefektívne kódy, s ktorými sa stretávajú v iných sieťových a databázových problémoch, čo opäť oneskoruje čas ich doručenia.
konektivita databázy v jave s mysql
Keď konečne dodajú kódy operačnému tímu, zostáva im veľmi minimálny čas na vytvorenie a implementáciu nových testovacích prípadov. Vynechajú teda veľa testovacích prípadov, ktoré si neskôr uvedomia, že mali vysokú prioritu.
Fáza 3:
Aj keď sa zdá, že zostava je prakticky pripravená na výrobu, výsledky sú úplne neočakávané. Zostavenie zlyhá a dôjde k množstvu chýb.
Potom pri každej vyskytnutej chybe musia sledovať, prečo k nej došlo, kde sa vyskytla, aké zmeny je potrebné vykonať, aby sa to podarilo prekonať, či dôjde k zmene iných kódov, aby bola kompatibilná s tými predchádzajúcimi. Nakoniec je potrebné pre všetky tieto chyby vygenerovať hlásenie o chybe.
Zlyhanie je spôsobené systémovými chybami v dôsledku neznalosti vývojára databázy v účinnosti kódu, neznalosti testera v počte testovacích prípadov atď.
Pretože klient vždy dodržiava termín, zamestnanci podieľajúci sa na ich dosiahnutí sa sústredia iba na konečné vydanie, aj keď musia ohroziť celkovú kvalitu.
Aj keď sa to zdá byť problémom v koordinácii práce, toto je vlastne zlyhanie prijatej kultúry.
Stáva sa to kvôli veľkej závislosti od manuálnych procesov. Beh a tam v rovnakom tíme z dôvodu nedostatku znalostí z rôznych oblastí, nedostatok prístupu alebo nedostatok záujmu zvyšuje našu vlastnú záťaž a bolesť.
Je najvyšší čas, aby sme boli všestranní. Môže byť ťažké ovládať všetky procesy zapojené do systému, ale môžeme byť hybnou silou všetkých, ovládať jeden z nich. Len my potom môžeme automatizovať náš systém alebo zabezpečiť, aby bol dostatočne inteligentný na to, aby sa skôr zotavil ako obnovil.
Teraz by ste si mohli myslieť prečo?
Je to preto, že ten, ktorý ovládate, veľmi závisí od ostatných. Aby sme teda vedeli o bode závislosti, musíme porozumieť celému systému.
Poďme teda na proces zmeny kultúry. Predtým máte odpoveď na nasledujúce otázky?
- Kde zlyháva vaša súčasná kultúra?
- Prečo chcete zmeniť postup?
- Jasne ste identifikovali všetky požadované zmeny?
- Získali ste spätnú väzbu a buy-in od všetkých dotknutých zúčastnených strán?
- Predĺžili ste procesnú disciplínu, údaje a systém merania pre zmenu?
Takže keď teraz máme odpoveď na všetky, myslíme na revolúciu v našom systéme. Ako bude táto revolúcia prebiehať? Dá sa to dosiahnuť, iba keď zabijeme to, čo sme teraz. Veľa času sa stráca pri migrácii kódu medzi tímami. Musíme priniesť proces, ktorý umožní nepretržitú integráciu a neustále nasadenie.
Tento proces nepretržitej integrácie a nasadenia zvyšuje jeho agilitu. Získanie tejto agility sa považuje za kultúru DevOps.
DevOps je prax prevádzkových a vývojových inžinierov zúčastňujúcich sa spoločne na celom životnom cykle služieb, od návrhu cez vývojový proces až po podporu výroby.
Nie je ľahké časom zmeniť fungujúci systém. Úspešným prechodom je skôr renovácia systému ako jeho opätovné vybudovanie.
Teraz sa pozrime, ako to môžeme dosiahnuť. Existujú dva spôsoby prístupu.
1) zhora nadol
2) Zdola nahor
Keď sa ponoríme hlbšie do týchto techník, uvedomíme si, ktorá je pre našu organizáciu najvhodnejšia.
Pri prístupe zhora nadol môžeme ísť na vyšší manažment a požiadať ich o vykonanie zmien vo všetkých tímoch. Ak je vedenie potom presvedčené, môžeme na tom začať pracovať.
Pravdepodobnosť, že dostanete odpoveď ako „NIE“, je však dosť veľká. Je to preto, lebo zmena systému môže viesť organizáciu k nestabilite.
Musia preskúmať štruktúru organizácie, výnosy, úroveň záujmu klienta atď. Najdôležitejším faktorom, ktorý ich ťahá späť od vymykania sa zo starého systému, je to, že nevidia celkový obraz toho, čo sa dá dosiahnuť a ako ľahko sa to dá dosiahnuť s novšou.
rozdiel medzi rozhraním a triedou
V takom prípade môžeme hľadať druhý prístup, aby sme dosiahli tento celkový obraz.
Prístup zdola nahor vyžaduje dobrovoľníctvo. Tu musíme vziať malý tím a malú úlohu a vykonať ju v modeli DevOps.
Ak sa pozrieme na technickú stránku tohto modelu, máme k dispozícii rôzne sofistikované nástroje, vďaka ktorým je práca efektívnejšia a rýchlejšia. Samotné nástroje však nie sú natoľko schopné, aby vytvorili prostredie pre spoluprácu, ktoré sa označuje ako DevOps.
Vytvorenie takéhoto prostredia si vyžaduje, aby ste po vybalení z krabice premysleli napr. hodnotenie a preladenie toho, ako si ľudia myslia o svojich tímoch, podnikaní a zákazníkoch.
Zostavenie novej sady nástrojov je jednoduchšie ako zmena organizačnej kultúry. Propagácia asociálnych hlavných vývojárov, integrácia neefektívneho kódu, nasadzovanie kódov, ktoré neboli správne testované, kladenie si viny na hlavu, považovanie operačného tímu za hlúpe, nie sú osvedčenými postupmi, ktoré používame na umožnenie podnikania. a vytvárať hodnotu pre našich zákazníkov.
Nie je to nástroj, ale ľudia, ktorí ich používajú, robia tento proces zložitým. Povedať na abstraktnej úrovni a nie zbierať nápady a správanie, to, že sme k nim otvorení, nás vedie na svetlú cestu.
Začnime 6-členným tímom a 3-bodovým príbehom. Najprv musíme prelomiť tím, ktorý nazývame vývojári, prevádzka, testéri atď. Všetky považujeme za jeden celok, povedzme „DevOps“. Keď dostaneme požiadavky, musíme analyzovať rizikové zóny. Majte na pamäti hlbšie časti mora a hellip .. Začneme sa plaviť.
Teraz si musíte myslieť „aký je x-faktor týchto nepretržitých integrácií a nepretržitého nasadenia, ktorý znižuje pravdepodobnosť zlyhania“.
Vďaka vylepšenej vízii a procesu môžeme priblížiť manažmentu a poskytnúť jasný obraz o výsledkoch, ako je hladký priebeh procesu, zníženie rizika zlyhania, dokončenie úlohy pred časovou osou atď.
Teraz môžeme jasne vizualizovať, ako bol celý proces optimalizovaný na technickej a kultúrnej pôde, a to po každej iterácii spätnou kontrolou.
Edureka špeciálne upravila ktorý vám pomôže osvojiť si koncepty okolo iných ako Puppet, Jenkins, Ansible, SaltStack, Chef.
Máte na nás otázku? Uveďte ich v sekcii komentárov a my sa vám ozveme.
Súvisiace príspevky: