Кој е DevOps и кога не е потребен?

DevOps стана многу популарна тема во последните неколку години. Многу луѓе сонуваат да му се придружат, но, како што покажува практиката, честопати само поради нивото на платите.

Некои луѓе наведуваат DevOps во нивната биографија, иако не секогаш ја знаат или разбираат суштината на терминот. Некои луѓе мислат дека по проучувањето на Ansible, GitLab, Jenkins, Terraform и слично (списокот може да се продолжи по ваш вкус), веднаш ќе станете „девопсист“. Ова, се разбира, не е точно.

Во изминатите неколку години, главно бев вклучен во имплементацијата на DevOps во различни компании. Пред тоа, тој работеше повеќе од 20 години на позиции од системски администратор до директор за ИТ. Во моментов главен инженер за DevOps во Playgendary.

Кој е DevOps

Идејата да се напише статија се појави по друго прашање: „кој е DevOps? Се уште нема утврден термин за што или кој е. Некои од одговорите се веќе во ова видео. Прво, ќе ги истакнам главните точки од него, а потоа ќе ги споделам моите согледувања и размислувања.

DevOps не е специјалист што може да се вработи, не е збир на комунални услуги, ниту пак оддел на програмери со инженери.

DevOps е филозофија и методологија.

Со други зборови, тоа е збир на практики што им помага на програмерите активно да комуницираат со системските администратори. Односно, да се поврзат и интегрираат работните процеси еден во друг.

Со доаѓањето на DevOps, структурата и улогите на специјалистите останаа исти (има програмери, има инженери), но правилата за интеракција се сменија. Границите меѓу одделите се заматени.

Целите на DevOps може да се опишат во три точки:

• Софтверот мора редовно да се ажурира.
• Софтверот мора да се направи брзо.
• Софтверот треба да се распореди удобно и за кратко време.

Не постои единствена алатка за DevOps. Конфигурирањето, испораката и проучувањето на неколку производи не значи дека DevOps се појавил во компанијата. Има многу алатки и сите тие се користат во различни фази, но служат за една заедничка цел.

И ова е само дел од алатките DevOps

Веќе повеќе од 2 години интервјуирав луѓе за позицијата инженер за DevOps и сфатив колку е важно јасно да се разбере суштината на терминот. Имам акумулирано конкретни искуства, набљудувања и размислувања кои сакам да ги споделам.

Од искуството на интервјуто, ја гледам следната слика: Специјалистите кои го сметаат DevOps за работно место обично имаат недоразбирања со колегите.

Имаше еклатантен пример. Еден млад човек дојде на интервју со многу паметни зборови на неговата биографија. На последните три работни места имаше 5-6 месеци стаж. Оставив две стартапи затоа што „не тргнаа“. Но, за третата компанија, тој рече дека никој не го разбира таму: програмерите пишуваат код на Windows, а директорот го принудува овој код да се „завитка“ во обичен Docker и да се вгради во гасоводот CI/CD. Момчето кажа многу негативни работи за неговото сегашно место на работа и неговите колеги - само сакав да одговорам: „Значи, нема да продавате слон“.

Потоа му поставив прашање кое е високо на мојата листа за секој кандидат.

— Што значи DevOps за вас лично?
- Воопшто или како јас тоа го доживувам?

Ме интересираше неговото лично мислење. Ја знаел теоријата и потеклото на терминот, но силно не се согласувал со нив. Тој веруваше дека DevOps е титула за работа. Тука лежи коренот на неговите проблеми. Како и други специјалисти со исто мислење.

Работодавците, откако слушнале многу за „магијата на DevOps“, сакаат да најдат личност која ќе дојде и ќе ја создаде оваа „магија“. И апликантите од категоријата „DevOps е работа“ не разбираат дека со овој пристап нема да можат да ги исполнат очекувањата. И, генерално, тие напишаа DevOps на нивната биографија бидејќи тоа е тренд и плаќаат многу за тоа.

Методологија и филозофија на DevOps

Методологијата може да биде теоретска и практична. Во нашиот случај, тоа е второто. Како што споменав погоре, DevOps е збир на практики и стратегии кои се користат за постигнување на наведените цели. И во секој случај, во зависност од деловните процеси на компанијата, може значително да се разликува. Што не го прави подобро или полошо.

Методологијата DevOps е само средство за постигнување цели.

Сега за тоа што е филозофијата на DevOps. И ова е веројатно најтешкото прашање.

Прилично е тешко да се формулира краток и концизен одговор, бидејќи тој сè уште не е формализиран. И бидејќи приврзаниците на филозофијата DevOps се повеќе ангажирани во пракса, едноставно нема време за филозофирање. Сепак, ова е многу важен процес. Покрај тоа, тоа е директно поврзано со инженерските активности. Постои дури и специјализирана област на знаење - филозофија на технологијата.

