ProHoster > Blogs > Administrācija > Kas ir DevOps?

Kas ir DevOps?

Å obrÄ«d Ŕī ir gandrÄ«z visdārgākā pozÄ«cija tirgÅ«. Satraukums ap ā€œDevOpsā€ inženieriem pārsniedz visus iedomājamos ierobežojumus, un tas ir vēl sliktāks ar vecāka gadagājuma DevOps inženieriem.
Es strādāju par integrācijas un automatizācijas nodaļas vadÄ«tāju, uzminiet angļu valodas dekodÄ“Å”anu - DevOps Manager. Diez vai angļu stenogramma atspoguļo mÅ«su ikdienas aktivitātes, taču krievu versija Å”ajā gadÄ«jumā ir precÄ«zāka. Manas darbÄ«bas rakstura dēļ ir likumsakarÄ«gi, ka man ir jāintervē nākamie savas komandas locekļi, un pēdējā gada laikā caur mani ir izgājuÅ”i apmēram 50 cilvēki, un tikpat daudz ir nogriezts priekÅ”skatÄ«jumā ar maniem darbiniekiem.

Joprojām meklējam kolēģus, jo aiz DevOps etiķetes slēpjas ļoti liels slānis dažāda veida inženieru.

Viss zemāk rakstītais ir mans personīgais viedoklis, tam nav jāpiekrīt, bet pieļauju, ka tas pieliks kādu krāsu tavai attieksmei pret tēmu. Neskatoties uz risku izkrist no labvēlības, publicēju savu viedokli, jo uzskatu, ka tam ir kur būt.

Uzņēmumiem ir atŔķirÄ«ga izpratne par to, kas ir DevOps inženieri, un, lai ātri pieņemtu darbā resursus, tie visiem pieliek Å”o etiÄ·eti. Situācija ir visai dÄ«vaina, jo uzņēmumi ir gatavi Å”iem cilvēkiem maksāt nereālus atalgojumus, vairumā gadÄ«jumu par tiem saņemot rÄ«ku administratoru.

Tātad, kas ir DevOps inženieri?

Sāksim ar tā parādÄ«Å”anās vēsturi ā€“ attÄ«stÄ«bas operācijas parādÄ«jās kā vēl viens solis ceļā uz mijiedarbÄ«bas optimizÄ“Å”anu mazās komandās, lai palielinātu produktu ražoÅ”anas ātrumu, kā paredzamās sekas. Ideja bija stiprināt izstrādes komandu ar zināŔanām par procedÅ«rām un pieejām produktu vides pārvaldÄ«bā. Citiem vārdiem sakot, izstrādātājam ir jāsaprot un jāzina, kā viņa produkts darbojas noteiktos apstākļos, ir jāsaprot, kā izvietot savu produktu, kādas vides Ä«paŔības var pielāgot, lai uzlabotu veiktspēju. Tātad kādu laiku parādÄ«jās izstrādātāji ar DevOps pieeju. DevOps izstrādātāji rakstÄ«ja veidoÅ”anas un iepakoÅ”anas skriptus, lai vienkārÅ”otu savas darbÄ«bas un ražoÅ”anas vides veiktspēju. Tomēr risinājuma arhitektÅ«ras sarežģītÄ«ba un infrastruktÅ«ras komponentu savstarpējā ietekme laika gaitā sāka pasliktināt vidi veiktspēju; ar katru iterāciju bija nepiecieÅ”ama arvien dziļāka izpratne par atseviŔķiem komponentiem, samazinot izstrādātāja produktivitāti papildu izmaksas, kas saistÄ«tas ar komponentu un regulÄ“Å”anas sistēmu izpratni konkrētam uzdevumam. Pieauga paÅ”a izstrādātāja paÅ”izmaksa, lÄ«dz ar to arÄ« produkta paÅ”izmaksa, strauji uzlēca prasÄ«bas jaunajiem izstrādātājiem komandā, jo bija jāsedz arÄ« izstrādes ā€œzvaigznesā€ pienākumi un, protams, ā€œzvaigžņuā€ kļuva mazāk. un mazāk pieejami. Ir arÄ« vērts atzÄ«mēt, ka, pēc manas pieredzes, dažus izstrādātājus interesē operētājsistēmas kodola pakeÅ”u apstrādes specifika, pakeÅ”u marÅ”rutÄ“Å”anas noteikumi un resursdatora droŔības aspekti. LoÄ£isks solis bija piesaistÄ«t administratoru, kurÅ” to pārzina un viņam uzticēt lÄ«dzÄ«gus pienākumus, kas, pateicoties viņa pieredzei, ļāva sasniegt tos paÅ”us rādÄ«tājus ar zemākām izmaksām, salÄ«dzinot ar ā€œzvaigznesā€ izstrādes izmaksām. Šādi administratori tika ievietoti komandā, un viņa galvenais uzdevums bija pārvaldÄ«t testÄ“Å”anas un ražoÅ”anas vidi, saskaņā ar noteiktas komandas noteikumiem, ar resursiem, kas pieŔķirti Å”ai komandai. Tā patiesÄ«bā DevOps parādÄ«jās vairākuma prātos.

