DevOpsForum 2019. DevOps енгізуді күте алмайсыз

Мен жақында Logrocon ұйымдастырған DevOpsForum 2019 көрмесіне қатыстым. Бұл конференцияда қатысушылар бизнес пен даму және ақпараттық технологиялар қызметінің мамандары арасындағы тиімді өзара әрекеттесу үшін шешімдер мен жаңа құралдарды табуға тырысты.

DevOpsForum 2019. DevOps енгізуді күте алмайсыз

Конференция сәтті өтті: шынымен де көптеген пайдалы баяндамалар, қызықты презентация форматтары және спикерлермен көп қарым-қатынас болды. Ешкім маған ештеңе сатқысы келмегені өте маңызды, бұл соңғы уақытта үлкен конференцияларда спикерлер кінәлі болды.

Raiffeisenbank, Alfastrakhovanie баяндамаларынан үзінді, Mango Telecom компаниясының автоматтандыруды енгізу тәжірибесі және қысқартылған басқа да мәліметтер.

Менің атым Яна, мен тестілеуші ​​болып жұмыс істеймін, мен DevOps сияқты автоматтандырумен айналысамын және конференциялар мен кездесулерге баруды жақсы көремін. Соңғы екі жылда мен Олег Буниннің конференцияларында (HighLoad++, TeamLead Conf), Jug оқиғаларында (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Мәскеуде болдым.

Ең алдымен конференция бағдарламасына назар аударамын. Мен баяндаманың не туралы болатынын азырақ, ал баяндамашыға көбірек қараймын. Есеп өте технологиялық және қызықты болып шықса да, есептің кейбір озық тәжірибелерін өз компанияңызда қолдана алатыныңыз шындық емес. Содан кейін сізге динамик қажет.

Райффайзенбанктегі құбырдың соңында жарық

Әдетте мен өзімді қызықтыратын спикерлерді іздеймін. DevOpsForum 2019 көрмесінде Райффайзенбанктің спикері Михаил Бижан мені қызықтырды. Өз сөзінде ол өз топтарын біртіндеп DevOps-қа қалай қосып жатқаны, бұл не үшін қажет және DevOps трансформациясының идеясын бизнеске қалай сату керектігі туралы айтты. Жалпы, құбырдың соңында жарықты қалай көруге болатынын айттым.

DevOpsForum 2019. DevOps енгізуді күте алмайсыз
Михаил Бижан, Raiffeisenbank автоматтандыру директоры

Енді олардың компанияларында «DevOps» жоқ. Яғни, ол жұмыс істейді, бірақ барлық командаларда емес. DevOps енгізу кезінде олар нақты инженерлер тұрғысынан да, өнімнің қажеттілігі мен осы өнім салынған платформаның жетілгендігі тұрғысынан да командалардың дайындығына сүйенеді. Миша бизнеске DevOps не үшін қажет екенін қалай түсіндіру керектігін айтты.

Банк сегментінде өсудің бірнеше драйверлері бар: қызметтердің құны және клиенттік базаның кеңеюі. Қызметтердің құнын көтеру өте жақсы драйвер емес, бірақ клиенттік базаның өсуі керісінше. Егер бәсекелестер объективті түрде салқын өнімді шығарса, барлық тұтынушылар сол жерге барады, содан кейін уақыт өте келе нарық деңгейі төмендейді. Сондықтан нарыққа жаңа өнімдерді енгізу және оларды енгізу жылдамдығы банктердің басты назарында. Бұл DevOps үшін дәл осы және бизнес мұны түсінеді.

Келесі маңызды ескерту: DevOps нарыққа шығу уақытын әрдайым қысқарта бермейді. DevOps жалғыз жұмыс істей алмайды, бұл әзірлеуден өндіріске (кодтан тұтынушыға) өнімді жасау және нарыққа шығару процесінің бір бөлігі ғана. Бірақ кодқа дейінгі барлық нәрсе DevOps-пен тікелей байланысты емес. Яғни, маркетологтар нарықты жылдар бойы зерттеп, бүкіл өмірін бәсекелестерді қуып жетуге жұмсай алады. Клиентке не қажет екенін тез түсініп, осы немесе басқа мүмкіндікті жүзеге асыруды жоспарлау қажет - бұл көбінесе DevOps жұмыс істеуі және компанияның мақсатына жетуі үшін жеткіліксіз. Сондықтан, ең алдымен, Райффайзенбанк DevOps қолдануды үйрену керек деген бизнеспен келісті. Автоматтандыру үшін автоматтандыру жаңа тұтынушылар үшін күресте көп көмектеспейді.

Жалпы, Миша DevOps-ті іске асыру керек деп санайды, бірақ ақылмен. Біз трансформацияның басында ұжымның өнімділігі төмендеп, аз ақша табатынына дайын болуымыз керек, бірақ кейін ол ақталады.

Mango Telecom компаниясында тестілеуді автоматтандыру

Мен үшін тестілеуші ​​ретінде тағы бір қызықты есеп Mango Telecom компаниясынан Егор Маслов берді. Презентация «SCRUM командасындағы толық тестілеу циклін автоматтандыру» деп аталды. Егор DevOps арнайы SCRUM үшін жасалған деп санайды, бірақ сонымен бірге DevOps-ті SCRUM командасына енгізу өте қиын. Бұл SCRUM командасы әрқашан бір жерде жұмыс істейтіндіктен болады, инновацияларға алаңдап, процесті қайта құруға уақыт жоқ. Мәселе сонымен қатар SCRUM командадағы қосалқы топтардың бөлінуін қамтымайтындығында (тестілеу тобы, әзірлеу тобы және т.б.). Сонымен қатар, бар процесті автоматтандыру үшін құжаттама қажет, ал SCRUM-да көбінесе құжаттама толығымен болмайды - «өнім жазудың қандай да бір түрінен маңыздырақ».

SCRUM жүйесіне ауысқаннан кейін тестерлер әзірлеушілермен мүмкіндіктерді қалай тексеруге болатыны туралы кеңес ала бастады. Бірте-бірте функционалдылық көлемі өсті, ешқандай құжаттама болмады және олар функционалдық сынақтармен қамтылмаған көптеген қателерді ұстай бастады және жалпы оны кім және қашан тексергені белгісіз болды. Бір сөзбен айтқанда - шатасу және ауытқу. Біз тестілеуді автоматтандыруға көшуді шештік. Бірақ сонда да толық сәтсіздік болды. Олар ішкі тестерлерге белгісіз стекке жазған автоматтандыру бойынша аутсорсинг мамандарын жалдады. Әрине, автотесттердің негізі жұмыс істеді, бірақ аутсорсингтер кеткеннен кейін ол екі аптаға созылды. Одан кейін екінші нөмірлі автотестілеуді енгізу әрекеті болды. Бұл барлығын компанияның ішінде, өз бетіңізше (дұрыс вектор: ішкі тәжірибені жинақтау), SCRUM шеңберінде құру және процесте құжаттама жасау қажет екендігімен басталды. Автоматтандыруға арналған стек өнімнің стекіне тең болуы керек (мұнда мен оны қосып отырмын, JavaScript жобаңызды басқа ештеңемен сынамаңыз). Спринт соңында олар автотесттің бүкіл командамен қалай жұмыс істейтіні туралы демонстрация жасады (пайдалы). Осылайша, барлық топ мүшелерінің автоматтандыру процесіне қатысуы, сондай-ақ автотесттерге сенім артты және бұл автотест міндетті түрде қолданылады (және тұрақты сәтсіздіктерге байланысты бір айдан кейін түсініктеме берілмейді).

Айтпақшы, DevOpsForum 2019 көрмесінде ашық микрофон болды - бұрыннан белгілі және менің ойымша, пайдалы сөйлеу форматы. Сіз осылай айналасыз, баяндамаларды тыңдайсыз, содан кейін конференцияда белгілі бір тақырыпты немесе мәселені талқылау, мәселені шешуде тиісті тәжірибемен бөлісу керек деп шешесіз.

Ұйымдастырушылардың қысқаша баяндамалар легін жасағанын да байқадым. Әр есеп 10 минуттан аспайды, одан кейін сұрақтар беріледі. Осылайша сіз бірден көптеген тақырыптарды қамти аласыз және сізді қызықтыратын спикерлерге сұрақтар қоя аласыз.

DevOpsForum 2019. DevOps енгізуді күте алмайсыз
DevOpsForum 2019. DevOps енгізуді күте алмайсыз
Презентациялар арасында мен конференция серіктестерінің стендтерін аралап, көп нәрсені ұрладым/ұтып алдым. О, мен таратпаны жақсы көремін!

Дөңгелек үстел және DevOps мәселелері Alfastrakhovanie әзірлеу жөніндегі директорымен

Мен үшін DevOpsForum 2019 тортындағы глазурь DevOps сарапшыларымен бір сағатқа созылған пленарлық сессия болды. Сессияның төрт қатысушысы DevOps-қа әртүрлі қырынан қарауға шақырылды: Антон Исанин (Альфастрахование, әзірлеу жөніндегі директор), Наиля Замашкина (Fintech Lab, операциялық директор), Олег Егоркин (Ростелеком, Agile коуч) және Антон Мартьянов (тәуелсіз сарапшы, DevOps-қа қарады. іскерлік тұрғыдан).

Сарапшылар халыққа жақынырақ отырды, содан кейін жағдай басталды: бір сағат бойы аудитория қатысушылары өз сұрақтарын қойды, ал сарапшылар рэп алды. Кейде нағыз пікірталас болды. Сұрақтар өте әртүрлі болды, мысалы: DevOps инженерлері мүлдем қажет пе, неге оларды жүйелік әкімші ретінде оқытуға болмайды, DevOps барлығына ұсынылуы керек пе, оның құндылығы қандай және т.б.

Содан кейін мен Антон Исанинмен жеке сөйлестім. Біз DevOps мәдениетін әр үйге жеткізу қажеттілігін талқыладық және DevOps трансформациясының қараңғы жағын аштық.

Барлығы жиналып, DevOps өнімге де, бизнес пен командаға да қажет деп шешті деп елестетіп көрейік. Оны жүзеге асырайық. Бәрі ойдағыдай болды. Біз дем шығардық. DevOps бізді клиентке жақындатты, енді біз оның барлық тілектерін тез орындай аламыз. Нәтижесінде бізде қатаң ережелері мен талаптары бар үлкен операциялық бөлім бар және ол үнемі өнімдегі ақауларды тауып, көптеген сұраныстар тудырады. Сонымен қатар, клиент күтпеген жерден түймені жасыл емес сары түске бояғысы келсе де, барлық ақауларға «шұғыл» күй беріледі. Жоба өсіп келеді, шығарылымдар саны өсуде және сәйкесінше, клиенттердің жаңа функционалдық ақаулар мен түсінбеушіліктері. Ops ақаулар туралы хабарлау үшін тағы 10 адамды, ал әзірлеу оларды жабу үшін тағы 15 адамды жалдайды. Жаңа мүмкіндіктерді енгізудің орнына команда шексіз SD-мен жұмыс істейді, пайдаланушыға функционалдылықты түсіндіреді және бір уақытта қолдау көрсетеді. Нәтижесінде операция да, әзірлеу де жұмыс істеп тұр, бірақ клиент пен бизнес риза емес: жаңа мүмкіндіктер тоқтап қалады. DevOps бар сияқты, бірақ ол жоқ сияқты.

DevOps енгізу қажеттілігіне қатысты Антон бұл бизнестің ауқымына тікелей байланысты екенін анық айтты. Егер жылына бір клиентке қызмет көрсету компанияға миллиард әкелсе, DevOps қажет емес (егер бұл клиентке жаңа өзгерістерді жүйелі түрде енгізу қажет болмаса). Барлығы шоколадпен қапталған. Бірақ егер бизнес өсіп, көбірек клиенттер пайда болса, сізге сәйкес келу керек. Әдетте, компанияда бастапқыда керемет операция жоқ. Алдымен біз өнімді кесеміз, содан кейін ғана өнімнің жұмыс істеуі үшін серверлерді қадағалап, жеткізілімдерді бақылау керек екенін түсінеміз. Дәл осы кезде Ops пайда болады. Опс жеке бөлім ретінде дамуға көптеген кедергілер қоя бастайтынын және барлық жеткізілімдер тоқтай бастайтынын түсіну керек. Яғни, бұл жағдайда DevOps мәдениеті қазірдің өзінде өзекті, бірақ біз оның қараңғы жағын ұмытпауымыз керек.

Ақпарат көзі: www.habr.com

пікір қалдыру