Batay sa isang talakayan sa chat
Kamakailan, sumiklab ang mga totoong labanan sa kahulugan ng DevOps at SRE.
Sa kabila ng katotohanan na sa maraming paraan ang mga talakayan tungkol sa paksang ito ay nakapagbigay na sa aking mga ngipin, kasama na ako, nagpasya akong dalhin ang aking pananaw sa paksang ito sa hukuman ng komunidad ng Habra. Para sa mga interesado, maligayang pagdating sa pusa. At hayaang magsimula muli ang lahat!
prehistory
Kaya, noong sinaunang panahon, ang isang pangkat ng mga developer ng software at mga administrator ng server ay nanirahan nang hiwalay. Ang una ay matagumpay na naisulat ang code, ang pangalawa, gamit ang iba't ibang mainit, mapagmahal na mga salita na tinutugunan sa una, i-set up ang mga server, pana-panahong dumarating sa mga developer at tumatanggap bilang tugon ng isang komprehensibong "ang lahat ay gumagana sa aking makina." Ang negosyo ay naghihintay para sa software, lahat ay walang ginagawa, ito ay nasira pana-panahon, lahat ay kinakabahan. Lalo na yung nagbayad ng buong gulo. Maluwalhating panahon ng lampara. Well, alam mo na kung saan nagmula ang DevOps.
Ang pagsilang ng mga kasanayan sa DevOps
Pagkatapos ay dumating ang mga seryosong lalaki at sinabi - hindi ito isang industriya, hindi ka maaaring magtrabaho nang ganoon. At nagdala sila ng mga modelo ng siklo ng buhay. Narito, halimbawa, ang V-modelo.
Kaya ano ang nakikita natin? Ang isang negosyo ay may isang konsepto, mga solusyon sa disenyo ng mga arkitekto, sumulat ng code ang mga developer, at pagkatapos ay nabigo ito. May sumubok sa produkto, kahit papaano ay naghahatid nito sa end user, at sa isang lugar sa output ng himalang modelong ito ay nakaupo ang isang malungkot na customer ng negosyo na naghihintay para sa ipinangakong panahon sa tabi ng dagat. Nakarating kami sa konklusyon na kailangan namin ng mga pamamaraan na magpapahintulot sa amin na maitatag ang prosesong ito. At nagpasya kaming lumikha ng mga kasanayan na magpapatupad ng mga ito.
Isang lyrical digression sa paksa kung ano ang practice
Sa pamamagitan ng pagsasanay ang ibig kong sabihin ay kumbinasyon ng teknolohiya at disiplina. Ang isang halimbawa ay ang kasanayan ng paglalarawan ng imprastraktura gamit ang terraform code. Ang disiplina ay kung paano ilarawan ang imprastraktura gamit ang code, ito ay nasa ulo ng developer, at ang teknolohiya ay ang terraform mismo.
At nagpasya silang tawagan silang mga kasanayan sa DevOps - sa tingin ko ang ibig nilang sabihin ay mula sa Pag-unlad hanggang sa Mga Operasyon. Nakabuo kami ng iba't ibang matalinong bagay - mga kasanayan sa CI/CD, mga kasanayan batay sa prinsipyo ng IaC, libu-libo sa mga ito. At umalis na tayo, sumulat ang mga developer ng code, binago ng mga inhinyero ng DevOps ang paglalarawan ng system sa anyo ng code sa mga gumaganang sistema (oo, ang code ay, sa kasamaang-palad, isang paglalarawan lamang, ngunit hindi ang sagisag ng system), nagpapatuloy ang paghahatid, at iba pa. Ang mga administrator kahapon, na nakabisado ang mga bagong kasanayan, ay buong pagmamalaki na nagsanay muli bilang mga inhinyero ng DevOps, at lahat ay nagmula doon. At nagkaroon ng gabi, at nagkaroon ng umaga... sorry, hindi mula doon.
Hindi na naman maganda lahat, salamat sa Diyos
Sa sandaling huminahon ang lahat, at nagsimulang magsulat ang iba't ibang tusong "methodologist" ng makakapal na mga libro sa mga kasanayan sa DevOps, tahimik na sumiklab ang mga pagtatalo tungkol sa kung sino ang kilalang inhinyero ng DevOps at ang DevOps ay isang kultura ng produksyon, muling bumangon ang kawalang-kasiyahan. Biglang lumabas na ang paghahatid ng software ay isang ganap na di-maliit na gawain. Ang bawat imprastraktura ng pag-unlad ay may sariling stack, sa isang lugar na kailangan mong tipunin ito, sa isang lugar na kailangan mong i-deploy ang kapaligiran, dito kailangan mo ng Tomcat, dito kailangan mo ng isang tuso at kumplikadong paraan upang ilunsad ito - sa pangkalahatan, ang iyong ulo ay pumipintig. At ang problema, kakaiba, ay naging pangunahin sa samahan ng mga proseso - ang pagpapaandar na ito ng paghahatid, tulad ng isang bottleneck, ay nagsimulang harangan ang mga proseso. Bilang karagdagan, walang nagkansela ng Operations. Hindi ito nakikita sa V-model, ngunit mayroon pa ring buong ikot ng buhay sa kanan. Bilang resulta, kinakailangan na kahit papaano ay mapanatili ang imprastraktura, subaybayan ang pagsubaybay, lutasin ang mga insidente, at harapin din ang paghahatid. Yung. umupo nang may isang paa sa parehong pag-unlad at pagpapatakbo - at bigla itong naging Development & Operations. At pagkatapos ay mayroong pangkalahatang hype para sa mga microservice. At kasama nila, ang pag-unlad mula sa mga lokal na makina ay nagsimulang lumipat sa cloud - subukang i-debug ang isang bagay nang lokal, kung mayroong dose-dosenang at daan-daang mga microservice, kung gayon ang patuloy na paghahatid ay nagiging isang paraan ng kaligtasan. Para sa isang "maliit na katamtamang kumpanya" ayos lang, ngunit gayon pa man? Paano ang tungkol sa Google?
SRE ng Google
Dumating ang Google, kumain ng pinakamalaking cacti at nagpasya - hindi namin ito kailangan, kailangan namin ng pagiging maaasahan. At ang pagiging maaasahan ay dapat pangasiwaan. At napagpasyahan ko na kailangan namin ng mga espesyalista na mamamahala sa pagiging maaasahan. I called them SR engineers and said, para sa inyo yan, do it well as usual. Narito ang SLI, narito ang SLO, narito ang pagsubaybay. At tinusok niya ang kanyang ilong sa operasyon. At tinawag niya ang kanyang "maaasahang DevOps" na SRE. Mukhang maayos ang lahat, ngunit may isang maruming hack na kayang bayaran ng Google - para sa posisyon ng mga inhinyero ng SR, umarkila ng mga taong kwalipikadong developer at gumawa din ng kaunting takdang-aralin at nauunawaan ang paggana ng mga gumaganang sistema. Bukod dito, ang Google mismo ay may mga problema sa pagkuha ng gayong mga tao - higit sa lahat dahil dito ito nakikipagkumpitensya sa sarili nito - kinakailangan upang ilarawan ang lohika ng negosyo sa isang tao. Ang paghahatid ay itinalaga upang palabasin ang mga inhinyero, SR - ang mga inhinyero ay namamahala sa pagiging maaasahan (siyempre, hindi direkta, ngunit sa pamamagitan ng pag-impluwensya sa imprastraktura, pagbabago ng arkitektura, pagsubaybay sa mga pagbabago at tagapagpahiwatig, pagharap sa mga insidente). Nice, kaya mo . Ngunit paano kung hindi ka Google, ngunit nababahala pa rin ang pagiging maaasahan?
Pagbuo ng mga ideya sa DevOps
Sa sandaling dumating ang Docker, na lumaki mula sa lxc, at pagkatapos ay ang iba't ibang mga sistema ng orkestra tulad ng Docker Swarm at Kubernetes, at ang mga inhinyero ng DevOps ay huminga - ang pag-iisa ng mga kasanayan ay pinasimple ang paghahatid. Pinasimple nito ito sa isang lawak na naging posible na mag-outsource ng paghahatid sa mga developer - ano ang deployment.yaml. Nilulutas ng containerization ang problema. At ang maturity ng CI/CD system ay nasa antas na ng pagsusulat ng isang file at umalis na tayo - ang mga developer ay kayang hawakan ito mismo. At pagkatapos ay magsisimula kaming pag-usapan kung paano kami makakagawa ng sarili naming SRE, kasama ang... o kahit na may kasama.
Wala sa Google ang SRE
Well, ok, we delivered the delivery, it seems we can exhale, return to the good old days, when admins watched the processor load, tune the systems and quietly sipped something incomprehensible from mugs in peace and quiet... Stop. Hindi ito ang dahilan kung bakit namin sinimulan ang lahat (na sayang naman!). Biglang lumalabas na sa diskarte ng Google ay madali nating gamitin ang mahuhusay na kagawian - hindi ang pag-load ng processor ang mahalaga, at hindi kung gaano kadalas natin binabago ang mga disk doon, o na-optimize ang gastos sa cloud, ngunit ang mga sukatan ng negosyo ay parehong kilalang-kilala SLx. At walang sinuman ang nag-alis ng pamamahala sa imprastraktura mula sa kanila, at kailangan nilang lutasin ang mga insidente, at maging on duty sa pana-panahon, at sa pangkalahatan ay manatili sa tuktok ng mga proseso ng negosyo. At guys, simulan ang programming nang paunti-unti sa isang mahusay na antas, naghihintay na sa iyo ang Google.
Upang ibuod. Bigla, ngunit pagod ka na sa pagbabasa at hindi ka makapaghintay na dumura at sumulat sa may-akda sa isang komento sa artikulo. Ang DevOps bilang isang kasanayan sa paghahatid ay dati at magiging. At hindi ito pupunta kahit saan. Ang SRE bilang isang hanay ng mga kasanayan sa pagpapatakbo ay ginagawang matagumpay ang paghahatid na ito.
Pinagmulan: www.habr.com