{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Seitsme DevOps p\u00f5him\u00f5tetel p\u00f5hineva transformatsiooni arhet\u00fc\u00fcbi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

K\u00fcsimus \"kuidas DevOps-i rakendada\" on olnud p\u00e4evakorras juba mitu aastat, kuid h\u00e4id materjale pole kuigi palju. Vahel satud sa mitte just k\u00f5ige nutikamate konsultantide reklaamidest petta, kellele on oluline m\u00fc\u00fca vaid oma aega, olenemata sellest, kuidas. Sageli on need h\u00e4gused, \u00e4\u00e4rmiselt \u00fcldised s\u00f5numid selle kohta, kuidas suured korporatsioonide laevad r\u00e4ndavad universumi avarustes. Tekib k\u00fcsimus: kas sellest on meile midagi kasu? Lugupeetud autor, kas saaksite selgelt oma ideed loetellu panna?<\/p>\n

K\u00f5ik see tuleneb sellest, et reaalse praktika ja ettev\u00f5tte kultuuri transformatsioonide m\u00f5istmise kohta on kogunenud mitte just palju teadmisi. Kultuuri muutmine on pikaajaline protsess, mille tulemused ei ilmne n\u00e4dalate ega kuude jooksul. Me vajame kedagi, kes on piisavalt kogenud ja n\u00e4inud, kuidas ettev\u00f5tteid on loodud ja h\u00e4vinud aastaid.<\/p>\n

\"Seitsme
\n
\nJohn Willis<\/b> \u2014 \u00fcks DevOpsi isadest. Johnil on palju aastaid kogemusi mitmesugustes ettev\u00f5tetes. Viimasel ajal on John hakanud m\u00e4rkama erilisi mustreid, mis on nende t\u00f6\u00f6des kohal. Kasutades neid arhet\u00fc\u00fcpide, juhendab John ettev\u00f5tteid t\u00f5elise DevOps-muundamise teele. Rohkem nende arhet\u00fc\u00fcpidest leiate t\u00f5lkes tema ettekandest DevOops 2018 konverentsil.
\n<\/a><\/noindex>
\n

\r\n \"Vaata\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Ettekandja kohta:<\/b><\/p>\n

Rohkem kui 35 aastat IT-juhtimises, osales OpenCloud eelk\u00e4ija loomises Canonicalis, t\u00f6\u00f6tas k\u00fcmnes idufirmas, millest kaks m\u00fc\u00fcdi Dellile ja Dockerile. Praegu on ta SJ Technologiesi DevOps ja Digitaalsete Praktikate asepresident.<\/p>\n

Edasi \u2014 jutustus Johnilt.<\/b><\/p>\n

Minu nimi on John Willis ja mind on k\u00f5ige lihtsam leida Twitteris, @botchagalupe<\/a><\/noindex>. Sama h\u00fc\u00fcdnimi on mul ka Gmailis ja GitHubis. Samuti sellel lingil<\/a><\/noindex> v\u00f5ite leida videoklippe minu ettekannetest ja nende esitlusi.<\/p>\n

Mul on palju kohtumisi erinevate suurte ettev\u00f5tete CIO-dega. Nad kurdavad tihti, et ei saa aru, mis on DevOps, ja k\u00f5ik, kes p\u00fc\u00fcavad seda neile selgitada, r\u00e4\u00e4givad millestki oma. Teine sagedane kaebus on \u2014 DevOps ei toimi, kuigi n\u00e4iliselt j\u00e4rgivad direktorid k\u00f5ike, nagu neile selgitati. R\u00e4\u00e4gime suurtest ettev\u00f5tetest, millel on \u00fcle saja aasta ajalugu. Suheldes nendega, j\u00f5udsin j\u00e4reldusele, et paljudele probleemidele sobivad k\u00f5ige paremini mitte k\u00f5rgtehnoloogilised lahendused, vaid suhteliselt madalatehnoloogilised lahendused. N\u00e4dalate viisi vestlesin lihtsalt erinevate osakondade inimestega. See, mida te n\u00e4ete postituse k\u00f5ige esimesel pildil \u2014 see on minu viimane projekt, tuba n\u00e4gi p\u00e4rast kolme p\u00e4eva t\u00f6\u00f6d v\u00e4lja selline.<\/p>\n

Mis on DevOps?<\/h2>\n

\nT\u00f5epoolest, kui k\u00fcsida 10 erinevalt inimeselt, saavad nad 10 erinevat vastust. Kuid huvitaval kombel on k\u00f5ik need k\u00fcmme vastust \u00f5iged. Valet vastust siin ei ole. Olen tegelenud DevOpsiga \u00fcsna s\u00fcvitsi, umbes 10 aastat, ja olin esimene ameeriklane esimesel DevOpsDayl. Ma ei \u00fctle, et olen k\u00f5igist, kes tegelevad DevOpsiga, targem, kuid kahtlemata ei ole kedagi, kes oleks sellele sama palju aega p\u00fchendanud. Usun, et DevOps tekib siis, kui kohtuvad inimkapital ja tehnoloogia. Tihti unustame inimlikud m\u00f5\u00f5tmed, kuigi r\u00e4\u00e4gime palju igasugustest kultuuridest. <\/p>\n

\"Seitsme
\n
\nPraegu on meil palju andmeid, viis aastat akadeemilisi uuringuid ja teooriate kontrollimine on t\u00f6\u00f6stuslikult seadistatud. Need uuringud \u00fctlevad meile j\u00e4rgmist: kui organisatsioonikultuuris \u00fchendada teatud k\u00e4itumismustreid, on v\u00f5imalik saavutada 2000-kordne kiirus. Sellele kiirusel vastab sama suurusj\u00e4rgu paranemine stabiilsuses. See on kvantitatiivne m\u00f5\u00f5de sellest, millist eeliseid DevOps v\u00f5ib igale ettev\u00f5ttele tuua. Paar aastat tagasi r\u00e4\u00e4kisin DevOpsist \u00fche Fortune 5000 ettev\u00f5tte tegevjuhile. Kui ma valmistasin esitlust, olin v\u00e4ga n\u00e4rvis, sest pidin viie minutiga edastama oma pikaajalise kogemuse. <\/p>\n

Viimaks esitasin j\u00e4rgmist DevOpsi m\u00e4\u00e4ratlust<\/b>: see on praktika ja mustrite komplekt, mis v\u00f5imaldab inimkapitali muuta k\u00f5rge efektiivsusega organisatsiooniliseks kapitaliks. N\u00e4ide \u2014 kuidas Toyota on viimased 50 v\u00f5i 60 aastat t\u00f6\u00f6tanud.<\/p>\n

\"Seitsme
\n
\n(Siin ja edaspidi tuuakse sellised skeemid mitte viidatud materjalina, vaid illustreerimiseks. Nende sisu on igas uues ettev\u00f5ttes erinev. Siiski v\u00f5ib pilti eraldi vaadata ja suurendada sellel lingil.)<\/a><\/noindex><\/i><\/p>\n

\u00dcks edukamaid selliseid praktikaid on v\u00e4\u00e4rtusvoogude kaardistamine<\/b>. Sel teemal on kirjutatud mitmeid h\u00e4id raamatuid, mille \u00fcheks edukamaks autoriks on Karen Martin. Kuid m\u00f6\u00f6dunud aasta jooksul olen j\u00f5udnud j\u00e4reldusele, et isegi see l\u00e4henemine on liiga k\u00f5rgetehnoloogiline. Sellel on kindlasti palju voorusi, millest olen palju kasu saanud. Kuid kui tegevjuht k\u00fcsib sinult, miks tema ettev\u00f5te ei saa uutele radadele minna, on v\u00e4\u00e4rtusvoogude kaardistamisest veel vara r\u00e4\u00e4kida. On palju oluliselt fundamentaalsemaid k\u00fcsimusi, millele tuleb eelnevalt vastused leida. <\/p>\n

Minu arvates on paljude kolleegide viga see, et nad annavad ettev\u00f5ttele viiepunktilise juhise ning seej\u00e4rel tulevad kuue kuu p\u00e4rast tagasi ja vaatavad, mis juhtus. Isegi hea skeemi, n\u00e4iteks v\u00e4\u00e4rtuste voo kaardistamise puhul on olemas, \u00fctleme nii, pimedaid alasid. P\u00e4rast sadu intervjuusid erinevate ettev\u00f5tete direktoritega olen v\u00e4lja t\u00f6\u00f6tanud teatud mustri, mis v\u00f5imaldab probleemi osadeks jagada, ja n\u00fc\u00fcd arutame iga nende osa j\u00e4rjekorras. Enne mistahes tehnoloogiliste lahenduste rakendamist kasutan seda mustrit, ja tulemusena on k\u00f5ik mu seinad skeemidega kaetud. Hiljuti t\u00f6\u00f6tasin \u00fche investeerimisfondiga, ja l\u00f5puks oli mul 100\u2013150 sellist skeemi.<\/p>\n

Halb kultuur s\u00f6\u00f6b h\u00e4id l\u00e4henemisviise hommikuks<\/h2>\n

\nPeamine m\u00f5te on see: \u00fckski Lean, Agile, SAFE ega DevOps ei aita, kui organisatsiooni kultuur on halb. See on nagu sukeldumine s\u00fcgavusse ilma hingamisaparaadita v\u00f5i opereerimine ilma r\u00f6ntgenpildita. Teisis\u00f5nu, \u00fcmber s\u00f5nastades Druckerit ja Demingi: halb organisatsioonikultuur neelab alla iga hea s\u00fcsteemi ega k\u00f6hi v\u00e4lja. <\/p>\n

Peamine probleem lahendamiseks tuleb v\u00f5tta j\u00e4rgmised sammud:<\/p>\n

    \n
  1. Tehke kogu t\u00f6\u00f6 n\u00e4htavaks:<\/b> t\u00f6\u00f6 peab olema n\u00e4htav. Mitte selles m\u00f5ttes, et see peab ilmuma mingile ekraanile, vaid et see peab olema j\u00e4lgitav.<\/li>\n
  2. Konsolideerige t\u00f6\u00f6 juhtimiss\u00fcsteemid:<\/b> t\u00f6\u00f6 juhtimiss\u00fcsteemide konsolideerimine on vajalik. Probleemi \"klanniliste\" teadmiste ja institutsionaalsete teadmiste osas on 9 juhul 10 n\u00f5rk koht inimesed. Raamatus \u00abPhoenix Project\u00bb<\/a><\/noindex> oli probleem \u00fcheainsa inimese, Brenti, t\u00f5ttu, kes sai projekti viibima kolm aastat. Ja selliseid \"Brente\" ma kohtan igal pool. Nende kitsaskohade lahendamiseks kasutan meie nimekirjas j\u00e4rgmisi kahte punkti. <\/li>\n
  3. Piirangute Teooria Metoodika:<\/b> piirangute teooria.<\/li>\n
  4. Koost\u00f6\u00f6 nipid:<\/b> koost\u00f6\u00f6 hack'id. <\/li>\n
  5. Toyota Kata (Kooting Kata<\/a><\/noindex>):<\/b> Toyota Kata kohta ma palju r\u00e4\u00e4kima ei hakka. Kui huvitav, siis minu GitHubis on presentatsioonid<\/a><\/noindex> peaaegu iga teema kohta. <\/li>\n
  6. Turule orienteeritud organisatsioon:<\/b> turule suunatud organisatsioon.<\/li>\n
  7. Varajased audiitorid:<\/b> audit varases etapis.<\/li>\n<\/ol>\n

    \"Seitsme
    \n
    \nOma t\u00f6\u00f6 alustamine organisatsiooniga on v\u00e4ga lihtne: l\u00e4hen ettev\u00f5ttesse ja r\u00e4\u00e4gin t\u00f6\u00f6tajatega. Nagu n\u00e4ha, ei ole siin mingeid k\u00f5rgtehnoloogilisi meetodeid. K\u00f5ik, mis on vajalik, on midagi, millega kirjutada. Kogun mitmed meeskonnad samas ruumis ja anal\u00fc\u00fcsin seda, mida nad mulle \u00fctlevad, oma seitsme arhet\u00fc\u00fcbi vaatenurgast. Seej\u00e4rel annan neile ise markerid ja palun neil kirja panna k\u00f5ik see, mida nad seni valjusti r\u00e4\u00e4kisid. Tavaliselt on sellistel kohtumistel \u00fcks inimene, kes k\u00f5ik \u00fcles kirjutab, ja parimal juhul suudab ta fikseerida 10% arutelust. Minu meetodiga \u00f5nnestub seda protsenti t\u00f5sta umbes 40%ni. <\/p>\n

    \"Seitsme
    \n
    \n(Erakordselt seda illustratsiooni on v\u00f5imalik     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Minu l\u00e4henemine p\u00f5hineb William Schneideri t\u00f6\u00f6l (William Schneider, The Reengineering Alternative<\/a><\/noindex>). Selle l\u00e4henemise aluseks on m\u00f5te, et iga organisatsiooni saab jagada neljaks ruuduks. See skeem on tavaliselt minu t\u00f6\u00f6 tulemus mitmete teiste skeemide seas, mis tekivad organisatsiooni anal\u00fc\u00fcsi k\u00e4igus. Oletame, et meil on organisatsioon, millel on k\u00f5rge kontrollitase, kuid madal p\u00e4devus. See on \u00e4\u00e4rmiselt ebasoovitav variant: k\u00f5ik k\u00e4ivad sirgelt, kuid keegi ei tea, mida teha. <\/p>\n

    Veidi parem variant on k\u00f5rge kontrolli ja p\u00e4devuse tase. Kui selline ettev\u00f5te on kasumlik, siis v\u00f5ib-olla DevOps ei olegi vajalik. K\u00f5ige huvitavam on t\u00f6\u00f6tada ettev\u00f5ttega, millel on k\u00f5rge kontrollitase, madal p\u00e4devus ja koost\u00f6\u00f6, kuid samas k\u00f5rge kultuuri(t\u00e4iendamine) tase. See t\u00e4hendab, et ettev\u00f5ttes on palju inimesi, kellel on hea meel seal t\u00f6\u00f6tada, ning t\u00f6\u00f6tajate voolavus on madal. <\/p>\n

    \"Seitsme
    \n
    \n(Erakordselt seda illustratsiooni on v\u00f5imalik     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Minu arvates takistavad rangelt m\u00e4\u00e4ratletud soovitustega meetodid l\u00f5ppkokkuv\u00f5ttes t\u00f5e saavutamist. Eriti kehtib see v\u00e4\u00e4rtuste voogude kaardistamise kohta, kus on palju reegleid teabe struktureerimise osas. Varases faasis, millest ma n\u00fc\u00fcd r\u00e4\u00e4gin, pole neid reegleid kellelegi vaja. Kui inimene markeriga k\u00e4es kirjeldab tahvlil ettev\u00f5tte tegelikku olukorda, on see parim viis aru saada, kuidas asjad on. Selline teave ei j\u00f5ua direktoriteni. Sel hetkel on rumal inimest katkestada ja \u00f6elda, et ta on valesti joonistanud mingit noolt. Sellel etapil on parem j\u00e4rgida lihtsaid reegleid, n\u00e4iteks: mitmetasandilise abstraktsiooni v\u00f5ib luua lihtsalt kasutades erineva v\u00e4rvusega markereid. <\/p>\n

    Kordan, ei mingit k\u00f5rgtehnoloogiat. Must marker kujutab objektiivset reaalsust, kuidas k\u00f5ik t\u00f6\u00f6tab. Punase markeriga m\u00e4rgivad inimesed, mis neile olemasolevas olukorras ei meeldi. Oluline on, et seda kirjutavad nemad, mitte mina. Kui l\u00e4heme p\u00e4rast koosolekut IT-direktori juurde, ei paku ma v\u00e4lja nimekirja 10 asjast, mida tuleb parandada. P\u00fc\u00fcan leida seoseid selle vahel, mida ettev\u00f5tte inimesed r\u00e4\u00e4givad, ja olemasolevate, t\u00f5estatud mustrite vahel. L\u00f5puks, sinise markeriga pakutakse v\u00e4lja v\u00f5imalikke lahendusi probleemile. <\/p>\n

    \"Seitsme
    \n
    \n(Erakordselt seda illustratsiooni on v\u00f5imalik     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Selle l\u00e4henemise n\u00e4idis on praegu \u00fcleval. Selle aasta alguses t\u00f6\u00f6tasin \u00fche pangaga. Seal olid julgeolekuteenistuse t\u00f6\u00f6tajad veendunud, et nad ei tohi osaleda n\u00f5uete ja projekteerimise \u00fclevaatuses (design and requirement reviews). <\/p>\n

    \"Seitsme
    \n
    \n(Erakordselt seda illustratsiooni on v\u00f5imalik     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Siis r\u00e4\u00e4kisime teiste osakondade inimestega ja selgus, et umbes 8 aastat tagasi v\u00e4ljasaatud tarkvaraarendajad pani julgeolekut\u00f6\u00f6tajad v\u00e4lja, sest need aeglustasid t\u00f6\u00f6d. Ja siis sellest kujunes v\u00e4lja keeld, mida v\u00f5eti kui iseenesestm\u00f5istetavust. Kuigi tegelikult ei olnud mingit keelt. <\/p>\n

    Meie kohtumine kulges \u00e4\u00e4rmiselt segaselt: umbes kolme tunni jooksul ei suutnud viis erinevat tiimi mulle selgitada, mis toimub koodi ja kokkupakkimise vahel. Ning see n\u00e4ib olevat k\u00f5ige lihtsam asi. Enamik DevOps konsultante eeldavad, et see on juba k\u00f5igile teada. <\/p>\n

    Siis inimene, kes vastutas IT halduse eest, kes oli nelja tunni jooksul vaikinud, \u00e4kki \u00e4rkas ellu, kui j\u00f5udsime tema teema juurde, ja hoidis meid veel pikalt tegevuses. L\u00f5puks k\u00fcsisin temalt, mida ta meie kohtumisest arvab, ja ma ei unusta kunagi tema vastust. Ta \u00fctles: \"Varem arvasin, et meie pangas on ainult kaks tarkvara tarnimise viisi, aga n\u00fc\u00fcd tean, et neid on lausa viis, millest kolmest ma isegi ei teadnud.\" <\/p>\n

    \"Seitsme
    \n
    \n(Erakordselt seda illustratsiooni on v\u00f5imalik     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Viimane koosolek selles pangas toimus meeskonnaga, mis tegeleb investeerimistarkvaraga. Just nemad selgitasid, et markeriga skeemide joonistamine paberile on parem kui tahvlile, ja isegi parem kui nutitahvlile. <\/p>\n

    \"Seitsme
    \n
    \nFotod, mida n\u00e4ete, on sellest, kuidas hotellis konverentsisaal neljandal kohtumise p\u00e4eval v\u00e4lja n\u00e4gi. Ja neid skeeme kasutasime mustrite, st. arhet\u00fc\u00fcpide leidmiseks. <\/p>\n

    Nii et, esitan k\u00fcsimusi t\u00f6\u00f6tajatele, nad kirjutavad vastuseid kolme v\u00e4rvi markeritega (must, punane ja sinine). Anal\u00fc\u00fcsin nende vastuseid arhet\u00fc\u00fcpide osas. N\u00fc\u00fcd arutame k\u00f5iki arhet\u00fc\u00fcpe j\u00e4rjekorras. <\/p>\n

    1. Make All Work Visible: Teha kogu t\u00f6\u00f6 n\u00e4htavaks<\/h3>\n

    \nEnamikus ettev\u00f5tetes, mida ma tunnen, on v\u00e4ga k\u00f5rge m\u00e4\u00e4r teadmata t\u00f6\u00f6st. N\u00e4iteks, kui \u00fcks t\u00f6\u00f6taja palub teiselt midagi teha. Suurtes organisatsioonides v\u00f5ib olla kuni 60% etten\u00e4gematut t\u00f6\u00f6d. Ja kuni 40% t\u00f6\u00f6st ei ole mingil moel dokumenteeritud. Kui see oleks Boeing, siis ma ei t\u00f5usnud enam kunagi nende lennukiga. Kui ainult pool t\u00f6\u00f6st on dokumenteeritud, ei ole teada, kas see t\u00f6\u00f6 tehakse \u00f5igesti v\u00f5i mitte. K\u00f5ik \u00fclej\u00e4\u00e4nud meetodid osutuvad kasutuks \u2014 pole mingit m\u00f5tet proovida midagi automatiseerida, sest tuntud 50% v\u00f5ib olla just k\u00f5ige koordineeritum ja selgem t\u00f6\u00f6 osa, mille automatiseerimine suuri tulemusi ei too, samas kui k\u00f5ige hullem on just n\u00e4htamatus pooles. Ilma dokumentatsioonita on v\u00f5imatu leida igasuguseid trikke ja peidetud t\u00f6\u00f6d, ei suudeta kindlaks teha kitsaskohti, neid samu \u201eBrente\u201d, millest ma juba r\u00e4\u00e4kisin. On suurep\u00e4rane raamat Dominica De Grandiselt \u00abMaking Work Visible\u00bb<\/a><\/noindex>. See toob v\u00e4lja viis erinevat \u00abaja lekkimist\u00bb<\/b> (aeg vargad):<\/p>\n