Kwa mara nyingine tena kuhusu DevOps na SRE

Kulingana na mazungumzo ya gumzo Jumuiya ya AWS Minsk

Hivi majuzi, vita vya kweli vimepamba moto juu ya ufafanuzi wa DevOps na SRE.
Licha ya ukweli kwamba kwa njia nyingi majadiliano juu ya mada hii tayari yameweka meno yangu makali, ikiwa ni pamoja na mimi, niliamua kuleta maoni yangu juu ya mada hii kwa mahakama ya jumuiya ya Habra. Kwa wale ambao wana nia, karibu paka. Na wacha kila kitu kianze upya!

kabla ya historia

Kwa hiyo, katika nyakati za kale, timu ya watengenezaji wa programu na wasimamizi wa seva waliishi tofauti. Wa kwanza aliandika kwa mafanikio nambari hiyo, ya pili, kwa kutumia maneno ya joto na ya upendo yaliyoelekezwa kwa wa kwanza, alianzisha seva, mara kwa mara akija kwa watengenezaji na kupokea kwa kujibu "kila kitu kinafanya kazi kwenye mashine yangu." Biashara ilikuwa ikingojea programu, kila kitu kilikuwa bila kazi, kilivunjika mara kwa mara, kila mtu alikuwa na wasiwasi. Hasa yule aliyelipa fujo hii yote. Enzi ya taa tukufu. Kweli, tayari unajua DevOps inatoka wapi.

Kuzaliwa kwa mazoea ya DevOps

Kisha watu wakubwa walikuja na kusema - hii sio tasnia, huwezi kufanya kazi kama hiyo. Na walileta mifano ya mzunguko wa maisha. Hapa, kwa mfano, ni V-mfano.

Kwa mara nyingine tena kuhusu DevOps na SRE
Kwa hiyo tunaona nini? Biashara inakuja na dhana, ufumbuzi wa kubuni wa wasanifu, watengenezaji huandika msimbo, na kisha inashindwa. Mtu kwa namna fulani anajaribu bidhaa, mtu kwa namna fulani hutoa kwa mtumiaji wa mwisho, na mahali fulani katika pato la mfano huu wa muujiza anakaa mteja wa upweke wa biashara akisubiri hali ya hewa iliyoahidiwa na bahari. Tulifikia hitimisho kwamba tunahitaji mbinu ambazo zitaturuhusu kuanzisha mchakato huu. Na tuliamua kuunda mazoea ambayo yangeyatekeleza.

Upungufu wa sauti juu ya mada ya mazoezi ni nini
Kwa mazoezi namaanisha mchanganyiko wa teknolojia na nidhamu. Mfano ni utaratibu wa kuelezea miundombinu kwa kutumia terraform code. Nidhamu ni jinsi ya kuelezea miundombinu kwa kutumia msimbo, iko kichwani mwa msanidi programu, na teknolojia ndiyo eneo lenyewe.

Na waliamua kuziita mazoea ya DevOps - nadhani walimaanisha kutoka kwa Maendeleo hadi Uendeshaji. Tulikuja na mambo mbalimbali ya werevu - mazoea ya CI/CD, mazoea kulingana na kanuni ya IaC, maelfu yao. Na tunaenda, watengenezaji wanaandika msimbo, wahandisi wa DevOps hubadilisha maelezo ya mfumo katika mfumo wa nambari kuwa mifumo ya kufanya kazi (ndio, nambari ni, kwa bahati mbaya, maelezo tu, lakini sio mfano wa mfumo), utoaji unaendelea, Nakadhalika. Wasimamizi wa jana, wakiwa wamebobea katika mbinu mpya, walijivunia kuwa wahandisi wa DevOps, na kila kitu kilitoka hapo. Na kulikuwa na jioni, na kulikuwa na asubuhi ... sorry, si kutoka huko.

Sio nzuri tena, asante Mungu

Mara tu kila kitu kilipotulia, na "wataalamu" wa ujanja walianza kuandika vitabu vizito juu ya mazoea ya DevOps, mizozo ilizuka kimya kimya kuhusu mhandisi maarufu wa DevOps alikuwa nani na kwamba DevOps ni utamaduni wa uzalishaji, kutoridhika kulizuka tena. Ghafla ikawa kwamba utoaji wa programu ni kazi isiyo ya kawaida kabisa. Kila miundombinu ya maendeleo ina stack yake mwenyewe, mahali fulani unahitaji kukusanyika, mahali fulani unahitaji kupeleka mazingira, hapa unahitaji Tomcat, hapa unahitaji njia ya ujanja na ngumu ya kuzindua - kwa ujumla, kichwa chako kinapiga. Na shida, isiyo ya kawaida, iligeuka kuwa katika shirika la michakato - kazi hii ya utoaji, kama kizuizi, ilianza kuzuia michakato. Kwa kuongeza, hakuna mtu aliyeghairi Uendeshaji. Haionekani katika mfano wa V, lakini bado kuna mzunguko mzima wa maisha upande wa kulia. Kwa hiyo, ni muhimu kwa namna fulani kudumisha miundombinu, ufuatiliaji, kutatua matukio, na pia kushughulikia utoaji. Wale. kukaa na mguu mmoja katika maendeleo na uendeshaji - na ghafla ikawa Maendeleo & Operesheni. Na kisha kulikuwa na hype ya jumla kwa microservices. Na pamoja nao, maendeleo kutoka kwa mashine za ndani yalianza kuhamia kwenye wingu - jaribu kurekebisha kitu ndani ya nchi, ikiwa kuna kadhaa na mamia ya huduma ndogo, basi utoaji wa mara kwa mara unakuwa njia ya kuishi. Kwa "kampuni ndogo ya kawaida" ilikuwa sawa, lakini bado? Na Google?

