Ohjelmointi

Mikä on SRE? Sivuston luotettavuusinsinöörin tärkeä rooli

Kun maailma on muuttunut verkossa, verkkosivustojen, pilvisovellusten ja pilvi-infrastruktuurin luotettavuudesta on tullut kriittinen liiketoiminnan välttämättömyys - kaikesta sähköisestä kaupankäynnistä globaaleihin pankkeihin hakukoneisiin.

Tapa, jolla hallitsemme järjestelmiä ja niiden kuormitusta, on muuttunut. Tänään ajattelemme harvoin arvokkaita, korkean kosketuksen ja tehokkaita palvelimia, mutta sen sijaan telineet tavara-palvelimista, jotka on yhdistetty virtualisoinnin avulla, hajautetun ohjelmistoarkkitehtuurin avulla, joka estää palvelinkatkoksia aiheuttamasta seisokkeja. Painopiste on siirtynyt laitteistosta ohjelmistojen määrittelemään infrastruktuuriin ja epäjohdonmukaisista ja virheille alttiista manuaalisista prosesseista johdonmukaisiin, luotettaviin ja toistettaviin automaattisiin tehtäviin.

Sivuston luotettavuustekniikka on käytäntö ylläpitää ohjelmoitavaa infrastruktuuria ja maksimoida sitä käyttävien kuormitusten saatavuus. Sivuston luotettavuusinsinöörin (SRE) työnimike on peräisin Googlen salista, joka halusi vuosituhannen vaihteessa määritellä uudelleen ohjelmistokehittäjien ja operatiivisen henkilöstön välisen suhteen - ja auttaa heitä työskentelemään yhdessä rakentamaan vankkoja, joustavia järjestelmiä jatkuva parantaminen ja automatisointi keskeisinä periaatteina.

Mikä on SRE?

Perustasolla SRE: t tuovat ohjelmistotuotannon periaatteet infrastruktuuri- ja käyttöongelmiin, ja pohjoistähden tavoitteena on luoda erittäin skaalautuvia ja luotettavia järjestelmiä.

"Pohjimmiltaan se tapahtuu, kun pyydät ohjelmistoinsinööriä suunnittelemaan toimintotoiminnon", kuten usein mainitaan Googlen insinööripäällikkönä ja SRE: n kummisetä Ben Treynorina.

Suurin osa SRE-vastuualueista on palvelutasokynnysten asettaminen, jotka usein ilmenevät palvelutason tavoitteina (SLO), jotka auttavat saamaan tiedon siitä, onko julkaisu vihreästi valaistu vai ei. Pyhä graali on aina pyhitetty ”viisi yhdeksää” eli 99,999% käyttöaika. Mitä parempi käyttöaika, sitä enemmän köyden kehittäjät saavat käynnistää hienoja uusia juttuja ja sitä enemmän unia SRE: t saavat, mikä johtaa molempia osapuolia hyödyttävään suhteeseen toimintojen välillä, kaukana kehittäjien ja operaatioiden vastakkainasetteluista.

SRE-toiminto mitataan tyypillisesti luotettavuuden tärkeimpien mittareiden joukosta, nimittäin: järjestelmän suorituskyky, käytettävyys, viive, tehokkuus, seuranta, kapasiteetin suunnittelu ja hätätilanteissa reagointi.

[Myös: Sovellusten valvonta: Mitä devops voi tehdä paremmin]

SRE: n keskeiset työtehtävät

Mikä tahansa hyvä SRE on pakkomielle erityisesti yhdestä asiasta: automaatiosta.

Kuten Jason Qualman, ohjelmistotoimittaja New Relicin seurantaryhmä, toteaa blogikirjoituksessa: "Paljon tässä roolissa ajatellaan tehottomista ja aikaa vievistä asioista, joita ihmiset tekevät, ja lopettaa ne mahdollisimman pian. Sen sijaan, että potkaisit tölkkiä manuaalisesti, sanot: "Aion käyttää aikaa tämän automatisointiin juuri nyt ja estää ketään muuta tekemästä tätä tuskallista asiaa."

Toinen keskeinen osa SRE-roolia on jotain, jota kutsutaan julkaisutekniikaksi, johon sisältyy parhaiden käytäntöjen määritteleminen ohjelmistojulkaisujen johdonmukaisuuden ja toistettavuuden varmistamiseksi.

"Julkaisuinsinööreillä on vankka (ellei asiantuntija) käsitys lähdekoodien hallinnasta, kääntäjistä, koontikokoonpanokielistä, automatisoiduista rakennustyökaluista, pakettien hallintaohjelmista ja asentajista. Heidän taitopaketti sisältää perusteellisen tietämyksen useista toimialueista: kehityksestä, kokoonpanon hallinnasta, testien integroinnista, järjestelmän hallinnosta ja asiakastukesta ", kirjoitti Googlen tekninen ohjelmapäällikkö Dinah McNutt Sivuston luotettavuuden suunnittelu (julkaisija O’Reilly vuonna 2016 ja kirjoittaneet Googler-työntekijät Jennifer Petoff, Niall Richard Murphy, Chris Jones ja Betsy Beyer).