Daļēji vai pilnÄ«bā ar laiku Å”ie sistēmu administratori sāka izprast Ŕīs konkrētās komandas vajadzÄ«bas izstrādes jomā, kā atvieglot dzÄ«vi izstrādātājiem un testētājiem, kā izlaist atjauninājumu un nav jāpaliek pa nakti piektdien birojā, labojot izvietoÅ”anas kļūdas. Laiks pagāja, un tagad ā€œzvaigznesā€ bija sistēmu administratori, kuri saprata, ko izstrādātāji vēlas. Lai samazinātu ietekmi, sāka parādÄ«ties pārvaldÄ«bas utilÄ«tas; visi atcerējās vecās un uzticamās OS lÄ«meņa izolācijas metodes, kas ļāva samazināt prasÄ«bas droŔībai, tÄ«kla daļas pārvaldÄ«bai un resursdatora konfigurācijai. kopumā un rezultātā samazinās prasÄ«bas pēc jaunām ā€œzvaigznēmā€.

Ir parādÄ«jusies "brÄ«niŔķīga" lieta - dokeris. Kāpēc brÄ«niŔķīgi? Jā, tikai tāpēc, ka, lai izveidotu izolāciju chroot vai cietumā, kā arÄ« OpenVZ, bija nepiecieÅ”amas netriviālas zināŔanas par OS, turpretim utilÄ«ta ļauj vienkārÅ”i izveidot izolētu lietojumprogrammu vidi noteiktā resursdatorā ar visu nepiecieÅ”amo iekÅ”pusē un rokā. atkal pāri attÄ«stÄ«bas grožiem, un sistēmas administrators var pārvaldÄ«t tikai ar vienu resursdatoru, nodroÅ”inot tā droŔību un augstu pieejamÄ«bu - loÄ£isks vienkārÅ”ojums. Taču progress nestāv uz vietas un sistēmas atkal kļūst arvien sarežģītākas, komponentu ir arvien vairāk, viens resursdators vairs neatbilst sistēmas vajadzÄ«bām un ir jāveido klasteri, mēs atkal atgriežamies pie sistēmu administratoriem, kuri ir spēj izveidot Ŕīs sistēmas.

Ciklu pēc cikla parādās dažādas sistēmas, kas vienkārÅ”o izstrādi un/vai administrÄ“Å”anu, parādās orÄ·estrÄ“Å”anas sistēmas, kuras, kamēr nav jāatkāpjas no standarta procesa, ir ērti lietojamas. Mikropakalpojumu arhitektÅ«ra parādÄ«jās arÄ« ar mērÄ·i vienkārÅ”ot visu iepriekÅ” aprakstÄ«to ā€“ mazāk attiecÄ«bu, vieglāk pārvaldÄ«t. Pēc savas pieredzes es neatradu pilnÄ«bā mikropakalpojumu arhitektÅ«ru, es teiktu, 50 lÄ«dz 50 - 50 procenti mikropakalpojumu, melnās kastes, ienāca, iznāca apstrādāti, pārējie 50 ir saplēsts monolÄ«ts, servisi nespēj strādāt atseviŔķi no citiem. sastāvdaļas. Tas viss atkal uzlika ierobežojumus gan izstrādātāju, gan administratoru zināŔanu lÄ«menim.

LÄ«dzÄ«gas ā€œÅ”Å«polesā€ ekspertu zināŔanu lÄ«menÄ« par konkrētu resursu turpinās lÄ«dz pat Å”ai dienai. Bet mēs nedaudz novirzāmies, ir daudzi punkti, kurus vērts izcelt.

