D'r is gjin bettere tiid om te learen yn it libben dan hjoed.
It is 2019, en DevOps is relevanter dan ea. Se sizze dat de dagen fan systeembehearders foarby binne, krekt as it tiidrek fan 'e mainframe. Mar is dit echt sa?
Lykas faak bart yn IT, is de situaasje feroare. De DevOps-metodology is ûntstien, mar it kin net bestean sûnder in persoan mei systeembehearderfeardigens, dat is sûnder Ops.
Foardat de DevOps-oanpak syn moderne foarm oannaam, klassifisearre ik mysels as in Ops. En ik wit hiel goed wat in systeembehearder ûnderfynt as er beseft hoefolle er noch net kin en hoe min tiid er hat om it te learen.
Mar is it echt sa eng? Ik soe sizze dat gebrek oan kennis net as in soarte fan grut probleem ûnderfûn wurde moat. It is mear in profesjonele útdaging.
Produkten op webskaal binne basearre op Linux of oare iepen boarne software, en d'r binne hieltyd minder minsken op 'e merke dy't se kinne behâlde. De fraach hat it oantal profesjonals op dit mêd al grutter. In systeembehearder sil net langer yn steat wêze om gewoan troch te wurkjen sûnder syn feardigensnivo te ferbetterjen. Hy moat automatisearringsfeardigens hawwe om meardere servers / knopen te behearjen en in goed begryp te hawwen fan hoe't se wurkje om problemen op te lossen dy't ûntsteane.
Foardat jo lid wurde fan it DevOps-team, moatte jo in nochal lange, mar ynteressante reis trochgean, nije technologyen leare en ferskate ark nedich om it systeem te ûnderhâlden neffens DevOps-standerts.
Dus, hoe kin in systeembehearder oergean fan 'e gewoane oanpak om te wurkjen nei it nije konsept fan DevOps? Alles is as gewoanlik: earst moatte jo jo tinken feroarje. It is net maklik om de oanpak dy't jo de lêste tsien of tweintich jier folge hawwe op te jaan en dingen oars te dwaan, mar it is needsaaklik.
Alderearst is it wichtich om te begripen dat DevOps gjin spesifike posysje is yn in bedriuw, mar in set fan spesifike praktiken. Dizze praktiken betsjutte de distribúsje fan isolearre systemen, it ferminderjen fan de skea fan bugs en flaters, faak en op 'e tiid software-updates, goed fêstige ynteraksje tusken ûntwikkelders (Dev) en behearders (Ops), lykas konstante testen fan net allinich de koade, mar ek de hiele struktuer binnen it proses .
Tegearre mei it feroarjen fan 'e manier fan tinken, moatte jo leare hoe't jo de ynfrastruktuer behâlde en har stabile wurking, betrouberens en beskikberens soargje foar trochgeande yntegraasje en levering fan applikaasjes, tsjinsten en software.
Wat jo miskien misse as in Ops-profesjonele is programmearfeardigens. No it skriuwen fan skripts (skripts), dy't systeembehearders brûke om automatysk patches op in server te ynstallearjen, bestannen en akkounts te behearjen, problemen op te lossen en dokumintaasje te kompilearjen, wurdt al beskôge as ferâldere. Skripting jildt noch yn relatyf ienfâldige gefallen, mar DevOps giet oer it oplossen fan grutskalige problemen, of it no ymplemintaasje, testen, builds of ynset is.
Dus, as jo automatisearring wolle leare, moatte jo op syn minst in bytsje programmearring behearskje, sels as jo gjin ûntwikkelder binne, om't op dit stadium fan jo ûntwikkeling yn DevOps fereasket dizze feardigens.
Wat te dwaan? Om as spesjalist yn 'e fraach te bliuwen, moatte jo relevante feardichheden krije - op syn minst ien programmeartaal behearskje, bygelyks Python. Dit kin lestich lykje foar in persoan dy't profesjoneel belutsen is by administraasje, om't hy wend is om te tinken dat allinich ûntwikkelers programmearje. It is net nedich om in ekspert te wurden, mar kennis fan ien fan 'e programmeartalen (it kin Python, Bash of sels wêze ), sil perfoarst in foardiel wêze.
Learje om te programmearjen duorret wat tiid. Omtinken en geduldich te wêzen sil jo helpe om op 'e hichte te bliuwen by it kommunisearjen mei DevOps-teamleden en klanten. In heal oere deis, in oere of mear, it learen fan in programmeartaal moat jo haaddoel wêze.
Systeembehearders en DevOps-spesjalisten losse ferlykbere problemen op, lykwols binne d'r wichtige ferskillen. It wurdt leaud dat in systeembehearder net alles kin dwaan wat in DevOps-yngenieur kin. Se sizze dat de systeembehearder mear rjochte is op it konfigurearjen, ûnderhâlden en garandearjen fan de prestaasjes fan serversystemen, mar de DevOps-yngenieur lûkt al dizze karre en in oare lytse karre.
Mar hoe wier is dizze útspraak?
Systeembehearder: ien strider yn it fjild
Nettsjinsteande de ferskillen en oerienkomsten opmurken yn dit artikel, leau ik noch dat d'r gjin signifikant ferskil is tusken systeembehear en DevOps. Systeembehearders hawwe altyd deselde funksjes útfierd as DevOps-spesjalisten, it is gewoan dat gjinien it earder DevOps neamde. Ik leau dat it gjin punt hat om spesifyk nei ferskillen te sykjen, benammen as it net relatearre is oan elke taak. Ferjit net dat, yn tsjinstelling ta in systeembehearder, DevOps gjin posysje is, mar in konsept.
Ien mear wichtich ding moat wurde opmurken, sûnder dat in petear oer sawol administraasje as DevOps ûnfolslein sil wêze. Systeemadministraasje yn 'e gewoane sin giet derfan út dat in spesjalist in spesifike set fan feardichheden hat en rjochte is op it betsjinjen fan ferskate soarten ynfrastruktuer. Net yn de sin dat it om in universele meiwurker giet, mar yn de sin dat der in tal taken troch alle bestjoerders útfierd wurde.
Sa moatte se sa no en dan fungearje as in soarte fan technysk handyman, dat is, letterlik alles dwaan. En as der mar ien sa'n behearder is foar de hiele organisaasje, dan sil hy yn 't algemien alle technyske wurken útfiere. Dit kin alles wêze fan it ûnderhâlden fan printers en kopiearapparaten oant it útfieren fan netwurk-relatearre taken lykas it opsetten en behearen fan routers en skeakels of it konfigurearjen fan in firewall.
Hy sil ek ferantwurdlik wêze foar hardware-upgrades, log-ynspeksje en analyse, befeiligingskontrôles, tsjinner patching, troubleshooting, root-oarsaakanalyse, en automatisearring - typysk fia PowerShell, Python, of Bash-skripts. In foarbyld fan gebrûk is it behear fan brûkers- en groepsakkounts. Brûkersakkounts oanmeitsje en tagongsrjochten tawize is in ekstreem ferfeelsume taak, om't brûkers hast elke dei ferskine en ferdwine. Automatisearring troch skripts makket tiid frij foar wichtiger ynfrastruktuertaken, lykas it opwurdearjen fan switches en servers en oare projekten dy't ynfloed hawwe op de profitabiliteit fan it bedriuw dêr't de behearder wurket (ek al is it algemien akseptearre dat de IT-ôfdieling net direkt ynkommen generearret).
De taak fan de systeembehearder is gjin tiid te fergrieme en it bedriuw jild op elke mooglike manier te besparjen. Soms wurkje systeembehearders as leden fan in grut team, ferienigje bygelyks behearders fan Linux, Windows, databases, opslach, ensfh. Wurkskema's ferskille ek. Bygelyks, in ferskowing yn ien tiidsône oan 'e ein fan' e dei ferpleatst gefallen nei de folgjende ferskowing yn in oare tiidsône, sadat prosessen net stopje (folgje de sinne); of meiwurkers hawwe in normale wurkdei út 9 oan 5; of it wurket yn in XNUMX/XNUMX datasintrum.
Yn 'e rin fan' e tiid hawwe systeembehearders leard om strategysk te tinken en wichtige saken te kombinearjen mei routinetaken. De teams en ôfdielingen dêr't se yn wurkje, hawwe meastentiids tekoart oan middels, mar tagelyk besiket elkenien de deistige taken yn 'e measte omfang te foltôgjen.
DevOps: ûntwikkeling en ûnderhâld as ien
is in soarte fan filosofy foar de ûntwikkeling en ûnderhâld prosessen. Dizze oanpak yn 'e IT-wrâld is wirklik ynnovatyf wurden.
Under de paraplu fan DevOps is d'r in softwareûntwikkelingsteam oan 'e iene kant en in ûnderhâldsteam oan' e oare. Se wurde faak ferbûn troch spesjalisten foar produktbehear, testers en ûntwerpers fan brûkersynterface. Tegearre streamline dizze saakkundigen operaasjes om fluch nije applikaasjes en koade-updates út te rollen om de effisjinsje fan it heule bedriuw te stypjen en te ferbetterjen.
DevOps is basearre op kontrôle oer de ûntwikkeling en eksploitaasje fan software yn har heule libbenssyklus. Underhâldsminsken moatte ûntwikkelders stypje, en ûntwikkelders hawwe de opdracht mear te begripen dan allinich de API's dy't yn systemen brûkt wurde. Se moatte begripe wat der ûnder de motorkap sit (dat is, hoe't hardware en bestjoeringssystemen funksjonearje), sadat se bugs better kinne omgean, problemen oplosse en ynteraksje kinne mei servicetechnisy.
Systeembehearders kinne ferhúzje nei in DevOps-team as se de lêste technologyen wolle leare en iepen binne foar ynnovative ideeën en oplossingen. Lykas ik earder sei, hoege se gjin folweardige programmeurs te wurden, mar it behearskjen fan in programmeartaal lykas Ruby, Python of Go sil har helpe om tige brûkbere leden fan it team te wurden. Hoewol't systeembehearders tradysjoneel al it wurk sels dogge en faaks as iensumers wurde sjoen, hawwe se yn DevOps in folslein tsjinoerstelde ûnderfining, wêrby't elkenien yn it proses mei-inoar omgiet.
It ûnderwerp fan automatisearring wurdt hieltyd relevanter. Sawol systeembehearders as DevOps-spesjalisten binne ynteressearre yn fluch skaalfergrutting, ferminderjen fan flaters, en fluch fine en reparearje besteande flaters. Sa is automatisearring in konsept dêr't twa gebieten gearkomme. Systeembehearders binne ferantwurdlik foar wolktsjinsten lykas AWS, Azure en Google Cloud Platform. Se moatte de prinsipes fan trochgeande yntegraasje en levering begripe en hoe't jo ark kinne brûke lykas .
Derneist moatte systeembehearders konfiguraasje- en behearynstruminten brûke lykas , nedich foar parallelle ynset fan tsien of tweintich tsjinners.
It wichtichste konsept is . Software is alles. Yn feite, om it berop fan in systeembehearder gjin relevânsje te ferliezen, moatte jo gewoan de klam in bytsje feroarje. Systeembehearders binne yn it tsjinstbedriuw en moatte effektyf kinne kommunisearje mei ûntwikkelders, en oarsom. As se sizze, ien holle is goed, mar twa binne better.
En it lêste detail yn dit meganisme is . Wurkje mei Git is ien fan 'e tradisjonele deistige ferantwurdlikheden fan in systeembehearder. Dit ferzjekontrôlesysteem wurdt in protte brûkt troch ûntwikkelders, DevOps-spesjalisten, Agile-teams en in protte oaren. As jo wurk relatearre is oan 'e software-libbensyklus, dan sille jo perfoarst wurkje mei Git.
Git hat in protte funksjes. Jo sille wierskynlik noait alle Git-kommando's leare, mar jo sille presys begripe wêrom't it in haadstik is yn softwarekommunikaasje en gearwurking. In yngeande kennis fan Git is heul wichtich as jo wurkje yn in DevOps-team.
As jo in systeembehearder binne, dan moatte jo Git better studearje, begripe hoe't ferzjekontrôle is boud en de mienskiplike kommando's ûnthâlde: git status, git commit -m, git add, git pull, git push, git rebase, git branch, git diff en oaren. D'r binne in protte online kursussen en boeken dy't jo kinne helpe dit ûnderwerp fanôf it begjin te learen en in profesjonele te wurden mei spesifike feardigens. Der binne ek prachtich , dus jo hoege se net allegear te proppen, mar hoe mear jo Git brûke, hoe makliker it sil wêze.
konklúzje
Uteinlik beslute jo as jo in DevOps-spesjalist moatte wurde of dat it better is om in systeembehearder te bliuwen. Sa't jo sjen kinne, is d'r in learkurve om de oergong te meitsjen, mar hoe earder jo begjinne, hoe better. Kies in programmeartaal en lear tagelyk ark lykas (ferzje kontrôle), (CI / CD, trochgeande yntegraasje) en (konfiguraasje en automatisearring). Hokker opsje jo ek kieze, ferjit net dat jo jo feardigens konstant moatte leare en ferbetterje.
Boarne: www.habr.com