Sitten on roolin vastausosa, johon kuuluu hälytys, päivystys ja vianetsintä sekä hätätilanteisiin ja tapahtumiin reagoiminen sekä kuolemantapaukset.

Pohjimmiltaan on tärkeää, että SRE: t osaavat parhaiten seurata järjestelmiä ja reagoida, kun asiat menevät pieleen, kirjoittamalla ja kirjoittamalla jatkuvasti vastauskirjoja, jotta lyhennetään mahdollisten vikojen korjaamiseen kuluvaa aikaa. Googlessa tähän liittyy tapahtuman dokumentointi, kaikkien mukana olevien perimmäisten syiden ymmärtäminen ja tulevien ennaltaehkäisevien toimien toteuttaminen.

"Jälkikuoleman kirjoittaminen ei ole rangaistus - se on koko yrityksen oppimismahdollisuus", kirjoittavat Googlen työntekijät John Lunney ja Sue Lueder Sivuston luotettavuuden suunnittelu kirja.

[Myös: 3 vaihetta ketterien menetelmien soveltamiseen IT-toiminnassa]

SRE: t vs. devops-insinöörit

Tiedän mitä ajattelet. Kaikki tämä kuulostaa paljon devopsilta, mutta terminologian osalta SRE-työnimike on ennen insinööriä jo ennestään noin viidellä vuodella.

Molemmat perustuvat samankaltaisiin periaatteisiin, mutta ero on sekä hienovarainen että tärkeä. Molempiin toimintatapoihin kuuluu esteiden purkaminen kehittäjien ja käyttöhenkilöstön välillä, ja molemmilla pyritään lisäämään kehitystiimien nopeutta pitäen yllä näiden palveluiden ydinjoustavuutta.

Tärkein ero on se, että devops-insinöörit keskittyvät yleensä jatkuvan toimituksen ja kehittäjien nopeuden tukemiseen, kun taas SRE: t ottavat vastuun luotettavuudesta ja automatisoitumisesta koko ohjelmiston elinkaaren ajan. Painopiste on julkaisujen onnistuneessa käyttöönotossa ja seurannassa sekä ohjelmistojen määrittelemän infrastruktuurin humisemisessa. SRE: llä on kiinteä tehtävä laajemmassa suunnittelutiimissä: varmistaa, että pöydässä on asiantuntijapaikka, joka keskittyy vakaiden järjestelmien rakentamiseen.

Kuten Jayne Groll The Devops -instituutista sanoo: “Devops keskittyy jatkuvaan suunnitteluun käyttöönottopisteeseen asti; SRE keskittyy jatkuvaan suunnitteluun asiakkaiden kulutushetkellä. "

SRE: n historia Googlessa

SRE-periaatteiden jäljittäminen niiden alkuperään Googlessa 2000-luvun alkupuolella tarjoaa keskeisen kohteen oppitunnin kurinalaisuudessa.

"Kun tulin Googleen, minulla oli onni olla osa tiimiä, joka koostui osittain ihmisistä, jotka olivat ohjelmistoinsinöörejä ja jotka olivat taipuvaisia ​​käyttämään ohjelmistoja tapana ratkaista ongelmat, jotka oli historiallisesti ratkaistu käsin. Joten kun oli aika muodostaa virallinen tiimi tämän operatiivisen työn suorittamiseksi, oli luonnollista käyttää lähestymistapaa "kaikkea voidaan pitää ohjelmisto-ongelmana" ja ajaa sen kanssa ", Ben Treynor totesi haastattelussa Googlen sisäisessä blogissa.

"Joten SRE tekee pohjimmiltaan työtä, jonka historiallisesti on tehnyt operatiivinen työryhmä, mutta käyttää insinöörejä, joilla on ohjelmisto-asiantuntemusta ja pankki, siitä, että nämä insinöörit ovat luonnostaan ​​taipuvaisia ​​korvaamaan automaation ihmisen työvoimalla ja kykenevät siihen, ”Lisää Treynor.

Google ajattelee myös melko tiukasti SRE-ryhmän kokoonpanoa. Kaikkien Google SRE: ien on oltava joko Google-ohjelmistosuunnittelijoita tai "ehdokkaita, jotka ovat hyvin lähellä Google-ohjelmistotekniikan pätevyyttä" Heillä on oltava myös infrastruktuurin hallinnan taidot, yleisimmin "Unix-järjestelmän sisäiset ja verkostoitumisosaaminen (kerrokset 1 - kerros 3)".

SRE-pätevyydet vaihtelevat edelleen yrityksittäin, mutta perusperiaatteiden mukaan Google-lähestymistapa on vankka lähtökohta. Yksityiskohdat riippuvat yrityksen tarpeista, vakiintuneista prosesseista ja organisaation jo hyväksymästä tekniikkapinosta.