На мојот универзитет немаше таков предмет, морав да учам сè сам користејќи ги материјалите што можев да ги најдам во 90-тите. Темата е изборна за инженерско образование, па оттука и неформализација на одговорот. Но, оние луѓе кои се сериозно нурнати во DevOps почнуваат да чувствуваат одреден „дух“ или „несвесна сеопфатност“ на сите процеси на компанијата.

Користејќи го сопственото искуство, се обидов да формализирам некои од „постулатите“ на оваа филозофија. Резултатот е следниот:

• DevOps не е нешто независно што може да се подели во посебна област на знаење или активност.
• Сите вработени во компанијата треба да се водат според методологијата DevOps при планирањето на нивните активности.
• DevOps влијае на сите процеси во една компанија.
• DevOps постои за да ги намали временските трошоци за сите процеси во компанијата за да обезбеди развој на нејзините услуги и максимална удобност на клиентите.
• DevOps, на современ јазик, е проактивна позиција на секој вработен во компанијата, насочена кон намалување на временските трошоци и подобрување на квалитетот на ИТ производите околу нас.

Мислам дека моите „постулати“ се посебна тема за дискусија. Но, сега има на што да се надоградува.

Што прави DevOps

Клучниот збор овде е комуникација. Има многу комуникации, чиј иницијатор треба да биде токму истиот инженер DevOps. Зошто е тоа? Затоа што ова е филозофија и методологија, па дури потоа инженерско знаење.

Не можам да зборувам со 100% доверба за западниот пазар на труд. Но, знам доста за пазарот на DevOps во Русија. Покрај стотиците интервјуа, во текот на изминатата година и половина учествував во стотици технички предпродажби за услугата „Имплементација на DevOps“ за големи руски компании и банки.

Во Русија, DevOps е сè уште многу млада, но веќе во тренд тема. Колку што знам, само во Москва недостигот на такви специјалисти во 2019 година беше повеќе од 1000 луѓе. А зборот Kubernetes за работодавците е речиси како црвено партал за бик. Приврзаниците на оваа алатка се подготвени да ја користат дури и таму каде што не е неопходно и економски профитабилно. Работодавачот не секогаш разбира во кои случаи што е посоодветно да се користи, а со правилно распоредување, одржувањето на кластерот Kubernetes чини 2-3 пати повеќе од распоредувањето на апликација користејќи конвенционална шема на кластери. Користете го таму каде што навистина ви треба.

Спроведувањето на DevOps е скапо во однос на пари. И тоа е оправдано само таму каде што носи економски придобивки во други области, а не само по себе.

Инженерите на DevOps се, всушност, пионери - тие се оние кои треба први да ја имплементираат оваа методологија во компанијата и да градат процеси. За ова да биде успешно, специјалистот мора постојано да комуницира со вработените и колегите на сите нивоа. Како што обично велам, сите вработени во компанијата треба да бидат вклучени во процесот на имплементација на DevOps: од чистачка до извршен директор. И ова е предуслов. Ако најмладиот член на тимот не знае и не разбира што е DevOps и зошто се изведуваат одредени организациски активности, тогаш успешната имплементација нема да работи.

Исто така, инженерот DevOps треба да користи административен ресурс од време на време. На пример, да се надмине „отпорот на животната средина“ - кога тимот не е подготвен да ги прифати алатките и методологијата на DevOps.

Програмерот треба да пишува само код и тестови. За да го направи тоа, не му треба супермоќен лаптоп на кој ќе ја распореди и локално ќе ја поддржува целата проектна инфраструктура. На пример, развивачот од предниот дел ги чува сите елементи на апликацијата на својот лаптоп, вклучувајќи ја и базата на податоци, емулатор S3 (minio) итн. Односно, тој троши многу време на одржување на оваа локална инфраструктура и сам се бори со сите проблеми на таквото решение. Наместо да се развива код за предната страна. Таквите луѓе можат да бидат многу отпорни на секоја промена.

Но, има тимови кои, напротив, со задоволство воведуваат нови алатки и методи и активно учествуваат во овој процес. Иако и во овој случај, комуникацијата помеѓу инженерот DevOps и тимот не беше откажана.

Кога DevOps не е потребен

Има ситуации кога DevOps не е потребен. Ова е факт - треба да се разбере и прифати.

Пред сè, ова се однесува на сите компании (особено малите бизниси), кога нивниот профит не зависи директно од присуството или отсуството на ИТ производи кои обезбедуваат информативни услуги на клиентите. И тука не зборуваме за веб-страницата на компанијата, било да е тоа статична „визит-картичка“ или со динамични блокови за вести итн.

DevOps е потребен кога задоволството на вашиот клиент и неговата желба повторно да се врати кај вас зависат од достапноста на овие информативни услуги за интеракција со клиентот, нивниот квалитет и таргетирање.

Впечатлив пример е една добро позната банка. Компанијата нема традиционални канцеларии за клиенти, протокот на документи се врши преку пошта или курири, а многу вработени работат од дома. Компанијата престана да биде само банка и, според мене, се претвори во ИТ компанија со развиени DevOps технологии.

