Sino ang DevOps?

Sa ngayon, ito ang halos ang pinakamahal na posisyon sa merkado. Ang kaguluhan sa mga inhinyero ng "DevOps" ay lampas sa lahat ng maiisip na limitasyon, at mas masahol pa sa mga Senior DevOps engineer.
Nagtatrabaho ako bilang pinuno ng departamento ng integration at automation, hulaan ang English decoding - DevOps Manager. Hindi malamang na ang transcript ng Ingles ay sumasalamin sa aming mga pang-araw-araw na gawain, ngunit ang bersyon ng Ruso sa kasong ito ay mas tumpak. Dahil sa likas na katangian ng aking aktibidad, natural na kailangan kong makapanayam ang mga susunod na miyembro ng aking koponan, at sa nakalipas na taon, humigit-kumulang 50 tao ang dumaan sa akin, at ang parehong bilang ay naputol sa prescreen kasama ng aking mga empleyado.

Naghahanap pa rin kami ng mga kasamahan, dahil sa likod ng label ng DevOps ay may napakalaking layer ng iba't ibang uri ng mga inhinyero na nagtatago.

Ang lahat ng nakasulat sa ibaba ay aking personal na opinyon, hindi mo kailangang sumang-ayon dito, ngunit aminado ako na ito ay magdaragdag ng kaunting kulay sa iyong saloobin sa paksa. Sa kabila ng panganib na mawalan ng pabor, inilalathala ko ang aking opinyon dahil naniniwala ako na ito ay may tamang lugar.

Ang mga kumpanya ay may iba't ibang pang-unawa sa kung sino ang mga inhinyero ng DevOps at, para sa kapakanan ng mabilis na pagkuha ng mapagkukunan, isinasabit nila ang label na ito sa lahat. Ang sitwasyon ay medyo kakaiba, dahil ang mga kumpanya ay handa na magbayad ng hindi makatotohanang mga kabayaran sa mga taong ito, na tumatanggap, sa karamihan ng mga kaso, isang tool administrator para sa kanila.

Kaya sino ang mga inhinyero ng DevOps?

Magsimula tayo sa kasaysayan ng paglitaw nito - Ang Development Operations ay lumitaw bilang isa pang hakbang tungo sa pag-optimize ng pakikipag-ugnayan sa maliliit na team para mapabilis ang produksyon ng produkto, bilang inaasahang resulta. Ang ideya ay palakasin ang development team na may kaalaman sa mga pamamaraan at diskarte sa pamamahala sa kapaligiran ng produkto. Sa madaling salita, dapat na maunawaan at malaman ng developer kung paano gumagana ang kanyang produkto sa ilang mga kundisyon, dapat maunawaan kung paano i-deploy ang kanyang produkto, kung anong mga katangian ng kapaligiran ang maaaring iakma upang mapabuti ang pagganap. Kaya, sa loob ng ilang panahon, lumitaw ang mga developer na may diskarte sa DevOps. Ang mga developer ng DevOps ay nagsulat ng mga script ng build at packaging upang pasimplehin ang kanilang mga aktibidad at ang pagganap ng kapaligiran ng produksyon. Gayunpaman, ang pagiging kumplikado ng arkitektura ng solusyon at ang magkaparehong impluwensya ng mga bahagi ng imprastraktura sa paglipas ng panahon ay nagsimulang lumala sa pagganap ng mga kapaligiran; sa bawat pag-ulit, ang isang mas malalim na pag-unawa sa ilang mga bahagi ay kinakailangan, na binabawasan ang pagiging produktibo ng developer dahil sa karagdagang mga gastos sa pag-unawa sa mga bahagi at mga sistema ng pag-tune para sa isang partikular na gawain. . Ang sariling gastos ng developer ay lumago, ang gastos ng produkto kasama nito, ang mga kinakailangan para sa mga bagong developer sa koponan ay tumalon nang husto, dahil kailangan din nilang masakop ang mga responsibilidad ng pag-unlad na "bituin" at, natural, ang "mga bituin" ay naging mas kaunti at hindi gaanong magagamit. Kapansin-pansin din na, sa aking karanasan, ilang mga developer ang interesado sa mga detalye ng pagpoproseso ng packet ng kernel ng operating system, mga panuntunan sa pagruruta ng packet, at mga aspeto ng seguridad ng host. Ang lohikal na hakbang ay upang maakit ang isang tagapangasiwa na pamilyar dito at magtalaga ng mga katulad na responsibilidad sa kanya, na, salamat sa kanyang karanasan, naging posible na makamit ang parehong mga tagapagpahiwatig sa mas mababang gastos kumpara sa gastos ng pag-unlad ng "bituin". Ang mga naturang administrator ay inilagay sa isang koponan at ang kanyang pangunahing gawain ay ang pamahalaan ang mga kapaligiran sa pagsubok at produksyon, ayon sa mga patakaran ng isang partikular na koponan, na may mga mapagkukunang inilalaan sa partikular na pangkat na ito. Ganito, sa katunayan, lumitaw ang DevOps sa isipan ng karamihan.

