Anton Weiss, Otomato Softwaren perustaja ja johtaja, yksi Israelin ensimmäisen DevOps-sertifioinnin käynnistäjistä ja ohjaajista, puhui viime vuoden konferenssissa. kaaosteoriasta ja kaaossuunnittelun pääperiaatteista ja selitti myös kuinka tulevaisuuden ihanteellinen DevOps-organisaatio toimii.
Olemme laatineet raportista tekstiversion.
Hyvää huomenta!
DevOpsDays Moskovassa toista vuotta peräkkäin, tämä on toinen kerta tällä lavalla, monet teistä ovat tässä huoneessa toista kertaa. Mitä se tarkoittaa? Tämä tarkoittaa, että DevOps-liike Venäjällä kasvaa, moninkertaistuu, ja mikä tärkeintä, se tarkoittaa, että on tullut aika puhua siitä, mitä DevOps on vuonna 2018.
Nostakaa kätenne, kuka ajattelee, että DevOps on ammatti jo vuonna 2018? Sellaisiakin on. Onko huoneessa DevOps-insinöörejä, joiden työnkuvassa lukee "DevOps Engineer"? Onko huoneessa DevOps-johtajia? Ei ole sellaista. DevOps-arkkitehdit? Myös ei. Ei tarpeeksi. Onko todella totta, että kukaan ei sano olevansa DevOps-insinööri?
Joten useimpien mielestä tämä on anti-malli? Eikö tällaista ammattia pitäisi olla olemassa? Voimme ajatella mitä haluamme, mutta samalla kun ajattelemme, teollisuus etenee juhlallisesti eteenpäin DevOps-trumpetin sointiin.
Kuka on kuullut uudesta aiheesta nimeltä DevDevOps? Tämä on uusi tekniikka, joka mahdollistaa tehokkaan yhteistyön kehittäjien ja kehittäjien välillä. Eikä niin uusi. Twitterin perusteella he alkoivat puhua tästä jo 4 vuotta sitten. Ja tähän asti kiinnostus tätä kohtaan kasvaa ja kasvaa, eli ongelma on olemassa. Ongelma on ratkaistava.
Olemme luovia ihmisiä, emme vain lepää rauhassa. Sanomme: DevOps ei ole tarpeeksi kattava sana; siitä puuttuu silti kaikenlaisia erilaisia mielenkiintoisia elementtejä. Ja menemme salaisiin laboratorioihimme ja alamme tuottaa mielenkiintoisia mutaatioita: DevTestOps, GitOps, DevSecOps, BizDevOps, ProdOps.
Logiikka on rautaista, eikö? Toimitusjärjestelmämme ei toimi, järjestelmämme ovat epävakaita ja käyttäjämme ovat tyytymättömiä, meillä ei ole aikaa ottaa ohjelmistoja käyttöön ajoissa, emme mahdu budjettiin. Miten aiomme ratkaista tämän kaiken? Keksimme uuden sanan! Se päättyy "Ops" ja ongelma on ratkaistu.
Joten kutsun tätä lähestymistapaa - "Ops, ja ongelma on ratkaistu."
Tämä kaikki jää taustalle, jos muistutamme itseämme, miksi keksimme kaiken tämän. Keksimme tämän koko DevOps-jutun tehdäksemme ohjelmistotoimituksesta ja omasta työstämme tässä prosessissa mahdollisimman esteettömän, kivuttoman, tehokkaan ja mikä tärkeintä, nautinnollisen.
DevOps kasvoi kivusta. Ja olemme kyllästyneitä kärsimykseen. Ja jotta tämä kaikki tapahtuisi, luotamme ikivihreisiin käytäntöihin: tehokkaaseen yhteistyöhön, virtauskäytäntöihin ja mikä tärkeintä järjestelmäajatteluun, koska ilman sitä mikään DevOps ei toimi.
Mikä on järjestelmä?
Ja jos puhumme jo järjestelmäajattelusta, muistutetaanpa itsellemme, mikä järjestelmä on.
Jos olet vallankumouksellinen hakkeri, järjestelmä on sinulle selvästi paha. Se on pilvi, joka roikkuu ylläsi ja pakottaa sinut tekemään asioita, joita et halua tehdä.
Järjestelmäajattelun näkökulmasta järjestelmä on kokonaisuus, joka koostuu osista. Tässä mielessä jokainen meistä on järjestelmä. Organisaatiot, joissa työskentelemme, ovat järjestelmiä. Ja sitä, mitä sinä ja minä rakennamme, kutsutaan järjestelmäksi.
Kaikki tämä on osa yhtä suurta sosioteknologista järjestelmää. Ja vain jos ymmärrämme, kuinka tämä sosioteknologinen järjestelmä toimii yhdessä, vain silloin voimme todella optimoida jotain tässä asiassa.
Järjestelmäajattelun näkökulmasta järjestelmällä on useita mielenkiintoisia ominaisuuksia. Ensinnäkin se koostuu osista, mikä tarkoittaa, että sen käyttäytyminen riippuu osien käyttäytymisestä. Lisäksi kaikki sen osat ovat myös toisistaan riippuvaisia. Osoittautuu, että mitä enemmän osia järjestelmässä on, sitä vaikeampaa on ymmärtää tai ennustaa sen käyttäytymistä.
Käyttäytymisen näkökulmasta on toinenkin mielenkiintoinen tosiasia. Järjestelmä voi tehdä jotain, mitä mikään sen yksittäisistä osista ei pysty tekemään.
Kuten tohtori Russell Ackoff (yksi systeemiajattelun perustajista) sanoi, tämä on melko helppo todistaa ajatuskokeella. Esimerkiksi, kuka huoneessa osaa kirjoittaa koodin? Käsiä on paljon, ja tämä on normaalia, koska tämä on yksi ammattimme päävaatimuksista. Osaatko kirjoittaa, mutta voivatko kätesi kirjoittaa koodia erillään sinusta? Jotkut ihmiset sanovat: "Minun käteni eivät kirjoita koodia, vaan aivoni kirjoittavat koodin." Voivatko aivosi kirjoittaa koodia erillään sinusta? No, luultavasti ei.
Aivot ovat hämmästyttävä kone, emme edes tiedä 10% kuinka ne toimivat siellä, mutta ne eivät voi toimia erillään järjestelmästämme, joka on kehomme. Ja tämä on helppo todistaa: avaa kallosi, ota aivot ulos, laita se tietokoneen eteen, anna hänen yrittää kirjoittaa jotain yksinkertaista. Esimerkiksi "Hei, maailma" Pythonissa.
Jos järjestelmä voi tehdä jotain, mitä mikään sen osista ei voi tehdä erikseen, tämä tarkoittaa, että sen käyttäytyminen ei ole sen osien käyttäytymisen määräämä. Mistä se sitten määräytyy? Sen määrää näiden osien välinen vuorovaikutus. Ja vastaavasti, mitä enemmän osia, mitä monimutkaisempia vuorovaikutuksia on, sitä vaikeampaa on ymmärtää ja ennustaa järjestelmän käyttäytymistä. Ja tämä tekee tällaisesta järjestelmästä kaoottisen, koska mikä tahansa, jopa kaikkein merkityksetön, näkymätön muutos missä tahansa järjestelmän osassa voi johtaa täysin arvaamattomiin tuloksiin.
Tämän herkkyyden alkuolosuhteille löysi ja tutki ensimmäisenä amerikkalainen meteorologi Ed Lorenz. Myöhemmin sitä kutsuttiin "perhosefektiksi", ja se johti "kaaosteoriaksi" kutsutun tieteellisen ajattelun liikkeen kehittämiseen. Tästä teoriasta tuli yksi suurimmista paradigman muutoksista 20-luvun tieteessä.
Kaaosteoria
Ihmiset, jotka tutkivat kaaosta, kutsuvat itseään kaosologeiksi.
Itse asiassa syy tähän raporttiin oli se, että työskennellessäni monimutkaisten hajautettujen järjestelmien ja suurten kansainvälisten organisaatioiden parissa tajusin jossain vaiheessa, että siltä minusta tuntuu. Olen kaosologi. Tämä on pohjimmiltaan näppärä tapa sanoa: "En ymmärrä mitä täällä tapahtuu, enkä tiedä mitä tehdä asialle."
Luulen, että monet teistä myös usein tuntevat näin, joten olette myös kaosologeja. Kutsun sinut kaosologien kiltaan. Systeemejä, joita te ja minä, rakkaat kaosologit, tutkimme, kutsutaan "monimutkaisiksi adaptiivisiksi järjestelmiksi".
Mitä on sopeutumiskyky? Sopeutuvuus tarkoittaa, että osien yksilöllinen ja kollektiivinen käyttäytyminen tällaisessa mukautuvassa järjestelmässä muuttuu ja organisoituu itse, reagoiden tapahtumiin tai mikrotapahtumien ketjuihin järjestelmässä. Eli järjestelmä mukautuu muutoksiin itseorganisoitumisen kautta. Ja tämä itseorganisoitumiskyky perustuu vapaiden autonomisten agenttien vapaaehtoiseen, täysin hajautettuun yhteistyöhön.
Toinen tällaisten järjestelmien mielenkiintoinen ominaisuus on, että ne ovat vapaasti skaalautuvia. Minkä pitäisi epäilemättä kiinnostaa meitä, kaosologeja-insinöörejä. Joten jos sanomme, että monimutkaisen järjestelmän käyttäytyminen määräytyy sen osien vuorovaikutuksen perusteella, niin mistä meidän pitäisi olla kiinnostunut? Vuorovaikutus.
On vielä kaksi mielenkiintoista löytöä.
Ensinnäkin ymmärrämme, että monimutkaista järjestelmää ei voida yksinkertaistaa yksinkertaistamalla sen osia. Toiseksi, ainoa tapa yksinkertaistaa monimutkaista järjestelmää on yksinkertaistaa sen osien välisiä vuorovaikutuksia.
Miten olemme vuorovaikutuksessa? Sinä ja minä olemme kaikki osa suurta tietojärjestelmää, jota kutsutaan ihmisyhteiskunnaksi. Olemme vuorovaikutuksessa yhteisen kielen kautta, jos meillä on se, jos löydämme sen.
Mutta kieli itsessään on monimutkainen mukautuva järjestelmä. Vastaavasti, jotta voimme olla vuorovaikutuksessa tehokkaammin ja yksinkertaisemmin, meidän on luotava jonkinlaisia protokollia. Eli jokin symbolien ja toimintojen sarja, joka tekee tiedonvaihdosta välillämme yksinkertaisempaa, ennakoitavampaa, ymmärrettävämpää.
Haluan sanoa, että suuntaukset kohti monimutkaisuutta, kohti sopeutumiskykyä, kohti hajauttamista, kohti kaaosta voidaan jäljittää kaikessa. Ja järjestelmissä, joita sinä ja minä rakennamme, ja niissä järjestelmissä, joiden osa olemme.
Ja ollakseen perusteettomia, katsotaanpa, kuinka luomamme järjestelmät muuttuvat.
Odotit tätä sanaa, ymmärrän. Olemme DevOps-konferenssissa, tänään tämä sana kuullaan noin satatuhatta kertaa ja sitten uneksimme siitä yöllä.
Mikropalvelut ovat ensimmäinen ohjelmistoarkkitehtuuri, joka syntyi vastauksena DevOps-käytäntöihin. Sen tarkoituksena on tehdä järjestelmistämme joustavampia, skaalautuvampia ja varmistaa jatkuvan toimituksen. Miten hän tekee tämän? Vähentämällä palvelujen määrää, vähentämällä näiden palvelujen käsittelemien ongelmien määrää ja lyhentämällä toimitusaikaa. Toisin sanoen vähennämme ja yksinkertaistamme järjestelmän osia, lisäämme niiden määrää, ja vastaavasti näiden osien välisten vuorovaikutusten monimutkaisuus kasvaa poikkeuksetta, eli syntyy uusia ongelmia, jotka meidän on ratkaistava.
Mikropalvelut eivät ole loppua, mikropalvelut ovat yleensä jo eilen, koska Serverless on tulossa. Kaikki palvelimet paloivat, ei palvelimia, ei käyttöjärjestelmiä, vain puhdasta suoritettavaa koodia. Konfiguraatiot ovat erillisiä, tilat ovat erillisiä, kaikkea ohjaavat tapahtumat. Kauneus, puhtaus, hiljaisuus, ei tapahtumia, mitään ei tapahdu, täydellinen järjestys.
Missä on monimutkaisuus? Vaikeus on tietysti vuorovaikutuksessa. Kuinka paljon yksi toiminto voi tehdä yksin? Miten se on vuorovaikutuksessa muiden toimintojen kanssa? Viestijonot, tietokannat, tasapainottimet. Kuinka luoda jokin tapahtuma uudelleen, kun vika tapahtui? Paljon kysymyksiä ja vähän vastauksia.
Mikropalvelut ja Serverless ovat sitä, mitä me nörttihipsterit kutsumme Cloud Nativeksi. Kyse on pilvestä. Mutta pilven skaalautuvuus on myös luonnostaan rajoitettu. Olemme tottuneet ajattelemaan sitä hajautetuksi järjestelmäksi. Itse asiassa missä pilvipalvelujen tarjoajien palvelimet sijaitsevat? Datakeskuksissa. Eli meillä on täällä eräänlainen keskitetty, hyvin rajoitettu, hajautettu malli.
Nykyään ymmärrämme, että esineiden internet ei ole enää vain isoja sanoja, että vaatimattomienkin ennusteiden mukaan miljardit Internetiin yhdistetyt laitteet odottavat meitä seuraavan viiden-kymmenen vuoden aikana. Valtava määrä hyödyllistä ja hyödytöntä dataa, joka yhdistetään pilveen ja ladataan pilvestä.
Pilvi ei kestä, joten puhumme yhä enemmän niin sanotusta reunalaskentasta. Tai pidän myös "sumulaskennan" upeasta määritelmästä. Se on verhottu romantiikan ja mysteerin mystiikkaan.
Sumulaskenta. Asia on, että pilvet ovat keskitettyjä vesi-, höyry-, jää- ja kivimöykkyjä. Ja sumu on vesipisaroita, jotka ovat hajallaan ympärillämme ilmakehässä.
Sumuparadigmassa nämä pisarat tekevät suurimman osan työstä täysin itsenäisesti tai yhteistyössä muiden pisaroiden kanssa. Ja he kääntyvät pilven puoleen vasta, kun niitä todella painaa.
Eli jälleen hajauttaminen, autonomia ja tietysti monet teistä jo ymmärtävät, mihin tämä kaikki johtaa, koska et voi puhua hajauttamisesta mainitsematta lohkoketjua.
Jotkut uskovat, nämä ovat niitä, jotka ovat sijoittaneet kryptovaluuttaan. On niitä, jotka uskovat mutta pelkäävät, kuten esimerkiksi minä. Ja on niitä, jotka eivät usko. Täällä voit käsitellä eri tavalla. On tekniikkaa, uutta tuntematonta asiaa, on ongelmia. Kuten mikä tahansa uusi tekniikka, se herättää enemmän kysymyksiä kuin antaa vastauksia.
Blockchainin ympärillä oleva hype on ymmärrettävää. Kultakuume syrjään, itse teknologialla on merkittäviä lupauksia valoisammalle tulevaisuudelle: enemmän vapautta, enemmän autonomiaa, hajautettua maailmanlaajuista luottamusta. Mitä ei halua?
Tästä syystä yhä useammat insinöörit ympäri maailmaa alkavat kehittää hajautettuja sovelluksia. Ja tämä on voima, jota ei voi sivuuttaa yksinkertaisesti sanomalla: "Ahh, lohkoketju on vain huonosti toteutettu hajautettu tietokanta." Tai kuten skeptikot haluavat sanoa: "Blockchainille ei ole todellisia sovelluksia." Jos ajattelee sitä, 150 vuotta sitten he sanoivat saman asian sähköstä. Ja he olivat jopa oikeassa jossain mielessä, koska se, minkä sähkö tekee mahdolliseksi nykyään, ei ollut mitenkään mahdollista 19-luvulla.
Muuten, kuka tietää, millainen logo näytöllä on? Tämä on Hyperledger. Tämä on projekti, jota kehitetään The Linux Foundationin alaisuudessa ja joka sisältää joukon lohkoketjutekniikoita. Tämä on todella avoimen lähdekoodin yhteisömme vahvuus.
Kaaoksen suunnittelu
Joten kehittämästämme järjestelmästä on tulossa yhä monimutkaisempi, kaoottisempi ja mukautuvampi. Netflix on mikropalvelujärjestelmien edelläkävijä. He olivat ensimmäisten joukossa, jotka ymmärsivät tämän, he kehittivät joukon työkaluja, joita he kutsuivat Simian Armyksi, joista tunnetuin oli . Hän määritteli sen, mikä tuli tunnetuksi .
Muuten, raporttia työstäessämme käänsimme jopa tämän tekstin venäjäksi, joten siirry osoitteeseen , lue, kommentoi, moiti.
Lyhyesti kaaostekniikan periaatteet sanovat seuraavaa. Monimutkaiset hajautetut järjestelmät ovat luonnostaan arvaamattomia ja luonnostaan bugisia. Virheet ovat väistämättömiä, mikä tarkoittaa, että meidän on hyväksyttävä nämä virheet ja työskenneltävä näiden järjestelmien kanssa täysin eri tavalla.
Meidän on itse yritettävä tuoda nämä virheet tuotantojärjestelmiimme testataksemme järjestelmiämme tämän saman sopeutumiskyvyn, itseorganisoitumiskyvyn ja selviytymisen suhteen.
Ja se muuttaa kaiken. Ei vain sitä, miten otamme järjestelmät tuotantoon, vaan myös miten kehitämme niitä, miten testaamme niitä. Ei ole olemassa koodin vakauttamis- tai jäädytysprosessia, päinvastoin, on jatkuva epävakautusprosessi. Yritämme tappaa järjestelmän ja nähdä sen jatkuvan.
Hajautetut järjestelmäintegraatioprotokollat
Tämä edellyttää, että järjestelmämme muuttuvat jotenkin. Jotta niistä tulisi vakaampia, he tarvitsevat uusia protokollia osien väliseen vuorovaikutukseen. Jotta nämä osat voisivat sopia ja tulla jonkinlaiseen itseorganisoitumiseen. Ja kaikenlaisia uusia työkaluja, uusia protokollia syntyy, joita kutsun "protokollaksi hajautettujen järjestelmien vuorovaikutukseen".
Mistä minä puhun? Ensinnäkin projekti . Jotkut yrittävät luoda yleisen hajautetun seurantaprotokollan, joka on ehdottoman välttämätön työkalu monimutkaisten hajautettujen järjestelmien virheenkorjaukseen.
Edelleen - . Sanomme, että emme voi ennustaa, mitä järjestelmälle tapahtuu, eli meidän on lisättävä sen havaittavuutta, havaittavuutta. Opentracing kuuluu työkaluperheeseen, joka antaa järjestelmillemme havaittavuuden. Mutta tarvitsemme havainnointia voidaksemme määrittää, käyttäytyykö järjestelmä odotetulla tavalla vai ei. Miten määrittelemme odotetun käyttäytymisen? Määrittelemällä jonkinlaista politiikkaa, jotkin säännöt. Open Policy Agent -projekti pyrkii määrittelemään tämän sääntöjoukon, joka ulottuu pääsystä resurssien allokointiin.
Kuten sanoimme, järjestelmämme ovat yhä enemmän tapahtumalähtöisiä. Palvelimeton on loistava esimerkki tapahtumapohjaisista järjestelmistä. Jotta voimme siirtää tapahtumia järjestelmien välillä ja seurata niitä, tarvitsemme yhteisen kielen, yhteisen protokollan, jolla puhumme tapahtumista, kuinka välitämme ne toisillemme. Tätä kutsutaan projektiksi .
Jatkuva muutosvirta, joka huuhtelee järjestelmiämme jatkuvasti horjuttaen niitä jatkuvasti, on jatkuva ohjelmistoartefakttien virta. Jotta voimme ylläpitää tätä jatkuvaa muutosvirtaa, tarvitsemme jonkinlaisen yhteisen protokollan, jonka kautta voimme puhua siitä, mikä ohjelmistoartefaktti on, miten sitä testataan, minkä varmuuden se on läpäissyt. Tätä kutsutaan projektiksi . Toisin sanoen yleinen metatietoprotokolla ohjelmistoartefakteille.
Ja lopuksi, jos haluamme, että järjestelmämme ovat täysin riippumattomia, mukautuvia ja itseorganisoituneita, meidän on annettava niille oikeus itsetunnistukseen. Projekti nimeltä Juuri tätä hän tekee. Tämä on myös Cloud Native Computing Foundationin suojeluksessa oleva projekti.
Kaikki nämä projektit ovat nuoria, ne kaikki tarvitsevat rakkauttamme, vahvistuksemme. Tämä kaikki on avoimen lähdekoodin, meidän testaus, meidän toteutus. Ne näyttävät meille, mihin tekniikka on menossa.
Mutta DevOps ei ole koskaan ollut ensisijaisesti teknologiaa, se on aina ollut ihmisten välistä yhteistyötä. Ja vastaavasti, jos haluamme kehittämiemme järjestelmien muuttuvan, meidän on itsekin muututtava. Itse asiassa me muutumme joka tapauksessa; meillä ei ole paljon valinnanvaraa.
Siellä on upea Brittikirjailija Rachel Botsman, jossa hän kirjoittaa luottamuksen kehityksestä läpi ihmiskunnan historian. Hän sanoo, että alun perin primitiivisissä yhteiskunnissa luottamus oli paikallista, eli luotimme vain niihin, jotka tunsimme henkilökohtaisesti.
Sitten oli hyvin pitkä aika - synkkä aika, jolloin luottamus keskitettiin, jolloin alettiin luottaa ihmisiin, joita emme tunne sen perusteella, että kuulumme samaan julkiseen tai valtion instituutioon.
Ja tämä on se, mitä näemme nykymaailmassamme: luottamus on yhä enemmän hajautunutta ja hajautettua, ja se perustuu tiedonkulun vapauteen, tiedon saatavuuteen.
Jos ajattelet sitä, juuri tätä saavutettavuutta, joka tekee tämän luottamuksen mahdolliseksi, toteutamme sinä ja minä. Tämä tarkoittaa, että sekä yhteistyön että toimintatavan on muututtava, koska vanhat keskitetyt, hierarkkiset IT-organisaatiot eivät enää toimi. Ne alkavat kuolla pois.
DevOps-organisaation perusteet
Tulevaisuuden ihanteellinen DevOps-organisaatio on hajautettu, mukautuva järjestelmä, joka koostuu itsenäisistä ryhmistä, joista jokainen koostuu itsenäisistä yksilöistä. Nämä tiimit ovat hajallaan ympäri maailmaa ja tekevät tehokasta yhteistyötä toistensa kanssa käyttämällä asynkronista viestintää ja erittäin läpinäkyviä viestintäprotokollia. Todella kaunista, eikö? Todella kaunis tulevaisuus.
Tämä ei tietenkään ole mahdollista ilman kulttuurista muutosta. Meillä on oltava transformoiva johtajuus, henkilökohtainen vastuu, sisäinen motivaatio.
Tämä on DevOps-organisaatioiden perusta: tiedon läpinäkyvyys, asynkroninen viestintä, transformoiva johtajuus, hajauttaminen.
Zapping
Järjestelmät, joihin olemme osa ja joita rakennamme, ovat yhä kaoottisempia, ja meidän ihmisten on vaikea selviytyä tästä ajatuksesta, on vaikea luopua hallinnan illuusiosta. Yritämme edelleen hallita niitä, ja tämä johtaa usein loppuunuuttumiseen. Sanon tämän omasta kokemuksestani, minäkin palasin, olin myös vammainen tuotannon odottamattomien epäonnistumisten vuoksi.
Burnout tapahtuu, kun yritämme hallita jotain, joka on luonnostaan hallitsematon. Kun palamme loppuun, kaikki menettää merkityksensä, koska menetämme halun tehdä jotain uutta, lähdemme puolustautumaan ja alamme puolustaa sitä, mitä meillä on.
Insinöörin ammatti, kuten usein haluan muistuttaa itseäni, on ennen kaikkea luova ammatti. Jos menetämme halun luoda jotain, muutumme tuhkaksi, muuttumme tuhkaksi. Ihmiset palavat loppuun, kokonaiset organisaatiot palavat loppuun.
Minusta vain kaaoksen luovan voiman hyväksyminen, vain yhteistyön rakentaminen sen periaatteiden mukaisesti auttaa meitä olemaan menettämättä sitä, mikä on ammatissamme hyvää.
Tätä toivon sinulle: rakasta työtäsi, rakasta sitä, mitä teemme. Tämä maailma ruokkii tietoa, meillä on kunnia ruokkia sitä. Joten tutkitaan kaaosta, ollaan kaosologeja, tuodaan arvoa, luodaan jotain uutta, no, ongelmat, kuten olemme jo havainneet, ovat väistämättömiä, ja kun niitä ilmaantuu, sanomme vain "Ops!", ja ongelma on ratkaistu. .
Mitä muuta kuin Chaos Monkey?
Itse asiassa kaikki nämä soittimet ovat niin nuoria. Sama Netflix rakensi työkaluja itselleen. Rakenna omat työkalusi. Lue kaaossuunnittelun periaatteet ja toimi näiden periaatteiden mukaisesti sen sijaan, että yrität löytää muita työkaluja, joita joku muu on jo rakentanut.
Yritä ymmärtää, kuinka järjestelmäsi hajoaa, ja ala hajottaa niitä ja katso kuinka ne kestävät. Tämä tulee ensin. Ja voit etsiä työkaluja. Kaikenlaisia projekteja on.
En oikein ymmärtänyt sitä hetkeä, kun sanoit, että järjestelmää ei voi yksinkertaistaa yksinkertaistamalla sen komponentteja, ja siirryin heti mikropalveluihin, jotka yksinkertaistavat järjestelmää yksinkertaistamalla itse komponentteja ja monimutkaistamalla vuorovaikutuksia. Nämä ovat pohjimmiltaan kaksi osaa, jotka ovat ristiriidassa keskenään.
Aivan oikein, mikropalvelut ovat yleisesti ottaen hyvin kiistanalainen aihe. Itse asiassa osien yksinkertaistaminen lisää joustavuutta. Mitä mikropalvelut tarjoavat? Ne antavat meille joustavuutta ja nopeutta, mutta eivät todellakaan anna meille yksinkertaisuutta. Ne lisäävät vaikeutta.
Joten DevOps-filosofian mukaan mikropalvelut eivät ole niin hyvä asia?
Kaikella hyvällä on kääntöpuolensa. Sen etuna on, että se lisää joustavuutta, jolloin voimme tehdä muutoksia nopeammin, mutta se lisää koko järjestelmän monimutkaisuutta ja siten haurautta.
Kumpaa kuitenkin painotetaan enemmän: vuorovaikutuksen yksinkertaistamista vai osien yksinkertaistamista?
Painopiste on tietysti vuorovaikutuksen yksinkertaistamisessa, koska jos katsomme tätä siitä näkökulmasta, miten työskentelemme kanssasi, niin meidän on ensinnäkin kiinnitettävä huomiota vuorovaikutuksen yksinkertaistamiseen, ei työn yksinkertaistamiseen. jokaisesta meistä erikseen. Koska työn yksinkertaistaminen tarkoittaa muuttumista roboteiksi. Täällä McDonald'sissa toimii normaalisti, kun on ohje: tähän laitat hampurilaisen, tähän kaadat kastikkeen päälle. Tämä ei toimi lainkaan luovassa työssämme.
Onko totta, että kaikki, mitä sanoit, elää maailmassa, jossa ei ole kilpailua, ja siellä vallitseva kaaos on niin ystävällistä, eikä tässä kaaoksessa ole ristiriitoja, kukaan ei halua syödä tai tappaa ketään? Miten kilpailun ja DevOpsin pitäisi pärjätä?
No, se riippuu siitä, millaisesta kilpailusta puhumme. Onko kyse kilpailusta työpaikalla vai yritysten välisestä kilpailusta?
Palveluiden kilpailusta, joka on olemassa, koska palveluita ei ole useita yrityksiä. Luomme uudenlaista tietoympäristöä, eikä mikään ympäristö voi elää ilman kilpailua. Kilpailua on kaikkialla.
Sama Netflix, otamme heidät roolimallina. Miksi he keksivät tämän? Koska heidän piti olla kilpailukykyisiä. Tämä joustavuus ja liikkumisnopeus ovat juuri erittäin kilpailukykyinen vaatimus, se tuo kaaosta järjestelmiimme. Toisin sanoen kaaos ei ole jotain, mitä me tietoisesti teemme, koska haluamme sen, vaan se tapahtuu, koska maailma vaatii sitä. Meidän on vain sopeuduttava. Ja kaaos, se on juuri kilpailun tulos.
Tarkoittaako tämä sitä, että kaaos on ikään kuin tavoitteiden puuttuminen? Tai ne tavoitteet, joita emme halua nähdä? Olemme talossa emmekä ymmärrä muiden tavoitteita. Kilpailu itse asiassa johtuu siitä, että meillä on selkeät tavoitteet ja tiedämme, mihin päädymme jokaisella seuraavalla hetkellä. Tämä on minun näkökulmastani DevOpsin ydin.
Katso myös kysymys. Luulen, että meillä kaikilla on sama tavoite: selviytyä ja tehdä se
suurin ilo. Ja minkä tahansa organisaation kilpailutavoite on sama. Selviytyminen tapahtuu usein kilpailun kautta, et voi sille mitään.
Tämän vuoden konferenssi järjestetään 7. joulukuuta Technopoliksessa. Otamme vastaan raportteja 11. asti. meille, jos haluat puhua.
Osallistujien ilmoittautuminen on auki, liput maksavat 7000 XNUMX ruplaa. Liity meihin!
Lähde: will.com