Kysymys "miten toteuttaa devops" on ollut olemassa jo vuosia, mutta hyviä materiaaleja ei ole paljon. Joskus joudut mainosten uhriksi ei niin älykkäiltä konsulteilta, joiden on myytävä aikaansa riippumatta siitä, miten. Joskus nämä ovat epämääräisiä, äärimmäisen yleisiä sanoja siitä, kuinka megayhtiöiden alukset kyntävät universumin avaruutta. Herää kysymys: mitä väliä tällä on meille? Hyvä kirjoittaja, voitko muotoilla ajatuksesi selkeästi luetteloon?
Kaikki tämä johtuu siitä, että todellista käytäntöä ja ymmärrystä yrityksen kulttuurin muutosten tuloksista ei ole kertynyt paljoa. Kulttuurin muutokset ovat pitkäaikaisia asioita, joiden tulokset eivät näy viikossa tai kuukaudessa. Tarvitsemme jonkun tarpeeksi vanhan näkemään, kuinka yrityksiä on rakennettu ja epäonnistunut vuosien varrella.
John Willis - yksi DevOpsin isistä. Johnilla on vuosikymmenten kokemus työskentelystä useiden yritysten kanssa. Äskettäin John alkoi huomata tiettyjä malleja, jotka tapahtuvat työskennellessään heidän kanssaan. Näiden arkkityyppien avulla John ohjaa yrityksiä DevOps-muutoksen todelliselle polulle. Lue lisää näistä arkkityypeistä hänen DevOops 2018 -konferenssin raportin käännöksestä.
Tietoja kaiuttimesta:
Yli 35 vuotta IT-johtamisessa, osallistunut OpenCloudin edeltäjän luomiseen Canonicalilla, osallistunut 10 startupiin, joista kaksi myytiin Dellille ja Dockerille. Tällä hetkellä hän on SJ Technologiesin DevOps- ja digitaalisten käytäntöjen varatoimitusjohtaja.
Seuraava on tarina Johnin näkökulmasta.
Nimeni on John Willis ja helpoin paikka löytää minut on Twitterissä, . Minulla on sama alias Gmailissa ja GitHubissa. A löydät videotallenteita raporteistani ja esityksiäni niitä varten.
Minulla on useita tapaamisia eri suurten yritysten tietohallintojohtajien kanssa. He valittavat usein, etteivät he ymmärrä mitä DevOps on, ja jokainen, joka yrittää selittää sitä heille, puhuu jostain eri asiasta. Toinen yleinen valitus on, että DevOps ei toimi, vaikka näyttää siltä, että johtajat tekevät kaiken, kuten heille on selitetty. Puhumme yli sata vuotta vanhoista suurista yrityksistä. Keskusteltuani heidän kanssaan tulin siihen tulokseen, että moniin ongelmiin ei soveltu parhaiten korkea teknologia, vaan suhteellisen matalan teknologian ratkaisut. Puhuin viikkojen ajan ihmisten kanssa eri osastoilta. Se mitä näet postauksen aivan ensimmäisessä kuvassa on viimeinen projektini, tältä huone näytti kolmen päivän työn jälkeen.
Mikä DevOps on?
Todellakin, jos kysyt 10 eri ihmiseltä, he antavat 10 erilaista vastausta. Mutta tässä on mielenkiintoinen asia: kaikki nämä kymmenen vastausta ovat oikeita. Tässä ei ole väärää vastausta. Olin melko syvällä DevOpsiin noin 10 vuotta, ja olin ensimmäinen amerikkalainen ensimmäisessä DevOpsDayssa. En sano olevani älykkäämpi kuin kaikki DevOpsiin osallistuvat, mutta tuskin kukaan on käyttänyt niin paljon vaivaa siihen. Uskon, että DevOps syntyy, kun inhimillinen pääoma ja teknologia kohtaavat. Unohdamme usein inhimillisen ulottuvuuden, vaikka puhummekin paljon kaikenlaisista kulttuureista.
Nyt meillä on paljon dataa, viiden vuoden akateemista tutkimusta, teorioiden testausta teollisessa mittakaavassa. Nämä tutkimukset kertovat meille, että jos yhdistät joitakin käyttäytymismalleja organisaatiokulttuurissa, voit saavuttaa 2000-kertaisen nopeuden. Tätä kiihtyvyyttä vastaa tasainen vakauden paraneminen. Tämä on määrällinen mittaus hyödystä, jonka DevOps voi tuoda mille tahansa yritykselle. Pari vuotta sitten puhuin DevOpsista Fortune 5000 -yrityksen toimitusjohtajalle, kun valmistauduin esitykseen, jännitin kovasti, koska piti tiivistää vuosien kokemukseni 5 minuutissa.
Lopulta annoin seuraavan Määritelmä DevOps: Se on joukko käytäntöjä ja malleja, jotka mahdollistavat inhimillisen pääoman muuttamisen tehokkaaksi organisaatiopääomaksi. Esimerkkinä on tapa, jolla Toyota on toiminut viimeiset 50 tai 60 vuotta.
(Jäljempänä tällaiset kaaviot eivät ole referenssimateriaalia, vaan havainnollistavia. Niiden sisältö vaihtelee uusilla yrityksillä. Kuvaa voi kuitenkin katsoa erikseen ja suurennettuna
Yksi menestyneimmistä tällaisista käytännöistä on arvovirran kartoitus. Tästä on kirjoitettu useita hyviä kirjoja, joista menestyneimmät ovat Karen Martinilta. Mutta viimeisen vuoden aikana olen tullut siihen tulokseen, että tämäkin lähestymistapa on liian korkean teknologian. Sillä on varmasti monia etuja ja olen käyttänyt sitä paljon. Mutta kun toimitusjohtaja kysyy, miksi hänen yrityksensä ei voi siirtyä uusille raiteille, on liian aikaista puhua arvovirran kartoituksesta. On monia paljon perustavanlaatuisempia kysymyksiä, joihin on ensin vastattava.
Mielestäni monet kollegani tekevät virheen siinä, että he yksinkertaisesti antavat yritykselle viiden kohdan oppaan ja palaavat sitten kuuden kuukauden kuluttua katsomaan, mitä tapahtui. Jopa hyvässä järjestelmässä, kuten arvovirran kartoittamisessa, on esimerkiksi sokeita kulmia. Satojen eri yritysten johtajien haastattelujen jälkeen olen kehittänyt tietyn mallin, jonka avulla voimme jakaa ongelman osiin, ja nyt keskustelemme jokaisesta näistä komponenteista järjestyksessä. Ennen kuin käytän teknisiä ratkaisuja, käytän tätä mallia, ja sen seurauksena kaikki seinäni on peitetty kaavioilla. Äskettäin työskentelin sijoitusrahaston kanssa ja päädyin 100-150 tällaiseen järjestelmään.
Huono kulttuuri syö hyviä tapoja aamiaiseksi
Pääidea on tämä: mikään Lean, Agile, SAFE ja DevOps ei auta, jos organisaation kulttuuri itsessään on huono. Se on kuin sukeltamista syvyyksiin ilman sukellusvarusteita tai toimimista ilman röntgenkuvaa. Toisin sanoen Druckerin ja Demingin parafraasin mukaan: huono organisaatiokulttuuri nielee minkä tahansa hyvän järjestelmän tukehtumatta siihen.
Tämän pääongelman ratkaisemiseksi sinun on suoritettava seuraavat vaiheet:
- Tee kaikki työt näkyväksi: sinun on tehtävä kaikki työ näkyväksi. Ei siinä mielessä, että se on välttämättä näytettävä jollakin näytöllä, vaan siinä mielessä, että sen on oltava havaittavissa.
- Konsolidoidut työnhallintajärjestelmät: hallintojärjestelmät on vahvistettava. Heimotiedon ja institutionaalisen tiedon ongelmassa 9 tapauksessa 10 pullonkaulana ovat ihmiset. Kirjassa ongelma oli yhdessä henkilössä, Brentissä, joka aiheutti hankkeen kolme vuotta myöhässä aikataulusta. Ja törmään näihin "Brentseihin" kaikkialla. Näiden pullonkaulojen ratkaisemiseksi käytän luettelomme kahta seuraavaa kohdetta.
- Rajoitusteorian metodologia: rajoitteiden teoria.
- Yhteistyöhakkerit: yhteistyöhakkerit.
- Toyota Kata (): En puhu paljon Toyota Katasta. Jos kiinnostaa, githubissani lähes jokaisessa näistä aiheista.
- Markkinalähtöinen organisaatio: markkinalähtöinen organisaatio.
- Vuorovasen tilintarkastajat: auditointi syklin alkuvaiheessa.
Aloitan työskentelyn organisaation kanssa hyvin yksinkertaisesti: menen yritykseen ja juttelen työntekijöiden kanssa. Kuten näette, ei huipputekniikkaa. Tarvitset vain jotain, johon kirjoittaa. Kokoan useita ryhmiä yhteen huoneeseen ja analysoin, mitä he kertovat minulle seitsemän arkkityyppini näkökulmasta. Ja sitten annan heille itselleen merkin ja pyydän heitä kirjoittamaan taululle kaikki, mitä he ovat sanoneet ääneen tähän mennessä. Yleensä tämän tyyppisissä tapaamisissa on yksi henkilö, joka kirjoittaa kaiken ylös, ja parhaimmillaan hän pystyy kirjoittamaan 7% keskustelusta. Menetelmälläni tämä luku voidaan nostaa noin 10 prosenttiin.
(Tämä kuva on katsottavissa erikseen )
Lähestymistavani perustuu William Schneiderin työhön. ). Lähestymistapa perustuu ajatukseen, että mikä tahansa organisaatio voidaan jakaa neljään neliöön. Tämä kaavio minulle on yleensä tulos niiden satojen muiden järjestelmien kanssa työskentelystä, jotka syntyvät organisaation analysoinnissa. Oletetaan, että meillä on organisaatio, jolla on korkea valvontataso, mutta heikko pätevyys. Tämä on äärimmäisen ei-toivottu vaihtoehto: kun kaikki ovat linjassa, mutta kukaan ei tiedä mitä tehdä.
Hieman parempi vaihtoehto on sellainen, jossa sekä hallinnan että osaamisen taso on korkea. Jos tällainen yritys on kannattava, se ei ehkä tarvitse DevOpsia. Mielenkiintoisinta on työskennellä yrityksen kanssa, jolla on korkea hallinta, alhainen osaaminen ja yhteistyö, mutta samalla korkea kulttuurin (viljelyn) taso. Tämä tarkoittaa, että yrityksessä on paljon ihmisiä, jotka haluavat työskennellä siellä ja työvoiman vaihtuvuus on alhainen.
(Tämä kuva on katsottavissa erikseen )
Minusta näyttää siltä, että menetelmät jäykillä ohjeilla päätyvät estämään totuuden saavuttamisen. Erityisesti arvovirtakartoituksessa on monia sääntöjä siitä, miten tiedot tulee jäsentää. Työn alkuvaiheessa, josta nyt puhun, kukaan ei tarvitse näitä sääntöjä. Jos henkilö, jolla on merkki käsissään, kuvaa hallituksessa yrityksen todellista tilannetta, tämä on paras tapa ymmärtää asioiden tila. Sellainen tieto ei saavuta johtajia. Tällä hetkellä on typerää keskeyttää henkilö ja sanoa, että hän piirsi jonkinlaisen nuolen väärin. Tässä vaiheessa on parempi käyttää yksinkertaisia sääntöjä, esimerkiksi: monitasoinen abstraktio voidaan luoda yksinkertaisesti käyttämällä monivärisiä merkkejä.
Toistan, ei huipputekniikkaa. Musta merkki kuvaa objektiivista todellisuutta siitä, miten kaikki toimii. Punaisella merkillä ihmiset merkitsevät sen, mistä he eivät pidä nykyisessä tilanteessa. On tärkeää, että he kirjoittavat tämän, en minä. Kun menen tietohallintojohtajalle kokouksen jälkeen, en tarjoa luetteloa 10 korjattavasta asiasta. Pyrin löytämään yhteyksiä yrityksen ihmisten sanomien ja olemassa olevien, hyväksi havaittujen mallien välillä. Lopuksi sininen merkki ehdottaa mahdollisia ratkaisuja ongelmaan.
(Tämä kuva on katsottavissa erikseen )
Esimerkki tästä lähestymistavasta on nyt kuvattu edellä. Tämän vuoden alussa työskentelin yhdessä pankissa. Siellä olevat turvallisuushenkilöt olivat vakuuttuneita siitä, että heidän ei pitäisi tulla suunnittelu- ja vaatimustarkastuksiin.
(Tämä kuva on katsottavissa erikseen )
Ja sitten keskustelimme muiden osastojen ihmisten kanssa, ja kävi ilmi, että noin 8 vuotta sitten ohjelmistokehittäjät irtisanoivat turvatyöntekijöitä, koska he hidastivat työtä. Ja sitten se muuttui kielloksi, jota pidettiin itsestäänselvyytenä. Vaikka todellisuudessa ei ollut kieltoa.
Tapaamisemme eteni äärimmäisen hämmentävästi: noin kolmen tunnin ajan viisi eri tiimiä ei pystynyt selittämään minulle, mitä koodin ja kokoonpanon välillä tapahtui. Ja tämä näyttäisi olevan yksinkertaisin asia. Useimmat DevOps-konsultit olettavat etukäteen, että kaikki tietävät tämän jo.
Sitten neljä tuntia hiljaa ollut IT-hallinnosta vastaava henkilö heräsi yhtäkkiä henkiin, kun pääsimme hänen aiheeseensa, ja vaivasi meitä hyvin pitkään. Lopuksi kysyin häneltä, mitä hän ajatteli kokouksesta, enkä koskaan unohda hänen vastaustaan. Hän sanoi: "Aiemmin luulin, että pankillamme on vain kaksi tapaa toimittaa ohjelmistoja, mutta nyt tiedän, että niitä on viisi, enkä tiennyt edes kolmesta."
(Tämä kuva on katsottavissa erikseen )
Viimeinen tapaaminen tässä pankissa oli sijoitusohjelmistotiimin kanssa. Hänen kanssaan kävi ilmi, että kaavioiden kirjoittaminen tussilla paperiarkille on parempi kuin taululle ja jopa parempi kuin älytaululle.
Näkemäsi valokuvat ovat miltä hotellin konferenssihuone näytti tapaamisemme neljäntenä päivänä. Ja käytimme näitä malleja etsiäksemme malleja, eli arkkityyppejä.
Joten esitän työntekijöille kysymyksiä, he kirjoittavat vastaukset kolmen värin (musta, punainen ja sininen) merkeillä. Analysoin heidän vastauksiaan arkkityyppien varalta. Keskustellaan nyt kaikista arkkityypeistä järjestyksessä.
1. Tee kaikki työ näkyväksi: Tee työ näkyväksi
Useimmissa yrityksissä, joissa työskentelen, on erittäin suuri osa tuntemattomista töistä. Esimerkiksi tämä on silloin, kun yksi työntekijä tulee toisen luo ja pyytää vain tekemään jotain. Suurissa organisaatioissa voi olla 60 % suunnittelematonta työtä. Ja jopa 40 % työstä ei ole dokumentoitu millään tavalla. Jos se olisi Boeing, en enää koskaan eläissäni nousisi heidän koneeseensa. Jos vain puolet työstä on dokumentoitu, ei tiedetä, tehdäänkö tämä työ oikein vai ei. Kaikki muut menetelmät osoittautuvat hyödyttömiksi - ei ole mitään järkeä yrittää automatisoida mitään, koska tiedossa oleva 50% voi olla johdonmukaisin ja selkein osa työtä, jonka automatisointi ei tuota suuria tuloksia, ja kaikki pahinta asiat ovat näkymättömällä puoliskolla. Dokumentaation puuttuessa on mahdotonta löytää kaikenlaisia hakkereita ja piilotettuja töitä, ei löytää pullonkauloja, juuri niitä "Brentsejä", joista jo puhuin. Siellä on upea Dominica DeGrandisin kirja . Hän paljastaa viisi erilaista "aikavuotoa" (ajan varkaat):
- Liian paljon työtä prosessissa (WIP)
- Tuntemattomat riippuvuudet
- Suunnittelematon työ
- Ristiriitaiset prioriteetit
- Laiminlyöty työ
Tämä on erittäin arvokas analyysi ja kirja on loistava, mutta kaikki nämä neuvot ovat hyödyttömiä, jos vain 50% tiedosta on näkyvissä. Dominican ehdottamia menetelmiä voidaan käyttää, jos saavutetaan yli 90 %:n tarkkuus. Puhun tilanteista, joissa pomo antaa alaiselle 15 minuutin tehtävän, mutta se kestää kolme päivää; mutta pomo ei todellakaan tiedä, että tämä alainen on riippuvainen neljästä tai viidestä muusta ihmisestä.
Phoenix Project on upea tarina projektista, joka oli kolme vuotta myöhässä. Yksi hahmoista joutuu irtisanoutumiseen tämän vuoksi, ja hän tapaa toisen hahmon, joka esitetään eräänlaisena Sokratesena. Hän auttaa selvittämään, mikä meni pieleen. Osoittautuu, että yrityksellä on yksi järjestelmänvalvoja, jonka nimi on Brent, ja kaikki työ menee jotenkin hänen kauttaan. Yhdessä kokouksessa yhdeltä alaisista kysytään: miksi jokainen puolen tunnin tehtävä kestää viikon? Vastaus on hyvin yksinkertaistettu esitys jonoteoriasta ja Littlen laista, ja tässä esityksessä käy ilmi, että 90 %:n käyttöasteella jokainen työtunti kestää 9 tuntia. Jokainen tehtävä on lähetettävä seitsemälle muulle henkilölle, jotta tuosta tunnista tulee 63 tuntia, 7 kertaa 9. Tarkoitan, että Pikkulain tai minkä tahansa monimutkaisen jonoteorian käyttäminen edellyttää ainakin dataa.
Joten kun puhun näkyvyydestä, en tarkoita sitä, että kaikki on näytöllä, vaan että sinulla on ainakin dataa. Kun he tekevät, usein käy ilmi, että on olemassa erittäin suuri määrä suunnittelemattomia töitä, jotka jollakin tavalla lähetetään Brentille, kun sille ei ole tarvetta. Ja Brent on hieno kaveri, hän ei koskaan sano ei, mutta hän ei kerro kenellekään, kuinka hän tekee työtään.
Kun työ on näkyvissä, tiedot voidaan luokitella siististi (näin Dominika tekee kuvassa), voidaan soveltaa viiden aikavuotojen abstraktiota ja automaatiota.
2. Yhdistä työnhallintajärjestelmät: Tehtävienhallinta
Arkkityypit, joista puhun, ovat eräänlainen pyramidi. Jos ensimmäinen on tehty oikein, niin toinen on jo eräänlainen lisäosa. Monet näistä eivät toimi aloitteleville yrityksille, vaan ne on pidettävä mielessä suuremmissa yrityksissä, kuten Fortune 5000. Viimeksi työskennellyssä yrityksessä oli 10 lippujärjestelmää. Yhdellä joukkueella oli Remedy, toinen kirjoitti jonkinlaisen oman järjestelmän, kolmas käytti Jiraa ja jotkut tyytyvät sähköpostiin. Sama ongelma syntyy, jos yrityksellä on 30 erilaista putkistoa, mutta minulla ei ole aikaa keskustella kaikista tällaisista tapauksista.
Keskustelen ihmisten kanssa siitä, miten liput luodaan, mitä heille tapahtuu seuraavaksi ja miten niitä kierretään. Mielenkiintoisinta on, että ihmiset kokouksissamme puhuvat melko vilpittömästi. Kysyin, kuinka monet ihmiset laittavat "vähäinen / ei vaikutusta" sellaisiin lippuihin, joille pitäisi itse asiassa antaa "merkittävä vaikutus". Kävi ilmi, että melkein kaikki tekevät näin. En osallistu tuomitsemiseen ja yritän kaikin mahdollisin tavoin olla tunnistamatta ihmisiä. Kun he vilpittömästi tunnustavat jotain minulle, en luovuta henkilöä. Mutta kun melkein kaikki ohittavat järjestelmän, se tarkoittaa, että kaikki turvallisuus on pohjimmiltaan ikkunapukua. Tästä syystä tämän järjestelmän tiedoista ei voida tehdä johtopäätöksiä.
Lippuongelman ratkaisemiseksi sinun on valittava yksi pääjärjestelmä. Jos käytät Jiraa, säilytä se Jira. Jos on jokin vaihtoehto, olkoon se ainoa. Tärkeintä on, että lippuja tulisi nähdä toisena vaiheena kehitysprosessissa. Jokaisella toiminnolla on oltava lippu, jonka täytyy kulkea kehitystyön kulun läpi. Liput lähetetään tiimille, joka julkaisee ne kuvakäsikirjoituksessa ja ottaa niistä sitten vastuun.
Tämä koskee kaikkia osastoja, mukaan lukien infrastruktuuri ja toiminta. Tässä tapauksessa on mahdollista muodostaa ainakin jokin uskottava käsitys asioiden tilasta. Kun tämä prosessi on perustettu, on yhtäkkiä helppo tunnistaa, kuka on vastuussa kustakin sovelluksesta. Koska nyt emme saa 50 %, vaan 98 % uusista palveluista. Jos tämä ydinprosessi toimii, tarkkuus paranee koko järjestelmässä.
Palveluputkisto
Tämä koskee jälleen vain suuria yrityksiä. Jos olet uusi yritys uudella alalla, kääri hihat ja työskentele Travis CI:n tai CircleCI:n kanssa. Mitä tulee Fortune 5000 -yrityksiin, esimerkkitapaus tapahtui pankissa, jossa työskentelin. Google tuli heidän luokseen ja heille näytettiin kaavioita vanhoista IBM-järjestelmistä. Googlen kaverit kysyivät hämmentyneenä - missä on tämän lähdekoodi? Mutta ei ole lähdekoodia, ei edes graafista käyttöliittymää. Tämä on todellisuus, jonka suuret organisaatiot joutuvat käsittelemään: 40 vuotta vanhat pankkitiedot muinaisella keskuskoneella. Yksi asiakkaistani käyttää Kubernetes-säiliöitä, joissa on Circuit Breaker -kuviot, sekä Chaos Monkeya, kaikki KeyBank-sovelluksessa. Mutta nämä säiliöt yhdistetään lopulta COBOL-sovellukseen.
Googlen kaverit olivat täysin varmoja siitä, että he ratkaisevat kaikki asiakkaani ongelmat, ja sitten he alkoivat kysellä: mikä on IBM-tietoputki? Heille kerrotaan: tämä on liitin. Mihin se liittyy? Sperryn järjestelmään. Ja mikä tuo on? Ja niin edelleen. Ensi silmäyksellä näyttää: millaisia DevOppeja voi olla? Mutta itse asiassa se on mahdollista. On olemassa toimitusjärjestelmiä, joiden avulla voit luovuttaa työnkulun toimitustiimeille.
3. Rajoitusteoria: Rajoitusteoria
Siirrytään kolmanteen arkkityyppiin: institutionaaliseen/"heimon" tietoon. Pääsääntöisesti missä tahansa organisaatiossa on useita ihmisiä, jotka tietävät kaiken ja hallitsevat kaiken. Nämä ovat ne, jotka ovat olleet organisaatiossa pisimpään ja tietävät kaikki kiertotavat.
Kun tämä tulee kaavioon, ympyrän nimenomaan sellaiset ihmiset merkillä: esimerkiksi käy ilmi, että tietty Lou on läsnä kaikissa kokouksissa. Ja minulle on selvää: tämä on paikallinen Brent. Kun tietohallintojohtaja valitsee minun välillä t-paidassa ja tennareissa ja IBM:n puvussa olevan kaverin välillä, minut valitaan, koska voin kertoa ohjaajalle asioita, joita toinen ei kerro ja joita ohjaaja ei ehkä halua kuulla. . Kerron heille, että heidän yrityksensä pullonkaula on joku nimeltä Fred ja joku nimeltä Lou. Tämä pullonkaula on purettava, heidän tietonsa on hankittava heiltä tavalla tai toisella.
Tällaisen ongelman ratkaisemiseksi voin esimerkiksi ehdottaa Slackin käyttöä. Älykäs ohjaaja kysyy - miksi? Tyypillisesti tällaisissa tapauksissa DevOps-konsultit vastaavat: koska kaikki tekevät niin. Jos ohjaaja on todella älykäs, hän sanoo: entä sitten. Ja tähän dialogi päättyy. Ja vastaukseni tähän on: koska yhtiössä on neljä pullonkaulaa, Fred, Lou, Susie ja Jane. Heidän tietämyksensä institutionalisoimiseksi on ensin esitettävä Slack. Kaikki wikisi ovat täyttä hölynpölyä, koska kukaan ei tiedä niiden olemassaolosta. Jos suunnittelutiimi on mukana etu- ja taustakehityksessä ja kaikkien on tiedettävä, että he voivat ottaa yhteyttä etupään kehitystiimiin tai infrastruktuuritiimiin kysymyksissä. Silloin Loulla tai Fredillä on todennäköisesti aikaa liittyä wikiin. Ja sitten Slackissa joku saattaa kysyä, miksi esimerkiksi vaihe 5 ei toimi. Ja sitten Lou tai Fred korjaa wikin ohjeet. Jos perustat tämän prosessin, monet asiat loksahtavat paikoilleen itsestään.
Tämä on tärkein pointtini: jotta voit suositella korkeaa teknologiaa, sinun on ensin saatava niiden perusta kuntoon, ja tämä voidaan tehdä juuri kuvailluilla matalan teknologian ratkaisuilla. Jos aloitat korkeasta teknologiasta etkä selitä, miksi niitä tarvitaan, tämä ei yleensä pääty hyvin. Yksi asiakkaistamme käyttää Azure ML:ää, erittäin halpaa ja yksinkertaista ratkaisua. Itseoppiva kone vastasi noin 30 prosenttiin heidän kysymyksistään. Ja tämän asian ovat kirjoittaneet operaattorit, jotka eivät olleet mukana tietotieteessä, tilastoissa tai matematiikassa. Tämä on merkittävää. Tällaisen ratkaisun kustannukset ovat minimaaliset.
4. Yhteistyöhakkerointi: Yhteistyöhakkerointi
Neljäs arkkityyppi on tarve torjua eristäytymistä. Useimmat ihmiset tietävät jo tämän: eristäytyminen synnyttää vihamielisyyttä. Jos jokainen osasto on omassa kerroksessaan, eivätkä ihmiset risteä toistensa kanssa millään tavalla, paitsi hississä, syntyy heidän välilleen erittäin helposti vihamielisyyttä. Mutta jos päinvastoin ihmiset ovat samassa huoneessa toistensa kanssa, hän lähtee välittömästi. Kun joku heittää esille jonkin yleisen syytöksen, esimerkiksi tällainen ja sellainen käyttöliittymä ei koskaan toimi, ei ole mitään helpompaa purkaa sellaista syytöstä. Käyttöliittymän kirjoittaneiden ohjelmoijien on vain alettava kysyä tiettyjä kysymyksiä, ja pian käy selväksi, että esimerkiksi käyttäjä yksinkertaisesti käytti työkalua väärin.
Eristyksen voittamiseksi on monia tapoja. Minua pyydettiin kerran keskustelemaan pankista Australiassa, mutta kieltäydyin tekemästä sitä, koska minulla on kaksi lasta ja vaimo. Voisin vain suositella graafista tarinankerrontaa. Tämä on jotain, joka on todistetusti toimiva. Toinen mielenkiintoinen tapa on vähärasvaiset kahvikokoukset. Suuressa organisaatiossa tämä on erinomainen vaihtoehto tiedon levittämiseen. Lisäksi voit järjestää sisäisiä devopspäiviä, hackathoneja ja niin edelleen.
5. Valmentaa Kata
Kuten alussa varoitin, en puhu tästä tänään. Jos olet kiinnostunut, voit katsoa .
Tästä aiheesta on myös hyvä keskustelu Mike Rotherilta:
6. Markkinasuuntautunut: markkinalähtöinen organisaatio
Tässä on erilaisia ongelmia. Esimerkiksi "I"-henkilöt, "T"-henkilöt ja "E"-henkilöt. "Minä" ihmiset ovat niitä, jotka tekevät vain yhden asian. Tyypillisesti niitä on organisaatioissa, joissa on erilliset osastot. "T" tarkoittaa sitä, että henkilö on hyvä yhdessä asiassa, mutta myös hyvä joissakin muissa asioissa. "E" tai jopa "kampa" tarkoittaa, kun henkilöllä on monia taitoja.
Conwayn laki toimii täällä (), joka yksinkertaisimmassa muodossa voidaan ilmaista seuraavasti: jos kääntäjän parissa työskentelee kolme tiimiä, tuloksena on kolmen osan kääntäjä. Siksi, jos organisaation sisällä on korkea eristys, niin jopa Kubernetes, Circuitbreaker, API laajennettavuus ja muut hienot asiat tässä organisaatiossa järjestetään samalla tavalla kuin organisaatio itse. Tarkkaan Conwayn mukaan ja kaikista teistä nuorista nörteistä huolimatta.
Ratkaisu tähän ongelmaan on kuvattu monta kertaa. On olemassa esimerkiksi Fernando Fernandezin kuvaamia organisaatioarkkityyppejä. Se ongelmallinen arkkitehtuuri, josta juuri puhuin, on eristäytyneenä toimintolähtöistä arkkitehtuuria. Toinen tyyppi on pahin, matriisiarkkitehtuuri, sotku kahdesta muusta. Kolmas on se, mitä nähdään useimmissa startup-yrityksissä, ja myös suuret yritykset yrittävät vastata tähän tyyppiin. Se on markkinalähtöinen organisaatio. Täällä optimoimme saavuttaaksemme nopeimman vastauksen asiakkaiden pyyntöihin. Tätä kutsutaan joskus tasaiseksi organisaatioksi.
Monet ihmiset kuvaavat tätä rakennetta eri tavoin, pidän sanamuodosta rakentaa/johtaa tiimejä, Amazonissa he kutsuvat sitä kaksi pizzaryhmää. Tässä rakenteessa kaikki I-tyypin ihmiset on ryhmitelty yhden palvelun ympärille ja vähitellen heistä tulee lähemmäksi tyyppiä "T", ja jos oikea hallinta on paikallaan, heistä voi tulla jopa "E". Ensimmäinen vasta-argumentti tässä on, että tällainen rakenne sisältää tarpeettomia elementtejä. Miksi tarvitset testaajan jokaiselle osastolle, jos sinulla voi olla erityinen testaajien osasto? Vastaan tähän: ylimääräiset kustannukset ovat tässä tapauksessa hinta siitä, että koko organisaatiosta tulee tulevaisuudessa tyyppi "E". Tässä rakenteessa testaaja oppii vähitellen verkoista, arkkitehtuurista, suunnittelusta jne. Tämän seurauksena jokainen organisaation osallistuja on täysin tietoinen kaikesta, mitä organisaatiossa tapahtuu. Jos haluat tietää, kuinka tämä järjestelmä toimii teollisuudessa, lue .
7. Vuorovasemman tarkastajat: auditointi syklin varhaisessa vaiheessa. Näytössä olevien turvallisuussääntöjen noudattaminen
Tämä on silloin, kun toimintasi eivät läpäise hajutestiä niin sanotusti. Ihmiset, jotka työskentelevät sinulle, eivät ole tyhmiä. Jos, kuten yllä olevassa esimerkissä, he asettivat vähäisen/ei vaikutuksen kaikkialle, tämä kesti kolme vuotta, eikä kukaan huomannut mitään, niin kaikki tietävät erittäin hyvin, että järjestelmä ei toimi. Tai toinen esimerkki - muutosneuvottelukunta, jossa raportit on toimitettava joka, vaikkapa keskiviikko. Siellä työskentelee joukko ihmisiä (ei muuten kovin hyvin palkattuja), joiden teoriassa pitäisi tietää, miten järjestelmä kokonaisuudessaan toimii. Ja viimeisen viiden vuoden aikana olet luultavasti huomannut, että järjestelmämme ovat uskomattoman monimutkaisia. Ja viiden tai kuuden ihmisen on tehtävä päätös muutoksesta, jota he eivät ole tehneet ja josta he eivät tiedä mitään.
Tämä lähestymistapa ei tietenkään toimi. Minun on päästävä eroon sellaisista asioista, koska nämä ihmiset eivät suojele järjestelmää. Päätös on tehtävä joukkueen itse, koska tiimin on oltava siitä vastuussa. Muuten syntyy paradoksaalinen tilanne, kun esimies, joka ei ole koskaan elämässään kirjoittanut koodia, kertoo ohjelmoijalle, kuinka kauan koodin kirjoittamisen tulisi kestää. Yhdellä yrityksellä, jonka kanssa työskentelin, oli 7 erilaista lautaa, jotka arvioivat jokaisen muutoksen, mukaan lukien arkkitehtuuritaulu, tuotelevy jne. Siellä oli jopa pakollinen odotusaika, vaikka eräs työntekijä kertoi minulle, että kymmenen työvuoden aikana kukaan ei ollut koskaan hylännyt tämän pakollisen ajanjakson aikana tekemää muutosta.
Tilintarkastajien on kutsuttava joukkoomme, eikä heistä päästävä eroon. Kerro heille, että kirjoitat muuttumattomia binäärisäilöjä, jotka, jos ne läpäisevät kaikki testit, pysyvät muuttumattomina ikuisesti. Kerro heille, että sinulla on putki koodina ja selitä, mitä se tarkoittaa. Näytä heille seuraava kaavio: muuttumaton vain luku -binaari säiliössä, joka läpäisee kaikki haavoittuvuustestit; ja sitten kukaan ei koske siihen, he eivät edes kosketa järjestelmää, joka luo putken, koska se myös luodaan dynaamisesti. Minulla on asiakkaita, Capital One, jotka käyttävät Holvia luodakseen jotain lohkoketjun kaltaista. Tilintarkastajan ei tarvitse näyttää Chefin "reseptejä", riittää, että näyttää lohkoketjun, josta selviää, mitä Jira-lipulle tapahtui tuotannossa ja kuka siitä on vastuussa.
Mukaan , jonka Sonatype loi vuonna 2018, vuonna 2017 oli 87 miljardia OSS-latauspyyntöä.
Haavoittuvuuksista aiheutuvat tappiot ovat kohtuuttomat. Lisäksi edellä näkyvät luvut eivät sisällä vaihtoehtokustannuksia. Mikä on DevSecOps pähkinänkuoressa? Sanon heti, että en ole kiinnostunut puhumaan tämän nimen menestyksestä. Asia on siinä, että koska DevOps on ollut niin menestyvä, meidän pitäisi yrittää lisätä tietoturvaa tuohon putkistoon.
Esimerkki tästä sarjasta:
Tämä ei ole suositus tietyille tuotteille, vaikka pidän niistä kaikista. Mainitsin ne esimerkkinä osoittaakseni, että DevOps, joka perustui alun perin teollisuuden organisaatioparadigmaan, mahdollistaa tuotteen jokaisen työvaiheen automatisoinnin.
Eikä ole mitään syytä, miksi emme voisi suhtautua turvallisuuteen samalla tavalla.
Koko
Lopuksi annan muutamia vinkkejä DevSecOpsiin. Sinun on otettava auditoijat mukaan järjestelmien luomiseen ja käytettävä aikaa heidän kouluttamiseen. Sinun on tehtävä yhteistyötä tilintarkastajien kanssa. Seuraavaksi sinun täytyy käydä ehdottoman häikäilemätön taistelu vääriä positiivisia tuloksia vastaan. Jopa kalleimmalla haavoittuvuuksien tarkistustyökalulla voit päätyä luomaan erittäin huonoja tapoja kehittäjien keskuudessa, jos et tiedä signaali-kohinasuhdettasi. Kehittäjät hukkuvat tapahtumiin, ja he yksinkertaisesti poistavat ne. Jos kuulit Equifax-tarinasta, niin suurin osa tapahtui siellä, missä korkein hälytystaso jätettiin huomiotta. Lisäksi haavoittuvuudet on selitettävä tavalla, joka tekee selväksi, kuinka ne vaikuttavat liiketoimintaan. Voit esimerkiksi sanoa, että tämä on sama haavoittuvuus kuin Equifax-tarinassa. Tietoturvahaavoittuvuuksia tulee käsitellä samalla tavalla kuin muita ohjelmistoongelmia, eli ne tulee sisällyttää yleiseen DevOps-prosessiin. Sinun on työskenneltävä heidän kanssaan Jiran, Kanbanin jne. Kehittäjät eivät saa ajatella, että joku muu tekee tämän - päinvastoin, kaikkien pitäisi tehdä tämä. Lopuksi sinun on käytettävä energiaa ihmisten kouluttamiseen.
Hyödyllisiä linkkejä
Tässä on muutamia DevOops-konferenssin puheita, joista voi olla hyötyä:
- Sergei Berdnikov, Artjom Kalichkin – Menestystarina tai ”Dev+DevOps+Ops” (, )
- Baruch Sadogursky, Leonid Igolnik - DevOps mittakaavassa: kreikkalainen tragedia kolmessa näytöksessä (, )
- Aleksanteri Titov, Kirill Tolkachev -
- Timothy Lister -
Tarkastella DevOops 2020 Moskova – Siellä on myös paljon mielenkiintoista.
Lähde: will.com