Калі прыкладанне не працуе, менш за ўсё хочацца пачуць ад калег фразу "праблема на вашым баку". У выніку пакутуюць карыстачы - а ім усё роўна, якая частка каманды нясе адказнасць за паломку. Культура DevOps з'явілася якраз затым, каб згуртаваць распрацоўку і падтрымку і аб'яднаць іх вакол агульнай адказнасці за канчатковы прадукт.
Якія практыкі ўваходзяць у паняцце DevOps і навошта яны патрэбны? Чым займаюцца DevOps-інжынеры і што яны павінны ўмець? На гэтыя і іншыя пытанні адказваюць эксперты з EPAM: Кірыл Сяргееў, сістэмны інжынер і DevOps-евангеліст, і Ігар Бойка, вядучы сістэмны інжынер і каардынатар адной з DevOps-каманд кампаніі.
Навошта патрэбен DevOps?
Раней паміж распрацоўшчыкамі і падтрымкай (т. н. operations) існаваў бар'ер. Гучыць парадаксальна, але ў іх былі розныя мэты і KPI, хаця яны і рабілі агульную справу. Мэтай распрацоўкі было як мага хутчэй рэалізаваць бізнес-патрабаванні і дадаць іх у працуючы прадукт. Падтрымка адказвала за тое, каб прыкладанне стабільна працавала - а любыя змены ставяць стабільнасць пад пагрозу. У наяўнасці канфлікт інтарэсаў - DevOps з'явіўся, каб яго вырашыць.
Што такое DevOps?
Пытанне добрае - і спрэчнае: канчаткова ў свеце пра гэта пакуль не дамовіліся. У ЕРАМ лічаць, што DevOps аб'ядноўвае ў сабе тэхналогіі, працэсы і культуру ўзаемадзеяння ўнутры каманды. Гэта аб'яднанне накіравана на бесперапынную дастаўку каштоўнасцяў канчатковым карыстальнікам.
Кірыл Сяргееў: «Распрацоўшчыкі пішуць код, тэсціроўшчыкі яго правяраюць, а адміністратары ўсталёўваюць фінальны прадукт на вытворчае асяроддзе. Доўгі час гэтыя часткі каманды былі некалькі разрознены, а потым з'явілася ідэя аб'яднаць іх агульным працэсам. Так з'явіліся DevOps-практыкі».
Надышоў той дзень, калі распрацоўшчыкі і сістэмныя інжынеры зацікавіліся працай адзін аднаго. Бар'ер паміж вытворчасцю і падтрымкай пачаў сцірацца. Так з'явіўся DevOps, у які ўваходзяць практыкі, культура і парадак узаемадзеяння ў камандзе.
У чым сутнасць DevOps-культуры?
У тым, што адказнасць за канчатковы вынік ляжыць на кожным з удзельнікаў каманды. Самае цікавае і складанае ў філасофіі DevOps - зразумець, што канкрэтны чалавек не проста адказвае за свой этап працы, а нясе адказнасць за тое, як будзе працаваць увесь прадукт. Праблема ляжыць не на чыімсьці баку - яна агульная, і кожны член каманды дапамагае яе вырашыць.
Найважнейшае становішча DevOps-культуры - менавіта вырашаць праблему, а не проста прымяняць DevOps-практыкі. Больш за тое, гэтыя практыкі ўкараняюць не "на чыім-то баку", а ва ўвесь прадукт. Праекту патрэбен не сам па сабе DevOps-інжынер - яму трэба рашэнне праблемы, а роля DevOps-інжынера можа быць размеркавана па некалькіх членам каманды з рознай спецыялізацыяй.
Якія бываюць DevOps-практыкі?
DevOps-практыкі пакрываюць усе этапы жыццёвага цыклу ПЗ.
Ігар Бойка: «Ідэальны выпадак - калі мы пачынаем выкарыстоўваць DevOps-практыкі прама пры ініцыяцыі праекта. Разам з архітэктарамі мы плануем, які ў дадатку будзе архітэктурны ландшафт, дзе яно будзе размяшчацца і як маштабавацца, выбіраем платформу. Цяпер у модзе мікрасэрвісная архітэктура - для яе мы выбіраем сістэму аркестрацыі: трэба ўмець кіраваць кожным элементам прыкладання па асобнасці і абнаўляць яго незалежна ад іншых. Яшчэ адна практыка - гэта "інфраструктура як код". Так называюць падыход, пры якім інфраструктура праекта ствараецца і кіруецца пры дапамозе кода, а не праз прамое ўзаемадзеянне з серверамі.
Далей мы пераходзім на этап распрацоўкі. Тут адна з найбуйных практык пабудова CI/CD: трэба дапамагчы распрацоўнікам інтэграваць змены ў прадукт хутка, дробнымі порцыямі, гушчару і бязбольнай. CI/CD пакрывае і праверку кода, і заліванне майстра ў кодавую базу, і разгортванне прыкладання на тэставых і прадуктыўных асяроддзях.
На этапах CI/CD код праходзіць праз quality gates. З іх дапамогай правяраюць, каб код, які выйшаў з працоўнай станцыі распрацоўніка, адпавядаў зададзеным крытэрам якасці. Тут дадаецца юніт-і UI-тэставанне. Для хуткага, бязбольнага і факусаванага разгортвання прадукта можна абраць падыходны тып дэплойменту.
DevOps-практыкам ёсць месца і на стадыі падтрымкі гатовага прадукта. Іх ужываюць для маніторынгу, зваротнай сувязі, бяспекі, укараненні змен. На ўсе гэтыя задачы DevOps глядзіць з пункта гледжання пастаянных паляпшэнняў. Мы зводзім да мінімуму паўтараюцца аперацыі, аўтаматызуем іх. Сюды ж адносяцца міграцыі, пашырэнне дадатку, падтрымка працаздольнасці».
Чым карысныя DevOps-практыкі?
Калі б мы пісалі падручнік па сучасных практыках DevOps, на яго першай старонцы значыліся б тры пункты: аўтаматызацыя, паскарэнне рэлізу і хуткая зваротная сувязь ад карыстальнікаў.
Кірыл Сяргееў: «Першае - гэта аўтаматызацыя. Усе ўзаемадзеянні ў камандзе мы можам аўтаматызаваць: напісалі код - выкацілі - праверылі - усталявалі - сабралі фідбэк - вярнуліся ў пачатак. Усё гэта - аўтаматычна.
Другое - паскарэнне выхаду рэлізу і нават спрашчэнне распрацоўкі. Заказчыку заўсёды важна, каб прадукт выйшаў на рынак як мага хутчэй і пачаў прыносіць карысць раней, чым аналагі канкурэнтаў. Працэс дастаўкі прадукта можна бясконца паляпшаць: скарачаць час, дадаваць дадатковыя кантрольныя пазнакі, удасканальваць маніторынг.
Трэцяе - гэта паскарэнне зваротнай сувязі ад карыстальніка. Калі ў яго ёсць заўвагі, мы можам адразу ж уносіць карэкціроўкі і тут жа абнаўляць дадатак».
Як суадносяцца паняцці "сістэмны інжынер", "білд-інжынер" і "DevOps-інжынер"?
Яны перасякаюцца, але ставяцца да крыху розных сфер.
Сістэмны інжынер у ЕРАМ - гэта пасада. Яны бываюць розных узроўняў: ад джуніёра да chief-спецыяліста.
Білд-інжынер - гэта хутчэй роля, якую можна выконваць на праекце. Цяпер так называюць людзей, адказных за CI/CD.
DevOps-інжынерам называюць спецыяліста, які ўкараняе на праекце DevOps-практыкі.
Калі суміраваць усё гэта, атрымліваецца прыкладна наступнае: чалавек на пасадзе сістэмнага інжынера выконвае на праекце ролю білд-інжынера і займаецца там укараненнем DevOps-практык.
Чым менавіта займаецца DevOps-інжынер?
DevOps-інжынеры збіраюць разам усе часткі, з якіх складаецца праект. Яны ведаюць спецыфіку працы праграмістаў, тэсціроўшчыкаў, сістэмных адміністратараў і дапамагаюць спрасціць іх працу. Яны разумеюць патрэбы і патрабаванні бізнесу, яго роля ў працэсе распрацоўкі - і будуюць працэс з улікам інтарэсаў заказчыка.
Мы шмат казалі пра аўтаматызацыю - ёю DevOps-інжынеры займаюцца ў першую чаргу. Гэта вельмі вялікі пункт, у які, апроч іншага, уваходзіць падрыхтоўка акружэння.
Кірыл Сяргееў: «Перш чым укараняць абнаўленні ў прадукт, іх трэба пратэставаць на іншым асяроддзі. Яго рыхтуюць DevOps-інжынеры. Яны ж укараняюць на праекце DevOps-культуру ў цэлым: укараняюць DevOps-практыкі на ўсіх пластах сваіх праектаў. Гэтыя тры прынцыпы: аўтаматызацыя, спрашчэнне, паскарэнне - яны прыўносяць усюды, куды могуць дацягнуцца ».
Што павінен ведаць DevOps-інжынер?
Па вялікім рахунку, у яго павінны быць веды з розных абласцей: праграмаванне, праца з аперацыйнымі сістэмамі, базамі дадзеных, сістэмамі зборкі і канфігурацый. Да іх дабаўляецца ўменне працаваць з хмарнай інфраструктурай, сістэмамі аркестрацыі, маніторынгу.
1. Мовы праграмавання
DevOps-інжынеры ведаюць некалькі базавых моў для аўтаматызацыі і могуць, напрыклад, сказаць праграмісту: «Давай ты будзеш рабіць усталёўку кода не рукамі, а з дапамогай нашага скрыпту, які ўсё аўтаматызуе? Да яго мы падрыхтуем config-файл, яго будзе зручна чытаць і табе, і нам - і мы ў любы момант зможам яго змяніць. А яшчэ мы будзем бачыць, хто, калі і для чаго ўносіць у яго змены».
DevOps-інжынер можа вывучыць адну ці некалькі з гэтых моў: Python, Groovy, Bash, Powershell, Ruby, Go. Ведаць іх на глыбінным узроўні не патрабуецца - дастаткова асноў сінтаксісу, прынцыпаў ААП, уменні пісаць нескладаныя скрыпты для аўтаматызацыі.
2. Аперацыйныя сістэмы
DevOps-інжынер павінен разумець, на якім серверы будзе ўсталяваны прадукт, у якім асяроддзі будзе запускацца, з якімі сэрвісамі будзе ўзаемадзейнічаць. Можна абраць спецыялізацыю на Windows або Linux-сямействе.
3. Сістэмы кантролю версій
Без ведаў сістэмы кантролю версій DevOps-інжынеру нікуды. Git - адна з самых папулярных сістэм у сапраўдны момант.
4. Воблачнае правайдэры
AWS, Google, Azure - асабліва калі мы гаворым пра Windows-кірунак.
Кірыл Сяргееў: «Хмарныя правайдэры падаюць нам віртуальныя серверы, якія выдатна кладуцца на рэйкі CI/CD.
Ўстаноўка дзесяці фізічных сервераў патрабуе каля ста ручных аперацый. Кожны сервер трэба ўручную запусціць, усталяваць і наладзіць патрэбную аперацыйную сістэму, усталяваць наша дадатак на гэтых дзесяці серверах, а потым дзесяць разоў усё пераправерыць. Хмарныя сэрвісы замяняюць гэтую працэдуру дзесяццю радкамі кода, і добры DevOps-інжынер павінен умець імі апераваць. Так ён эканоміць час, сілы і грошы - і для заказчыка, і для кампаніі».
5. Сістэмы аркестрацыі: Docker і Kubernetes
Кірыл Сяргееў: «Віртуальныя серверы падзеленыя на кантэйнеры, у кожны з якіх мы можам усталяваць наша дадатак. Калі кантэйнераў шмат, трэба імі кіраваць: адзін уключыць, іншы выключыць, дзесьці зрабіць бэкапы. Гэта становіцца даволі складанай справай, для якой патрэбная сістэма аркестрацыі.
Раней кожным дадаткам займаўся асобны сервер - любыя змены ў яго працы маглі паўплываць на спраўнасць прыкладання. Дзякуючы кантэйнерам прыкладанні становяцца ізаляванымі і запускаюцца па асобнасці - кожнае на сваёй віртуальнай машыне. Калі адбываецца збой, ня трэба марнаваць час на пошук прычыны. Прасцей знішчыць стары кантэйнер і дадаць новы».
6. Сістэмы канфігурацый: Chef, Ansible, Puppet
Калі неабходна абслугоўваць цэлы парк сервераў, даводзіцца рабіць шмат аднатыпных аперацый. Гэта доўга і складана, а яшчэ ручная праца падвышае шанец памылкі. Тут на дапамогу прыходзяць сістэмы канфігурацый. З іх дапамогай ствараюць скрыпт, які зручна чытаць і праграмістамі, і DevOps-інжынерамі, і сістэмнымі адміністратарамі. Гэты скрыпт дапамагае праводзіць аднолькавыя аперацыі на серверах аўтаматычна. Так ручных аперацый (і, такім чынам, памылак) становіцца менш.
Якую кар'еру можа пабудаваць DevOps-інжынер?
Развівацца можна і гарызантальна, і вертыкальна.
Ігар Бойка: «З пункту гледжання гарызантальнага развіцця, у DevOps-інжынераў зараз самыя шырокія перспектывы. Усё ўвесь час змяняецца, і нарошчваць навыкі можна па самых розных кірунках: ад сістэм кантролю версій да маніторынгу, ад кіравання канфігурацыямі да баз дадзеных.
Можна стаць сістэмным архітэктарам, калі супрацоўніку цікава разабрацца, як працуе дадатак на ўсіх этапах свайго жыццёвага цыклу - ад распрацоўкі да падтрымкі».
Як стаць DevOps-інжынерам?
- Прачытайце кнігі "Праект "Фенікс"" і DevOps Handbook. Гэта сапраўдныя слупы філасофіі DevOps, прычым першая - мастацкі раман.
- Вывучайце тэхналогіі са спіса вышэй: самастойна або на анлайн-курсах.
- Далучайцеся ў якасці DevOps-інжынера на апенсорс-праект.
- Практыкуйце і прапануйце DevOps-практыкі на сваіх асабістых і працоўных праектах.
Крыніца: habr.com