SRE-työn kuvaus ja palkka

SRE: t käyttävät yleensä noin 50 prosenttia ajastaan ​​perinteisten toimintojen suorittamiseen, kuten päivystykseen ja hyppäämiseen ongelmien ratkaisemiseksi. Loput 50 prosenttia keskittyy ohjelmistojen kehittämiseen, jotta taustalla olevista järjestelmistä tulisi joustavampia, automatisoituneempia ja itsensä parantavia ajan myötä. Siksi rooli vaatii vankan yhdistelmän ohjelmistotekniikan pilkkuja ja toimintataitoja. Hyvä SRE järjestetään, viileä paineen alla ja ongelmanratkaisija. SRE-johtajat vastaavat tiimin suorituskyvystä, strategiasta ja optimoinnista.

Mutta entä organisaatiot, joissa SRE-roolia ei ole olemassa? O'Reilly-raportissa "Mikä on SRE?" Kurt Andersen LinkedInistä ja Craig Sebenik Splitistä (julkaisunhallintaohjelmistotoimittaja) suosittelevat "ruohonjuuritason" lähestymistapaa. He suosittelevat löytävänsä kehitystiimin, joka on motivoitunut vaihtamaan ja toteuttamaan pieni SRE-tiimi (tai yksilö) siellä. Ajan myötä voit käyttää menestystä positiivisena esimerkkinä muille joukkueille. "

SRE: n keskimääräinen vuosipalkka on noin 130 000 dollaria Yhdysvalloissa ja 76 000 puntaa Isossa-Britanniassa, todellakin työmaalla.

SRE-resurssit

Resursseja on runsaasti SRE-taitojen rakentamiseen DevOps-instituutin sertifikaateista O’Reillyn, Microsoftin ja Googlen kirjoihin ja verkkoresursseihin. Edellä mainittu 550-sivuinen behemothSivuston luotettavuuden suunnittelu kirjoittaneet Jennifer Petoff, Niall Richard Murphy, Chris Jones ja Betsy Beyer on aiheen pääkirjoitus, julkaistu vuonna 2016. Kirja on saatavana myös ilmaiseksi Googlelta.

Muita tuoreempia kirjoja aiheesta ovatKoulutuspaikan luotettavuusinsinöörit esittäjät Jennifer Petoff, JC van Winkel ja Preston Yoshioka;Mikä on SRE? esittäjä (t): Kurt Andersen ja Craig Sebenik;Etsitään SREesittäjä (t): David N.Blank-Edelman, jaSivuston luotettavuuden työkirja esittäjät Betsy Beyer, Niall Richard Murphy, David K. Rensin, Kent Kawahara ja Stephen Thorne.

O’Reillyllä on myös kattava kirjasto aiheesta julkaistavasta verkko-omaisuudesta, videoista ja e-kirjoista, joka on kuratoitu kätevästi tähän SRE Essentials -soittolistaan ​​entisen Google-sivuston luotettavuusinsinöörin Liz Fong-Jonesin toimesta.

Online-oppimisen juggernaut Coursera tarjoaa useita kursseja, mukaan lukien suosittu sivuston luotettavuustekniikka: Luotettavuuden mittaaminen ja hallinta Google Cloud Training -sivustolta. Tämä kurssi on saatavana myös Pluralsightilta, samoin kuin aloittelijakurssi Site Reliability Engineering (SRE): Elton Stonemanin suuri kuva. Linux-säätiö tarjoaa itseohjatun kurssin nimeltä DevOps and SRE Fundamentals: Implementing Continuous Delivery.

Isossa-Britanniassa sijaitseva meduusan koulutus tarjoaa useita kahden päivän yksityisiä kurssivaihtoehtoja SRE Foundationille (SREF).

Lue lisää devopsista

  • Mikä on devops? Ohjelmistokehityksen muutos
  • 3 tapaa aloittaa devops-ohjelma
  • Hyviä käytäntöjä: Viisi menetelmää, jotka sinun tulisi ottaa käyttöön
  • 15 KPI: tä seuraamaan devops-muunnosta
  • Sovellusten valvonta: Mitä devops voi tehdä paremmin
  • Missä sivuston luotettavuustekniikka kohtaa devopsia
  • Viisi periaatetta tulla ketteräksi yhteistyötiimiksi
  • 3 vaihetta ketterien menetelmien soveltamiseen IT-toiminnassa
  • Kuinka ketterät tiimit voivat tukea tapahtumien hallintaa
  • Kuinka datasopit parantavat dataa, analytiikkaa ja koneoppimista
  • Devopsin soveltaminen datatieteessä ja koneoppimisessa
  • 7 kysymystä priorisoida devops-tilisi
$config[zx-auto] not found$config[zx-overlay] not found