У апошні час такія аб'явы апанавалі інтэрнэт. Нягледзячы на прыемны заробак, не можа не бянтэжыць, што ўнутры напісана дзікая ерась. Спачатку мяркуецца, што "DevOps" і "інжынер" можна нейкім чынам склеіць разам у адно слова, а далей ідзе рандомны спіс патрабаванняў, частка якіх відавочна скапіяваная з вакансіі сісадміна.
У гэтым пасце хочацца крыху пагаварыць, як мы дайшлі да жыцця такі, што такое DevOps на самой справе і што зараз з гэтым рабіць.
Такія вакансіі можна ўсяляк ганіць, але факт застаецца фактам: іх шмат, і так уладкованы рынак на дадзены момант. Мы зрабілі дэвопс-канферэнцыю і адкрыта заяўляем: « - не для DevOps-інжынераў ». Тут шмат каму здасца дзіўным і дзікім: чаму людзі, якія робяць зусім камерцыйнае мерапрыемства, ідуць супраць рынка. Цяпер усё растлумачым.
Пра культуру і працэсы
Пачнем з таго, што DevOps - гэта не інжынерная дысцыпліна. Пачалося ўсё з таго, што падзел па ролях, які склаўся гістарычна, не працуе на якасць прадуктаў. Калі праграмісты толькі праграмуюць, але нічога не жадаюць чуць аб тэставанні - софт завалены багамі. Калі адмінам напляваць, як і чаму напісаны софт - падтрымка ператвараецца ў пекла.
Напрыклад, апісаннем розніцы паміж сісадмінскім і SRE-шным падыходам да service management. . Цікавыя даследаванні праведзены ў рамках - Відаць, што самыя лепшыя распрацоўшчыкі нейкім чынам прымудраюцца дэплоіць новыя змены на прадакшн хутчэй, чым раз у гадзіну. Яны ж тэстуюць рукамі не больш за 10% (гэта відаць па ). Якім чынам у іх гэта атрымоўваецца? "Excel or die" - кажа адзін з загалоўкаў справаздачы. За падрабязным абмеркаваннем гэтай статыстыкі ў разрэзе тэсціравання можна звярнуцца да кейноўта Баруха Садагурскага. на іншай нашай канферэнцыі, Heisenbug.
«Калі ў таварышах згоды няма,
На лад іх справа не пойдзе,
І выйдзе з яго не справа, толькі мука.
Аднойчы Лебедзь, Рак ды Шчука…»
Як думаеце, якая частка вэб-праграмістаў сапраўды разумее, у якіх умовах эксплуатуюцца іх прыкладанні на продзе? Колькі з іх пойдзе да адмін і паспрабуе разабрацца, што адбудзецца пры падзенні базы? А хто з іх адправіцца да тэсціроўшчыкаў і папросіць навучыць, як правільна пісаць тэсты? А там яшчэ ёсць бяспечнікі, менеджэры прадуктаў, яшчэ куча людзей.
Агульная ідэя DevOps у тым, каб наладзіць узаемадзеянне паміж ролямі і аддзеламі. У першую чаргу гэта дасягаецца не нейкім хітра наладжаным софтам, а практыкай зносін. DevOps - гэта пра культуру, практыку, метадалогію і працэсы. Не існуе такой інжынернай спецыяльнасці, якая б адказвала на гэтыя пытанні.
Замкнёнае кола
Адкуль жа ўзялася тады дысцыпліна "дэвопс-інжынерыі"? У нас ёсць версія! Ідэі DevOps апынуліся добрыя - настолькі добрыя, што сталі ахвярамі свайго поспеху. Вакол усёй гэтай тэмы сталі клубіцца нейкія каламутныя рекрутеры і гандляры людзьмі, у якіх вельмі свая атмасфера.
Прадстаўце: учора вы ў Хімках лудзілі шаурма, а сёння - вы ўжо вялікі чалавек, сеніёр рекрутер. Тут цэлы працэс пошуку і адбору кандыдатаў, усё няпроста, трэба разумець. Дапушчальны, начальнік аддзела кажа: знайдзі адмыслоўца па X. Прыпісваем да X слова "інжынер", і справа ў капелюшы. Патрэбен Linux? Ну гэта сапраўды Linux-інжынер, жадаеш DevOps - DevOps-інжынер. Вакансія складаецца не толькі з загалоўка, але ўсярэдзіне трэба ўпісаць нейкі тэкст. Прасцей за ўсё - упісаць набор кейвордаў з Гугла, каму колькі хопіць фантазіі. DevOps складаецца з двух слоў – "Dev" і "Ops", значыць, трэба склейваць кейворды, якія адносяцца да распрацоўшчыкаў і адміністратараў, усё ў адну кучу. Так з'яўляюцца вакансіі пра валоданне 42 мовамі праграмавання і 20 гадоў выкарыстання Kubernetes і Swarm адначасова. Рабочая схема.
Такім у свядомасці людзей укаранілася бессэнсоўная і бязлітасная выява нейкага супергероя-«дэвопсу», які наладзіць усім дэплой на Jenkins, і наступіць шчасце. Ах, калі б усё было так проста. «А яшчэ так можна хантыць сісадмінаў, – думае эйчар, – слова моднае, кейворды тыя ж самыя, павінны клюнуць».
Попыт нараджае прапанову, і на ўсе гэтыя трэш-вакансіі наляцела вар'яцкая колькасць сісадмінаў, якія сцямілі: можна рабіць усё тое ж самае, што і раней, але атрымліваць у некалькі разоў больш, назваўшыся "дэвопсамі". Як ты наладжваў сервера праз SSH рукамі па адным, так і працягнеш наладжваць, але зараз гэта нібыта дэвопс-практыка. Гэта нейкая складаная з'ява, часткова звязаная і з недаацэненасцю класічных адмінаў, і з хайпам вакол DevOps, але ўвогуле - што атрымалася, тое атрымалася.
Такім чынам, у нас ёсць попыт і прапанова. Замкнёнае кола, якое падсілкоўвае сам сябе. Вось з гэтым мы і дужаемся (у тым ліку, ствараючы канферэнцыю DevOops).
Безумоўна, акрамя сісадмінаў, якія перайменаваліся ў «дэвопсы», ёсць і іншыя ўдзельнікі – напрыклад, прафесійныя SRE або распрацоўшчыкі Infrastructure-as-Code.
Чым людзі займаюцца ў DevOps (насамрэч)
Такім чынам, вы жадаеце рушыць наперад у вывучэнні і ўжыванні практык DevOps. Але як гэта зрабіць, у які бок глядзець? Відавочна, слепа кіравацца папулярнымі ключавымі словамі не варта.
Калі праца ёсць, нехта ёй павінен займацца. Мы ўжо высветлілі, што гэта не "дэвопс-інжынеры", тады хто? Здаецца, больш правільна сфармуляваць гэта не ў тэрмінах пасад, а ў тэрмінах канкрэтных напрамкаў працы.
Па-першае, можна займацца самым сэрцам DevOps - працэсамі і культурай. Культура - справа няхуткая і нялёгкая, і хоць гэта традыцыйна сфера адказнасці кіраўнікоў, так ці інакш у гэтым удзельнічаюць усе, ад праграмістаў да адмінаў. Пару месяцаў таму Цім Лістэр :
«Культура задаецца асноўнымі каштоўнасцямі арганізацыі. Звычайна людзі гэтага не заўважаюць, але мы, працуючы ў кансалтынгу на працягу шматлікіх гадоў, абвыклі гэта прыкмячаць. Ты заходзіш у кампанію і літаральна праз некалькі хвілін пачынаеш адчуваць, што адбываецца. Мы называем гэта "водарам". Часам гэты водар сапраўды добры. Часам ён выклікае млоснасць. (…) Ты не можаш змяніць культуру да таго, як былі ўсвядомлены каштоўнасці і перакананні, якія стаяць за канкрэтнымі дзеяннямі. Паводзіны назіраць лёгка, а шукаць перакананні - складана. DevOps - гэта як раз выдатны прыклад таго, як усё становіцца складаней і складаней ».
Ёсць і тэхнічная частка пытання, вядома. Калі ў цябе новы код на тэставанне пападае праз месяц, а ў рэлізе апыняецца толькі праз год, і паскорыць усё гэта фізічна немагчыма - да добрых практык можна не дажыць. Добрыя практыкі падтрымліваюцца добрымі прыладамі. Напрыклад, трымаючы ў галаве ідэю Infrastructure-as-Code, можна выкарыстоўваць што заўгодна, ад AWS CloudFormation і Terraform да Chef-Ansible-Puppet. Усё гэта трэба ведаць і ўмець, і вось гэта ўжо інжынерная дысцыпліна. Важна не блытаць прычыну са следствамі: спачатку вы працуеце па прынцыпах SRE і толькі потым ужо ўвасабляеце гэтыя прынцыпы ў выглядзе нейкіх канкрэтных тэхнічных рашэнняў. Пры гэтым SRE - гэта вельмі комплексная метадалогія, якая распавядае не пра тое, як наладзіць Jenkins, а пра пяць асноўных прынцыпаў:
- Паляпшэнне ўзаемадзеяння паміж ролямі і аддзеламі
- Прыняцце памылак як неад'емнай часткі працы
- Паступовае ажыццяўленне змен
- Выкарыстанне тулінга і іншай аўтаматыкі
- Вымярэнне за ўсё, што можна вымераць
Гэта не проста нейкі набор сцвярджэнняў, а канкрэтнае . Напрыклад, на шляхі прыняцця памылак трэба будзе разабрацца з рызыкамі, вымераць даступнасць і недаступнасць сэрвісаў з дапамогай чагосьці накшталт SLI.) і SLO (), навучыцца пісаць постмартэмы і зрабіць так, каб пісаць іх было не страшна.
У дысцыпліне SRE выкарыстанне прылад - толькі адна з частак поспеху, зрэшты, немалаважная. Нам трэба ўвесь час развівацца ў тэхнічным плане, глядзець, што адбываецца ў свеце і як гэта можна прымяніць у сваёй працы.
У сваю чаргу, зараз сталі вельмі папулярнымі рашэнні Cloud Native. Паводле сучаснага разумення Cloud Native Computing Foundation, тэхналогіі Cloud Native дазваляюць арганізацыям распрацоўваць і запускаць маштабуюцца прыкладанні ў сучасных дынамічных асяроддзях, такіх як публічныя, прыватныя і гібрыдныя аблокі. У якасці прыкладу можна прывесці кантэйнеры, сэрвіс-мешы, мікрасэрвісы, нязменную інфраструктуру і дэкларатыўныя API. Усе гэтыя тэхнікі дазваляюць слабазвязаным сістэмам заставацца эластычнымі, кіраванымі і добра назіранымі. Добрая аўтаматыка дазваляе інжынерам рабіць вялікія змены часта і з прадказальнымі вынікамі, не ператвараючы гэта ў пякельную працу. Усё гэта падтрымліваецца стэкам з усіх вядомых інструментаў, такіх як Docker і Kubernetes.
Гэта даволі няпростае і раскідзістае вызначэнне звязана з тым, што і вобласць даволі няпростая. З аднаго боку сцвярджаецца, што новыя змены ў гэтую сістэму павінны дадавацца дастаткова проста. З іншага боку, каб разабрацца ў тым, як зрабіць нейкае кантэйнерызаванае асяроддзе, у якім слабазлучаныя сэрвісы жывуць на software-defined інфраструктуры і пастаўляюцца туды з дапамогай бесперапыннага CI/CD, і выбудаваць вакол усяго гэтага DevOps-практыкі – на ўсім гэтым трэба не адну сабаку з'есці.
Што з усім гэтым рабіць
Кожны вырашае гэтыя праблемы па-свойму: напрыклад, можна публікаваць нармальныя вакансіі, каб разарваць замкнёнае кола. Можна разабрацца, што азначаюць словы накшталт DevOps і Cloud Native і ўжываць іх правільна і па справе. Можна развівацца ў DevOps і сваім прыкладам дэманстраваць правільныя падыходы.
Мы ж робім канферэнцыю , якая дае магчымасць глыбей разабрацца ў рэчах, пра якія мы толькі што пагаварылі. Для гэтага ёсць некалькі груп дакладаў:
- Працэсы і культура;
- Site Reliability Engineering;
- Cloud Native;
Як абраць, куды ісці? Тут ёсьць тонкі момант. З аднаго боку, DevOps - гэта пра ўзаемадзеянне, і нам вельмі хочацца, каб вы схадзілі на даклады з розных блокаў. З іншага боку, калі вы - кіраўнік распрацоўкі, які прыйшоў на канферэнцыю, каб сканцэнтравацца на адной канкрэтнай задачы, то ніхто вас не абмяжоўвае - відавочна, гэта будзе блок пра працэсы і культуру. Не забывайце, што пасля канферэнцыі ў вас застануцца запісы (пасля запаўнення формы зваротнай сувязі), таму вы заўсёды зможаце паглядзець менш важныя даклады пазней.
Відавочна, што на самой канферэнцыі вы не можаце пайсці адразу на тры трэкі адначасова, таму мы так фармуем праграму, каб у кожным часовым слоце былі тэмы на любы густ.
Засталося толькі зразумець, што рабіць, калі вы DevOps-інжынер! Па-першае, паспрабуйце вызначыць, чым на самой справе вы займаецеся. Звычайна гэтым словам кахаюць зваць:
- Распрацоўнікаў, якія займаюцца інфраструктурай. Для вас больш за ўсё падыдуць групы дакладаў пра SRE і Cloud Native.
- Сістэмных адміністратараў. Тут складаней. DevOops - не пра сістэмнае адміністраванне. На шчасце, на тэму сістэмнага адміністравання ёсць маса выдатных канферэнцый, кніг, артыкулаў, відэа ў інтэрнэце і да т.п. З іншага боку, калі вам цікава развівацца ў плане разумення культуры і працэсаў, вывучэння хмарных тэхналогій і падрабязнасцяў жыцця з Cloud Native, то мы будзем рады вас бачыць! Падумайце вось пра што: вось вы займаецеся адмінствам, а далей што вы будзеце рабіць? Каб раптоўна не апынуцца ў непрыемнай сітуацыі, варта вучыцца ўжо зараз.
Ёсць яшчэ адзін варыянт: вы ўпарціцеся і працягваеце сцвярджаць, што з'яўляецеся менавіта DevOps-інжынерам і ніяк інакш, што б гэта ні значыла. Тады вымушаныя засмуціць, DevOops - гэта канферэнцыя не для DevOps-інжынераў!
Слайд з у Мюнхене
DevOops 2020 Moscow пройдзе 29-30 красавіка ў Маскве, квіткі ўжо можна .
Акрамя таго, вы можаце да 8 лютага. Звярніце ўвагу, што пры запаўненні формы вы павінны абраць мэтавую аўдыторыю, якой ваш даклад прынясе больш карысці (ўнутры спісу закапаны сюрпрыз).
Крыніца: habr.com