Bahagyang o ganap, sa paglipas ng panahon, ang mga system administrator na ito ay nagsimulang maunawaan ang mga pangangailangan ng partikular na pangkat na ito sa larangan ng pag-unlad, kung paano gawing mas madali ang buhay para sa mga developer at tester, kung paano ilunsad ang isang update at hindi kailangang manatili ng magdamag sa Biyernes sa sa opisina, pagwawasto ng mga error sa deployment. Lumipas ang oras, at ngayon ang "mga bituin" ay mga tagapangasiwa ng system na nakauunawa sa gusto ng mga developer. Upang mabawasan ang epekto, nagsimulang lumitaw ang mga utility sa pamamahala; naalala ng lahat ang luma at maaasahang mga pamamaraan ng paghiwalay sa antas ng OS, na naging posible upang mabawasan ang mga kinakailangan para sa seguridad, pamamahala ng bahagi ng network, at pagsasaayos ng host bilang isang buo at, bilang isang resulta, bawasan ang mga kinakailangan para sa mga bagong "bituin".

Isang "kahanga-hangang" bagay ang lumitaw - docker. Bakit kahanga-hanga? Oo, dahil lamang sa paglikha ng paghihiwalay sa isang chroot o kulungan, pati na rin ang OpenVZ, ay nangangailangan ng hindi walang kuwentang kaalaman sa OS, sa kabaligtaran, pinapayagan ka ng utility na lumikha lamang ng isang nakahiwalay na kapaligiran ng application sa isang tiyak na host na may lahat ng kailangan sa loob at kamay. sa reins ng pag-unlad muli, at ang system administrator ay maaari lamang pamahalaan sa isang host lamang, tinitiyak ang seguridad at mataas na kakayahang magamit - isang lohikal na pagpapasimple. Ngunit ang pag-unlad ay hindi tumitigil at ang mga sistema ay muling nagiging mas kumplikado, parami nang parami ang mga bahagi, ang isang host ay hindi na nakakatugon sa mga pangangailangan ng system at ito ay kinakailangan upang bumuo ng mga kumpol, muli tayong bumalik sa mga tagapangasiwa ng system na kayang bumuo ng mga sistemang ito.

Lumilitaw ang iba't ibang mga sistema na nagpapasimple sa pag-unlad at/o pangangasiwa, lumilitaw ang mga sistema ng orkestrasyon, na, hanggang sa kailangan mong lumihis mula sa karaniwang proseso, ay madaling gamitin. Lumitaw din ang arkitektura ng microservice na may layuning gawing simple ang lahat ng inilarawan sa itaas - mas kaunting mga relasyon, mas madaling pamahalaan. Sa aking karanasan, hindi ako nakahanap ng isang ganap na arkitektura ng microservice, sasabihin ko na 50 hanggang 50 - 50 porsiyento ng mga microservice, mga itim na kahon, pumasok, lumabas na naproseso, ang iba pang 50 ay isang punit na monolith, ang mga serbisyo ay hindi gumana nang hiwalay sa iba mga bahagi. Ang lahat ng ito ay muling nagpataw ng mga paghihigpit sa antas ng kaalaman ng parehong mga developer at administrator.

Ang mga katulad na "swings" sa antas ng kaalaman ng eksperto sa isang partikular na mapagkukunan ay nagpapatuloy hanggang sa araw na ito. Ngunit lumihis kami ng kaunti, mayroong maraming mga puntos na dapat i-highlight.

