Ang webinar ay may mahinang audio, kaya na-transcribe namin ito.
Ang pangalan ko ay Medvedev Eduard. Ngayon ay magsasalita ako tungkol sa kung ano ang SRE, kung paano lumitaw ang SRE, kung anong pamantayan sa trabaho ang mayroon ang mga inhinyero ng SRE, kaunti tungkol sa pamantayan ng pagiging maaasahan, kaunti tungkol sa pagsubaybay nito. Maglalakad kami sa tuktok, dahil wala kang masasabi sa loob ng isang oras, ngunit magbibigay ako ng mga materyales para sa karagdagang pagsusuri, at lahat kami ay naghihintay para sa iyo sa . sa Moscow sa katapusan ng Enero.
Una, pag-usapan natin kung ano ang SRE - Site Reliability Engineering. At kung paano ito lumitaw bilang isang hiwalay na posisyon, bilang isang hiwalay na direksyon. Nagsimula ang lahat sa katotohanan na sa tradisyonal na mga lupon ng pag-unlad, ang Dev at Ops ay dalawang ganap na magkaibang mga koponan, karaniwang may dalawang ganap na magkaibang layunin. Ang layunin ng development team ay ilunsad ang mga bagong feature at matugunan ang mga pangangailangan ng negosyo. Ang layunin ng Ops team ay tiyaking gumagana ang lahat at walang masisira. Malinaw, ang mga layuning ito ay direktang sumasalungat sa isa't isa: para gumana ang lahat at walang masira, ilunsad ang mga bagong feature nang kaunti hangga't maaari. Dahil dito, maraming mga panloob na salungatan na sinusubukang lutasin ng pamamaraan na ngayon ay tinatawag na DevOps.
Ang problema ay wala kaming malinaw na kahulugan ng DevOps at malinaw na pagpapatupad ng DevOps. Nagsalita ako sa isang kumperensya sa Yekaterinburg 2 taon na ang nakakaraan, at hanggang ngayon ang seksyon ng DevOps ay nagsimula sa ulat na "Ano ang DevOps". Noong 2017, halos 10 taong gulang na ang Devops, ngunit pinagtatalunan pa rin namin kung ano ito. At ito ay isang kakaibang sitwasyon na sinubukan ng Google na lutasin ilang taon na ang nakakaraan.
Noong 2016, naglabas ang Google ng aklat na tinatawag na Site Reliability Engineering. At sa katunayan, sa aklat na ito nagsimula ang kilusang SRE. Ang SRE ay isang partikular na pagpapatupad ng paradigm ng DevOps sa isang partikular na kumpanya. Ang mga inhinyero ng SRE ay nakatuon sa pagtiyak na ang mga sistema ay gumagana nang maaasahan. Karamihan sa kanila ay nagmula sa mga developer, kung minsan ay mga administrator na may malakas na background sa pag-unlad. At ginagawa nila ang dati nang ginagawa ng mga tagapangasiwa ng system, ngunit ang isang malakas na background sa pag-unlad at kaalaman ng system sa mga tuntunin ng code ay humahantong sa katotohanan na ang mga taong ito ay hindi hilig sa karaniwang gawaing administratibo, ngunit hilig sa automation.
Lumalabas na ang paradigm ng DevOps sa mga koponan ng SRE ay ipinatupad sa pamamagitan ng katotohanan na mayroong mga inhinyero ng SRE na lumulutas ng mga problema sa istruktura. Narito ito, ang parehong koneksyon sa pagitan ng Dev at Ops na pinag-uusapan ng mga tao sa loob ng 8 taon. Ang tungkulin ng isang SRE ay katulad ng sa isang arkitekto na ang mga bagong dating ay hindi nagiging mga SRE. Ang mga tao sa simula ng kanilang mga karera ay wala pang karanasan, walang kinakailangang lawak ng kaalaman. Dahil ang SRE ay nangangailangan ng isang napaka banayad na kaalaman sa kung ano at kailan eksaktong maaaring magkamali. Samakatuwid, kailangan ang ilang karanasan dito, bilang panuntunan, sa loob ng kumpanya at sa labas.
Nagtatanong sila kung ang pagkakaiba sa pagitan ng SRE at devops ay ilalarawan. Siya ay inilarawan lamang. Maaari nating pag-usapan ang lugar ng SRE sa organisasyon. Hindi tulad ng klasikong diskarte sa DevOps na ito, kung saan ang Ops ay isa pa ring hiwalay na departamento, ang SRE ay bahagi ng development team. Sila ay kasangkot sa pagbuo ng produkto. Mayroong kahit isang diskarte kung saan ang SRE ay isang tungkulin na dumadaan mula sa isang developer patungo sa isa pa. Lumalahok sila sa mga pagsusuri ng code sa parehong paraan tulad ng, halimbawa, mga taga-disenyo ng UX, mga developer mismo, kung minsan ay mga tagapamahala ng produkto. Gumagana ang mga SRE sa parehong antas. Kailangan nating aprubahan, kailangan nating suriin ang mga ito, para sa bawat deployment ay sasabihin ng SRE: βOkay, itong deployment, itong produktong ito ay hindi makakaapekto sa pagiging maaasahan. At kung mangyayari ito, sa loob ng ilang katanggap-tanggap na limitasyon. Pag-uusapan din natin ito.
Alinsunod dito, ang SRE ay may veto upang baguhin ang code. At sa pangkalahatan, humahantong din ito sa ilang uri ng maliit na salungatan kung ang SRE ay ipinatupad nang hindi tama. Sa parehong libro tungkol sa Site Reliability Engineering, maraming bahagi, kahit isa, ang nagsasabi kung paano maiiwasan ang mga salungatan na ito.
Nagtatanong sila kung paano nauugnay ang SRE sa seguridad ng impormasyon. Ang SRE ay hindi direktang kasangkot sa seguridad ng impormasyon. Karaniwan, sa malalaking kumpanya, ginagawa ito ng mga indibidwal, tester, analyst. Ngunit ang SRE ay nakikipag-ugnayan din sa kanila sa kahulugan na ang ilang mga operasyon, ang ilan ay gumawa, ang ilang mga deployment na nakakaapekto sa seguridad ay maaari ding makaapekto sa pagkakaroon ng produkto. Samakatuwid, ang SRE sa kabuuan ay may pakikipag-ugnayan sa anumang mga koponan, kabilang ang mga pangkat ng seguridad, kabilang ang mga analyst. Samakatuwid, ang mga SRE ay pangunahing kailangan kapag sinusubukan nilang ipatupad ang DevOps, ngunit sa parehong oras, ang pasanin sa mga developer ay nagiging masyadong malaki. Ibig sabihin, ang mismong development team ay hindi na makayanan ang katotohanan na ngayon ay kailangan din nilang maging responsable para sa Ops. At mayroong isang hiwalay na tungkulin. Ang papel na ito ay binalak sa badyet. Minsan ang papel na ito ay inilatag sa laki ng koponan, lumilitaw ang isang hiwalay na tao, kung minsan ang isa sa mga developer ay nagiging ito. Ganito ang hitsura ng unang SRE sa koponan.
Ang pagiging kumplikado ng system na apektado ng SRE, ang pagiging kumplikado na nakakaapekto sa pagiging maaasahan ng operasyon, ay kinakailangan at hindi sinasadya. Ang kinakailangang pagiging kumplikado ay kapag ang pagiging kumplikado ng isang produkto ay tumataas sa lawak na kinakailangan ng mga bagong tampok ng produkto. Ang random na pagiging kumplikado ay kapag ang pagiging kumplikado ng system ay tumataas, ngunit ang tampok ng produkto at mga kinakailangan sa negosyo ay hindi direktang nakakaapekto dito. Lumalabas na ang developer ay nagkamali sa isang lugar, o ang algorithm ay hindi pinakamainam, o ang ilang mga karagdagang interes ay ipinakilala na nagpapataas ng pagiging kumplikado ng produkto nang walang espesyal na pangangailangan. Ang isang mahusay na SRE ay dapat palaging putulin ang sitwasyong ito. Iyon ay, anumang commit, anumang deployment, anumang pull request, kung saan ang kahirapan ay nadagdagan dahil sa random na karagdagan, ay dapat na ma-block.
Ang tanong ay bakit hindi na lang kumuha ng engineer, isang system administrator na may maraming kaalaman sa team. Ang isang developer sa papel ng isang engineer, sinabi sa amin, ay hindi ang pinakamahusay na solusyon sa staffing. Ang isang developer sa papel ng isang engineer ay hindi palaging ang pinakamahusay na solusyon sa staffing, ngunit ang punto dito ay ang isang developer na nakikibahagi sa Ops ay may kaunting pagnanais para sa automation, may kaunting kaalaman at isang set ng kasanayan upang maipatupad ang automation na ito. At ayon dito, binabawasan namin hindi lamang ang oras para sa ilang partikular na operasyon, hindi lamang ang routine, kundi pati na rin ang mahahalagang parameter ng negosyo gaya ng MTTR (Mean Time To Recovery, recovery time). Kaya, at pag-uusapan din natin ito sa ibang pagkakataon, nagtitipid tayo ng pera para sa organisasyon.
Ngayon pag-usapan natin ang mga pamantayan para sa pagpapatakbo ng SRE. At una sa lahat tungkol sa pagiging maaasahan. Sa mga maliliit na kumpanya, mga startup, madalas na nangyayari na ang mga tao ay ipinapalagay na kung ang serbisyo ay nakasulat nang maayos, kung ang produkto ay isinulat nang maayos at tama, ito ay gagana, hindi ito masira. Yun lang, maganda ang code na sinusulat namin, kaya walang masisira. Ang code ay napaka-simple, walang masira. Ito ay tungkol sa parehong mga tao na nagsasabi na hindi namin kailangan ng mga pagsubok, dahil, tingnan mo, ito ang tatlong pamamaraan ng VPI, bakit break dito.
Mali ang lahat ng ito, siyempre. At ang mga taong ito ay madalas na nakagat ng naturang code sa pagsasanay, dahil ang mga bagay ay nasira. Ang mga bagay ay nasira kung minsan sa mga hindi inaasahang paraan. Minsan sinasabi ng mga tao na hindi, hindi ito mangyayari. At ito ay nangyayari sa lahat ng oras. Sapat na madalas na nangyayari. At iyon ang dahilan kung bakit walang sinuman ang nagsusumikap para sa 100% availability, dahil 100% availability ay hindi kailanman nangyayari. Ito ang pamantayan. At kaya lagi naming, kapag pinag-uusapan namin ang pagkakaroon ng serbisyo, pinag-uusapan namin ang tungkol sa siyam. 2 nines, 3 nines, 4 nines, 5 nines. Kung isasalin natin ito sa downtime, kung gayon, halimbawa, 5 nines, ito ay higit pa sa 5 minuto ng downtime bawat taon, 2 nines ay 3,5 araw ng downtime.
Pero halata naman na minsan may pagbaba sa POI, return on investment. Ang pagpunta mula sa dalawang siyam hanggang tatlong siyam ay nangangahulugan ng mas kaunting downtime ng higit sa 3 araw. Ang pagpunta mula sa apat na siyam hanggang lima ay binabawasan ang downtime ng 47 minuto bawat taon. At lumalabas na para sa negosyo ay maaaring hindi ito kritikal. At sa pangkalahatan, ang kinakailangang pagiging maaasahan ay hindi isang teknikal na isyu, una sa lahat, ito ay isang isyu sa negosyo, ito ay isang isyu sa produkto. Anong antas ng downtime ang katanggap-tanggap para sa mga gumagamit ng produkto, kung ano ang kanilang inaasahan, kung magkano ang kanilang binabayaran, halimbawa, kung gaano karaming pera ang nawala sa kanila, kung gaano karaming pera ang nawala sa system.
Ang isang mahalagang tanong dito ay kung ano ang pagiging maaasahan ng mga natitirang bahagi. Dahil ang pagkakaiba sa pagitan ng 4 at 5 nines ay hindi makikita sa isang smartphone na may 2 nines ng pagiging maaasahan. Sa halos pagsasalita, kung may nasira sa isang smartphone sa iyong serbisyo nang 10 beses sa isang taon, malamang na 8 beses na nangyari ang pagkasira sa panig ng OS. Nakasanayan na ito ng gumagamit, at hindi na papansinin ng isa pang beses sa isang taon. Kinakailangan na iugnay ang presyo ng pagtaas ng pagiging maaasahan at pagtaas ng kita.
Sa libro pa lang sa SRE ay may magandang halimbawa ng pagtaas sa 4 na siyam mula sa 3 siyam. Lumalabas na ang pagtaas ng availability ay medyo mas mababa sa 0,1%. At kung ang kita ng serbisyo ay $1 milyon sa isang taon, ang pagtaas ng kita ay $900. Kung ito ay nagkakahalaga sa amin ng mas mababa sa $900 sa isang taon upang madagdagan ang affordability ng siyam, ang pagtaas ay may katuturan sa pananalapi. Kung ito ay nagkakahalaga ng higit sa 900 dolyar sa isang taon, hindi na ito makatwiran, dahil ang pagtaas ng kita ay hindi lamang nagbabayad para sa mga gastos sa paggawa, mga gastos sa mapagkukunan. At sapat na para sa amin ang 3 siyam.
Ito ay siyempre isang pinasimple na halimbawa kung saan ang lahat ng mga kahilingan ay pantay. At ang pagpunta mula sa 3 siyam hanggang 4 na siyam ay sapat na madali, ngunit sa parehong oras, halimbawa, mula sa 2 siyam hanggang 3, ito ay isang pagtitipid na 9 libong dolyar, maaari itong magkaroon ng kahulugan sa pananalapi. Naturally, sa katotohanan, ang pagkabigo ng kahilingan sa pagpaparehistro ay mas masahol pa kaysa sa pagkabigo na ipakita ang pahina, ang mga kahilingan ay may iba't ibang timbang. Maaaring mayroon silang ganap na naiibang pamantayan mula sa pananaw ng negosyo, ngunit gayon pa man, bilang panuntunan, kung hindi natin pinag-uusapan ang ilang partikular na serbisyo, ito ay isang medyo maaasahang pagtatantya.
Nakatanggap kami ng tanong kung ang SRE ay isa sa mga coordinator kapag pumipili ng solusyon sa arkitektura para sa serbisyo. Sabihin natin sa mga tuntunin ng pagsasama sa umiiral na imprastraktura, upang walang pagkawala sa katatagan nito. Oo, ang mga SRE, sa parehong paraan na ang mga pull request, commit, release ay nakakaapekto sa arkitektura, ang pagpapakilala ng mga bagong serbisyo, microservices, ang pagpapatupad ng mga bagong solusyon. Bakit ko pa sinabi na kailangan ang experience, kailangan ng qualifications. Sa katunayan, ang SRE ay isa sa mga humaharang na boses sa anumang solusyon sa arkitektura at software. Alinsunod dito, ang isang SRE bilang isang inhinyero ay dapat, una sa lahat, hindi lamang maunawaan, ngunit maunawaan din kung paano makakaapekto ang ilang partikular na desisyon sa pagiging maaasahan, katatagan, at maunawaan kung paano ito nauugnay sa mga pangangailangan ng negosyo, at mula sa anong punto ng view ito ay maaaring maging katanggap-tanggap at na hindi.
Samakatuwid, ngayon ay maaari na nating pag-usapan ang tungkol sa pamantayan ng pagiging maaasahan, na ayon sa kaugalian ay tinukoy sa SRE bilang SLA (Service Level Agreement). Malamang isang pamilyar na termino. SLI (Service Level Indicator). SLO (Layunin sa Antas ng Serbisyo). Ang Kasunduan sa Antas ng Serbisyo ay maaaring isang simbolikong termino, lalo na kung nagtrabaho ka sa mga network, sa mga provider, sa pagho-host. Ito ay isang pangkalahatang kasunduan na naglalarawan sa pagganap ng iyong buong serbisyo, mga parusa, ilang mga parusa para sa mga pagkakamali, sukatan, pamantayan. At ang SLI ay ang sukatan ng availability mismo. Iyon ay, kung ano ang maaaring maging SLI: oras ng pagtugon mula sa serbisyo, ang bilang ng mga error bilang isang porsyento. Maaaring ito ay bandwidth kung ito ay isang uri ng file hosting. Pagdating sa mga algorithm ng pagkilala, ang tagapagpahiwatig ay maaaring, halimbawa, maging ang kawastuhan ng sagot. Ang SLO (Service Level Objective) ay, ayon sa pagkakabanggit, isang kumbinasyon ng tagapagpahiwatig ng SLI, ang halaga at panahon nito.
Sabihin nating ang SLA ay maaaring maging ganito. Ang serbisyo ay magagamit 99,95% ng oras sa buong taon. O 99 na kritikal na support ticket ang isasara sa loob ng 3 oras bawat quarter. O 85% ng mga query ang makakakuha ng mga tugon sa loob ng 1,5 segundo bawat buwan. Ibig sabihin, unti-unti nating naiintindihan na ang mga pagkakamali at pagkabigo ay medyo normal. Ito ay isang katanggap-tanggap na sitwasyon, pinaplano namin ito, kahit na kami ay umaasa dito sa ilang lawak. Iyon ay, ang SRE ay nagtatayo ng mga sistema na maaaring magkamali, na dapat tumugon nang normal sa mga pagkakamali, na dapat isaalang-alang ang mga ito. At hangga't maaari, dapat nilang pangasiwaan ang mga error sa paraang hindi mapapansin ng gumagamit ang mga ito, o mapansin, ngunit mayroong ilang uri ng workaround, salamat sa kung saan ang lahat ay hindi ganap na bumagsak.
Halimbawa, kung nag-upload ka ng video sa YouTube, at hindi ito maiko-convert kaagad ng YouTube, kung masyadong malaki ang video, kung hindi optimal ang format, natural na hindi mabibigo ang kahilingan nang may timeout, hindi magbibigay ng 502 error ang YouTube , sasabihin ng YouTube: βGinawa namin ang lahat, pinoproseso ang iyong video. Magiging handa ito sa loob ng halos 10 minuto." Ito ang prinsipyo ng magandang pagkasira, na pamilyar, halimbawa, mula sa front-end na pag-unlad, kung nagawa mo na ito.
Ang mga susunod na termino na pag-uusapan natin, na napakahalaga para sa pagtatrabaho nang may pagiging maaasahan, na may mga pagkakamali, na may mga inaasahan, ay MTBF at MTTR. Ang MTBF ay ang ibig sabihin ng oras sa pagitan ng mga pagkabigo. MTTR Mean Time To Recovery, average na oras sa recovery. Iyon ay, kung gaano karaming oras ang lumipas mula sa sandaling natuklasan ang error, mula sa sandaling lumitaw ang error hanggang sa sandaling ang serbisyo ay naibalik sa ganap na normal na operasyon. Ang MTBF ay pangunahing naayos sa pamamagitan ng trabaho sa kalidad ng code. Iyon ay, ang katotohanan na ang mga SRE ay maaaring magsabi ng "hindi". And you need an understanding of the whole team that when SRE says "no", he says it not because he is harmful, not because he is bad, but because otherwise everyone will suffer.
Muli, maraming mga artikulo, maraming pamamaraan, maraming paraan kahit sa mismong aklat na madalas kong tinutukoy, kung paano masigurado na ang ibang mga developer ay hindi magsisimulang mapoot sa SRE. Ang MTTR, sa kabilang banda, ay tungkol sa pagtatrabaho sa iyong mga SLO (Service Level Objective). At karamihan ay automation. Dahil, halimbawa, ang aming SLO ay isang uptime na 4 nines bawat quarter. Nangangahulugan ito na sa loob ng 3 buwan maaari kaming magbigay ng 13 minutong downtime. At lumalabas na ang MTTR ay hindi maaaring higit sa 13 minuto. Kung tumugon kami sa hindi bababa sa 13 downtime sa loob ng 1 minuto, nangangahulugan ito na naubos na namin ang buong badyet para sa quarter. Sinisira namin ang SLO. Ang 13 minuto upang mag-react at ayusin ang isang pag-crash ay marami para sa isang makina, ngunit napakaikli para sa isang tao. Dahil hanggang sa makatanggap ng alerto ang isang tao, hanggang sa magreact siya, hanggang sa maintindihan niya ang error, ilang minuto na. Hanggang sa maunawaan ng isang tao kung paano ayusin ito, kung ano ang eksaktong ayusin, kung ano ang gagawin, pagkatapos ito ay ilang minuto pa. At sa katunayan, kahit na kailangan mo lang i-restart ang server, tulad ng lumalabas, o itaas ang isang bagong node, pagkatapos ay mano-mano ang MTTR ay mga 7-8 minuto na. Kapag awtomatiko ang proseso, ang MTTR ay madalas na umabot sa isang segundo, minsan millisecond. Karaniwang nagsasalita ang Google tungkol sa mga millisecond, ngunit sa katotohanan, siyempre, ang lahat ay hindi napakahusay.
Sa isip, dapat na i-automate ng SRE ang trabaho nito nang halos ganap, dahil direktang nakakaapekto ito sa MTTR, sa mga sukatan nito, sa SLO ng buong serbisyo, at, nang naaayon, sa kita ng negosyo. Kung lumampas ang oras, tatanungin kami kung may kasalanan ang SRE. Sa kabutihang palad, walang dapat sisihin. At ito ay isang hiwalay na kultura na tinatawag na balmeless postmortem, na hindi natin pag-uusapan ngayon, ngunit susuriin natin ito sa Slurm. Ito ay isang napaka-interesante na paksa na maaaring pag-usapan ng marami. Sa madaling salita, kung nalampasan ang inilaan na oras bawat quarter, kung gayon ang kaunti sa lahat ay dapat sisihin, na nangangahulugan na ang pagsisi sa lahat ay hindi produktibo, sa halip, huwag nating sisihin ang sinuman, ngunit itama ang sitwasyon at magtrabaho sa kung ano ang mayroon tayo. Sa aking karanasan, ang diskarte na ito ay medyo alien sa karamihan ng mga koponan, lalo na sa Russia, ngunit ito ay makatuwiran at gumagana nang mahusay. Samakatuwid, irerekomenda ko sa dulo ng artikulo at panitikan na mababasa mo sa paksang ito. O pumunta sa Slurm SRE.
Hayaan mo akong magpaliwanag. Kung ang oras ng SLO kada quarter ay lumampas, kung ang downtime ay hindi 13 minuto, ngunit 15, sino ang maaaring sisihin para dito? Siyempre, maaaring sisihin ang SRE, dahil malinaw na gumawa siya ng ilang uri ng masamang commit o deployment. Maaaring sisihin ito ng administrator ng data center, dahil maaaring nagsagawa siya ng ilang uri ng hindi naka-iskedyul na pagpapanatili. Kung ang tagapangasiwa ng data center ang dapat sisihin para dito, kung gayon ang tao mula sa Ops ang dapat sisihin para dito, na hindi nagkalkula ng pagpapanatili noong siya ay nag-coordinate sa SLO. Ang tagapamahala, teknikal na direktor o isang taong pumirma sa kontrata ng data center at hindi nagbigay-pansin sa katotohanang ang SLA ng data center ay hindi idinisenyo para sa kinakailangang downtime ang dapat sisihin para dito. Alinsunod dito, ang lahat ng unti-unti sa sitwasyong ito ay dapat sisihin. At nangangahulugan ito na walang saysay na sisihin ang sinuman sa sitwasyong ito. Pero syempre kailangan itama. Kaya naman may mga postmortem. At kung babasahin mo, halimbawa, ang mga postmortem ng GitHub, at ito ay palaging isang napaka-interesante, maliit at hindi inaasahang kuwento sa bawat kaso, maaari mong palitan na walang sinuman ang nagsabi na ang partikular na taong ito ang may kasalanan. Ang sisihin ay palaging inilalagay sa mga tiyak na hindi perpektong proseso.
Lumipat tayo sa susunod na tanong. Automation. Kapag pinag-uusapan ko ang tungkol sa automation sa ibang mga konteksto, madalas akong sumangguni sa isang talahanayan na nagsasabi sa iyo kung gaano katagal mo magagawa ang pag-automate ng isang gawain nang hindi naglalaan ng mas maraming oras upang i-automate ito kaysa sa aktwal mong i-save. May sagabal. Ang catch ay kapag ang mga SRE ay nag-automate ng isang gawain, hindi lamang sila nakakatipid ng oras, nakakatipid sila ng pera, dahil ang automation ay direktang nakakaapekto sa MTTR. Nai-save nila, wika nga, ang moral ng mga empleyado at developer, na isa ring nauubos na mapagkukunan. Binabawasan nila ang routine. At ang lahat ng ito ay may positibong epekto sa trabaho at, bilang isang resulta, sa negosyo, kahit na tila ang automation ay hindi makatwiran sa mga tuntunin ng mga gastos sa oras.
Sa katunayan, ito ay halos palaging mayroon, at mayroong napakakaunting mga kaso kung saan ang isang bagay ay hindi dapat awtomatiko sa papel ng SRE. Susunod na pag-uusapan natin ang tinatawag na error budget, ang badyet para sa mga error. Sa katunayan, lumalabas na kung ang lahat ay mas mahusay para sa iyo kaysa sa SLO na itinakda mo para sa iyong sarili, ito ay hindi rin napakahusay. Ito ay medyo masama, dahil gumagana ang SLO hindi lamang bilang isang mas mababa, kundi pati na rin bilang isang tinatayang upper bound. Kapag itinakda mo ang iyong sarili ng isang SLO na 99% na kakayahang magamit, at sa katunayan mayroon kang 99,99%, lumalabas na mayroon kang ilang puwang para sa mga eksperimento na hindi makapinsala sa negosyo, dahil ikaw mismo ang natukoy na lahat ito nang sama-sama, at ikaw ay hindi ginagamit ang espasyong ito. Mayroon kang badyet para sa mga pagkakamali, na sa iyong kaso ay hindi naubos.
Ano ang gagawin natin dito. Ginagamit namin ito para sa literal na lahat. Para sa pagsubok sa mga kundisyon ng produksyon, para sa paglulunsad ng mga bagong feature na maaaring makaapekto sa performance, para sa mga release, para sa pagpapanatili, para sa mga nakaplanong downtime. Nalalapat din ang reverse rule: kung naubos na ang budget, hindi tayo makakapaglabas ng bago, dahil kung hindi ay lalampas tayo sa SLO. Ang badyet ay naubos na, kami ay naglabas ng isang bagay kung ito ay negatibong nakakaapekto sa pagganap, iyon ay, kung ito ay hindi isang uri ng pag-aayos na mismo ay direktang nagpapataas ng SLO, kung gayon kami ay lumampas sa badyet, at ito ay isang masamang sitwasyon , kailangan itong pag-aralan , postmortem, at posibleng ilang pag-aayos sa proseso.
Iyon ay, lumalabas na kung ang serbisyo mismo ay hindi gumagana nang maayos, at ang SLO ay ginugol at ang badyet ay ginugol hindi sa mga eksperimento, hindi sa ilang mga paglabas, ngunit sa sarili nito, pagkatapos ay sa halip na ilang mga kagiliw-giliw na pag-aayos, sa halip na mga kagiliw-giliw na tampok, sa halip na mga kawili-wiling release. Sa halip na anumang malikhaing gawain, kailangan mong harapin ang mga hangal na pag-aayos upang maibalik ang badyet, o i-edit ang SLO, at ito rin ay isang proseso na hindi dapat mangyari nang madalas.
Samakatuwid, lumalabas na sa isang sitwasyon kung saan mayroon kaming mas maraming badyet para sa mga error, lahat ay interesado: parehong SRE at mga developer. Para sa mga developer, ang malaking badyet para sa mga bug ay nangangahulugan na maaari mong harapin ang mga release, pagsubok, eksperimento. Para sa mga SRE, ang isang badyet para sa mga pagkakamali at pagpasok sa badyet na iyon ay nangangahulugan na sila ay direktang ginagawa ang kanilang trabaho nang maayos. At ito ay nakakaapekto sa pagganyak ng ilang uri ng magkasanib na gawain. Kung makikinig ka sa iyong mga SRE bilang mga developer, magkakaroon ka ng mas maraming espasyo para sa mabuting trabaho at mas kaunting gawain.
Lumalabas na ang mga eksperimento sa produksyon ay isang mahalaga at halos mahalagang bahagi ng SRE sa malalaking koponan. At karaniwang tinatawag itong chaos engineering, na nagmumula sa koponan sa Netflix na naglabas ng utility na tinatawag na Chaos Monkey.
Kumokonekta ang Chaos Monkey sa pipeline ng CI/CD at random na nag-crash ang server sa produksyon. Muli, sa istraktura ng SRE, pinag-uusapan natin ang katotohanan na ang isang downed server ay hindi masama sa sarili nito, ito ay inaasahan. At kung ito ay pasok sa badyet, ito ay katanggap-tanggap at hindi nakakapinsala sa negosyo. Siyempre, ang Netflix ay may sapat na kalabisan na mga server, sapat na pagtitiklop, upang ang lahat ng ito ay maayos, at upang ang user sa kabuuan ay hindi man lang mapansin, at higit pa kaya walang nag-iiwan ng isang server para sa anumang badyet.
Ang Netflix ay nagkaroon ng isang buong hanay ng mga naturang kagamitan sa loob ng ilang sandali, isa rito, ang Chaos Gorilla, ay ganap na nagsasara ng isa sa mga Availability Zone ng Amazon. At ang mga ganitong bagay ay nakakatulong upang maihayag, una, ang mga nakatagong dependencies, kapag hindi lubos na malinaw kung ano ang nakakaapekto sa kung ano, kung ano ang nakasalalay sa kung ano. At ito, kung nagtatrabaho ka sa isang microservice, at ang dokumentasyon ay hindi masyadong perpekto, ito ay maaaring pamilyar sa iyo. At muli, malaki ang naitutulong nito upang mahuli ang mga error sa code na hindi mo mahuli sa pagtatanghal, dahil ang anumang pagtatanghal ay hindi eksaktong simulation, dahil sa ang katunayan na ang sukat ng pagkarga ay naiiba, ang pattern ng pagkarga ay naiiba, ang kagamitan ay din, malamang, iba pa. Ang mga peak load ay maaari ding hindi inaasahan at hindi mahuhulaan. At ang gayong pagsubok, na muli ay hindi lalampas sa badyet, ay nakakatulong nang husto upang mahuli ang mga error sa imprastraktura na hindi kailanman mahuhuli ng staging, autotest, CI / CD pipeline. And as long as kasama lahat sa budget mo, bale bumaba ang service mo diyan, although it would seem very scary, down ang server, what a nightmare. Hindi, normal lang iyon, mabuti iyon, nakakatulong sa paghuli ng mga bug. Kung may budget ka, pwede mong gastusin.
Q: Anong literatura ang mairerekomenda ko? Listahan sa dulo. Mayroong maraming mga panitikan, magpapayo ako ng ilang mga ulat. Paano ito gumagana, at gumagana ang SRE sa mga kumpanyang walang sariling produkto ng software o may kaunting pag-unlad. Halimbawa, sa isang negosyo kung saan ang pangunahing aktibidad ay hindi software. Sa isang enterprise, kung saan ang pangunahing aktibidad ay hindi software, ang SRE ay gumagana nang eksakto sa lahat ng dako, dahil sa isang enterprise kailangan mo ring gamitin, kahit na hindi binuo, ang mga produkto ng software, kailangan mong ilunsad ang mga update, kailangan mong baguhin ang imprastraktura, kailangan mong lumago, kailangan mong mag-scale. At ang mga SRE ay tumutulong na matukoy at mahulaan ang mga posibleng problema sa mga prosesong ito at kontrolin ang mga ito pagkatapos magsimula ang ilang paglago at magbago ang mga pangangailangan ng negosyo. Dahil ito ay ganap na hindi kinakailangan upang maging kasangkot sa software development upang magkaroon ng isang SRE kung mayroon kang hindi bababa sa ilang mga server at ikaw ay inaasahang magkaroon ng hindi bababa sa ilang paglago.
Ganoon din sa mga maliliit na proyekto, maliliit na organisasyon, dahil ang malalaking kumpanya ay may badyet at espasyo para mag-eksperimento. Ngunit sa parehong oras, ang lahat ng mga bunga ng mga eksperimento ay maaaring magamit kahit saan, iyon ay, ang SRE, siyempre, ay lumitaw sa Google, sa Netflix, sa Dropbox. Ngunit sa parehong oras, ang mga maliliit na kumpanya at mga startup ay maaari nang magbasa ng condensed material, magbasa ng mga libro, manood ng mga ulat. Nagsisimula silang marinig ang tungkol dito nang mas madalas, tumitingin sila sa mga partikular na halimbawa, sa palagay ko ay okay, maaari itong talagang kapaki-pakinabang, kailangan din natin ito, ito ay mahusay.
Ibig sabihin, lahat ng pangunahing gawain sa pag-standardize ng mga prosesong ito ay nagawa na para sa iyo. Nananatili para sa iyo na tukuyin ang papel ng SRE partikular sa iyong kumpanya at magsimulang aktwal na ipatupad ang lahat ng mga kasanayang ito, na, muli, ay inilarawan na. Iyon ay, mula sa mga kapaki-pakinabang na prinsipyo para sa maliliit na kumpanya, ito ang palaging kahulugan ng SLA, SLI, SLO. Kung hindi ka kasali sa software, ang mga ito ay magiging mga panloob na SLA at panloob na mga SLO, isang panloob na badyet para sa mga error. Ito ay halos palaging humahantong sa ilang mga kagiliw-giliw na talakayan sa loob ng koponan at sa loob ng negosyo, dahil maaaring lumabas na gumastos ka sa imprastraktura, sa ilang uri ng organisasyon ng mga perpektong proseso, ang perpektong pipeline ay higit pa sa kinakailangan. At itong 4 na siyam na mayroon ka sa departamento ng IT, hindi mo na sila kailangan ngayon. Ngunit sa parehong oras, maaari kang gumugol ng oras, gastusin ang badyet para sa mga pagkakamali sa ibang bagay.
Alinsunod dito, ang pagsubaybay at organisasyon ng pagsubaybay ay kapaki-pakinabang para sa isang kumpanya sa anumang laki. At sa pangkalahatan, ang ganitong paraan ng pag-iisip, kung saan ang mga pagkakamali ay isang bagay na katanggap-tanggap, kung saan may badyet, kung saan may Mga Layunin, ito ay muling kapaki-pakinabang para sa isang kumpanya ng anumang laki, simula sa mga startup para sa 3 tao.
Ang huli sa mga teknikal na nuances na pag-uusapan ay ang pagsubaybay. Dahil kung pinag-uusapan natin ang tungkol sa SLA, SLI, SLO, hindi natin mauunawaan nang hindi sinusubaybayan kung nababagay tayo sa badyet, kung sumusunod ba tayo sa ating Mga Layunin, at kung paano natin naiimpluwensyahan ang panghuling SLA. Napakaraming beses kong nakita na ang pagsubaybay ay nangyayari tulad nito: mayroong ilang halaga, halimbawa, ang oras ng isang kahilingan sa server, ang average na oras, o ang bilang ng mga kahilingan sa database. Mayroon siyang pamantayan na itinakda ng isang inhinyero. Kung ang sukatan ay lumihis mula sa pamantayan, may darating na e-mail. Ang lahat ng ito ay ganap na walang silbi, bilang isang panuntunan, dahil ito ay humahantong sa gayong labis na mga alerto, isang labis na mga mensahe mula sa pagsubaybay, kapag ang isang tao, una, ay dapat bigyang-kahulugan ang mga ito sa bawat oras, iyon ay, matukoy kung ang halaga ng sukatan ay nangangahulugan ang pangangailangan para sa ilang aksyon. At pangalawa, hihinto na lang niya ang pagpansin sa lahat ng mga alertong ito, kung sa pangkalahatan ay walang kinakailangang aksyon mula sa kanya. Iyon ay isang mahusay na panuntunan sa pagsubaybay at ang pinakaunang panuntunan kapag ipinatupad ang SRE ay ang abiso ay dapat lamang dumating kapag kinakailangan ang aksyon.
Sa karaniwang kaso, mayroong 3 antas ng mga kaganapan. May mga alerto, may mga tiket, may mga tala. Ang mga alerto ay anumang bagay na nangangailangan sa iyong gumawa ng agarang pagkilos. Ibig sabihin, sira ang lahat, kailangan mong ayusin ito ngayon din. Ang mga tiket ang nangangailangan ng naantalang pagkilos. Oo, kailangan mong gawin ang isang bagay, kailangan mong gawin nang manu-mano, nabigo ang automation, ngunit hindi mo na kailangang gawin ito sa susunod na ilang minuto. Ang mga log ay anumang bagay na hindi nangangailangan ng pagkilos, at sa pangkalahatan, kung magiging maayos ang lahat, walang sinuman ang magbabasa nito. Kakailanganin mo lamang na basahin ang mga log kapag, sa pagbabalik-tanaw, ito ay naging isang bagay na nasira nang ilang panahon, hindi namin alam ang tungkol dito. O kailangan mo bang magsaliksik. Ngunit sa pangkalahatan, lahat ng bagay na hindi nangangailangan ng anumang aksyon ay napupunta sa mga log.
Bilang side effect ng lahat ng ito, kung natukoy natin kung anong mga kaganapan ang nangangailangan ng mga aksyon at nailarawan nang mabuti kung ano dapat ang mga pagkilos na ito, nangangahulugan ito na maaaring awtomatiko ang pagkilos. Ibig sabihin, kung ano ang nangyayari. Umalis kami mula sa alerto. Mag-aksyon na tayo. Pumunta kami sa paglalarawan ng pagkilos na ito. At pagkatapos ay lumipat kami sa automation. Iyon ay, ang anumang automation ay nagsisimula sa isang reaksyon sa isang kaganapan.
Mula sa pagsubaybay, lumipat tayo sa isang terminong tinatawag na Observability. Nagkaroon din ng kaunting hype sa paligid ng salitang ito sa nakalipas na ilang taon. At kakaunting tao ang nakakaunawa kung ano ang ibig sabihin nito sa labas ng konteksto. Ngunit ang pangunahing punto ay ang Observability ay isang sukatan para sa transparency ng system. Kung may nangyaring mali, gaano mo kabilis matukoy kung ano ang eksaktong nagkamali at kung ano ang estado ng system sa sandaling iyon. Sa mga tuntunin ng code: aling function ang nabigo, aling serbisyo ang nabigo. Ano ang estado ng, halimbawa, mga panloob na variable, pagsasaayos. Sa mga tuntunin ng imprastraktura, ito ay kung saan ang availability zone naganap ang pagkabigo, at kung mayroon kang anumang mga Kubernetes na naka-install, kung saan pod nangyari ang pagkabigo, ano ang estado ng pod. At ayon dito, ang Observability ay may direktang kaugnayan sa MTTR. Kung mas mataas ang Observability ng serbisyo, mas madaling matukoy ang error, mas madaling ayusin ang error, mas madaling i-automate ang error, mas mababa ang MTTR.
Sa paglipat muli sa maliliit na kumpanya, karaniwan nang magtanong, kahit ngayon, kung paano haharapin ang laki ng koponan, at kung kailangan ng isang maliit na koponan na kumuha ng hiwalay na SRE. Napag-usapan na ito kanina pa. Sa mga unang yugto ng pag-unlad ng isang startup o, halimbawa, isang koponan, hindi ito kinakailangan, dahil ang SRE ay maaaring gawing transisyonal na tungkulin. At ito ay bubuhayin ng kaunti ang koponan, dahil mayroong hindi bababa sa ilang pagkakaiba-iba. At dagdag pa, ihahanda nito ang mga tao para sa katotohanan na sa paglago, sa pangkalahatan, ang mga responsibilidad ng SRE ay magbabago nang malaki. Kung kukuha ka ng isang tao, kung gayon, siyempre, mayroon siyang ilang mga inaasahan. At ang mga inaasahan na ito ay hindi magbabago sa paglipas ng panahon, ngunit ang mga kinakailangan ay magbabago nang husto. Samakatuwid, kung paano kumuha ng SRE ay medyo mahirap sa mga unang yugto. Ang pagpapalaki ng iyong sarili ay mas madali. Ngunit ito ay nagkakahalaga ng pag-iisip.
Ang tanging pagbubukod, marahil, ay kapag mayroong napakahigpit at mahusay na tinukoy na mga kinakailangan sa paglago. Iyon ay, sa kaso ng isang startup, ito ay maaaring isang uri ng presyon mula sa mga namumuhunan, isang uri ng pagtataya para sa paglago ng ilang beses nang sabay-sabay. Kung gayon ang pagkuha ng isang SRE ay karaniwang makatwiran dahil maaari itong mabigyang-katwiran. Mayroon kaming mga kinakailangan para sa paglago, kailangan namin ng isang tao na magiging responsable para sa katotohanan na sa gayong paglago ay walang masisira.
Isa pang tanong. Ano ang gagawin kapag ilang beses na pinutol ng mga developer ang isang tampok na pumasa sa mga pagsubok, ngunit sinira ang produksyon, naglo-load ng base, sinira ang iba pang mga tampok, kung anong proseso ang ipapatupad. Alinsunod dito, sa kasong ito, ito ay ang badyet para sa mga error na ipinakilala. At ang ilan sa mga serbisyo, ang ilan sa mga tampok ay sinusuri na sa produksyon. Maaari itong maging canary, kapag kakaunti lamang ang bilang ng mga user, ngunit nasa produksyon na, isang feature ang na-deploy, ngunit mayroon nang inaasahan na kung may masira, halimbawa, para sa kalahating porsyento ng lahat ng mga user, matutugunan pa rin nito ang badyet para sa mga pagkakamali. Alinsunod dito, oo, magkakaroon ng error, para sa ilang mga gumagamit ang lahat ay masisira, ngunit nasabi na namin na ito ay normal.
May tanong tungkol sa mga tool ng SRE. Ibig sabihin, mayroon bang partikular na bagay na gagamitin ng mga SRE na hindi gagawin ng lahat. Sa katunayan, mayroong ilang lubos na dalubhasang mga kagamitan, mayroong ilang uri ng software na, halimbawa, ay ginagaya ang mga naglo-load o nakikibahagi sa pagsubok sa canary A / B. Ngunit karaniwang ang SRE toolkit ay ang ginagamit na ng iyong mga developer. Dahil direktang nakikipag-ugnayan ang SRE sa development team. At kung mayroon kang iba't ibang mga tool, lalabas na nangangailangan ng oras upang mag-synchronize. Lalo na kung ang mga SRE ay nagtatrabaho sa malalaking koponan, sa malalaking kumpanya kung saan maaaring magkaroon ng ilang mga koponan, ito ay ang standardisasyon sa buong kumpanya na makakatulong ng malaki dito, dahil kung 50 iba't ibang mga utility ang gagamitin sa 50 mga koponan, nangangahulugan ito na dapat silang kilala ng SRE lahat. At siyempre hinding-hindi mangyayari ito. At ang kalidad ng trabaho, ang kalidad ng kontrol ng hindi bababa sa ilan sa mga koponan ay bababa nang malaki.
Matatapos na ang aming webinar. Nagawa kong sabihin ang ilang mga pangunahing bagay. Siyempre, wala tungkol sa SRE ang masasabi at mauunawaan sa loob ng isang oras. Ngunit umaasa ako na nagawa kong ihatid ang ganitong paraan ng pag-iisip, ang mga pangunahing punto. At pagkatapos ay magiging posible, kung interesado, upang bungkalin ang paksa, matuto sa iyong sarili, tingnan kung paano ito ipinapatupad ng ibang tao, sa ibang mga kumpanya. At ayon dito, sa unang bahagi ng Pebrero, pumunta sa amin sa Slurm SRE.
Ang Slurm SRE ay isang tatlong-araw na masinsinang kurso na magsasalita tungkol sa kung ano ang pinag-uusapan ko ngayon, ngunit sa mas malalim, sa totoong mga kaso, na may kasanayan, ang buong intensive ay naglalayong praktikal na gawain. Ang mga tao ay hahatiin sa mga pangkat. Gagawa kayong lahat sa mga totoong kaso. Alinsunod dito, mayroon kaming mga instruktor sa Booking.com na sina Ivan Kruglov at Ben Tyler. Mayroon kaming magandang Eugene Barabbas mula sa Google, mula sa San Francisco. At may sasabihin din ako sayo. Kaya siguraduhing bisitahin kami.
Kaya, ang bibliograpiya. May mga sanggunian sa SRE. sa parehong aklat, o sa halip sa 2 aklat tungkol sa SRE, na isinulat ng Google. Isa pa , kung saan ang mga tuntunin at ang kanilang aplikasyon ay bahagyang mas detalyado. Ang susunod na 3 ay mga ulat sa SRE sa iba't ibang kumpanya. Una - , ito ay isang pangunahing tono mula kay Ben Trainer ng Google. Pangalawa - . Ang pangatlo ay muli . Ikaapat na ulat mula sa , na mayroon lamang 5 pangunahing empleyado ng SRE sa 190 bansa. Napaka-interesante na tingnan ang lahat ng ito, dahil kung paanong ang DevOps ay nangangahulugang ibang-iba sa iba't ibang kumpanya at maging sa iba't ibang team, ang SRE ay may ibang-iba na mga responsibilidad, kahit na sa mga kumpanyang may katulad na laki.
2 higit pang mga link sa mga prinsipyo ng chaos engineering: , . At sa dulo mayroong 3 listahan mula sa seryeng Awesome Lists tungkol sa , tungkol sa at tungkol sa . Ang listahan sa SRE ay hindi kapani-paniwalang napakalaki, hindi kinakailangan na dumaan sa lahat ng ito, mayroong mga 200 na artikulo. Lubos kong inirerekumenda ang mga artikulo mula doon tungkol sa pagpaplano ng kapasidad at tungkol sa walang kapintasang postmortem.
Kagiliw-giliw na artikulo:
Salamat sa pakikinig sa akin sa lahat ng oras na ito. Sana may natutunan ka. Sana ay mayroon kang sapat na materyal upang matuto pa. At magkita tayo. Sana sa February.
Ang webinar ay pinangunahan ni Eduard Medvedev.
PS: sa mga mahilig magbasa, nagbigay si Eduard ng list of references. Ang mga mas gustong maunawaan sa pagsasanay ay malugod na tinatanggap .
Pinagmulan: www.habr.com