DevOpsin määritelmä on hyvin monimutkainen, joten meidän on aloitettava keskustelu siitä alusta joka kerta. Pelkästään Habresta on tästä aiheesta tuhat julkaisua. Mutta jos luet tätä, tiedät luultavasti mikä DevOps on. Koska en ole. Hei minun nimeni on Alexander Titov (@), ja puhumme vain DevOpsista ja jaan kokemukseni.
Olen pitkään miettinyt, miten voisin tehdä tarinastani hyödyllisen, joten täällä tulee olemaan paljon kysymyksiä - niitä, joita kysyn itseltäni ja niitä, joita kysyn yrityksemme asiakkailta. Vastaamalla näihin kysymyksiin ymmärrys paranee. Kerron sinulle, miksi DevOpsia tarvitaan minun näkökulmastani, mitä se taas on minun näkökulmastani ja kuinka ymmärtää, että olet siirtymässä taas kohti DevOpsia minun näkökulmastani. Viimeinen kohta on kysymysten kautta. Vastaamalla niihin itse voit ymmärtää, onko yrityksesi menossa kohti DevOpsia vai onko siinä jollain tavalla ongelmia.
Kerran ratsastin fuusioiden ja yritysostojen aalloilla. Ensin työskentelin pienessä startupissa nimeltä Qik, sitten sen osti hieman suurempi yritys nimeltä Skype, jonka sitten osti hieman suurempi yritys nimeltä Microsoft. Sillä hetkellä aloin nähdä, kuinka DevOps-idea oli muuttumassa erikokoisissa yrityksissä. Sen jälkeen innostuin katsomaan DevOpsia markkinoiden näkökulmasta ja perustimme kollegoideni kanssa yrityksen Express 42:n. Olemme nyt 6 vuotta liikkuneet markkinoiden aaltoja pitkin.
Olen muun muassa yksi DevOps Moskovan yhteisön järjestäjistä ja DevOps-Days 2017 -tapahtuman järjestäjä, mutta vuotta 2018 en järjestänyt. Express 42 toimii monien yritysten kanssa. Kasvatamme DevOpsia siellä, seuraamme sen tapahtumista, teemme johtopäätöksiä, analysoimme, kerromme kaikille johtopäätöksemme ja koulutamme ihmisiä DevOps-käytäntöihin. Yleisesti ottaen teemme parhaamme lisätäksemme kokemustamme ja asiantuntemustamme tässä suhteessa.
Miksi DevOps
Ensimmäinen kysymys, joka kummittelee kaikkia ja aina on - miksi? Monet ihmiset ajattelevat, että DevOps on vain automaatio tai vastaava asia, joka jokaisella yrityksellä on jo ollut.
— Meillä oli jatkuva integraatio – tämä tarkoittaa, että meillä oli jo DevOps, ja miksi kaikkea tätä tavaraa tarvitaan? He pitävät hauskaa ulkomailla, mutta he estävät meitä tekemästä työtä!
Yhteisön ja metodologian yhdeksän vuoden kehitystyön aikana on jo käynyt selväksi, että tämä ei edelleenkään ole markkinointikimalle, mutta silti ei ole täysin selvää, miksi sitä tarvitaan. Kuten kaikilla työkaluilla ja prosesseilla, DevOpsilla on tietyt tavoitteet, jotka se lopulta saavuttaa.
Kaikki tämä johtuu siitä, että maailma muuttuu. Hän siirtyy pois yrityslähestymistavasta, kun yritykset siirtyvät suoraan kohti unelmaa, kuten Pietarin klassikomme lauloi, pisteestä A pisteeseen B tietyn strategian mukaan, tietyllä rakenteella tätä varten.
Periaatteessa kaikki IT:ssä pitäisi rakentaa tämän lähestymistavan mukaan. Täällä IT:tä käytetään yksinomaan prosessien automatisointiin.
Automaatio ei muutu usein, koska kun yritys ajautuu vauhdikkaaseen uraan, mitä siinä on muuttaa? Se toimii - älä koske siihen. Nyt lähestymistavat maailmassa ovat muuttumassa, ja Agile-niminen lähestymistapa viittaa siihen, että päätepiste B ei ole heti näkyvissä.
Kun yritys käy markkinoiden läpi, työskentelee asiakkaan kanssa, se tutkii jatkuvasti markkinoita ja muuttaa päätepistettä B. Lisäksi mitä useammin yritys muuttaa suuntaa, sitä menestyneempi se lopulta on, koska se valitsee enemmän markkinoita markkinarakoja.
Strategiaa esittelee mielenkiintoinen yritys, josta sain tietää äskettäin. One Box Shave on tilauspalvelu parranajokoneille ja parranajotarvikkeille laatikossa. He osaavat mukauttaa "laatikkonsa" eri asiakkaille. Tämä tehdään tietyllä ohjelmistolla, joka lähettää tilauksen tuotteen valmistavalle Korean tehtaalle.
Unilever osti tämän tuotteen miljardilla dollarilla. Se kilpailee nyt Gilletten kanssa ja on vienyt merkittävän osan kuluttajista Amerikan markkinoilta. One Box Shave sano:
- 4 terää? Oletko tosissasi? Miksi tarvitset tätä - se ei paranna parranajon laatua. Erityisesti valittu kerma, tuoksu ja laadukas partakone kahdella terällä ratkaisevat paljon enemmän ongelmia kuin ne typerät 4 Gillette-terää! Pääsemmekö pian 10:een?
Näin maailma muuttuu. Unilever väittää, että heillä on siisti IT-järjestelmä, jonka avulla voit tehdä tämän. Loppujen lopuksi se näyttää konseptilta Aika markkinoida, josta kukaan ei ole jo puhunut.
Markkinoillepanon aika ei ole siinä, kuinka usein otamme käyttöön. Voit usein ottaa käyttöön, mutta julkaisujaksot ovat pitkiä. Jos kolmen kuukauden julkaisujaksot asetetaan päällekkäin ja siirretään niitä viikolla, käy ilmi, että yritys näyttää ottavan käyttöön kerran viikossa. Ja ideasta lopulliseen toteutukseen kestää 3 kuukautta.
Time-to-market tarkoittaa ajatuksen minimoimista ideasta lopulliseen toteutukseen.
Tässä tapauksessa ohjelmisto on vuorovaikutuksessa markkinoiden kanssa. Näin One Box Shave -verkkosivusto on vuorovaikutuksessa asiakkaan kanssa. Heillä ei ole myyjiä - vain verkkosivusto, jossa kävijät napsauttavat ja jättävät toiveita. Siten jotain uutta on jatkuvasti julkaistava sivustolla ja päivitettävä toiveiden mukaisesti. Esimerkiksi Etelä-Koreassa ajellaan eri tavalla kuin Venäjällä, ja he eivät pidä männyn, vaan esimerkiksi porkkanan ja vaniljan tuoksusta.
Koska on välttämätöntä muuttaa sivuston sisältöä nopeasti, ohjelmistokehitys muuttuu suuresti. Ohjelmiston avulla meidän on selvitettävä, mitä asiakas haluaa. Aiemmin olemme oppineet tämän jollain kiertoradalla, esimerkiksi liikkeenjohdon kautta. Sitten suunnittelimme sen, asetimme vaatimukset IT-järjestelmään ja kaikki oli siistiä. Nyt tilanne on erilainen – ohjelmiston suunnittelevat kaikki prosessissa mukana olevat, myös insinöörit, koska teknisten eritelmien kautta he oppivat, miten markkinat toimivat, ja jakavat näkemyksensä myös yrityksen kanssa.
Esimerkiksi Qikissa saimme yhtäkkiä tietää, että ihmiset todella pitivät yhteystietoluetteloiden lataamisesta palvelimelle, ja he toimittivat meille sovelluksen. Aluksi emme ajatellut sitä. Klassisessa yrityksessä kaikki olisivat päättäneet, että tämä oli bugi, koska tekniset tiedot eivät sanoneet, että sen pitäisi toimia hyvin ja se toteutettiin yleensä polvella, he olisivat sammuttaneet ominaisuuden ja sanoneet: "Kukaan ei tarvitse tätä, tärkeintä on, että päätoiminnot toimivat.” . Ja teknologiayritys näkee tämän mahdollisuutena ja alkaa muuttaa ohjelmistoja tämän mukaisesti.
Vuonna 1968 visionäärimies Melvin Conway muotoili seuraavan idean.
Järjestelmän luovaa organisaatiota rajoittaa rakenne, joka jäljittelee kyseisen organisaation viestintärakennetta.
Tarkemmin sanottuna, jotta voit tuottaa erityyppisiä järjestelmiä, sinulla on oltava myös viestintärakenne erityyppisessä yrityksessä. Jos viestintärakenne on huippuhierarkkinen, tämä ei salli sinun luoda järjestelmiä, jotka voivat tarjota erittäin korkean aika-indikaattorin markkinoille.
kunnia voidaan muodostaa . Se on tärkeää DevOps-kulttuurin tai -filosofian ymmärtämiseksi, koska Ainoa asia, joka muuttaa olennaisesti DevOpsissa, on tiimien välisen viestinnän rakenne.
Prosessin näkökulmasta ennen DevOpsia kaikki vaiheet: analytiikka, kehitys, testaus, käyttö olivat lineaarisia.
DevOpsin tapauksessa kaikki nämä prosessit tapahtuvat samanaikaisesti.
Aika markkinoille saattaminen on ainoa tapa tehdä se. Ihmisille, jotka työskentelivät vanhassa prosessissa, tämä näyttää jokseenkin kosmiselta, ja yleensä niin.
Joten miksi tarvitset DevOpsia?
Digitaaliseen tuotekehitykseen. Jos yritykselläsi ei ole digitaalista tuotetta, DevOpsia ei tarvita - se on erittäin tärkeää.
DevOps voittaa peräkkäisen ohjelmistotuotannon nopeusrajoitukset. Siinä kaikki prosessit tapahtuvat samanaikaisesti.
Vaikeus lisääntyy. Se on hölynpölyä, kun DevOps-evankelistat kertovat sinulle, että ohjelmistojen julkaiseminen on helpompaa.
DevOpsin avulla asiat vain muuttuvat monimutkaisemmiksi.
Aviton osastolla pidetyssä konferenssissa saattoi nähdä, millaista oli ottaa käyttöön Docker-kontti – epärealistinen tehtävä. Monimutkaisuudesta tulee kohtuuton; joudut jongleeraamaan monta palloa samanaikaisesti.
DevOps muuttaa täysin yrityksen prosessin ja organisaation — Tarkemmin sanottuna DevOps ei muutu, vaan digitaalinen tuote. Päästäksesi DevOpsiin, sinun on silti muutettava tämä prosessi kokonaan.
Kysymyksiä asiantuntijalle
Mitä sinulla on? Kysymyksiä, joita voit kysyä itseltäsi työskennellessäsi yrityksessä ja kehittyessäsi asiantuntijana.
Onko sinulla strategia digitaalisen tuotteen luomiseen? Jos on, se on jo hyvä. Tämä tarkoittaa, että yrityksesi on siirtymässä kohti DevOpsia.
Onko yrityksesi jo luomassa digitaalista tuotetta? Tämä tarkoittaa, että voit nousta tason korkeammalle ja tehdä asioita mielenkiintoisemmin – jälleen DevOpsin näkökulmasta. Puhun vain tästä näkökulmasta.
Onko yrityksesi yksi digitaalisten tuotteiden markkinajohtajista? Spotify, Yandex, Uber ovat yrityksiä, jotka ovat nyt teknologisen kehityksen huipulla.
Kysy itseltäsi nämä kysymykset, ja jos kaikki vastaukset ovat ei, sinun ei ehkä pitäisi tehdä DevOpsia tässä yrityksessä. Jos DevOps-aihe kiinnostaa sinua, ehkä... sinun pitäisi siirtyä toiseen yritykseen? Jos yrityksesi haluaa mennä DevOpsiin, mutta vastasit "ei" kaikkiin kysymyksiin, se on kuin kaunis sarvikuono, joka ei muutu koskaan.
Organisaatio
Kuten sanoin, Conwayn lain mukaan yrityksen organisaatio muuttuu. Aloitan siitä, mikä estää DevOpsia tunkeutumasta yrityksen sisälle organisaation näkökulmasta.
"kaivojen" ongelma
Englanninkielinen sana "Silo" käännetään tässä venäjäksi "hyvin". Tämän ongelman pointti on se joukkueiden välillä ei ole tiedonvaihtoa. Jokainen tiimi kaivaa syvälle asiantuntemukseensa rakentamatta yhteistä karttaa navigointia varten.
Jollain tapaa tämä muistuttaa minua juuri Moskovaan saapuneesta henkilöstä, joka ei vielä osaa navigoida metrokartalla. Moskovalaiset tuntevat yleensä alueensa erittäin hyvin, ja koko Moskovassa he voivat navigoida metrokartan avulla. Kun tulet Moskovaan ensimmäistä kertaa, sinulla ei ole tätä taitoa, ja olet vain sekaisin.
DevOps ehdottaa, että selviäisit tästä hämmentyneestä hetkestä ja kaikki osastot työskentelevät yhdessä yhteisen vuorovaikutuskartan luomiseksi.
Tätä estää kaksi tekijää.
Yritysjohtamisjärjestelmän seuraus. Se on rakennettu erillisiin hierarkkisiin "kaivoihin". Esimerkiksi yrityksissä on tiettyjä KPI:itä, jotka tukevat tätä järjestelmää. Toisaalta sellaisen ihmisen aivot, jonka on vaikea ylittää osaamisensa rajoja ja navigoida koko järjestelmässä, jäävät tielle. Se on vain epämukavaa. Kuvittele, että olet Bangkokin lentokentällä – et löydä reittiäsi nopeasti. DevOpsissa on myös vaikea navigoida, ja siksi ihmiset sanovat, että sinun on löydettävä opas päästäksesi sinne.
Mutta tärkeintä on, että DevOps-hengestä kyllästyneen, Fowleria ja joukon muita kirjoja lukeneen insinöörin "kaivojen" ongelma ilmenee siinä, että "kaivot" eivät salli sinun tehdä "ilmeisiä" asioita. Kokoonnumme usein yhteen DevOps Moskovan jälkeen, puhumme toisillemme ja ihmiset valittavat:
– Halusimme vain käynnistää CI:n, mutta kävi ilmi, että johto ei tarvinnut sitä.
Tämä tapahtuu juuri siksi CI и Jatkuva toimitusprosessi ovat monien tutkimusten rajalla. Yksinkertaisesti ratkaisematta "kaivojen" ongelmaa organisaatiotasolla, et voi siirtyä eteenpäin, vaikka teet mitä tahansa ja kuinka surullista se on.
Jokainen prosessiin osallistuja yrityksessä: tausta- ja käyttöliittymäkehittäjät, testaus, DBA, käyttö, verkko, kaivavat omaan suuntaansa, eikä kenelläkään ole yhteistä karttaa paitsi esimiehellä, joka jotenkin valvoo ja hallitsee niitä "jakaa" avulla. ja valloita" -menetelmä.
Ihmiset taistelevat tähdistä tai lipuista, kaikki kaivavat osaamistaan.
Tämän seurauksena, kun tehtävänä on yhdistää tämä kaikki yhteen ja rakentaa yhteinen putki, eikä enää ole tarvetta taistella tähdistä ja lipuista, herää kysymys - mitä tehdä? Meidän on päästävä jotenkin sopimukseen, mutta kukaan ei opettanut meille, kuinka tämä tehdään koulussa. Meille on opetettu koulusta asti: kahdeksas luokka - vau! - verrattuna seitsemänteen luokkaan! Se on sama täällä.
Onko sinun yrityksessäsi sama?
Voit tarkistaa tämän esittämällä itsellesi seuraavat kysymykset.
Käyttävätkö tiimit yhteisiä työkaluja ja osallistuvatko näiden yhteisten työkalujen muutoksiin?
Kuinka usein tiimit järjestäytyvät uudelleen – jotkut tiimin asiantuntijat siirtyvät toiseen tiimiin? DevOps-ympäristössä tästä tulee normaalia, koska joskus ihminen ei yksinkertaisesti ymmärrä, mitä toinen osaamisalue tekee. Hän muuttaa toiselle osastolle, työskentelee siellä kaksi viikkoa luodakseen itselleen kartan perehtymisestä ja vuorovaikutuksesta tämän osaston kanssa.
Onko mahdollista muodostaa muutostoimikunta ja muuttaa asioita? Vai vaatiiko se korkeimman johdon ja ohjauksen vahvaa kättä? Kirjoitin äskettäin Facebookissa, kuinka yksi vähän tunnettu pankki toteuttaa työkaluja tilausten kautta: kirjoitamme toimeksiannon, toteutamme sen vuoden ja katsotaan mitä tapahtuu. Tämä on tietysti pitkä ja surullinen.
Kuinka tärkeää esimiehille on saada henkilökohtaisia saavutuksia ottamatta huomioon yrityksen saavutuksia?
Jos vastaat itse näihin kysymyksiin, selviää, onko yrityksessäsi tällaista ongelmaa.
Infrastruktuuri koodina
Tämän ongelman ohituksen jälkeen on ensimmäinen tärkeä käytäntö, jota ilman on vaikea edetä DevOpsissa infrastruktuuri koodina.
Useimmiten infrastruktuuri koodina nähdään seuraavasti:
— Automatisoidaan kaikki bashissa, peitetään skripteillä, jotta ylläpitäjillä on vähemmän manuaalista työtä!
Mutta se ei ole totta.
Infrastruktuuri koodina tarkoittaa, että kuvaat käyttämääsi IT-järjestelmää koodin muodossa ymmärtääksesi jatkuvasti sen tilaa.
Luot yhdessä muiden tiimien kanssa koodin muodossa olevan kartan, jonka kaikki ymmärtävät ja jotka voivat navigoida ja navigoida. Ei ole väliä millä se on tehty – Chef, Ansible, Salt tai YAML-tiedostot Kubernetesissa – sillä ei ole eroa.
Konferenssissa kollega 2GIS:stä kertoi, kuinka he tekivät Kubernetesille oman sisäisen jutun, joka kuvaa yksittäisten järjestelmien rakennetta. 500 järjestelmän kuvaamiseksi he tarvitsivat erillisen työkalun, joka luo tämän kuvauksen. Kun tämä kuvaus on, jokainen voi tarkistaa keskenään, seurata muutoksia, miten sitä muuttaa ja parantaa, mitä puuttuu.
Samaa mieltä, yksittäiset bash-skriptit eivät yleensä tarjoa tätä ymmärrystä. Yhdessä yrityksessä, jossa työskentelin, oli jopa nimi "vain kirjoitus" -skriptille - kun käsikirjoitus on kirjoitettu, mutta sitä ei enää voi lukea. Luulen, että tämä on sinullekin tuttua.
Infrastruktuuri sellaisena kuin koodi on koodi, joka kuvaa infrastruktuurin nykyistä tilaa. Monet tuote-, infrastruktuuri- ja palvelutiimit työskentelevät yhdessä tämän koodin parissa, ja mikä tärkeintä, heidän kaikkien on ymmärrettävä, kuinka tämä koodi todella toimii.
Koodia ylläpidetään parhaiden koodikäytäntöjen mukaisesti: yhteinen kehitys, koodin tarkistus, XP-ohjelmointi, testaus, vetopyynnöt, CI koodiinfrastruktuureille - kaikki tämä sopii ja voidaan käyttää.
Koodista tulee yhteinen kieli kaikille insinööreille.
Infrastruktuurin muuttaminen koodissa ei vie paljon aikaa. Kyllä, infrastruktuurikoodilla voi olla myös teknistä velkaa. Yleensä tiimit kohtaavat sen puolitoista vuotta sen jälkeen, kun he aloittivat "infrastruktuurin koodina" toteuttamisen skriptien tai jopa Ansiblen muodossa, jotka he kirjoittavat kuin spagettikoodia, ja he heittävät myös bash-skriptejä sekoitukseen!
On tärkeää: Jos et ole vielä kokeillut tätä, muista se Ansible ei ole bash! Lue dokumentaatio huolellisesti, tutki, mitä he kirjoittavat siitä.
Infrastruktuuri koodina on infrastruktuurikoodin jakamista erillisiin kerroksiin.
Yrityksessämme erottelemme 3 peruskerrosta, jotka ovat hyvin selkeitä ja yksinkertaisia, mutta niitä voi olla enemmänkin. Voit katsoa infrastruktuurikoodiasi ja kertoa, onko sinulla tämä ehto vai ei. Jos yhtään kerrosta ei ole korostettu, sinun on käytettävä jonkin aikaa ja heijastettava hieman.
pohjakerros - näin konfiguroidaan käyttöjärjestelmä, varmuuskopiot ja muut matalan tason asiat, esimerkiksi kuinka Kubernetes otetaan käyttöön perustasolla.
Palvelutaso - nämä ovat palveluita, joita tarjoat kehittäjälle: kirjaaminen palveluna, seuranta palveluna, tietokanta palveluna, tasapainottaja palveluna, jono palveluna, Jatkuva toimitus palveluna - joukko palveluita, jotka yksittäiset tiimit voi tarjota kehitystä. Tämä kaikki on kuvattava erillisissä moduuleissa kokoonpanonhallintajärjestelmässäsi.
Kerros, jossa sovelluksia tehdään ja kuvaa kuinka ne avautuvat kahden edellisen kerroksen päälle.
Kontrollikysymykset
Onko yritykselläsi yhteinen infrastruktuuritietovarasto? Hallitsetko teknistä velkaa infrastruktuurissasi? Käytätkö kehittämiskäytäntöjä infrastruktuuriarkistossa? Onko infrastruktuurisi leikattu kerroksiin? Voit tarkistaa Base-service-APP-kaavion. Kuinka vaikeaa muutoksen tekeminen on?
Jos olet kokenut, että muutosten tekemiseen meni puolitoista päivää, tämä tarkoittaa, että sinulla on teknistä velkaa ja sinun on työskenneltävä sen kanssa. Olet juuri törmännyt tekniseen velkaharavaan infrastruktuurikoodissasi. Muistan monia sellaisia tarinoita, kun joidenkin CCTL:n vaihtamiseksi joudut kirjoittamaan puolet infrastruktuurikoodista uudelleen, koska luovuus ja halu automatisoida kaikki johtivat siihen, että kaikki on ruostunut kaikkialla, kaikki kahvat on poistettu ja on välttämätöntä heijastaa.
Jatkuva toimitus
Verrataan veloitusta luottoon. Ensin tulee kuvaus infrastruktuurista, joka voi olla melko yksinkertainen. Kaikkea ei tarvitse kuvata yksityiskohtaisesti, mutta peruskuvaus tarvitaan, jotta voit työskennellä sen kanssa. Muuten ei ole selvää, mitä jatkuvalla toimituksella seuraavaksi tehdä. Kaikki nämä käytännöt avautuvat samanaikaisesti, kun tulet DevOpsiin, mutta se alkaa ymmärtämällä, mitä sinulla on ja kuinka hallita sitä. Tämä on nimenomaan käytäntö infrastruktuurin käyttämisestä koodina.
Kun on selvää, että sinulla on se ja kuinka hallita sitä, alat miettiä, kuinka voit lähettää kehittäjäkoodin tuotantoon mahdollisimman nopeasti. Tarkoitan yhdessä kehittäjän kanssa - muistamme "kaivojen" ongelman, toisin sanoen yksittäiset ihmiset eivät keksi tätä, vaan joukkue.
Kun olemme mukana Vanya Evtukhovich näki ensimmäisen kirjan Jez Humble ja kirjailijaryhmiä "Jatkuva toimitus", joka julkaistiin vuonna 2009, mietimme pitkään, kuinka kääntää sen nimi venäjäksi. He halusivat kääntää sen sanaksi "Jatkuva toimitus", mutta valitettavasti se käännettiin "Jatkuvaksi toimitukseksi". Minusta näyttää siltä, että nimessämme on jotain venäläistä, jossa on painostusta.
Jatkuva toimitusväline
Tuotevarastossa oleva koodi voidaan aina ladata tuotantoon. Hän ei ehkä ole deflatoitu, mutta hän on aina valmis siihen. Näin ollen kirjoitat aina koodia vaikeasti selitettävän ahdistuksen tunteen häntäluun alla. Se näkyy usein, kun otat infrastruktuurikoodin käyttöön. Tämän jonkinlaisen ahdistuksen tunteen pitäisi olla läsnä - se laukaisee aivoprosesseja, joiden avulla voit kirjoittaa koodia hieman eri tavalla. Tämä tulee kirjata kehitystyön sääntöihin.
Jotta voit toimittaa jatkuvasti, tarvitset artefaktimuodon, joka toimii infrastruktuurialustalla. Jos heittää eri muotoisia "elämän jätettä" infrastruktuurialustalle, siitä tulee yhtenäinen, sitä on vaikea ylläpitää ja syntyy teknisen velan ongelma. Artefaktin muoto on linjattava - tämä on myös kollektiivinen tehtävä: meidän kaikkien täytyy kokoontua yhteen, kahistella aivomme ja keksiä tämä muoto.
Artefaktia parannetaan jatkuvasti ja se muuttuu tuotantoympäristöön sopivaksi, kun se liikkuu toimitusputken läpi. Kun artefakti liikkuu putkilinjaa pitkin, se kohtaa jatkuvasti sille epämiellyttäviä asioita, jotka ovat samanlaisia kuin tuotantoon laittamasi esine kohtaa. Jos klassisessa kehityksessä tämän tekee järjestelmänvalvoja, joka tekee käyttöönoton, niin DevOps-prosessissa tätä tapahtuu koko ajan: täällä testattiin sitä joillain testeillä, täällä heitettiin Kubernetes-klusteriin, joka on enemmän tai vähemmän samanlainen. tuotantoon, sitten yhtäkkiä he aloittivat kuormitustestauksen.
Tämä muistuttaa jossain määrin Pac-Man-peliä - artefakti käy läpi jonkinlaisen tarinan. Samalla on tärkeää valvoa, kulkeeko koodi todella tarinan läpi ja liittyykö se jotenkin tuotantoosi. Tarinoita tuotannosta voi vetää Continuous Delivery -prosessiin: näin oli, kun jotain putosi, nyt ohjelmoidaan tämä skenaario järjestelmän sisään. Joka kerta, kun koodi käy läpi myös tämän skenaarion, etkä kohtaa tätä ongelmaa seuraavalla kerralla. Opit siitä paljon aikaisemmin kuin se saavuttaa asiakkaasi.
Erilaisia käyttöönottostrategioita. Käytät esimerkiksi AB-testausta tai Canary-käyttöönottoa koodin testaamiseen eri tavalla eri asiakkailla, saadaksesi tietoa koodin toiminnasta ja paljon aikaisemmin kuin silloin, kun se otettiin käyttöön 100 miljoonalle käyttäjälle.
"Toimita johdonmukaisesti" näyttää tältä.
Toimitusprosessi Dev, CI, Test, PreProd, Prod ei ole erillinen ympäristö, nämä ovat vaiheita tai asemia, joissa on paloturvallisia summia, joiden läpi artefaktisi kulkee.
Jos sinulla on infrastruktuurikoodi, joka on kuvattu Base Service APP -sovelluksena, se auttaa älä unohda kaikkia käsikirjoituksiaja kirjoita ne tämän artefaktin koodiksi, mainostaa esinettä ja muuta sitä samalla kun menet.
Itsetestauskysymykset
Aika ominaisuuden kuvauksesta tuotantoon 95 %:ssa tapauksista on alle viikko? Paraneeko artefaktin laatu putkilinjan jokaisessa vaiheessa? Onko olemassa tarina, jonka se käy läpi? Käytätkö erilaisia käyttöönottostrategioita?
Jos kaikki vastaukset ovat kyllä, olet uskomattoman hieno! Kirjoita vastauksesi kommentteihin - olen iloinen).
Ota Yhteyttä
Tämä on vaikein harjoitus kaikista. DevOpsConf-konferenssissa asiasta puhuva kollega Infobipistä oli hieman hämmentynyt sanoistaan, koska tämä on todella monimutkainen käytäntö siitä, että sinun on valvottava kaikkea!
Esimerkiksi kauan sitten, kun työskentelin Qikissa ja tajusimme, että meidän on seurattava kaikkea. Teimme tämän, ja meillä on nyt 150 000 tuotetta Zabbixissa, joita seurataan jatkuvasti. Se oli pelottavaa, tekninen johtaja väänteli sormeaan ohimoaan:
- Kaverit, miksi raiskaatte palvelimen jollakin epäselvällä asialla?
Mutta sitten tapahtui tapaus, joka osoitti, että tämä on todella siisti strategia.
Yksi palveluista alkoi kaatua jatkuvasti. Aluksi se ei kaatunut, mikä on mielenkiintoista, koodia ei lisätty sinne, koska se oli perusvälittäjä, jolla ei käytännössä ollut liiketoimintaa - se vain lähetti viestejä yksittäisten palveluiden välillä. Palvelu ei muuttunut 4 kuukauteen, ja yhtäkkiä se alkoi kaatua "Segmentointivika" -virheellä.
Olimme järkyttyneitä, avasimme kaaviomme Zabbixissa, ja kävi ilmi, että puolitoista viikkoa sitten tämän välittäjän käyttämän API-palvelun pyyntöjen käyttäytyminen muuttui suuresti. Seuraavaksi näimme, että tietyntyyppisten viestien lähetystiheys oli muuttunut. Myöhemmin saimme selville, että nämä olivat Android-asiakkaita. Kysyimme:
– Kaverit, mitä teille tapahtui puolitoista viikkoa sitten?
Vastauksena kuulimme mielenkiintoisen tarinan siitä, kuinka he olivat suunnitelleet käyttöliittymän uudelleen. On epätodennäköistä, että kukaan sanoisi heti muuttaneensa HTTP-kirjastoa. Android-asiakkaille se on kuin saippuan vaihtamista kylpyhuoneessa – he eivät vain muista. Tämän seurauksena 40 minuutin keskustelun jälkeen saimme selville, että he olivat muuttaneet HTTP-kirjastoa ja sen oletusajoitukset olivat muuttuneet. Tämä johti siihen, että API-palvelimen liikennekäyttäytyminen muuttui, mikä johti tilanteeseen, joka aiheutti kilpailun välittäjän sisällä ja se alkoi kaatua.
Ilman syvällistä seurantaa tätä on yleensä mahdotonta avata. Jos organisaatiolla on edelleen "kaivojen" ongelma, kun kaikki heittelevät rahaa toisilleen, tämä voi elää vuosia. Käynnistät palvelimen uudelleen, koska ongelmaa ei voida ratkaista. Kun tarkkailet, seuraat, seuraat kaikkia tapahtumia, joita sinulla on, ja käytät seurantaa testauksena - kirjoitat koodia ja ilmoitat heti kuinka sitä seurataan, myös koodin muodossa (meillä on jo infrastruktuuri koodina), kaikki käy selväksi, kuinka kämmenellä. Jopa tällaiset monimutkaiset ongelmat ovat helposti jäljitettävissä.
Kerää kaikki tiedot siitä, mitä artefakille tapahtuu toimitusprosessin jokaisessa vaiheessa – ei tuotannossa.
Lataa valvonta CI:hen, niin siellä näkyy jo joitain perusasioita. Myöhemmin näet ne Testissä, PredProdissa ja kuormitustestauksessa. Kerää tietoja kaikissa vaiheissa, ei vain mittareita, tilastoja, vaan myös lokeja: kuinka sovellus on otettu käyttöön, poikkeamat - kerää kaikki.
Muuten sitä on vaikea selvittää. Sanoin jo, että DevOps on monimutkaisempi. Selviytyäksesi tästä monimutkaisuudesta sinulla on oltava normaali analytiikka.
Kysymyksiä itsehillintää varten
Onko seurantasi ja kirjaaminen kehitystyökalu sinulle? Kun kirjoitat koodia, ajattelevatko kehittäjäsi, mukaan lukien sinä, kuinka valvoa sitä?
Kuuletko asiakkailta ongelmista? Ymmärrätkö asiakasta paremmin seurannasta ja kirjaamisesta? Ymmärrätkö järjestelmän paremmin seurannasta ja kirjaamisesta? Muutatko järjestelmää vain siksi, että näit järjestelmän trendin kasvavan ja ymmärrät, että 3 viikon kuluttua kaikki kuolee?
Kun sinulla on nämä kolme komponenttia, voit miettiä, millainen infrastruktuurialusta sinulla on yrityksessäsi.
Infrastruktuurialusta
Pointti ei ole siinä, että se on joukko erilaisia työkaluja, joita jokaisella yrityksellä on.
Infrastruktuurialustan tarkoitus on, että kaikki tiimit käyttävät näitä työkaluja ja kehittävät niitä yhdessä.
On selvää, että on olemassa erilliset tiimit, jotka vastaavat yksittäisten infrastruktuurialustan osien kehittämisestä. Mutta samaan aikaan jokainen insinööri on vastuussa infrastruktuurialustan kehittämisestä, suorituskyvystä ja edistämisestä. Sisäisellä tasolla siitä tulee yleinen työkalu.
Kaikki tiimit kehittävät infrastruktuurialustaa ja käsittelevät sitä huolellisesti omana IDE-ympäristönä. Asennat IDE:hen erilaisia laajennuksia tehdäksesi kaikesta mukavaa ja nopeaa ja määrität pikanäppäimiä. Kun avaat Sublimen, Atomin tai Visual Studio Coden, koodivirheitä sataa ja huomaat, että työ on mahdotonta, tulee heti surullinen olo ja juokset korjaamaan IDE:täsi.
Kohtele infrastruktuurialustaa samalla tavalla. Jos ymmärrät, että siinä on jotain vialla, jätä pyyntö, jos et voi korjata sitä itse. Jos on jotain yksinkertaista, muokkaa sitä itse, lähetä vetopyyntö, kaverit harkitsevat sitä ja lisäävät sen. Tämä on hieman erilainen lähestymistapa suunnittelutyökaluihin kehittäjän päässä.
Infrastruktuurialusta varmistaa artefaktin siirron kehityksestä asiakkaalle jatkuvalla laadun parantamisella. IP on ohjelmoitu joukolla tarinoita, jotka tapahtuvat tuotannossa olevalle koodille. Vuosien kehitystyön aikana näitä tarinoita on ollut paljon, jotkut niistä ovat ainutlaatuisia ja liittyvät vain sinuun - niitä ei voi Googlettaa.
Tässä vaiheessa infrastruktuurialustasta tulee kilpailuetusi, koska siinä on jotain sisäänrakennettua, mitä ei ole kilpailijan työkalussa. Mitä syvemmälle IP-osoitteesi on, sitä suurempi on kilpailuetu markkinoille tulon suhteen. Näkyy täällä myyjän lukituksen ongelma: Voit ottaa jonkun toisen alustan, mutta jonkun muun kokemuksen perusteella et ymmärrä, kuinka tärkeä se on sinulle. Kyllä, kaikki yritykset eivät voi rakentaa Amazonin kaltaista alustaa. Tämä on vaikea linja, jossa yrityksen kokemuksella on merkitystä sen markkina-asemalle, eikä siellä voi käyttää myyjälukkoa. Tätä on myös tärkeä pohtia.
ohjelma
Tämä on peruskaavio infrastruktuurialustasta, joka auttaa sinua määrittämään kaikki käytännöt ja prosessit DevOps-yrityksessä.
Katsotaanpa, mistä se koostuu.
Resurssien orkestrointijärjestelmä, joka tarjoaa suorittimen, muistin, levyn sovelluksille ja muille palveluille. Tämän lisäksi - matalan tason palvelut: valvonta, kirjaus, CI/CD-moottori, artefaktien tallennus, infrastruktuuri järjestelmäkoodina.
Korkeamman tason palvelut: tietokanta palveluna, jonot palveluna, Load Balance palveluna, kuvan koon muuttaminen palveluna, Big Data tehdas palveluna. Tämän lisäksi - putki, joka toimittaa jatkuvasti muokatun koodin asiakkaallesi.
Saat tietoa siitä, miten ohjelmistosi toimii asiakkaalle, muutat sitä, annat tämän koodin uudelleen, vastaanotat tietoa - ja siten kehität jatkuvasti sekä infrastruktuurialustaa että ohjelmistoasi.
Kaaviossa toimitusputkisto koostuu useista vaiheista. Mutta tämä on kaavio, joka on annettu esimerkkinä - sitä ei tarvitse toistaa yksitellen. Vaiheet ovat vuorovaikutuksessa palvelujen kanssa kuin ne olisivat palveluita – alustan jokaisella lohkolla on oma tarinansa: kuinka resurssit allokoidaan, miten sovellus käynnistetään, toimii resurssien kanssa, valvotaan ja muuttuu.
On tärkeää ymmärtää, että alustan jokainen osa sisältää tarinan, ja kysy itseltäsi, mitä tarinaa tämä tiili kantaa, ehkä se pitäisi heittää pois ja korvata kolmannen osapuolen palvelulla. Onko esimerkiksi mahdollista asentaa Okmeter tiilen sijaan? Ehkä kaverit ovat jo kehittäneet tätä asiantuntemusta paljon enemmän kuin me. Mutta ehkä ei - ehkä meillä on ainutlaatuista asiantuntemusta, meidän on asennettava Prometheus ja kehitettävä sitä edelleen.
Alustan luominen
Tämä on monimutkainen viestintäprosessi. Kun sinulla on peruskäytännöt, aloitat kommunikoinnin eri insinöörien ja asiantuntijoiden välillä, jotka kehittävät vaatimuksia ja standardeja ja muuttavat niitä jatkuvasti erilaisiksi työkaluiksi ja lähestymistavoiksi. DevOps-kulttuuri on tärkeä tässä.
Kulttuurissa kaikki on hyvin yksinkertaista - kyse on yhteistyöstä ja kommunikaatiosta, eli halu työskennellä yhteisellä alalla toistensa kanssa, halu hallita yhtä instrumenttia yhdessä. Täällä ei ole rakettitiedettä - kaikki on hyvin yksinkertaista, banaalia. Esimerkiksi me kaikki asumme sisäänkäynnissä ja pidämme sen puhtaana - tällainen kulttuurin taso.
Mitä sinulla on?
Jälleen kysymyksiä, joita voit kysyä itseltäsi.
Onko infrastruktuurialusta omistettu? Kuka on vastuussa sen kehittämisestä? Ymmärrätkö infrastruktuurialustasi kilpailuedut?
Sinun on jatkuvasti kysyttävä itseltäsi näitä kysymyksiä. Jos jotain voidaan siirtää kolmannen osapuolen palveluihin, se on siirrettävä, jos kolmannen osapuolen palvelu alkaa estää liikkumistasi, sinun on rakennettava järjestelmä itseesi.
Eli DevOps...
... tämä on monimutkainen järjestelmä, siinä on oltava:
- Digitaalinen tuote.
- Liiketoimintamoduulit, jotka kehittävät tätä digitaalista tuotetta.
- Tuoteryhmät, jotka kirjoittavat koodia.
- Jatkuva toimituskäytäntö.
- Alustat palveluna.
- Infrastruktuuri palveluna.
- Infrastruktuuri koodina.
- Erilliset käytännöt luotettavuuden ylläpitämiseksi, sisäänrakennettu DevOpsiin.
- Palautekäytäntö, joka kuvaa kaiken.
Voit käyttää tätä kaaviota korostamalla siinä sitä, mitä sinulla jo on yrityksessäsi jossain muodossa: onko se kehittynyt tai kaipaa vielä kehittämistä.
Se on ohi parin viikon sisällä . osana RIT++:aa. Tule konferenssiin, josta löydät monia hienoja raportteja jatkuvasta toimituksesta, infrastruktuurista koodina ja DevOps-muunnoksista. , viimeinen hintapäivä on 20
Lähde: will.com