Celtniecības inženieris/izlaiduma inženieris

Ä»oti augsti specializēti inženieri, kas parādÄ«jās kā lÄ«dzeklis programmatÅ«ras veidoÅ”anas procesu un izlaidumu standartizÄ“Å”anai. PlaÅ”i izplatÄ«tā Agile ievieÅ”anas procesā Ŕķiet, ka tie vairs nav pieprasÄ«ti, taču tas nebÅ«t nav tā. Å Ä« specializācija parādÄ«jās kā lÄ«dzeklis programmatÅ«ras montāžas un piegādes standartizÄ“Å”anai rÅ«pnieciskā mērogā, t.i. izmantojot standarta metodes visiem uzņēmuma produktiem. LÄ«dz ar DevOps parādÄ«Å”anos izstrādātāji daļēji zaudēja savas funkcijas, jo tieÅ”i izstrādātāji sāka gatavot produktu piegādei, un, ņemot vērā mainÄ«go infrastruktÅ«ru un pieeju piegādei pēc iespējas ātrāk, neņemot vērā kvalitāti, laika gaitā tie kļuva par izmaiņu apturētājs, jo kvalitātes standartu ievēroÅ”ana neizbēgami bremzē piegādes. Tāpēc pakāpeniski daļa no Build/Release inženieru funkcionalitātes pārgāja uz sistēmas administratoru pleciem.

Ops ir tik dažādas

Mēs virzāmies uz priekÅ”u un atkal liela pienākumu loka klātbÅ«tne un kvalificēta personāla trÅ«kums virza mÅ«s uz stingru specializāciju, kā sēnes pēc lietus, parādās dažādas Operācijas:

  • TechOps ā€” enikey sistēmas administratori jeb HelpDesk Engineer
  • LiveOps ā€” sistēmu administratori, kas galvenokārt ir atbildÄ«gi par ražoÅ”anas vidēm
  • CloudOps ā€” sistēmu administratori, kas specializējas publiskos mākoņos Azure, AWS, GCP utt.
  • PlatOps/InfraOps/SysOps ā€“ infrastruktÅ«ras sistēmu administratori.
  • NetOps - tÄ«kla administratori
  • SecOps - sistēmu administratori, kas specializējas informācijas droŔībā - PCI atbilstÄ«ba, CIS atbilstÄ«ba, ielāpÄ“Å”ana utt.

DevOps (teorētiski) ir cilvēks, kurÅ” no pirmavotiem izprot visus izstrādes cikla procesus ā€“ izstrādi, testÄ“Å”anu, izprot produkta arhitektÅ«ru, spēj novērtēt droŔības riskus, pārzina pieejas un automatizācijas rÄ«kus, vismaz augstā lÄ«menÄ«. lÄ«menÄ«, papildus tam saprot arÄ« pirms- un pēcapstrādi.produkta izlaiÅ”anas atbalsts. Persona, kas spēj darboties gan kā darbÄ«bas, gan attÄ«stÄ«bas aizstāve, kas nodroÅ”ina labvēlÄ«gu sadarbÄ«bu starp Å”iem diviem pÄ«lāriem. Izprot komandu darba plānoÅ”anas un klientu vēlmju pārvaldÄ«Å”anas procesus.

Lai veiktu Ŕāda veida darbu un pienākumus, Å”ai personai ir jābÅ«t lÄ«dzekļiem, lai vadÄ«tu ne tikai izstrādes un testÄ“Å”anas procesus, bet arÄ« produkta infrastruktÅ«ras pārvaldÄ«bu, kā arÄ« resursu plānoÅ”anu. DevOps Å”ajā izpratnē nevar atrasties ne IT, ne pētniecÄ«bā un attÄ«stÄ«bā, ne pat PMO; tai ir jābÅ«t ietekmei visās Å”ajās jomās - uzņēmuma tehniskajam direktoram, galvenajam tehniskajam direktoram.

Vai tā ir taisnÄ«ba jÅ«su uzņēmumā? - ES Å”aubos. Vairumā gadÄ«jumu tas ir IT vai pētniecÄ«ba un attÄ«stÄ«ba.