Build Engineer/Release Engineer

Napakahusay na mga inhinyero na lumitaw bilang isang paraan ng pag-standardize ng mga proseso at paglabas ng software. Sa proseso ng pagpapakilala ng malawakang Agile, tila hindi na sila hinihiling, ngunit malayo ito sa kaso. Ang espesyalisasyon na ito ay lumitaw bilang isang paraan ng pag-standardize ng pagpupulong at paghahatid ng software sa isang pang-industriya na sukat, i.e. gamit ang mga karaniwang pamamaraan para sa lahat ng produkto ng kumpanya. Sa pagdating ng DevOps, bahagyang nawala ang mga pag-andar ng mga developer, dahil ang mga developer ang nagsimulang maghanda ng produkto para sa paghahatid, at binigyan ang pagbabago ng imprastraktura at diskarte sa paghahatid nang mabilis hangga't maaari nang walang pagsasaalang-alang sa kalidad, sa paglipas ng panahon sila ay naging isang stopper ng mga pagbabago, dahil ang pagsunod sa mga pamantayan ng kalidad ay tiyak na nagpapabagal sa mga paghahatid. Kaya, unti-unti, ang bahagi ng functionality ng mga Build/Release engineer ay lumipat sa mga balikat ng mga administrator ng system.

Iba talaga ang ops

Nagpapatuloy kami at muli ang pagkakaroon ng isang malaking hanay ng mga responsibilidad at ang kakulangan ng mga kwalipikadong tauhan ay nagtutulak sa amin patungo sa mahigpit na espesyalisasyon, tulad ng mga kabute pagkatapos ng ulan, iba't ibang mga Operasyon ang lilitaw:

• TechOps - mga enikey system administrator aka HelpDesk Engineer
• LiveOps - mga administrator ng system ang pangunahing responsable para sa mga kapaligiran ng produksyon
• CloudOps - mga administrator ng system na nag-specialize sa mga pampublikong ulap Azure, AWS, GCP, atbp.
• PlatOps/InfraOps/SysOps - mga administrator ng sistema ng imprastraktura.
• NetOps - mga administrator ng network
• SecOps - mga administrador ng system na dalubhasa sa seguridad ng impormasyon - pagsunod sa PCI, pagsunod sa CIS, pag-patch, atbp.

Ang DevOps ay (sa teorya) isang tao na unang nauunawaan ang lahat ng mga proseso ng cycle ng pag-unlad - pag-unlad, pagsubok, naiintindihan ang arkitektura ng produkto, nagagawang masuri ang mga panganib sa seguridad, pamilyar sa mga diskarte at mga tool sa automation, kahit na sa isang mataas na antas. antas, bilang karagdagan dito, nauunawaan din ang suporta sa pagpapalabas ng produkto bago at pagkatapos ng pagproseso. Isang taong may kakayahang kumilos bilang isang tagapagtaguyod para sa parehong Operasyon at Pag-unlad, na nagbibigay-daan para sa paborableng kooperasyon sa pagitan ng dalawang haliging ito. Nauunawaan ang mga proseso ng pagpaplano ng trabaho ng mga koponan at pamamahala ng mga inaasahan ng customer.

Upang maisagawa ang ganitong uri ng trabaho at mga responsibilidad, ang taong ito ay dapat magkaroon ng paraan upang pamahalaan hindi lamang ang mga proseso ng pag-unlad at pagsubok, kundi pati na rin ang pamamahala ng imprastraktura ng produkto, pati na rin ang pagpaplano ng mapagkukunan. Ang mga DevOps sa pag-unawang ito ay hindi matatagpuan sa IT, o sa R&D, o kahit sa PMO; dapat ay may impluwensya ito sa lahat ng mga lugar na ito - ang teknikal na direktor ng kumpanya, ang Chief Technical Officer.

Totoo ba ito sa iyong kumpanya? - Nagdududa ako. Sa karamihan ng mga kaso, ito ay alinman sa IT o R&D.