Многу други примери и предавања може да се најдат во снимките на тематски состаноци и конференции. Некои од нив ги посетив лично - ова е многу корисно искуство за оние кои сакаат да се развиваат во оваа насока. Еве линкови до каналите на YouTube со добри предавања и материјали за DevOps:

• DevOops
• DevOpsConf
• HighLoad ++
• Рамни
• MailRu Cloud решение

Сега погледнете го вашиот бизнис и размислете за ова: Колку вашата компанија и нејзиниот профит зависат од ИТ производите за да се овозможи интеракција со клиентите?

Ако вашата компанија продава риба во мала продавница и единствениот ИТ производ е два 1C: Enterprise конфигурации (Сметководство и UNF), тогаш тешко дека има смисла да се зборува за DevOps.

Ако работите во големо трговско и производствено претпријатие (на пример, произведувате ловечки пушки), тогаш треба да размислите за тоа. Можете да преземете иницијатива и да му ги пренесете на вашето раководство изгледите за имплементација на DevOps. Па, и во исто време, водете го овој процес. Проактивната позиција е еден од важните начела на филозофијата на DevOps.

Големината и обемот на годишниот финансиски обрт не се главниот критериум за одредување дали на вашата компанија и се потребни DevOps.

Да замислиме големо индустриско претпријатие кое не е директно во интеракција со клиентите. На пример, некои производители на автомобили и компании за производство на автомобили. Сега не сум сигурен, но од моето минато искуство, долги години целата интеракција со клиентите се одвиваше преку е-пошта и телефон.

Нивните клиенти се ограничена листа на дилери на автомобили. И на секој му е доделен специјалист од производителот. Целиот внатрешен проток на документи се јавува преку SAP ERP. Внатрешните вработени во суштина се клиенти на информацискиот систем. Но, оваа ИС е контролирана со класични средства за управување со кластер системи. Што ја исклучува можноста за користење на DevOps практики.

Оттука и заклучокот: за такви претпријатија, имплементацијата на DevOps не е нешто критично важно, ако се потсетиме на целите на методологијата од почетокот на статијата. Но, не исклучувам дека тие користат некои алатки за DevOps денес.

Од друга страна, има многу мали компании кои развиваат софтвер користејќи ја методологијата, филозофијата, практиките и алатките на DevOps. И тие веруваат дека трошоците за имплементација на DevOps се трошоците што им овозможуваат ефективно да се натпреваруваат на пазарот на софтвер. Може да се видат примери на такви компании тука.

Главниот критериум за разбирање дали се потребни DevOps: каква вредност имаат вашите ИТ производи за компанијата и клиентите.

Ако главниот производ на компанијата што генерира профит е софтверот, потребен ви е DevOps. И не е толку важно ако заработувате вистински пари користејќи други производи. Ова исто така вклучува онлајн продавници или мобилни апликации со игри.

Сите игри постојат благодарение на финансирањето: директно или индиректно од играчите. Во Playgendary, развиваме бесплатни мобилни игри со преку 200 луѓе директно вклучени во нивното создавање. Како ги користиме DevOps?

Да, точно исто како што е опишано погоре. Постојано комуницирам со програмери и тестери и спроведувам внатрешна обука за вработените за методологијата и алатките на DevOps.

Сега активно го користиме Jenkins како алатка за цевки за CI/CD за извршување на сите цевководи за склопување со Unity и последователно распоредување на App Store и Play Market. Повеќе од класичниот комплет алатки:

• Асана - за управување со проекти. Интеграцијата со Џенкинс е конфигурирана.
• Google Meet - за видео состаноци.
• Slack - за комуникации и разни предупредувања, вклучувајќи известувања од Џенкинс.
• Atlassian Confluence - за документација и групна работа.

Нашите непосредни планови вклучуваат воведување статичка анализа на кодови со помош на SonarQube и спроведување на автоматско тестирање на интерфејсот со користење на селен во фазата на континуирана интеграција.

Наместо заклучок

Би сакал да завршам со следнава мисла: за да станете висококвалификуван инженер за DevOps, од витално значење е да научите како да комуницирате во живо со луѓето.

Инженерот DevOps е тимски играч. И ништо друго. Иницијативата во комуникацијата со колегите треба да потекнува од него, а не под влијание на некои околности. Специјалист за DevOps мора да го види и предложи најдоброто решение за тимот.

И да, имплементацијата на кое било решение ќе бара многу дискусии, а до крајот може и целосно да се промени. Развивајќи се самостојно, предлагајќи ги и спроведувајќи ги своите идеи, таквата личност е од зголемена вредност и за тимот и за работодавецот. Што, во крајна линија, се рефлектира во висината на неговиот месечен надоместок или во форма на дополнителни бонуси.

Извор: www.habr.com