LÄ«dzekļu trÅ«kums un spēja ietekmēt vismaz vienu no Ŕīm trim darbÄ«bas jomām novirzÄ«s problēmu smagumu uz tām vietām, kur Ŕīs izmaiņas ir vieglāk piemērojamas, piemēram, tehnisko ierobežojumu piemēroÅ”ana izlaidumiem saistÄ«bā ar ā€œnetÄ«roā€ kodu saskaņā ar statisku. analizatoru sistēmas. Tas ir, ja PMO nosaka stingru termiņu funkcionalitātes izlaiÅ”anai, pētniecÄ«ba un attÄ«stÄ«ba Å”ajos termiņos nevar nodroÅ”ināt augstas kvalitātes rezultātu un nodroÅ”ina to pēc iespējas labāk, atstājot pārstrukturÄ“Å”anu vēlākam, ar IT saistÄ«tais DevOps bloķē izlaiÅ”anu, izmantojot tehniskos lÄ«dzekļus. . Pilnvaru trÅ«kums mainÄ«t situāciju atbildÄ«gu darbinieku gadÄ«jumā noved pie hiperatbildÄ«bas izpausmēm par to, ko viņi nevar ietekmēt, it Ä«paÅ”i, ja Å”ie darbinieki saprot un redz kļūdas un kā tās labot - ā€œSvētlaime ir nezināŔanaā€, un kā sekas Å”o darbinieku izdegÅ”anai un zaudÄ“Å”anai.

DevOps resursu tirgus

Apskatīsim vairākas vakances DevOps pozīcijām no dažādiem uzņēmumiem.

Mēs esam gatavi tikties ar jums, ja:

  1. Jums pieder Zabbix un zināt, kas ir Prometejs;
  2. Iptables;
  3. BASH doktorants;
  4. profesors Ansible;
  5. Linux Guru;
  6. Zināt, kā izmantot atkļūdoÅ”anu un atrast aplikāciju problēmas kopā ar izstrādātājiem (php/java/python);
  7. MarÅ”rutÄ“Å”ana nerada jÅ«s histēriski;
  8. Pievērsiet lielu uzmanÄ«bu sistēmas droŔībai;
  9. Dublējiet "visu un visu", kā arÄ« veiksmÄ«gi atjaunojiet Å”o "visu un visu";
  10. Jūs zināt, kā konfigurēt sistēmu tā, lai no minimuma iegūtu maksimumu;
  11. Iestatiet replikāciju pirms gulētieÅ”anas vietnēs Postgres un MySQL;
  12. CI/CD iestatÄ«Å”ana un pielāgoÅ”ana jums ir tikpat nepiecieÅ”ama kā brokastis/pusdienas/vakariņas.
  13. Ir pieredze darbā ar AWS;
  14. Gatavs attīstīties kopā ar uzņēmumu;

Tātad:

  • no 1 lÄ«dz 6 - sistēmas administrators
  • 7 - neliela tÄ«kla administrÄ“Å”ana, kas iekļaujas arÄ« sistēmas administratora vidējā lÄ«menÄ«
  • 8 - neliela droŔība, kas ir obligāta vidējā lÄ«meņa sistēmas administratoram
  • 9-11 ā€“ vidējās sistēmas administrators
  • 12 ā€” AtkarÄ«bā no pieŔķirtajiem uzdevumiem vai nu vidējā sistēmas administrators, vai bÅ«vinženieris
  • 13 - Virtualizācija - vidējais sistēmas administrators jeb tā sauktais CloudOps, padziļinātas zināŔanas par konkrētas mitināŔanas vietnes pakalpojumiem, lai efektÄ«vi izmantotu lÄ«dzekļus un samazinātu uzturÄ“Å”anas slodzi

Apkopojot Å”o vakanci, varam teikt, ka puiÅ”iem pietiek ar vidējo/vecāko sistēmas administratoru.

Starp citu, jums nevajadzētu stingri sadalÄ«t administratorus operētājsistēmās Linux/Windows. Protams, es saprotu, ka Å”o divu pasauļu pakalpojumi un sistēmas ir atŔķirÄ«gi, bet pamats visiem ir vienāds un jebkurÅ” sevi cienoÅ”s admins ir pazÄ«stams gan ar vienu, gan otru, un pat ja viņŔ nav pazÄ«stams kompetentam administratoram nebÅ«s grÅ«ti ar to iepazÄ«ties.