Ang kakulangan ng pondo at kakayahang maimpluwensyahan ang hindi bababa sa isa sa tatlong bahagi ng aktibidad na ito ay maglilipat sa bigat ng mga problema patungo sa kung saan mas madaling ilapat ang mga pagbabagong ito, tulad ng paglalapat ng mga teknikal na paghihigpit sa mga release na may kaugnayan sa "marumi" na code ayon sa static mga sistema ng analisador. Ibig sabihin, kapag nagtakda ang PMO ng mahigpit na deadline para sa pagpapalabas ng functionality, hindi makakagawa ang R&D ng mataas na kalidad na resulta sa loob ng mga deadline na ito at makakagawa nito sa abot ng makakaya nito, na iniiwan ang refactoring para sa ibang pagkakataon, hinaharangan ng DevOps na nauugnay sa IT ang paglabas sa pamamagitan ng mga teknikal na paraan. . Ang kakulangan ng awtoridad na baguhin ang sitwasyon, sa kaso ng mga responsableng empleyado, ay humahantong sa pagpapakita ng sobrang responsibilidad para sa hindi nila maimpluwensyahan, lalo na kung ang mga empleyadong ito ay naiintindihan at nakikita ang mga pagkakamali, at kung paano itama ang mga ito - "Ang kaligayahan ay kamangmangan", at bilang resulta sa pagka-burnout at pagkawala ng mga empleyadong ito.

Market ng mapagkukunan ng DevOps

Tingnan natin ang ilang bakante para sa mga posisyon sa DevOps mula sa iba't ibang kumpanya.

Handa kaming makipagkita sa iyo kung ikaw ay:

1. Pagmamay-ari mo ang Zabbix at alam mo kung ano ang Prometheus;
2. Iptables;
3. BASH PhD Student;
4. Propesor Ansible;
5. Linux Guru;
6. Alamin kung paano gumamit ng pag-debug at maghanap ng mga problema sa application kasama ng mga developer (php/java/python);
7. Ang pagruruta ay hindi nakakapagpa-hysterical sa iyo;
8. Bigyang-pansin ang seguridad ng system;
9. I-backup ang "kahit ano at lahat", at matagumpay ding ibalik itong "kahit ano at lahat";
10. Alam mo kung paano i-configure ang system sa paraang makuha ang maximum sa minimum;
11. Mag-set up ng replikasyon bago matulog sa Postgres at MySQL;
12. Ang pag-set up at pagsasaayos ng CI/CD ay kasing kinakailangan para sa iyo gaya ng almusal/tanghalian/hapunan.
13. Magkaroon ng karanasan sa AWS;
14. Handa nang umunlad kasama ng kumpanya;

Kaya:

• mula 1 hanggang 6 - tagapangasiwa ng system
• 7 - isang maliit na pangangasiwa ng network, na umaangkop din sa administrator ng system, Middle level
• 8 - isang maliit na seguridad, na sapilitan para sa isang Middle level na system administrator
• 9-11 – Administrator ng Gitnang System
• 12 — Depende sa mga nakatalagang gawain, alinman sa Middle System Administrator o Build Engineer
• 13 - Virtualization - Middle System Administrator, o ang tinatawag na CloudOps, advanced na kaalaman sa mga serbisyo ng isang partikular na hosting site, para sa mahusay na paggamit ng mga pondo at pagbabawas ng load sa maintenance

Summarizing this vacancy, we can say na Middle/Senior System Administrator is enough for the guys.

Sa pamamagitan ng paraan, hindi mo dapat malakas na hatiin ang mga administrator sa Linux/Windows. Siyempre, naiintindihan ko na ang mga serbisyo at sistema ng dalawang mundong ito ay magkaiba, ngunit ang batayan para sa lahat ay pareho at sinumang may paggalang sa sarili na admin ay pamilyar sa isa at sa isa, at kahit na hindi siya pamilyar, ito ay hindi mahirap para sa isang karampatang admin na maging pamilyar dito.

Isaalang-alang natin ang isa pang bakante:

1. Karanasan sa pagbuo ng mga high-load system;
2. Napakahusay na kaalaman sa Linux OS, pangkalahatang software ng system at web stack (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
3. Karanasan sa virtualization system (KVM, VMWare, LXC/Docker);
4. Kahusayan sa mga wika ng scripting;
5. Pag-unawa sa mga prinsipyo ng pagpapatakbo ng mga network protocol network;
6. Pag-unawa sa mga prinsipyo ng pagbuo ng fault-tolerant system;
7. Kalayaan at inisyatiba;

Tignan natin:

• 1 – Senior System Administrator
• 2 - Depende sa kahulugan na inilagay sa stack na ito - Middle/Senior System Administrator
• 3 - Ang karanasan sa trabaho, kasama ang, ay maaaring mangahulugan - "Ang cluster ay hindi tumaas, ngunit lumikha at pinamahalaan ang mga virtual machine, mayroong isang Docker host, ang access sa mga container ay hindi magagamit" - Middle System Administrator
• 4 - Junior System Administrator - oo, isang admin na hindi alam kung paano magsulat ng mga pangunahing script ng automation, anuman ang wika, hindi isang admin - enikey.
• 5 - Administrator ng Middle System
• 6 – Senior System Administrator

Upang ibuod - Middle/Senior System Administrator

Isa pa:

1. Devops karanasan;
2. Karanasan sa paggamit ng isa o higit pang mga produkto upang lumikha ng mga proseso ng CI/CD. Ang Gitlab CI ay magiging isang kalamangan;
3. Paggawa gamit ang mga lalagyan at virtualization; Kung gumamit ka ng docker, mabuti, ngunit kung gumamit ka ng mga k8, mahusay!
4. Karanasan sa pagtatrabaho sa isang mabilis na koponan;
5. Kaalaman sa anumang programming language;

Tingnan natin:

• 1 - Hmm... Ano ang ibig sabihin ng mga lalaki? =) Malamang sila mismo ay hindi alam kung ano ang nakatago sa likod nito
• 2 - Build Engineer
• 3 - Administrator ng Middle System
• 4 - Soft skill, hindi natin ito isasaalang-alang sa ngayon, bagama't ang Agile ay isa pang bagay na binibigyang kahulugan sa paraang maginhawa.
• 5 - Masyadong verbose - maaaring ito ay isang scripting language o isang compiled one. Iniisip ko kung ang pagsusulat sa Pascal at Basic sa paaralan ay babagay sa kanila? =)

Nais ko ring mag-iwan ng tala tungkol sa punto 3 upang palakasin ang pag-unawa kung bakit ang puntong ito ay sakop ng system administrator. Ang Kubernetes ay isa lamang orkestrasyon, isang tool na bumabalot ng mga direktang command sa mga driver ng network at virtualization/isolation host sa ilang command at nagbibigay-daan sa iyong gawing abstract ang komunikasyon sa kanila, iyon lang. Halimbawa, gawin natin ang 'build framework' na Gumawa, na, sa pamamagitan ng paraan, hindi ko isinasaalang-alang ang isang balangkas. Oo, alam ko ang tungkol sa fashion ng shoving Make kahit saan, kung saan ito ay kinakailangan at hindi kailangan - pambalot Maven sa Make, halimbawa, seryoso?
Sa pangkalahatan, ang Make ay isang wrapper lamang sa ibabaw ng shell, na pinapasimple ang compilation, linking, at compilation environment na mga command, tulad ng k8s.

Minsan, nakapanayam ko ang isang lalaki na gumamit ng mga k8 sa kanyang trabaho sa tuktok ng OpenStack, at pinag-usapan niya kung paano niya inilagay ang mga serbisyo dito, gayunpaman, nang magtanong ako tungkol sa OpenStack, ito ay pinangangasiwaan, pati na rin ang itinaas ng system mga tagapangasiwa. Talaga bang iniisip mo na ang isang taong nag-install ng OpenStack, anuman ang ginagamit niyang platform sa likod niya, ay hindi makakagamit ng k8s? =)
Ang aplikanteng ito ay hindi talaga isang DevOps, ngunit isang System Administrator at, upang maging mas tumpak, isang Kubernetes Administrator.

Muli nating ibuod - Sapat na para sa kanila ang Middle/Senior System Administrator.

Magkano ang timbangin sa gramo

Ang hanay ng mga panukalang suweldo para sa mga ipinahiwatig na bakante ay 90k-200k
Ngayon gusto kong gumuhit ng isang parallel sa pagitan ng monetary rewards ng System Administrators at DevOps Engineers.