SRE na Google

Google ilikuja, ikakula cacti kubwa zaidi na ikaamua - hatuitaji hii, tunahitaji kutegemewa. Na kuegemea lazima kusimamiwa. Na niliamua kwamba tunahitaji wataalamu ambao watasimamia kuegemea. Niliwaita wahandisi wa SR na nikasema, hiyo ni kwa ajili yako, fanya vizuri kama kawaida. Hii hapa SLI, hii hapa SLO, ufuatiliaji hapa ni. Na akatoa pua yake katika operesheni. Na aliita "DevOps yake ya kuaminika" SRE. Kila kitu kinaonekana kuwa sawa, lakini kuna utapeli mmoja mchafu ambao Google inaweza kumudu - kwa nafasi ya wahandisi wa SR, kuajiri watu ambao walikuwa watengenezaji waliohitimu na pia walifanya kazi ndogo ya nyumbani na kuelewa utendakazi wa mifumo ya kufanya kazi. Kwa kuongezea, Google yenyewe ina shida na kuajiri watu kama hao - haswa kwa sababu hapa inashindana yenyewe - ni muhimu kuelezea mantiki ya biashara kwa mtu. Utoaji ulipewa kutolewa kwa wahandisi, SR - wahandisi kusimamia kuegemea (bila shaka, si moja kwa moja, lakini kwa kushawishi miundombinu, kubadilisha usanifu, kufuatilia mabadiliko na viashiria, kukabiliana na matukio). Nzuri, unaweza kuandika vitabu. Lakini vipi ikiwa wewe si Google, lakini kuegemea bado kunatia wasiwasi kwa namna fulani?

Maendeleo ya mawazo ya DevOps

Wakati huo huo Docker alifika, ambayo ilikua nje ya lxc, na kisha mifumo mbalimbali ya ochestration kama vile Docker Swarm na Kubernetes, na wahandisi wa DevOps wakatoa pumzi - muunganisho wa mazoea umerahisisha utoaji. Imerahisisha kwa kiasi kwamba iliwezekana hata kutoa nje kwa watengenezaji - nini ni deployment.yaml. Uwekaji vyombo hutatua tatizo. Na ukomavu wa mifumo ya CI/CD tayari iko kwenye kiwango cha kuandika faili moja na tunaenda mbali - watengenezaji wanaweza kushughulikia wenyewe. Na kisha tunaanza kuzungumza juu ya jinsi tunaweza kutengeneza SRE yetu wenyewe, na ... au angalau na mtu.

SRE haipo kwenye Google

Naam, sawa, tuliwasilisha utoaji, inaonekana tunaweza exhale, kurudi siku nzuri za zamani, wakati admins walitazama mzigo wa processor, tuned mifumo na kimya kimya sipped kitu kisichoeleweka kutoka mugs kwa amani na utulivu ... Acha. Hii sio kwa nini tulianza kila kitu (ambayo ni huruma!). Ghafla inageuka kuwa katika mbinu ya Google tunaweza kupitisha mazoea bora kwa urahisi - sio mzigo wa processor ambayo ni muhimu, na sio mara ngapi tunabadilisha diski huko, au kuongeza gharama katika wingu, lakini metriki za biashara ni sawa na sifa mbaya. SLx. Na hakuna mtu aliyeondoa usimamizi wa miundombinu kutoka kwao, na wanahitaji kutatua matukio, na kuwa na kazi mara kwa mara, na kwa ujumla kukaa juu ya michakato ya biashara. Na nyie, anza kupanga programu kidogo kidogo kwa kiwango kizuri, Google tayari inakungoja.

Kwa muhtasari. Ghafla, lakini tayari umechoka kusoma na huwezi kusubiri mate na kuandika kwa mwandishi katika maoni juu ya makala. DevOps kama mazoezi ya uwasilishaji imekuwa daima na itakuwa hivyo. Na haiendi popote. SRE kama seti ya mazoea ya kufanya kazi hufanikisha uwasilishaji huu.

Chanzo: mapenzi.com

Kuongeza maoni