Apskatīsim vēl vienu vakanci:

  1. Pieredze lielas slodzes sistēmu būvniecībā;
  2. Teicamas zināŔanas par Linux OS, vispārējo sistēmas programmatÅ«ru un tÄ«mekļa steku (Nginx, PHP/Python, HAProxy, MySQL/PostgreSQL, Memcached, Redis, RabbitMQ, ELK);
  3. Pieredze ar virtualizācijas sistēmām (KVM, VMWare, LXC/Docker);
  4. skriptu valodu prasme;
  5. Izpratne par tīkla protokolu tīklu darbības principiem;
  6. Izpratne par defektizturÄ«gu sistēmu veidoÅ”anas principiem;
  7. Patstāvība un iniciatīva;

Apskatīsim:

  • 1 ā€“ vecākais sistēmas administrators
  • 2 ā€” atkarÄ«bā no nozÄ«mes, kas ievietota Å”ajā kaudzē ā€“ vidējais/vecākais sistēmas administrators
  • 3 - Darba pieredze, tai skaitā, var nozÄ«mēt - "Klasteris nevis cēla, bet izveidoja un pārvaldÄ«ja virtuālās maŔīnas, bija viens Docker resursdators, piekļuve konteineriem nebija pieejama" - Vidējās sistēmas administrators
  • 4 - jaunākais sistēmas administrators - jā, administrators, kurÅ” nezina, kā rakstÄ«t pamata automatizācijas skriptus, neatkarÄ«gi no valodas, nevis administrators - enikey.
  • 5 - vidējais sistēmas administrators
  • 6 ā€“ vecākais sistēmas administrators

Rezumējot - vidējais/vecākais sistēmas administrators

Vēl viens:

  1. Devops pieredze;
  2. Pieredze viena vai vairāku produktu izmantoŔanā, lai izveidotu CI/CD procesus. Gitlab CI būs priekŔrocība;
  3. Darbs ar konteineriem un virtualizāciju; Ja izmantojāt docker, labi, bet, ja izmantojāt k8s, lieliski!
  4. Pieredze darbā veiklā komandā;
  5. Jebkuras programmÄ“Å”anas valodas zināŔanas;

Paskatīsimies:

  • 1 - Hmm... Ko puiÅ”i domā? =) Visticamāk, viņi paÅ”i nezina, kas aiz tā slēpjas
  • 2 ā€” bÅ«vinženieris
  • 3 - vidējais sistēmas administrators
  • 4 - MÄ«ksta prasme, mēs to pagaidām neapsvērsim, lai gan Agile ir vēl viena lieta, kas tiek interpretēta ērtā veidā.
  • 5. Pārāk detalizēta ā€” tā varētu bÅ«t skriptu valoda vai kompilēta valoda. Nez vai viņiem derēs rakstÄ«t skolā Pascal un Basic? =)

Vēlos atstāt piezÄ«mi arÄ« par 3.punktu, lai stiprinātu izpratni par to, kāpēc Å”o punktu sedz sistēmas administrators. Kubernetes ir tikai orÄ·estrÄ“Å”ana, rÄ«ks, kas iesaiņo tieŔās komandas tÄ«kla draiveriem un virtualizācijas/izolācijas resursdatoriem pāris komandās un ļauj sazināties ar tiem abstraktu, tas arÄ« viss. Piemēram, ņemsim 'build framework' Make, ko, starp citu, es neuzskatu par ietvaru. Jā, es zinu par modi bāzt Make jebkur, kur vajag un nevajag - ietÄ«t Maven in Make, piemēram, nopietni?
Būtībā Make ir tikai apvalks, kas vienkārŔo kompilācijas, saistīŔanas un kompilācijas vides komandas, tāpat kā k8s.

Reiz es intervēju puisi, kurÅ” savā darbā izmantoja k8s virs OpenStack, un viņŔ stāstÄ«ja par to, kā viņŔ tajā izvietoja pakalpojumus, tomēr, kad jautāju par OpenStack, izrādÄ«jās, ka tas ir administrēts, kā arÄ« sistēmas radÄ«ts. administratori. Vai tieŔām jÅ«s domājat, ka cilvēks, kurÅ” ir instalējis OpenStack, neatkarÄ«gi no tā, kādu platformu viņŔ izmanto aiz sevis, nevar izmantot k8s? =)
Šis pretendents faktiski nav DevOps, bet gan sistēmas administrators un, precīzāk, Kubernetes administrators.

