De Webinar huet e schlechten Audio, also hu mir et transkribéiert.
Mäin Numm ass Medvedev Eduard. Haut wäert ech schwätzen iwwer wat SRE ass, wéi SRE erschéngt, wéi eng Aarbechtskriterien SRE Ingenieuren hunn, e bëssen iwwer Zouverlässegkeetskriterien, e bëssen iwwer seng Iwwerwaachung. Mir wäerten op d'Spëtze goen, well Dir kënnt net vill an enger Stonn soen, awer ech ginn Material fir zousätzlech Bewäertung, a mir waarden all op Iech . zu Moskau Enn Januar.
Als éischt schwätze mer iwwer wat SRE ass - Site Reliability Engineering. A wéi et als getrennte Positioun erschéngt, als separat Richtung. Et huet alles ugefaang mat der Tatsaach datt an traditionellen Entwécklungskreesser, Dev an Ops zwee komplett verschidden Équipen sinn, normalerweis mat zwee komplett verschidden Ziler. D'Zil vum Entwécklungsteam ass nei Features auszerollen an d'Bedierfnesser vum Geschäft z'erreechen. D'Zil vum Ops Team ass sécherzestellen datt alles funktionnéiert an näischt brécht. Natierlech widdersprécht dës Ziler direkt géigesäiteg: fir datt alles funktionnéiert an näischt ze briechen, nei Features sou mann wéi méiglech ausrollen. Dofir ginn et vill intern Konflikter déi d'Methodologie déi elo DevOps genannt gëtt probéiert ze léisen.
De Problem ass datt mir keng kloer Definitioun vun DevOps hunn an eng kloer Ëmsetzung vun DevOps. Ech hunn virun 2 Joer op enger Konferenz zu Jekaterinburg geschwat, a bis elo huet d'DevOps Sektioun mam Bericht "Wat ass DevOps" ugefaang. Am Joer 2017 ass Devops bal 10 Joer al, awer mir streiden nach ëmmer wat et ass. An dëst ass eng ganz komesch Situatioun déi Google virun e puer Joer probéiert huet ze léisen.
Am Joer 2016 huet Google e Buch verëffentlecht mam Numm Site Reliability Engineering. An tatsächlech war et mat dësem Buch datt d'SRE Bewegung ugefaang huet. SRE ass eng spezifesch Implementatioun vum DevOps Paradigma an enger spezifescher Firma. SRE Ingenieuren engagéieren sech dofir ze garantéieren datt Systemer zouverlässeg funktionnéieren. Si kommen meeschtens vun Entwéckler, heiansdo vun Administrateuren mat engem staarken Entwécklungshintergrund. A si maachen wat d'Systemadministrateuren benotzt hunn, awer e staarken Hannergrond an der Entwécklung a Wëssen vum System a punkto Code féiert zu der Tatsaach, datt dës Leit net zu Routine administrativ Aarbecht geneigt sinn, awer zu Automatiséierung geneigt sinn.
Et stellt sech eraus datt den DevOps Paradigma an SRE Teams ëmgesat gëtt duerch d'Tatsaach datt et SRE Ingenieuren sinn déi strukturell Probleemer léisen. Hei ass et, déiselwecht Verbindung tëscht Dev an Ops, iwwer déi d'Leit zënter 8 Joer geschwat hunn. D'Roll vun engem SRE ass ähnlech wéi déi vun engem Architekt an deem Newcomer net SREs ginn. Leit um Ufank vun hirer Carrière hunn nach keng Erfahrung, hunn net déi néideg Breet vun Wëssen. Well SRE erfuerdert e ganz subtile Wësse vu genau wat a wéini genau falsch ka goen. Dofir ass e puer Erfahrung hei néideg, an der Regel, souwuel bannen a baussen.
Si froen ob den Ënnerscheed tëscht SRE an Devops beschriwwe gëtt. Si ass just beschriwwe ginn. Mir kënnen iwwer d'Plaz vum SRE an der Organisatioun schwätzen. Am Géigesaz zu dëser klassescher DevOps Approche, wou Ops nach ëmmer eng separat Departement ass, ass SRE Deel vum Entwécklungsteam. Si sinn an der Produktentwécklung involvéiert. Et gëtt souguer eng Approche wou SRE eng Roll ass déi vun engem Entwéckler op en aneren iwwergëtt. Si huelen un Code Bewäertungen deel wéi zum Beispill UX Designer, Entwéckler selwer, heiansdo Produktmanager. SREs schaffen um selwechten Niveau. Mir mussen se approuvéieren, mir mussen se iwwerpréiwen, sou datt fir all Deployment SRE seet: "Okay, dës Deployment, dëst Produkt wäert d'Zouverlässegkeet net negativ beaflossen. A wann et geschitt, dann bannent e puer akzeptable Grenzen. Mir wäerten och doriwwer schwätzen.
Deementspriechend huet de SRE e Veto fir de Code z'änneren. An allgemeng féiert dat och zu enger Aart vu klenge Konflikt, wann de SRE falsch ëmgesat gëtt. Am selwechte Buch iwwer Site Reliability Engineering, vill Deeler, net emol een, erzielen wéi dës Konflikter ze vermeiden.
Si froe wéi d'SRE sech mat der Informatiounssécherheet verhält. SRE ass net direkt an Informatiounssécherheet involvéiert. Prinzipiell, a grousse Firmen, gëtt dëst vun Individuen, Tester, Analysten gemaach. Awer SRE interagéiert och mat hinnen am Sënn datt e puer Operatiounen, e puer engagéiert, e puer Détachementer, déi d'Sécherheet beaflossen, kënnen och d'Disponibilitéit vum Produkt beaflossen. Dofir huet SRE als Ganzt Interaktioun mat all Teams, dorënner Sécherheetsteams, och Analysten. Dofir sinn SREs haaptsächlech gebraucht wa se probéieren DevOps ëmzesetzen, awer zur selwechter Zäit gëtt d'Belaaschtung op d'Entwéckler ze grouss. Dat ass, d'Entwécklungsteam selwer kann net méi mat der Tatsaach eens ginn datt se elo och fir Ops verantwortlech sinn. An et gëtt eng separat Roll. Dës Roll ass am Budget geplangt. Heiansdo gëtt dës Roll an der Gréisst vum Team festgeluecht, eng separat Persoun erschéngt, heiansdo gëtt et ee vun den Entwéckler. Esou erschéngt den éischte SRE an der Equipe.
D'Komplexitéit vum System, dee vum SRE beaflosst ass, d'Komplexitéit déi d'Zouverlässegkeet vun der Operatioun beaflosst, ass néideg an zoufälleg. Noutwendeg Komplexitéit ass wann d'Komplexitéit vun engem Produkt eropgeet an d'Ausmooss erfuerderlech vun neie Produktfeatures. Zoufälleg Komplexitéit ass wann d'Komplexitéit vum System eropgeet, awer d'Produkt Feature an d'Geschäftsufuerderunge beaflossen dëst net direkt. Et stellt sech eraus datt entweder den Entwéckler iergendwou e Feeler gemaach huet, oder den Algorithmus ass net optimal, oder e puer zousätzlech Interesse ginn agefouert, déi d'Komplexitéit vum Produkt ouni spezielle Besoin erhéijen. E gudde SRE sollt ëmmer dës Situatioun ofschneiden. Dat ass, all Engagement, all Deployment, all Pull Ufro, wou d'Schwieregkeet erhéicht gëtt wéinst zoufälleger Zousatz, sollt blockéiert ginn.
D'Fro ass firwat net nëmmen en Ingenieur, e Systemadministrator mat vill Wëssen an d'Team astellen. En Entwéckler an der Roll vun engem Ingenieur, mir soen, ass net déi bescht Personalléisung. En Entwéckler an der Roll vun engem Ingenieur ass net ëmmer déi bescht Personalléisung, awer de Punkt hei ass datt en Entwéckler, deen an Ops engagéiert ass, e bësse méi Wonsch fir Automatisatioun huet, e bësse méi Wëssen an e Fäegkeetsset huet fir ëmzesetzen dëser Automatisatioun. An deementspriechend reduzéieren mir net nëmmen d'Zäit fir e puer spezifesch Operatiounen, net nëmmen d'Routine, awer och sou wichteg Geschäftsparameter wéi MTTR (Mean Time To Recovery, Recovery Time). Sou, a mir wäerten och e bësse méi spéit doriwwer schwätzen, mir spuere Suen fir d'Organisatioun.
Loosst eis elo iwwer d'Critèrë fir d'Operatioun vum SRE schwätzen. An als éischt iwwer Zouverlässegkeet. A klenge Firmen, Startups, geschitt et dacks datt d'Leit dovun ausgoen datt wann de Service gutt geschriwwen ass, wann de Produit gutt a korrekt geschriwwe gëtt, et funktionnéiert, et wäert net briechen. Dat ass et, mir schreiwen gudde Code, sou datt et näischt ze briechen ass. De Code ass ganz einfach, et gëtt näischt ze briechen. Dëst sinn ongeféier déiselwecht Leit déi soen datt mir keng Tester brauchen, well, kuckt, dat sinn déi dräi VPI Methoden, firwat briechen hei.
Dëst ass natierlech alles falsch. An dës Leit sinn ganz oft vun esou Code an der Praxis gebass gin, well Saachen Paus. D'Saachen briechen heiansdo op déi onberechenbarste Weeër. Heiansdo soen d'Leit nee, et wäert ni geschéien. An et geschitt déi ganzen Zäit. Et geschitt dacks genuch. An dofir strieft keen jee no 100% Disponibilitéit, well 100% Disponibilitéit geschitt ni. Dëst ass d'Norm. An dofir, wa mir iwwer d'Disponibilitéit vun engem Service schwätzen, schwätze mir ëmmer vun Néng. 2 Néng, 3 Néng, 4 Néng, 5 Néng. Wa mir dat an Ausdauer iwwersetzen, dann zum Beispill 5 Néngen, dann sinn dat e bësse méi wéi 5 Minutte Stéierungen pro Joer, 2 Néng sinn 3,5 Deeg Stéierungen.
Awer et ass offensichtlech datt iergendwann eng Ofsenkung vum POI ass, Rendement op Investitioun. Vun zwee Néng op dräi Néng ze goen heescht manner Ausdauer ëm méi wéi 3 Deeg. Wann Dir vu véier Néng op fënnef geet, reduzéiert d'Downtime ëm 47 Minutten pro Joer. An et stellt sech eraus datt et fir d'Geschäft vläicht net kritesch ass. An am allgemengen ass déi erfuerderlech Zouverlässegkeet keen techneschen Thema, als éischt ass et e Business Thema, et ass e Produktprobleem. Wat Niveau vun Ënnerbriechung ass akzeptabel fir Benotzer vum Produit, wat se erwaarden, wéi vill se bezuelen, zum Beispill, wéi vill Suen si verléieren, wéi vill Suen de System verléiert.
Eng wichteg Fro hei ass wat d'Zouverlässegkeet vun de Rescht Komponente ass. Well den Ënnerscheed tëscht 4 a 5 Néng gëtt net op engem Smartphone mat 2 Nénger Zouverlässegkeet ze gesinn. Grof geschwat, wann eppes op engem Smartphone an Ärem Service 10 Mol am Joer brécht, ass héchstwahrscheinlech 8 Mol den Decompte op der OS Säit geschitt. De Benotzer ass dat gewinnt a wäert net op eng Kéier am Joer oppassen. Et ass noutwendeg fir de Präis vun der Erhéijung vun der Zouverlässegkeet an der Erhéijung vun de Gewënn ze korreléieren.
Just am Buch iwwer SRE gëtt et e gutt Beispill fir op 4 Néng vun 3 Néng ze erhéijen. Et stellt sech eraus datt d'Erhéijung vun der Disponibilitéit e bësse manner wéi 0,1% ass. A wann d'Recetten vum Service $ 1 Millioun pro Joer ass, dann ass d'Erhéijung vun de Recetten $ 900. Wann et eis manner wéi $ 900 d'Joer kascht fir d'Bezuelbarkeet ëm eng néng ze erhéijen, mécht d'Erhéijung finanziell Sënn. Wann et méi wéi 900 Dollar pro Joer kascht, mécht et net méi Sënn, well d'Erhéijung vun de Recetten einfach net fir d'Aarbechtskäschte kompenséiert, d'Ressourcekäschten. An 3 Néng wäerten eis duergoen.
Dëst ass natierlech e vereinfacht Beispill wou all Ufroe gläich sinn. A vun 3 Néng op 4 Néng ze goen ass einfach genuch, awer gläichzäiteg, zum Beispill, vun 2 Néng op 3 goen, ass dëst schonn e Spuer vun 9 dausend Dollar, et kann finanziell Sënn maachen. Natierlech, a Wierklechkeet, ass den Echec vun der Ufro vun der Umeldung méi schlëmm wéi den Echec fir d'Säit ze weisen, Ufroe hunn ënnerschiddlech Gewiichter. Si kënnen e ganz anere Critère aus enger geschäftlecher Siicht hunn, awer iwwerhaapt, als Regel, wa mir net iwwer e puer spezifesch Servicer schwätzen, ass dat eng zimlech zouverléisseg Approximatioun.
Mir kruten eng Fro, ob SRE ee vun de Koordinateuren ass bei der Auswiel vun enger architektonescher Léisung fir de Service. Loosst eis soen wat d'Integratioun an déi bestehend Infrastruktur ugeet, sou datt et kee Verloscht u senger Stabilitéit gëtt. Jo, SREs, op déiselwecht Manéier wéi d'Ufroen, engagéiert, Verëffentlechungen beaflossen d'Architektur, d'Aféierung vun neie Servicer, Mikroservicer, d'Ëmsetzung vun neie Léisungen. Firwat hunn ech virdru gesot datt d'Erfahrung gebraucht gëtt, Qualifikatiounen sinn néideg. Tatsächlech ass SRE eng vun de blockéierende Stëmmen an all architektonescher a Softwareléisung. Deementspriechend muss en SRE als Ingenieur als éischt net nëmmen verstoen, mee och verstoen wéi e puer spezifesch Entscheedungen d'Zouverlässegkeet, d'Stabilitéit beaflossen, a verstoen wéi dëst mat de Geschäftsbedürfnisser bezunn ass, a vu wéi enger Siicht et akzeptabel ass an déi net.
Dofir kënne mir elo just iwwer Zouverlässegkeetskriterien schwätzen, déi traditionell am SRE als SLA (Service Level Agreement) definéiert sinn. Wahrscheinlech e vertraute Begrëff. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement ass vläicht e symbolesche Begrëff, besonnesch wann Dir mat Netzwierker geschafft hutt, mat Ubidder, mat Hosting. Dëst ass en allgemengen Accord deen d'Leeschtung vun Ärem ganze Service beschreift, Strofe, e puer Strofe fir Feeler, Metriken, Critèren. An SLI ass d'Disponibilitéitsmetrik selwer. Dat ass, wat SLI ka sinn: Äntwertzäit vum Service, d'Zuel vun de Feeler als Prozentsaz. Et kéint Bandbreedung sinn wann et eng Zort Dateihosting ass. Wann et ëm d'Unerkennung Algorithmen kënnt, kann den Indikator zum Beispill och d'Richtegkeet vun der Äntwert sinn. SLO (Service Level Objective) ass, respektiv, eng Kombinatioun vum SLI Indikator, säi Wäert an d'Period.
Loosst eis soen datt den SLA esou kéint sinn. De Service ass verfügbar 99,95% vun der Zäit d'ganzt Joer. Oder 99 kritesch Support Ticketen ginn bannent 3 Stonnen pro Véierel zougemaach. Oder 85% vun den Ufroe kréien Äntwerte bannent 1,5 Sekonnen all Mount. Dat ass, mir kommen no an no ze verstoen datt Feeler a Feeler ganz normal sinn. Dat ass eng akzeptabel Situatioun, mir plangen se, mir zielen esouguer zu engem gewësse Mooss drop. Dat ass, SRE baut Systemer déi Feeler maache kënnen, déi normalerweis op Feeler reagéiere mussen, déi se berücksichtegen mussen. A wa méiglech, solle se Fehler esou behandelen datt de Benotzer se entweder net bemierkt oder bemierkt, awer et gëtt eng Aart vu Léisung, dank deem alles net komplett erofgefall ass.
Zum Beispill, wann Dir e Video op YouTube eropluet, an YouTube kann et net direkt konvertéieren, wann de Video ze grouss ass, wann de Format net optimal ass, da wäert d'Ufro natierlech net mat engem Timeout falen, YouTube gëtt keen 502 Feeler , YouTube wäert soen: "Mir hunn alles erstallt, Äre Video gëtt veraarbecht. Et wäert an ongeféier 10 Minutten fäerdeg sinn." Dëst ass de Prinzip vun der graziéiser Degradatioun, déi vertraut ass, zum Beispill, vu Frontend Entwécklung, wann Dir dat jeemools gemaach hutt.
Déi nächst Begrëffer, iwwer déi mir schwätzen, déi ganz wichteg si fir mat Zouverlässegkeet ze schaffen, mat Feeler, mat Erwaardungen, sinn MTBF an MTTR. MTBF ass déi mëttlere Zäit tëscht Feeler. MTTR Moyenne Zäit fir Erhuelung, duerchschnëttlech Zäit fir Erhuelung. Dat ass, wéi vill Zäit ass vergaangen aus dem Moment wou de Feeler entdeckt gouf, vum Moment wou de Feeler erschéngt bis de Moment wou de Service op voll normal Operatioun restauréiert gouf. MTBF ass haaptsächlech fixéiert duerch Aarbecht op Codequalitéit. Dat ass, de Fait datt SREs "nee" kënne soen. An Dir braucht e Versteesdemech vun der ganzer Equipe datt wann SRE seet "nee", hien seet et net well hien schiedlech ass, net well hien schlecht ass, mee well soss jiddereen wäert leiden.
Erëm, et gi vill Artikelen, vill Methoden, vill Weeër souguer am ganz Buch, op dat ech sou dacks bezéien, wéi sécherzestellen datt aner Entwéckler net ufänken SRE ze haassen. MTTR, op der anerer Säit, ass iwwer Är SLOs (Service Level Objective) ze schaffen. An et ass meeschtens Automatisatioun. Well zum Beispill eise SLO eng Uptime vu 4 Néng pro Véierel ass. Dëst bedeit datt mir an 3 Méint 13 Minutte Standzäit erlaben. An et stellt sech eraus datt MTTR net méi wéi 13 Minutten ka sinn. Wa mir op mindestens 13 Ausdauer an 1 Minutten reagéieren, heescht dat, datt mir de ganze Budget fir de Véierel schonn ausgesat hunn. Mir briechen de SLO. 13 Minutte fir e Crash ze reagéieren an ze fixéieren ass vill fir eng Maschinn, awer ganz kuerz fir e Mënsch. Well bis eng Persoun eng Alarm kritt, bis hien reagéiert, bis hien de Feeler versteet, sinn et schonn e puer Minutten. Bis eng Persoun versteet wéi et ze fixéieren, wat genee ze fixéieren, wat ze maachen, dann ass et e puer Minutten méi. An Tatsaach, och wann Dir just de Server Reouverture braucht, wéi et sech erausstellt, oder en neien Node erhéijen, dann manuell MTTR ass schonn ongeféier 7-8 Minutten. Wann de Prozess automatiséiert gëtt, erreecht MTTR ganz dacks eng zweet, heiansdo Millisekonnen. Google schwätzt normalerweis iwwer Millisekonnen, awer a Wierklechkeet ass natierlech alles net sou gutt.
Idealerweis sollt de SRE seng Aarbecht bal komplett automatiséieren, well dëst direkt den MTTR, seng Metriken, den SLO vum ganze Service beaflosst, an deementspriechend de Geschäftsgewënn. Wann d'Zäit iwwerschratt ass, gi mir gefrot ob SRE Schold ass. Glécklecherweis ass kee Schold. An dëst ass eng separat Kultur genannt balmeless postmortem, iwwer déi mir haut net schwätzen, awer mir analyséieren et op Slurm. Dëst ass e ganz interessant Thema iwwer dat vill geschwat ka ginn. Grof geschwat, wann déi zougewisen Zäit pro Véierel iwwerschratt gëtt, dann ass e bëssen u jidderengem Schold, dat heescht, datt jidderengem ze blaméieren ass net produktiv, loosst eis amplaz vläicht kengem Schold maachen, mä d'Situatioun korrigéieren a mat deem schaffen, wat mir hunn. A menger Erfahrung ass dës Approche e bëssen friem fir déi meescht Teams, besonnesch a Russland, awer et mécht Sënn a funktionnéiert ganz gutt. Dofir wäert ech um Enn vum Artikel a Literatur recommandéieren, déi Dir iwwer dëst Thema liesen kann. Oder kommt op Slurm SRE.
Loosst mech erklären. Wann d'SLO Zäit pro Véierel iwwerschratt ass, wann d'Downtime net 13 Minutten war, awer 15, wien kann dofir Schold sinn? Natierlech kann SRE Schold sinn, well hien kloer eng Aart vu schlechten Engagement oder Deployment gemaach huet. Den Administrateur vum Datenzenter kann dofir schëlleg sinn, well hien eventuell eng Aart vun ongeplangten Ënnerhalt gemaach huet. Wann den Administrateur vum Datenzenter dofir Schold ass, dann ass d'Persoun vun Ops dofir Schold, déi den Ënnerhalt net berechent huet wéi hien de SLO koordinéiert huet. De Manager, den techneschen Direkter oder een deen den Datenzentervertrag ënnerschriwwen huet an net op d'Tatsaach opgepasst huet datt d'SLA vum Rechenzentrum net fir déi erfuerderlech Downtime entworf ass, ass dofir Schold. Deementspriechend sinn all lues a lues an dëser Situatioun Schold. An et heescht, datt et kee Sënn huet fir iergendeen an dëser Situatioun d'Schold ze leeën. Mä et muss natierlech korrigéiert ginn. Dofir ginn et Postmortem. A wann Dir zum Beispill GitHub Postmortems liest, an dëst ass ëmmer eng ganz interessant, kleng an onerwaart Geschicht an all spezifesche Fall, kënnt Dir ersetzen datt kee jee seet datt dës speziell Persoun Schold war. D'Schold gëtt ëmmer op spezifesch imperfekte Prozesser geluecht.
Loosst eis op déi nächst Fro goen. Automatisatioun. Wann ech iwwer Automatiséierung an anere Kontexter schwätzen, bezéien ech dacks op eng Tabell déi Iech seet wéi laang Dir un der Automatiséierung vun enger Aufgab schaffe kënnt ouni méi Zäit ze huelen fir se ze automatiséieren wéi Dir tatsächlech spuert. Et gëtt e Knascht. De Fang ass datt wann SREs eng Aufgab automatiséieren, se spueren net nëmmen Zäit, se spuere Suen, well d'Automatisatioun direkt MTTR beaflosst. Si spuere souzesoen d'Moral vun de Mataarbechter an Entwéckler, déi och eng ustrengend Ressource ass. Si reduzéieren d'Routine. An all dat huet e positiven Effekt op d'Aarbecht an, als Resultat, op d'Geschäft, och wann et schéngt datt d'Automatisatioun net Sënn mécht wat d'Zäitkäschte ugeet.
Tatsächlech huet et bal ëmmer, an et gi ganz wéineg Fäll wou eppes net an der Roll vum SRE automatiséiert soll ginn. Als nächst wäerte mir schwätzen iwwer dat wat de Feelerbudget genannt gëtt, de Budget fir Feeler. Tatsächlech stellt sech eraus datt wann alles vill besser fir Iech ass wéi de SLO deen Dir Iech selwer gesat hutt, dat ass och net ganz gutt. Dëst ass éischter schlecht, well SLO funktionnéiert net nëmmen als ënneschten, awer och als ongeféieren Uewergrenz. Wann Dir Iech e SLO vun 99% Disponibilitéit, an Tatsaach, hutt Dir 99,99%, et stellt sech eraus, datt Dir e puer Plaz fir Experimenter hunn, datt d'Geschäft guer net schueden wäert, well Dir selwer dëst all zesummen bestëmmt, an Dir sidd dësem Raum net benotzen. Dir hutt e Budget fir Feeler, déi an Ärem Fall net benotzt ginn.
Wat maache mir domat. Mir benotzen et fir wuertwiertlech alles. Fir Testen a Produktiounsbedingungen, fir nei Fonctiounen auszerollen déi d'Performance beaflosse kënnen, fir Verëffentlechungen, fir Ënnerhalt, fir geplangte Stéierungen. Déi ëmgedréint Regel gëllt och: Wann de Budget ausgespillt ass, kënne mir näischt Neies erausginn, well soss iwwerschreiden mir de SLO. De Budget ass schonn ausgespillt, mir hunn eppes fräigelooss wann et d'Leeschtung negativ beaflosst, dat heescht, wann dat net eng Aart vu Fix ass, déi u sech direkt den SLO erhéicht, da gi mer iwwer de Budget eraus, an dat ass eng schlecht Situatioun , et muss analyséiert ginn, postmortem, an eventuell e puer Prozess Fixen.
Dat ass, et stellt sech eraus datt wann de Service selwer net gutt funktionnéiert, an de SLO gëtt ausginn an de Budget ass net op Experimenter, net op e puer Verëffentlechungen, awer eleng, anstatt e puer interessant Fixen, anstatt interessant Features, amplaz interessant Verëffentlechungen. Amplaz vun enger kreativer Aarbecht, musst Dir mat domm Fixen ze dinn hunn, fir de Budget erëm an d'Rei ze kréien, oder den SLO z'änneren, an dat ass och e Prozess deen net ze dacks sollt geschéien.
Dofir stellt sech eraus datt an enger Situatioun wou mir méi Budget fir Feeler hunn, jiddereen interesséiert ass: souwuel SRE an Entwéckler. Fir Entwéckler bedeit e grousse Budget fir Bugs datt Dir mat Verëffentlechungen, Tester, Experimenter këmmere kënnt. Fir SREs, e Budget fir Feeler an de Budget anzeginn bedeit datt se direkt hir Aarbecht gutt maachen. An dat beaflosst d'Motivatioun vun enger Aart vu gemeinsamer Aarbecht. Wann Dir op Är SREs als Entwéckler lauschtert, hutt Dir méi Plaz fir gutt Aarbecht a vill manner Routine.
Et stellt sech eraus datt Experimenter an der Produktioun zimmlech e wichtege a bal integralen Deel vum SRE a groussen Teams sinn. An et gëtt normalerweis Chaos Engineering genannt, wat vun der Team bei Netflix kënnt, déi en Utility mam Numm Chaos Monkey verëffentlecht huet.
Chaos Monkey verbënnt mat der CI / CD Pipeline an zerstéiert de Server an der Produktioun zoufälleg. Nach eng Kéier, an der SRE Struktur schwätze mir iwwer d'Tatsaach datt en erofgefallen Server an sech selwer net schlecht ass, et gëtt erwaart. A wann et am Budget ass, ass et akzeptabel a schued net dem Geschäft. Natierlech huet Netflix genuch iwwerflësseg Serveren, genuch Replikatioun, sou datt dat alles fixéiert ka ginn, a fir datt de Benotzer als Ganzt net emol bemierkt, an nach méi datt keen ee Server fir all Budget léisst.
Netflix hat eng ganz Suite vun esou Utilities fir eng Zäit, ee vun deenen, Chaos Gorilla, schléisst eng vun den Amazon Disponibilitéitszonen komplett aus. An esou Saache hëllefe fir éischtens verstoppte Ofhängegkeeten opzeweisen, wann et net ganz kloer ass, wat beaflosst wat, wat hänkt vu wat of. An dëst, wann Dir mat engem Mikroservice schafft, an d'Dokumentatioun ass net ganz perfekt, kann dëst Iech vertraut sinn. An nach eng Kéier, dëst hëlleft vill Feeler am Code ze fangen, déi Dir net op Inszenéiere kënnt, well all Inszenéierung net genau eng exakt Simulatioun ass, wéinst der Tatsaach datt d'Laascht Skala anescht ass, d'Laaschtmuster ass anescht, d'Ausrüstung ass och, wahrscheinlech, aner. Peak Lasten kënnen och onerwaart an onberechenbar sinn. An esou Testen, déi erëm net iwwer de Budget geet, hëlleft ganz gutt fir Feeler an der Infrastruktur ze fangen, déi d'Inszenéierung, Autotesten, CI / CD Pipeline ni fangen. A soulaang et alles an Ärem Budget abegraff ass, ass et egal datt Äre Service do erofgaang ass, obwuel et ganz grujeleg wier, ass de Server erofgaang, wat en Albtraum. Nee, dat ass normal, dat ass gutt, dat hëlleft Käfere ze fangen. Wann Dir e Budget hutt, da kënnt Dir et ausginn.
Q: Wéi eng Literatur kann ech recommandéieren? Lëscht um Enn. Et gëtt vill Literatur, ech roden e puer Berichter. Wéi funktionnéiert et, a funktionnéiert SRE a Firmen ouni eegene Softwareprodukt oder mat minimaler Entwécklung. Zum Beispill, an enger Entreprise wou d'Haaptaktivitéit net Software ass. An enger Entreprise, wou d'Haaptaktivitéit net Software ass, funktionnéiert SRE genee d'selwecht wéi iwwerall soss, well an enger Entreprise musst Dir och Softwareprodukter benotzen, och wann net entwéckelt, Dir musst Updates ausrollen, Dir musst änneren d'Infrastruktur, Dir musst wuessen, Dir musst Skala. A SREs hëllefen méiglech Problemer an dëse Prozesser z'identifizéieren an virauszesoen a kontrolléieren hinnen no e puer Wuesstem fänkt a Betrib Besoinen änneren. Well et absolut net néideg ass an der Softwareentwécklung involvéiert ze sinn fir e SRE ze hunn wann Dir op d'mannst e puer Serveren hutt an Dir gëtt erwaart op d'mannst e Wuesstum ze hunn.
Datselwecht gëlt fir kleng Projeten, kleng Organisatiounen, well grouss Firmen de Budget an de Raum hunn fir ze experimentéieren. Awer gläichzäiteg kënnen all dës Uebst vun Experimenter iwwerall benotzt ginn, dat ass, SRE, natierlech, erschéngt op Google, an Netflix, an Dropbox. Awer gläichzäiteg kënne kleng Firmen a Startups scho kondenséiert Material liesen, Bicher liesen, Berichter kucken. Si fänken u méi dacks doriwwer ze héieren, si kucken spezifesch Beispiller, ech mengen et ass an der Rei, et kann wierklech nëtzlech sinn, mir brauchen dat och, et ass super.
Dat ass, all d'Haaptaarbechte fir dës Prozesser ze standardiséieren ass scho fir Iech gemaach. Et bleift fir Iech d'Roll vum SRE speziell an Ärer Entreprise ze bestëmmen an unzefänken all dës Praktiken tatsächlech ëmzesetzen, déi, erëm, scho beschriwwe goufen. Dat ass, aus nëtzleche Prinzipien fir kleng Firmen, ass dëst ëmmer d'Definitioun vu SLA, SLI, SLO. Wann Dir net an Software involvéiert sidd, da sinn dës intern SLAen an intern SLOs, en internen Budget fir Feeler. Dëst féiert bal ëmmer zu e puer interessant Diskussiounen am Team an am Geschäft, well et kann erauskommen datt Dir op Infrastruktur verbréngt, op eng Aart Organisatioun vun idealen Prozesser, déi ideal Pipeline ass vill méi wéi néideg. An dës 4 Néng déi Dir am IT Departement hutt, Dir braucht se elo net wierklech. Awer gläichzäiteg kënnt Dir Zäit verbréngen, de Budget fir Feeler op eppes anescht ausginn.
Deementspriechend ass d'Iwwerwaachung an d'Organisatioun vun der Iwwerwaachung nëtzlech fir eng Firma vun all Gréisst. An am Allgemengen, dës Manéier vun denken, wou Feeler eppes akzeptabel sinn, wou et e Budget ass, wou et Ziler sinn, ass et erëm nëtzlech fir eng Firma vun all Gréisst, ugefaange vu Startups fir 3 Leit.
Déi lescht vun den techneschen Nuancen fir ze schwätzen ass Iwwerwaachung. Well wa mir iwwer SLA, SLI, SLO schwätzen, kënne mir ouni Iwwerwaachung net verstoen ob mir an de Budget passen, ob mir eis Ziler entspriechen, a wéi mir den definitiven SLA beaflossen. Ech hunn esou vill Mol gesinn datt d'Iwwerwaachung esou geschitt: et gëtt e Wäert, zum Beispill d'Zäit vun enger Ufro un de Server, d'Duerchschnëttszäit oder d'Zuel vun den Ufroen un d'Datebank. Hien huet e Standard vun engem Ingenieur bestëmmt. Wann d'Metrik vun der Norm ofwäit, da kënnt eng E-Mail. Dëst ass alles absolut nëtzlos, an der Regel, well et zu sou engem Iwwerraschung vun Alarm féiert, e Glut vu Messagen aus der Iwwerwaachung, wann eng Persoun, éischtens, se all Kéier interpretéiere muss, dat heescht, bestëmmen ob de Wäert vun der metrescher Mëttel de Besoin fir eng Aktioun. An zweetens hält hien einfach op all dës Alarmer ze bemierken, wann am Fong keng Handlung vun him verlaangt gëtt. Dat ass eng gutt Iwwerwaachungsregel an déi alleréischt Regel wann SRE ëmgesat gëtt ass datt d'Notifikatioun nëmme sollt kommen wann Handlung erfuerderlech ass.
Am Standardfall sinn et 3 Niveauen vun Eventer. Et ginn Alarmer, et gi Ticketen, et gi Logbicher. Alarmer sinn alles wat Dir erfuerdert fir direkt ze handelen. Dat ass, alles ass gebrach, Dir musst et direkt fixéieren. Ticketen sinn wat verspéiten Aktioun verlaangen. Jo, Dir musst eppes maachen, Dir musst eppes manuell maachen, d'Automatisatioun ass gescheitert, awer Dir musst et net fir déi nächst puer Minutten maachen. Logbicher sinn alles wat keng Handlung erfuerdert, an allgemeng, wann d'Saache gutt goen, wäert keen se jee liesen. Dir braucht nëmmen d'Logbicher ze liesen wann, am Réckbléck, et erausgestallt huet datt eppes fir eng Zäit gebrach ass, mir woussten net doriwwer. Oder braucht Dir e puer Fuerschung ze maachen. Awer am Allgemengen, alles wat keng Handlung erfuerdert, geet an d'Logbicher.
Als Nebenwirkung vun all deem, wa mir definéiert hunn wéi eng Eventer Aktiounen erfuerderen a gutt beschriwwen hunn wat dës Aktiounen solle sinn, heescht dat datt d'Aktioun automatiséiert ka ginn. Dat ass, wat geschitt. Mir ginn aus Alarm. Loosst eis an d'Aktioun goen. Mir ginn op d'Beschreiwung vun dëser Aktioun. An da gi mer op d'Automatisatioun. Dat ass, all Automatisatioun fänkt mat enger Reaktioun op en Event un.
Vun der Iwwerwaachung gi mir weider op e Begrëff genannt Observabilitéit. Et gouf och e bëssen Hype ronderëm dëst Wuert fir déi lescht Joren. A wéineg Leit verstinn wat et aus dem Kontext bedeit. Awer den Haaptpunkt ass datt Observabilitéit eng Metrik fir Systemtransparenz ass. Wann eppes falsch gaang ass, wéi séier kënnt Dir bestëmmen wat genee falsch gaang ass a wéi den Zoustand vum System dee Moment war. Wat de Code ugeet: wéi eng Funktioun ass gescheitert, wéi en Service huet gescheitert. Wat war den Zoustand vun, zum Beispill, intern Verännerlechen, Configuratioun. Wat d'Infrastruktur ugeet, ass dat a wéi enger Disponibilitéitszone de Feeler geschitt ass, a wann Dir Kubernetes hutt, dann a wéi engem Pod de Feeler geschitt ass, wat war den Zoustand vum Pod. An deementspriechend huet d'Observabilitéit eng direkt Relatioun mam MTTR. Wat méi héich d'Observabilitéit vum Service ass, wat et méi einfach ass de Feeler z'identifizéieren, wat et méi einfach ass de Feeler ze fixéieren, wat et méi einfach ass de Feeler ze automatiséieren, wat méi niddereg ass den MTTR.
Fir erëm op kleng Firmen ze goen, ass et ganz heefeg ze froen, och elo, wéi een mat der Teamgréisst ëmgeet, an ob eng kleng Equipe eng separat SRE muss astellen. Schonn e bësse méi fréi doriwwer geschwat. An den éischte Stadien vun der Entwécklung vun engem Startup oder, zum Beispill, engem Team, ass dëst guer net néideg, well SRE kann eng Iwwergangsroll gemaach ginn. An dëst wäert d'Equipe e bëssen erëmbeliewen, well et op d'mannst eng Diversitéit gëtt. A plus et wäert d'Leit op d'Tatsaach virbereeden datt mam Wuesstum am Allgemengen d'Verantwortung vum SRE ganz däitlech änneren. Wann Dir eng Persoun astellen, dann, natierlech, hien huet e puer Erwaardungen. An dës Erwaardungen wäerten net mat der Zäit änneren, awer d'Ufuerderunge wäerte ganz vill änneren. Dofir, wéi en SRE astellen ass zimlech schwéier an de fréie Stadien. Är eege wuessen ass vill méi einfach. Awer et ass derwäert ze denken.
Déi eenzeg Ausnam, vläicht, ass wann et ganz strikt a gutt definéiert Wuesstumsfuerderunge gëtt. Dat ass, am Fall vun engem Startup, kann dëst eng Zort Drock vun Investisseuren ginn, eng Zort Prognose fir Wuesstem puer mol op eemol. Dann eng SRE astellen ass am Fong gerechtfäerdegt well et ka gerechtfäerdegt ginn. Mir hunn Ufuerderunge fir Wuesstem, mir brauche eng Persoun déi verantwortlech ass fir datt mat esou Wuesstem näischt brécht.
Eng Fro méi. Wat maache wann e puer Mol d'Entwéckler eng Feature schneiden déi d'Tester passéiert, awer d'Produktioun brécht, d'Basis lued, brécht aner Features, wéi en Prozess ëmzesetzen. Deementspriechend ass et an dësem Fall de Budget fir Feeler, déi agefouert gëtt. An e puer vun de Servicer, e puer vun de Funktiounen sinn schonn an der Produktioun getest. Et kann Kanaresch sinn, wann nëmmen eng kleng Zuel vu Benotzer, awer schonn an der Produktioun, eng Feature ofgebaut gëtt, awer scho mat der Erwaardung datt wann eppes brécht, zum Beispill fir en halleft Prozent vun all de Benotzer, et wäert nach ëmmer de Budget fir Feeler. Deementspriechend, jo, et gëtt e Feeler, fir e puer Benotzer wäert alles briechen, awer mir hu scho gesot datt dëst normal ass.
Et war eng Fro iwwer SRE Tools. Dat ass, ass et eppes Besonnesch datt SREs géif benotzen, datt all aner net géif. Tatsächlech ginn et e puer héich spezialiséiert Utilities, et gëtt eng Aart vu Software déi zum Beispill Lasten simuléiert oder mat Kanaresch A / B Testen engagéiert. Awer am Fong ass de SRE Toolkit dat wat Är Entwéckler scho benotzen. Well SRE interagéiert direkt mat der Entwécklungsteam. A wann Dir verschidden Tools hutt, wäert et erausstellen datt et Zäit brauch fir ze synchroniséieren. Besonnesch wann SREs a groussen Teams schaffen, a grousse Firmen, wou et e puer Teams kënne sinn, ass et d'Firma-breet Standardiséierung déi hei vill hëlleft, well wann 50 verschidden Utilities a 50 Teams benotzt ginn, heescht dat datt de SRE se muss kennen all. An dat wäert natierlech ni geschéien. An d'Qualitéit vun der Aarbecht, d'Qualitéit vun der Kontroll vun op d'mannst e puer vun den Équipen wäert däitlech erofgoen.
Eise Webinar geet op en Enn. Ech hunn et fäerdeg bruecht e puer grondleeënd Saachen ze soen. Natierlech kann näischt iwwer SRE an enger Stonn gesot a verstane ginn. Mee ech hoffen, datt ech et fäerdeg bruecht hunn dëse Wee vum Denken ze vermëttelen, déi wichtegst Punkten. An da wäert et méiglech sinn, wann Dir interesséiert sidd, an d'Thema ze verdéiwen, eleng ze léieren, kucken wéi et vun anere Leit, an anere Firmen ëmgesat gëtt. An deementspriechend, Ufank Februar, kommt bei eis op Slurm SRE.
De Slurm SRE ass en Dräi-Deeg-Intensivcours, deen iwwer dat schwätzt wat ech elo schwätzen, awer mat vill méi Déift, mat echte Fäll, mat Praxis, ass déi ganz Intensiv op praktesch Aarbecht riicht. D'Leit ginn an Teams opgedeelt. Dir wäert all op real Fäll schaffen. Deementspriechend hu mir Booking.com Instruktoren Ivan Kruglov a Ben Tyler. Mir hunn eng wonnerbar Eugene Barabbas vu Google, vu San Francisco. An ech wäert Iech och eppes soen. Also gitt sécher eis ze besichen.
Also, d'Bibliographie. Et gi Referenzen op SRE. op datselwecht Buch, oder éischter op 2 Bicher iwwer SRE, geschriwwen vu Google. Eng aner , wou d'Konditioune an hir Uwendung liicht méi detailléiert sinn. Déi nächst 3 sinn Berichter iwwer SRE a verschiddene Firmen. Éischten - , Dëst ass e Keynote vum Ben Trainer vu Google. Zweeten - . Déi drëtt ass erëm . Véierte Rapport vun , déi nëmmen 5 Schlëssel SRE Mataarbechter an 190 Länner huet. Et ass ganz interessant dëst alles ze kucken, well sou wéi DevOps ganz aner Saache fir verschidde Firmen a souguer verschidden Teams bedeit, huet SRE ganz aner Verantwortung, och a Firmen vun ähnlechen Gréissten.
2 méi Linken iwwer d'Prinzipien vum Chaos Engineering: , . An um Enn ginn et 3 Lëschten aus der Serie Awesome Lists iwwer , iwwer an iwwer . D'Lëscht op SRE ass onheemlech grouss, et ass net néideg alles duerch ze goen, et sinn ongeféier 200 Artikelen. Ech recommandéieren Artikelen vun do iwwer Kapazitéitsplanung an iwwer blamlos Postmortem.
Interessant Artikel:
Merci fir mech all dës Zäit ze lauschteren. Hoffen Dir hutt eppes geléiert. Hoffen Dir hutt genuch Material fir nach méi ze léieren. A bis gesinn. Hoffentlech am Februar.
De Webinar gouf vum Eduard Medvedev gehost.
PS: fir déi, déi gär liesen, huet den Eduard eng Referenzlëscht ginn. Déi, déi léiwer an der Praxis ze verstoen sinn wëllkomm op .
Source: will.com