Sa prinsipyo, upang gawing simple ang mga bagay, maaari mong ikalat ang mga marka batay sa karanasan sa trabaho, kahit na hindi ito magiging eksakto, ngunit para sa mga layunin ng artikulo ito ay magiging sapat.

Isang karanasan:

1. hanggang 3 taon - Junior
2. hanggang 6 na taong gulang - Gitna
3. higit sa 6 – Senior

Nag-aalok ang site ng paghahanap ng empleyado:
Mga Administrator ng System:

1. Junior - 2 taon - 50k kuskusin.
2. Gitna - 5 taon - 70k kuskusin.
3. Senior - 11 taon - 100k kuskusin.

Mga Inhinyero ng DevOps:

1. Junior - 2 taon - 100k kuskusin.
2. Gitna - 3 taon - 160k kuskusin.
3. Senior - 6 taon - 220k kuskusin.

Ayon sa karanasan ng "DevOps", ginamit ang karanasan na kahit papaano ay nakaapekto sa SDLC.

Mula sa itaas, ito ay sumusunod na sa katunayan ang mga kumpanya ay hindi nangangailangan ng DevOps, at din na maaari silang makatipid ng hindi bababa sa 50 porsyento ng mga unang binalak na gastos sa pamamagitan ng pagkuha ng isang Administrator; bukod pa rito, mas malinaw nilang matukoy ang mga responsibilidad ng taong hinahanap nila. at punan ang pangangailangan nang mas mabilis. Hindi rin natin dapat kalimutan na ang isang malinaw na dibisyon ng mga responsibilidad ay nagpapahintulot sa amin na bawasan ang mga kinakailangan para sa mga tauhan, gayundin ang lumikha ng isang mas kanais-nais na kapaligiran sa koponan, dahil sa kawalan ng mga overlap. Ang karamihan sa mga bakante ay puno ng mga utility at mga label ng DevOps, ngunit hindi sila nakabatay sa aktwal na mga kinakailangan para sa isang DevOps Engineer, mga kahilingan lamang para sa isang tool administrator.

Ang proseso ng pagsasanay sa mga inhinyero ng DevOps ay limitado lamang sa isang hanay ng mga partikular na gawain, mga kagamitan, at hindi nagbibigay ng pangkalahatang pag-unawa sa mga proseso at sa kanilang mga dependency. Tiyak na mabuti kapag ang isang tao ay maaaring mag-deploy ng AWS EKS gamit ang Terraform, kasabay ng Fluentd sidecar sa cluster na ito at ang AWS ELK stack para sa logging system sa loob ng 10 minuto, gamit lamang ang isang command sa console, ngunit kung hindi niya naiintindihan ang prinsipyo ng pagproseso ng sarili nitong mga log at kung ano ang kailangan ng mga ito, kung hindi mo alam kung paano mangolekta ng mga sukatan sa mga ito at subaybayan ang pagkasira ng serbisyo, kung gayon ito pa rin ang parehong enikey na marunong gumamit ng ilang mga utility.

Ang demand, gayunpaman, ay lumilikha ng supply, at nakikita namin ang sobrang init na merkado para sa posisyon ng DevOps, kung saan ang mga kinakailangan ay hindi tumutugma sa aktwal na tungkulin, ngunit pinapayagan lamang ang mga administrator ng system na kumita ng higit pa.

So sino sila? DevOps o sakim na mga administrator ng system? =)

Paano magpatuloy sa buhay?

Ang mga tagapag-empleyo ay dapat magbalangkas ng mga kinakailangan nang mas tumpak at hanapin ang eksaktong mga kinakailangan, at hindi magtapon ng mga label. Hindi mo alam kung ano ang ginagawa ng DevOps - hindi mo kailangan ang mga ito sa kasong iyon.

Manggagawa - Matuto. Patuloy na pagbutihin ang iyong kaalaman, tingnan ang pangkalahatang larawan ng mga proseso at subaybayan ang landas patungo sa iyong layunin. Pwede kang maging kahit sinong gusto mo, kailangan mo lang subukan.

Pinagmulan: www.habr.com