Rezumēsim vēlreiz ā€“ viņiem pietiks ar vidējo/vecāko sistēmas administratoru.

Cik daudz jāsver gramos

Piedāvāto algu diapazons norādītajām vakancēm ir 90k-200k
Tagad es vēlos vilkt paralēli starp sistēmu administratoru un DevOps inženieru naudas atlīdzību.

Principā, lai vienkārÅ”otu lietas, jÅ«s varat izkaisÄ«t atzÄ«mes pēc darba pieredzes, lai gan tas nebÅ«s precÄ«zi, bet raksta mērÄ·iem ar to pietiks.

Pieredze:

  1. lÄ«dz 3 gadiem ā€“ Junior
  2. lÄ«dz 6 gadiem ā€“ Vidējais
  3. vairāk nekā 6 ā€“ vecākais

Darbinieku meklÄ“Å”anas vietne piedāvā:
Sistēmas administratori:

  1. Juniors - 2 gadi - 50k rub.
  2. Vidējais - 5 gadi - 70k rub.
  3. Seniors - 11 gadi - 100k rub.

DevOps inženieri:

  1. Juniors - 2 gadi - 100k rub.
  2. Vidējais - 3 gadi - 160k rub.
  3. Seniors - 6 gadi - 220k rub.

Pēc ā€œDevOpsā€ pieredzes tika izmantota pieredze, kas vismaz kaut kādā veidā ietekmēja SDLC.

No iepriekÅ” minētā izriet, ka patiesÄ«bā uzņēmumiem nav nepiecieÅ”ami DevOps, kā arÄ«, algojot administratoru, tie varētu ietaupÄ«t vismaz 50 procentus no sākotnēji plānotajām izmaksām, turklāt varētu skaidrāk definēt meklējamās personas pienākumus. un aizpildiet vajadzÄ«bu ātrāk. Tāpat nevajadzētu aizmirst, ka skaidra pienākumu sadale ļauj samazināt prasÄ«bas pret personālu, kā arÄ« radÄ«t labvēlÄ«gāku atmosfēru kolektÄ«vā, jo nav pārklāŔanās. Lielākā daļa vakanču ir pilnas ar utilÄ«tprogrammām un DevOps etiÄ·etēm, taču tās nav balstÄ«tas uz faktiskajām DevOps inženiera prasÄ«bām, ir tikai rÄ«ka administratora pieprasÄ«jumi.

ArÄ« DevOps inženieru apmācÄ«bas process ir ierobežots tikai ar konkrētu darbu, utilÄ«tu kopumu un nesniedz vispārēju izpratni par procesiem un to atkarÄ«bām. Noteikti ir labi, ja cilvēks var izvietot AWS EKS, izmantojot Terraform, kopā ar Fluentd blakusvāģi Å”ajā klasterÄ« un AWS ELK steku reÄ£istrÄ“Å”anas sistēmai 10 minÅ«tēs, izmantojot tikai vienu komandu konsolē, bet, ja viņŔ nesaprot pats žurnālu apstrādes princips un kam tie ir nepiecieÅ”ami, ja jÅ«s nezināt, kā par tiem savākt metriku un izsekot pakalpojuma degradācijai, tad tas joprojām bÅ«s tas pats enikey, kurÅ” zina, kā izmantot dažas utilÄ«tas.

Pieprasījums tomēr rada piedāvājumu, un mēs redzam ārkārtīgi pārkarsētu DevOps pozīcijas tirgu, kur prasības neatbilst reālajai lomai, bet ļauj tikai sistēmas administratoriem nopelnīt vairāk.

Tātad, kas viņi ir? DevOps vai mantkārīgi sistēmu administratori? =)

Kā turpināt dzīvot?

Darba devējiem vajadzētu precÄ«zāk formulēt prasÄ«bas un meklēt tieÅ”i tos, kuri ir vajadzÄ«gi, nevis mētāties ar etiÄ·etēm. JÅ«s nezināt, ko dara DevOps ā€” tādā gadÄ«jumā jums tie nav vajadzÄ«gi.

Strādnieki ā€” mācieties. PastāvÄ«gi pilnveido savas zināŔanas, aplÅ«ko kopējo procesu ainu un seko ceļam uz savu mērÄ·i. JÅ«s varat kļūt par kuru vēlaties, jums tikai jāmēģina.

Avots: www.habr.com

Pievieno komentāru