{"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 arhet\u00fc\u00fcbi muutmine DevOpsi p\u00f5him\u00f5tete j\u00e4rgi","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

K\u00fcsimus \"kuidas DevOps'i enda juurde rakendada\" on p\u00fcsinud juba mitu aastat, kuid h\u00e4id materjale ei ole eriti palju. Vahel satute te mitteteadlike konsultantide reklaamkerge ohvriks, kellele on t\u00e4htis m\u00fc\u00fca oma aega, \u00fcksk\u00f5ik kuidas. M\u00f5nikord on see udused, \u00e4\u00e4rmiselt \u00fcldised s\u00f5nad selle kohta, kuidas hiidkorporatsioonide laevad avarustes seilavad. Kuidas see meid aga m\u00f5jutab? Auv\u00e4\u00e4rt autor, kas saaksite arusaadavalt loetleda oma ideed?<\/p>\n

K\u00f5ik see tuleneb sellest, et reaalse praktika ja arusaamise osas ettev\u00f5tte kultuuri transformatsioonidest on teadmisi veel v\u00e4he. Muutused kultuuris on pikaajalised asjad, mille tulemusi ei n\u00e4e n\u00e4dala ega kuu p\u00e4rast. Me vajame kedagi, kes on piisavalt kogenud ja n\u00e4inud, kuidas ettev\u00f5tted on loodud ja kokku kukkunud l\u00e4bi aastate.<\/p>\n

\"Seitsme
\n
\nJohn Willis<\/b> on \u00fcks DevOp'i isa. Johnil on aastate pikkune kogemus, t\u00f6\u00f6tades paljude ettev\u00f5tetega. Viimasel ajal on John hakanud m\u00e4rkama spetsiifilisi mustreid, mis on iga\u00fches t\u00f6\u00f6s omased. Kasutades neid arhet\u00fc\u00fcpe, suunab John ettev\u00f5tteid t\u00f5elisele DevOps'i transformatsiooniteele. Rohkem nende arhet\u00fc\u00fcpide kohta leiate tema DevOops 2018 konverentsi ettekande t\u00f5lkest.
\n<\/a><\/noindex>
\n

\r\n \"M\u00e4ngi\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Ettekanne:<\/b><\/p>\n

\u00dcle 35 aastat IT-halduse valdkonnas, osalenud OpenCloudi eelk\u00e4ija loomisel Canonicalis, olnud kaasatud 10 k\u00e4ivitusettev\u00f5ttesse, millest kaks m\u00fc\u00fcdi Dellile ja Dockerile. Hetkel on ta SJ Technologiesi DevOps'i ja Digitaalsete Praktikate asepresident.<\/p>\n

Edasi r\u00e4\u00e4gib John.<\/b><\/p>\n

Mina olen John Willis ja mind leiab k\u00f5ige lihtsamalt Twitterist, @botchagalupe<\/a><\/noindex>. Sama h\u00fc\u00fcdnimi on mul ka Gmailis ja GitHub'is. Ja selle lingi kaudu<\/a><\/noindex> leiate te minu ettekannete ja esitluste videod.<\/p>\n

Mul on palju kohtumisi erinevate suurte ettev\u00f5tete CIO-dega. Nad kurdavad sageli, et ei saa aru, mis asi on DevOps, ja k\u00f5ik, kes p\u00fc\u00fcavad seda neile selgitada, r\u00e4\u00e4givad millestki, mis on neile tuttav. Teine sage kaebus on see, et DevOps ei t\u00f6\u00f6ta, kuigi tundub, et direktorid teevad k\u00f5ik nii, nagu on neile selgitatud. Jutt k\u00e4ib suurtest ettev\u00f5tetest, mis on eksisteerinud \u00fcle saja aasta. Suheldes nendega, j\u00f5udsin j\u00e4reldusele, et paljude probleemide lahendamiseks sobivad paremini mitte k\u00f5rgtehnoloogilised, vaid suhteliselt madala tehnoloogia lahendused. N\u00e4dalaid suheldes erinevate osakondade inimestega. See, mida n\u00e4ete postituse esimesel pildil \u2014 see on minu viimane projekt, ruum n\u00e4gi v\u00e4lja p\u00e4rast kolme p\u00e4eva t\u00f6\u00f6d.<\/p>\n

Mis on DevOps?<\/h2>\n

\nT\u00f5epoolest, kui k\u00fcsida k\u00fcmnelt erinevalt inimeselt, annavad nad k\u00fcmme erinevat vastust. Kuid siin on huvitav asi: k\u00f5ik need k\u00fcmme vastust on \u00f5iged. Vale vastust siin ei ole. Olen DevOpsiga s\u00fcvitsi tegelenud umbes 10 aastat, olin esimene ameeriklane esimesel DevOpsDay'l. Ei \u00fctle, et olen targem kui k\u00f5ik, kes DevOpsiga tegelevad, aga ilmselt on harva kedagi, kes on sellesse energiat panustanud sama palju. Usun, et DevOps tekib siis, kui \u00fchenduvad inimkapital ja tehnoloogia. Tihti unustame inimliku m\u00f5\u00f5tme, kuigi r\u00e4\u00e4gime palju erinevatest kultuuridest. <\/p>\n

\"Seitsme
\n
\nPraegu on meil palju andmeid, viie aasta jooksul tehtud akadeemilisi uuringuid, teooriate kontrollimine t\u00f6\u00f6stuslikus mahus. Need uuringud \u00fctlevad meile j\u00e4rgmist: kui organisatsioonikultuuris \u00fchendatakse m\u00f5ned k\u00e4itumismustrid, v\u00f5ib saavutada kiirus suurenemise 2000 korda. Selle kiiruset\u00f5usuga vastab sama parendamine stabiilsusele. See on kvantitatiivne m\u00f5\u00f5de sellest eelisarvest, mida DevOps suudab anda mis tahes ettev\u00f5ttele. Paar aastat tagasi r\u00e4\u00e4kisin DevOps'ist Fortune 5000 ettev\u00f5tte tegevjuhile. Kui valmistusin esitluseks, olin v\u00e4ga n\u00e4rvis, sest pidin viie minutiga esitama oma aastatepikkuse kogemuse. <\/p>\n

Kokkuv\u00f5ttes andsin j\u00e4rgmise DevOps m\u00e4\u00e4ratluse<\/b>: see on praktikate ja mustrite kogum, mis v\u00f5imaldab muuta inimkapitali k\u00f5rge tootlikkusega organisatsioonikapitaliks. N\u00e4ide \u2014 see, kuidas Toyota on t\u00f6\u00f6tanud viimased 50 v\u00f5i 60 aastat.<\/p>\n

\"Seitsme
\n
\n(Edasi antud skeemid ei ole lihtsalt viidatud materjalina, vaid illustration. Nende sisu erineb iga uue ettev\u00f5tte puhul. Siiski saab pilti eraldi vaadata ja suurendada selle lingi kaudu.)<\/a><\/noindex><\/i><\/p>\n

\u00dcks k\u00f5ige edukamaid selliseid praktikaid on value stream mapping.<\/b>Selle kohta on kirjutatud m\u00f5ned head raamatud, autor k\u00f5ige edukamatest neist on Karen Martin. Kuid viimasel aastal olen j\u00f5udnud j\u00e4reldusele, et isegi see l\u00e4henemine on liiga tehnoloogiline. Sel on kindlasti palju eeliseid, mida olen palju kasutanud. Kuid kui peadirektor k\u00fcsib, miks tema ettev\u00f5te ei suuda uusi r\u00f6\u00f6pale minna, on veel vara r\u00e4\u00e4kida value stream mapping'ust. On palju m\u00e4rkimisv\u00e4\u00e4rselt fundamentaalsemaid k\u00fcsimusi, millele tuleb eelnevalt vastused leida. <\/p>\n

Minu arvates on paljude kolleegide viga see, et nad lihtsalt annavad ettev\u00f5ttele viie punkti juhendi ja seej\u00e4rel tulevad kuue kuu p\u00e4rast tagasi ning vaatavad, mis juhtus. Isegi hea skeemi, nagu value stream mapping, puhul on olemas nii-\u00f6elda pimedad kohad. P\u00e4rast sadu intervjuusid erinevate ettev\u00f5tete direktoritega olen v\u00e4lja t\u00f6\u00f6tanud teatud mustri, mis v\u00f5imaldab probleemi elementideks jagada, ja n\u00fc\u00fcd arutame neid komponente \u00fcksikasjalikult. Enne kui rakendan m\u00f5nda tehnoloogia lahendust, kasutan seda mustrit ja tulemuseks on see, et k\u00f5ik seinad on skeemidega kaetud. Hiljuti t\u00f6\u00f6tasin \u00fche investeerimisfondiga ja mul oli kokku 100-150 sellist skeemi.<\/p>\n

Halb kultuur s\u00f6\u00f6b h\u00e4id l\u00e4henemisviise hommikus\u00f6\u00f6giks.<\/h2>\n

\nPeamine m\u00f5te on selline: ei Lean, Agile, SAFE ega DevOps ei aita, kui organisatsiooni kultuur on halb. See on nagu sukelduda s\u00fcgavusse ilma hingamisaparaadita v\u00f5i opereerida ilma r\u00f6ntgenpildita. Teisis\u00f5nu, parafraseerides Druckerit ja Demingut: halb organisatsioonikultuur neelab alla iga hea s\u00fcsteemi ja ei l\u00e4mbu. <\/p>\n

Selle peamise probleemi lahendamiseks on vajalik astuda j\u00e4rgmised sammud:<\/p>\n

    \n
  1. Tee Kogu T\u00f6\u00f6 N\u00e4htavaks:<\/b> k\u00f5ik t\u00f6\u00f6 peaks olema n\u00e4htav. Mitte selles m\u00f5ttes, et see peaks tingimata olema arvutiekraanil, vaid selles, et see peaks olema j\u00e4lgitav.<\/li>\n
  2. Konsolideeri T\u00f6\u00f6halduse S\u00fcsteemid:<\/b> On vajalik konsolideerida juhtimiss\u00fcsteemid. Probleem \u201egeneetilise\u201d teadmise ja institutsionaalse teadmise osas on 9 juhul 10 kitsaskohaks inimesed. Raamatus \u201ePhoenix Project\u201d<\/a><\/noindex> oli probleem \u00fchesainses inimeses, Brentis, kelle t\u00f5ttu projekt hilines kolm aastat. Ja selliste \u201eBrentide\u201d otsa komistan kogu aeg. Nende kitsaskohtade lahendamiseks kasutan meie nimekirjas j\u00e4rgmisi kahte punkti. <\/li>\n
  3. Teooria piirangute metoodika:<\/b> piirangute teooria.<\/li>\n
  4. Koost\u00f6\u00f6 h\u00e4kid:<\/b> koost\u00f6\u00f6 h\u00e4kid. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> Toyota Kata teemal ma ei r\u00e4\u00e4gi pikalt. Kui huvitab, siis minu GitHubis on presentatsioonid<\/a><\/noindex> peaaegu iga selle teema kohta. <\/li>\n
  6. Turule suunatud organisatsioon:<\/b> turule suunatud organisatsioon.<\/li>\n
  7. Shift-left auditeerijad:<\/b> varajase etapi audit.<\/li>\n<\/ol>\n

    \"Seitsme
    \n
    \nAlustan koost\u00f6\u00f6d organisatsiooniga v\u00e4ga lihtsalt: l\u00e4hen ettev\u00f5ttesse ja r\u00e4\u00e4gin t\u00f6\u00f6tajatega. Nagu n\u00e4eme, ei ole siin midagi keerulist. K\u00f5ik, mis on vajalik \u2014 on, millega kirjutada. Kogun mitmed tiimid \u00fchte ruumi ja anal\u00fc\u00fcsin, mida nad mulle \u00fctlevad, oma seitsme arhet\u00fc\u00fcbi vaatenurgast. Siis annan neile markerid ja palun kirjutada tahvlile k\u00f5ik see, mida nad seni k\u00f5va h\u00e4\u00e4lega r\u00e4\u00e4kisid. Tavaliselt on sellistel koosolekutel \u00fcks inimene, kes k\u00f5ik \u00fcles kirjutab, ja parimal juhul \u00f5nnestub tal kirja panna 10% arutelust. Minu meetodi puhul \u00f5nnestub see n\u00e4itaja t\u00f5sta kuskile 40% juurde. <\/p>\n

    \"Seitsme
    \n
    \n(Erinevat illustreerimist saab     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Minu l\u00e4henemine p\u00f5hineb William Schneideri t\u00f6\u00f6del (William Schneider, The Reengineering Alternative<\/a><\/noindex>). L\u00e4henemise aluseks on m\u00f5te, et iga organisatsiooni saab jagada neljaks ruuduks. See skeem on tavaliselt minu t\u00f6\u00f6 tulemus, mida olen teinud nende sadade teiste skeemidega, mis ilmnevad organisatsiooni anal\u00fc\u00fcsimisel. Eeldame, et meil on organisatsioon, kus on k\u00f5rge kontrollitase, kuid madal p\u00e4devus. See on \u00e4\u00e4rmiselt soovimatu variant: kui k\u00f5ik k\u00e4ivad rikka, kuid keegi ei tea, mida teha. <\/p>\n

    M\u00f5nev\u00f5rra parem variant, kus on k\u00f5rge kontrollitunne ja kompetents. Kui selline ettev\u00f5te teenib kasumit, siis v\u00f5ib-olla DevOps neile ei olegi vajalik. Huvitav on t\u00f6\u00f6tada ettev\u00f5ttega, kus on k\u00f5rge kontrollitunne, madal kompetents ja koost\u00f6\u00f6, kuid samas k\u00f5rge kultuuri tase. See t\u00e4hendab, et ettev\u00f5ttes on palju inimesi, kellele meeldib seal t\u00f6\u00f6tada, ja t\u00f6\u00f6tajate vahetus on madal. <\/p>\n

    \"Seitsme
    \n
    \n(Erinevat illustreerimist saab     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Mulle tundub, et rangelt m\u00e4\u00e4ratletud soovituste meetodid l\u00f5ppkokkuv\u00f5ttes takistavad t\u00f5e saavutamist. Eelk\u00f5ige value stream mappingi puhul on palju reegleid selle kohta, kuidas teavet struktureerida. Varases t\u00f6\u00f6faasis, millest ma praegu r\u00e4\u00e4gin, ei ole need reeglid kellelegi vajalikud. Kui inimene markeri k\u00e4es kirjeldab tahvlil ettev\u00f5tte tegelikku olukorda, on see parim viis olukorraga tutvumiseks. Selline teave ei j\u00f5ua direktoriteni. Sel hetkel on rumal katkestada inimest ja \u00f6elda, et ta on mingit noolt valesti joonistanud. Sellel etapil on parem kasutada lihtsaid reegleid, n\u00e4iteks: mitmetasandilise abstraktsiooni saab luua, kasutades lihtsalt eri v\u00e4rvi markereid. <\/p>\n

    Kordan, mingeid k\u00f5rgtehnoloogiaid ei ole. Musta markeriga kujutatakse objektiivne reaalsus sellisena, nagu see t\u00f6\u00f6tab. Punase markeriga t\u00e4histavad inimesed, mis neile olemasolevas olukorras ei meeldi. Oluline on, et selle kirjutavad nemad, mitte mina. Kui p\u00e4rast koosolekut l\u00e4hen IT-juhile, ei paku ma 10 asja, mida tuleks parandada. P\u00fc\u00fcdlen sidemete leidmise poole selle vahel, mida inimesed ettev\u00f5ttes r\u00e4\u00e4givad, ja eksisteerivate, t\u00f5estatud mustrite vahel. L\u00f5puks pakuvad sinise markeriga v\u00e4lja v\u00f5imalikud lahendused probleemile. <\/p>\n

    \"Seitsme
    \n
    \n(Erinevat illustreerimist saab     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Sellise l\u00e4henemise n\u00e4ide on n\u00fc\u00fcd \u00fclal toodud. Sel aastal t\u00f6\u00f6tasin \u00fche pangaga. Seal olid turvameetmete osakonna t\u00f6\u00f6tajad veendunud, et nad ei tohi osaleda n\u00f5uete ja projekteerimise kontrolldes (design and requirement reviews). <\/p>\n

    \"Seitsme
    \n
    \n(Erinevat illustreerimist saab     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Ja siis r\u00e4\u00e4kisime teiste osakondade inimestega ning selgus, et umbes 8 aastat tagasi t\u00f5rjusid tarkvaraarendajad turvat\u00f6\u00f6tajad v\u00e4lja, kuna need aeglustasid t\u00f6\u00f6d. Ja siis tekkis sellest keeld, mida hakati pidama iseenesestm\u00f5istetavaks. Kuigi tegelikult ei olnud mingit keeld. <\/p>\n

    Meie kohtumine kulges \u00e4\u00e4rmiselt segases tempos: ligikaudu kolme tunni jooksul ei suutnud viis erinevat meeskonda mulle selgitada, mis toimub koodi ja kogumise vahel. See peaks ju olema k\u00f5ige lihtsam asi. Enamik DevOps n\u00f5ustajaid eeldavad, et see on juba k\u00f5igile teada. <\/p>\n

    Siis inimene, kes vastutas IT halduse eest (IT governance), kes oli neli tundi vait, \u00e4rkas \u00e4kki ellu, kui j\u00f5udsime tema teema juurde, ja haaras meid veel pikaks ajaks. L\u00f5puks k\u00fcsisin temalt, mida ta arvas kohtumisest, ja ma ei unusta kunagi tema vastust. Ta \u00fctles: \"Varem arvasin, et meie pangas on tarkvara tarnimiseks kaks meetodit, aga n\u00fc\u00fcd tean, et neid on tegelikult viis, ja kolmest ma isegi ei kahtlustanud.\" <\/p>\n

    \"Seitsme
    \n
    \n(Erinevat illustreerimist saab     vaadata lingilt<\/a><\/noindex>)<\/i><\/p>\n

    Viimane kohtumine selles pangas oli meeskonnaga, kes tegeleb investeerimistarkvaraga. Just nendega selgus, et skeemide kirjutamine markeriga paberile on parem kui tahvlile ja isegi parem kui nutitahvlile. <\/p>\n

    \"Seitsme
    \n
    \nFotod, mida te n\u00e4ete \u2013 need on sellised, nagu hotellis konverentsiruum neljandal kohtumise p\u00e4eval v\u00e4lja n\u00e4gi. Ja neid skeeme kasutasime mustrite, st arhet\u00fc\u00fcpide otsimiseks. <\/p>\n

    Nii et k\u00fcsin t\u00f6\u00f6tajatelt k\u00fcsimusi, nad kirjutavad vastused kolme v\u00e4rviga markeritega (must, punane ja sinine). Anal\u00fc\u00fcsin nende vastuseid arhet\u00fc\u00fcpidest l\u00e4htudes. N\u00fc\u00fcd arutame k\u00f5iki arhet\u00fc\u00fcpe j\u00e4rjekorras. <\/p>\n

    1. Make All Work Visible: Tehke k\u00f5ik t\u00f6\u00f6 n\u00e4htavaks<\/h3>\n

    \nEnamikus ettev\u00f5tetes, kellega ma t\u00f6\u00f6tan, on v\u00e4ga suur teadmata t\u00f6\u00f6 protsent. N\u00e4iteks, kui \u00fcks t\u00f6\u00f6taja l\u00e4heb teise juurde ja lihtsalt palub midagi teha. Suurtes organisatsioonides v\u00f5ib see ulatuda kuni 60% etten\u00e4gemata t\u00f6\u00f6ni. Ja kuni 40% t\u00f6\u00f6st ei ole mingil moel dokumenteeritud. Kui see oleks Boeing, siis ma ei istuks kunagi enam nende lennukisse. Kui dokumenteeritakse vaid pool t\u00f6\u00f6st, siis ei ole teada, kas t\u00f6\u00f6 on \u00f5igesti tehtud v\u00f5i mitte. K\u00f5ik teised meetodid osutuvad kasulikuks \u2014 ei ole mingit m\u00f5tet proovida midagi automatiseerida, kuna teadaolevad 50% v\u00f5ivad olla just k\u00f5ige sujuvam ja t\u00e4psem osa t\u00f6\u00f6st, mille automatiseerimine ei too suuri tulemusi, samas kui k\u00f5ige hirmsam peitub n\u00e4htamatus pooles. Ilma dokumentatsioonita on v\u00f5imatu leida igasuguseid h\u00e4kke ja varjatud t\u00f6\u00f6d, ei ole v\u00f5imalik tuvastada kitsaskohti, neid \u201eBrent\u2019e\u201d, millest ma juba r\u00e4\u00e4kisin. On suurep\u00e4rane raamat Dominica DeGrandiselt. \u201eMaking Work Visible\u201c<\/a><\/noindex>. See toob esile viis erinevat \u201eajalekke\u201c<\/b> (time thieves):<\/p>\n