Perustuu chat-keskusteluun
Viime aikoina todelliset taistelut ovat syttyneet DevOpsin ja SRE:n määritelmästä.
Huolimatta siitä, että tästä aiheesta käydyt keskustelut ovat jo monella tapaa kiristäneet hampaat, myös minä, päätin tuoda näkemykseni tästä aiheesta Habra-yhteisön oikeuteen. Kiinnostuneet tervetuloa kissoille. Ja anna kaiken alkaa alusta!
esihistoria
Joten muinaisina aikoina ohjelmistokehittäjien ja palvelinten ylläpitäjien ryhmä asui erillään. Ensimmäinen kirjoitti onnistuneesti koodin, toinen, käyttäen erilaisia lämpimiä, lempeitä sanoja, jotka oli osoitettu ensimmäiselle, asensi palvelimet, saapui ajoittain kehittäjille ja sai vastauksena kattavan "kaikki toimii koneellani". Yritys odotti ohjelmistoa, kaikki oli käyttämättömänä, se hajosi ajoittain, kaikki olivat hermostuneita. Varsinkin se, joka maksoi tämän koko sotkun. Loistava lamppuaika. Tiedät jo, mistä DevOps tulee.
DevOps-käytäntöjen synty
Sitten tulivat vakavat kaverit ja sanoivat - tämä ei ole ala, et voi työskennellä niin. Ja he toivat elinkaarimalleja. Tässä on esimerkiksi V-malli.
Joten mitä me näemme? Yrityksen mukana tulee konsepti, arkkitehdit suunnitteluratkaisut, kehittäjät kirjoittavat koodia, ja sitten se epäonnistuu. Joku jollakin tavalla testaa tuotetta, joku toimittaa sen loppukäyttäjälle ja jossain tämän ihmemallin lähdössä istuu yksinäinen yritysasiakas odottamassa meren rannalla luvattua säätä. Tulimme siihen tulokseen, että tarvitsemme menetelmiä, joiden avulla voimme toteuttaa tämän prosessin. Ja päätimme luoda käytäntöjä, jotka toteuttaisivat ne.
Lyyrinen poikkeama siitä, mitä käytäntö on
Käytännöllä tarkoitan tekniikan ja kurinalaisuuden yhdistelmää. Esimerkki on käytäntö, jossa infrastruktuuria kuvataan terraform-koodilla. Kuri on kuinka kuvailla infrastruktuuria koodilla, se on kehittäjän päässä, ja teknologia on itse terraformi.
Ja he päättivät kutsua niitä DevOps-käytännöiksi - mielestäni ne tarkoittivat kehitystä operaatioihin. Keksimme erilaisia fiksuja asioita - CI/CD-käytäntöjä, IaC-periaatteeseen perustuvia käytäntöjä, niitä tuhansia. Ja mennään, kehittäjät kirjoittavat koodia, DevOps-insinöörit muuttavat järjestelmän kuvauksen koodin muodossa toimiviksi järjestelmiksi (kyllä, koodi on valitettavasti vain kuvaus, mutta ei järjestelmän suoritusmuoto), toimitus jatkuu, ja niin edelleen. Eilisen järjestelmänvalvojat, jotka ovat oppineet uusia käytäntöjä, kouluttautuivat ylpeänä uudelleen DevOps-insinööreiksi, ja kaikki lähti siitä eteenpäin. Ja oli ilta ja oli aamu... anteeksi, ei sieltä.
Kaikki ei ole taaskaan hyvin, luojan kiitos
Heti kun kaikki rauhoittui ja erilaiset ovelat "metodologit" alkoivat kirjoittaa paksuja kirjoja DevOps-käytännöistä, hiljaa leimahti kiistat siitä, kuka pahamaineinen DevOps-insinööri oli ja että DevOps on tuotantokulttuuri, tyytymättömyys nousi jälleen. Yhtäkkiä kävi ilmi, että ohjelmistojen toimitus on täysin ei-triviaali tehtävä. Jokaisella kehitysinfrastruktuurilla on oma pinonsa, jossain sinun täytyy koota se, jossain sinun täytyy ottaa käyttöön ympäristö, täällä tarvitset Tomcatia, täällä tarvitset ovelan ja monimutkaisen tavan käynnistää se - yleensä pää hakkaa. Ja ongelma, kummallista kyllä, osoittautui ensisijaisesti prosessien organisoimiseksi - tämä toimitustoiminto, kuten pullonkaula, alkoi estää prosesseja. Lisäksi kukaan ei peruuttanut toimintoja. V-mallissa se ei näy, mutta oikealla on silti koko elinkaari. Seurauksena on, että infrastruktuuria on jotenkin ylläpidettävä, valvontaa, häiriötilanteiden selvittämistä ja myös toimitusta on hoidettava. Nuo. istua yhdellä jalalla sekä kehityksessä että käytössä - ja yhtäkkiä siitä tuli kehitys ja toiminta. Ja sitten oli yleinen hype mikropalveluista. Ja heidän kanssaan kehitys paikallisista koneista alkoi siirtyä pilveen - yritä korjata jotain paikallisesti, jos mikropalveluita on kymmeniä ja satoja, niin jatkuvasta toimituksesta tulee selviytymiskeino. ”Pienelle vaatimattomalle yritykselle” se oli ihan ok, mutta silti? Entä Google?
Googlen SRE
Google tuli, söi suurimmat kaktukset ja päätti – emme tarvitse tätä, tarvitsemme luotettavuutta. Ja luotettavuus on hallittava. Ja päätin, että tarvitsemme asiantuntijoita, jotka hallitsevat luotettavuutta. Soitin heille SR-insinööreiksi ja sanoin, että se on sinulle, tee se hyvin tavalliseen tapaan. Tässä on SLI, tässä SLO, tässä on valvonta. Ja hän työnsi nenäänsä leikkauksiin. Ja hän kutsui "luotettavaa DevOpsiaan" SRE:ksi. Kaikki näyttää olevan kunnossa, mutta Googlella on yksi likainen hakkeri, johon Googlella oli varaa - palkata SR-insinöörien tehtäviin ihmisiä, jotka olivat päteviä kehittäjiä ja tekivät myös vähän kotitehtäviä ja ymmärsivät toimivien järjestelmien toiminnan. Lisäksi Googlella itsellään on ongelmia tällaisten ihmisten palkkaamisessa - lähinnä siksi, että se kilpailee tässä itsensä kanssa - on välttämätöntä kuvata liikelogiikka jollekin. Toimitus määrättiin julkaisuinsinööreille, SR - insinöörit hallitsevat luotettavuutta (ei tietenkään suoraan, vaan vaikuttamalla infrastruktuuriin, muuttamalla arkkitehtuuria, seuraamalla muutoksia ja indikaattoreita, käsittelemällä tapauksia). Hienoa, voit . Mutta entä jos et ole Google, mutta luotettavuus on silti jotenkin huolenaihe?
DevOps-ideoiden kehittäminen
Juuri silloin saapui Docker, joka kasvoi lxc:stä, ja sitten erilaiset orkestrointijärjestelmät, kuten Docker Swarm ja Kubernetes, sekä DevOps-insinöörit hengittivät - käytäntöjen yhdistäminen yksinkertaisti toimitusta. Se yksinkertaisti sitä siinä määrin, että tuli mahdolliseksi jopa ulkoistaa toimitus kehittäjille - mikä on deployment.yaml. Säiliöinti ratkaisee ongelman. Ja CI/CD-järjestelmien kypsyys on jo yhden tiedoston kirjoittamisen tasolla ja mennään – kehittäjät voivat hoitaa sen itse. Ja sitten alamme puhua siitä, kuinka voimme tehdä oman SRE:n... tai ainakin jonkun kanssa.
SRE ei ole Googlessa
No, ok, toimitimme toimituksen, näyttää siltä, että voimme hengittää, palata vanhoihin hyviin aikoihin, kun ylläpitäjät seurasivat prosessorin kuormitusta, virittelivät järjestelmiä ja siemailivat hiljaa jotain käsittämätöntä mukeista rauhassa ja hiljaisuudessa... Stop. Tästä syystä emme aloittaneet kaikkea (mikä on sääli!). Yhtäkkiä käy ilmi, että Googlen lähestymistavassa voimme helposti omaksua erinomaisia käytäntöjä - ei ole tärkeää prosessorin kuormitus, ei se kuinka usein vaihdamme siellä olevia levyjä tai optimoimme kustannuksia pilvessä, vaan liiketoimintamittarit ovat samat pahamaineiset. SLx. Eikä kukaan ole poistanut heiltä infrastruktuurin hallintaa, ja heidän on ratkaistava tapaukset, oltava säännöllisesti päivystyksessä ja yleensä pysyttävä liiketoimintaprosessien ajan tasalla. Ja kaverit, aloita ohjelmointi pikkuhiljaa hyvällä tasolla, Google odottaa jo teitä.
Yhteenvetona. Yhtäkkiä, mutta olet jo kyllästynyt lukemiseen, etkä malta odottaa, että pääset sylkemään ja kirjoittamaan kirjoittajalle artikkelin kommentissa. DevOps toimituskäytäntönä on aina ollut ja tulee olemaan. Eikä se mene mihinkään. SRE operatiivisten käytäntöjen kokonaisuutena tekee tästä toimituksesta erittäin onnistuneen.
Lähde: will.com