DevOps тәжірибелері жұмыс істейді. Шығарылымды орнату уақытын 10 есе қысқартқанда біз бұған өзіміз көз жеткіздік. Біз VTB-де қолданатын FIS Profile жүйесінде қазір орнату 90 емес, 10 минутты алады. Шығарылымды құрастыру уақыты екі аптадан екі күнге дейін қысқарды. Тұрақты енгізу ақауларының саны дерлік минимумға дейін төмендеді. «Қол еңбегінен» құтылу және сатушыға тәуелділікті жою үшін балдақпен жұмыс істеуге және күтпеген шешімдерді табуға тура келді. Кесектің астында біз толыққанды ішкі дамуды қалай салғанымыз туралы егжей-тегжейлі әңгіме бар.
Пролог: DevOps - бұл философия
Соңғы бір жылда біз ВТБ-да DevOps тәжірибесін ішкі әзірлеу мен енгізуді ұйымдастыру бойынша үлкен жұмыс атқардық:
- Біз 12 жүйе үшін ішкі даму процестерін құрастырдық;
- Біз 15 құбырды іске қостық, оның төртеуі өндіріске әкелінді;
- Автоматтандырылған 1445 сынақ сценарийі;
- Біз ішкі топтар дайындаған бірқатар шығарылымдарды сәтті орындадық.
DevSecOps тәжірибесін әзірлеуді және енгізуді ұйымдастырудың ең қиын бірі FIS Profile жүйесі – реляциялық емес ДҚБЖ-дағы бөлшек өнім процессоры болып шықты. Соған қарамастан, біз әзірлеуді құрастыра алдық, құбырды іске қостық, өнімге жеке шығарылмайтын пакеттерді орнаттық және шығарылымдарды құрастыруды үйрендік. Тапсырма оңай емес, бірақ қызықты және іске асыруда айқын шектеулерсіз болды: міне, жүйе - сіз ішкі дамуды құруыңыз керек. Жалғыз шарт - ықшам дискіні өнімді ортадан бұрын пайдалану.
Басында іске асыру алгоритмі қарапайым және түсінікті болып көрінді:
- Біз бастапқы әзірлеу сараптамасын дамытамыз және код командасынан өрескел ақауларсыз қолайлы сапа деңгейіне қол жеткіземіз;
- Біз бар процестерге мүмкіндігінше интеграцияланамыз;
- Кодты айқын кезеңдер арасында тасымалдау үшін біз құбырды кесіп, оның бір ұшын жалғастыруға итереміз.
Осы уақыт ішінде қажетті көлемдегі әзірлеушілер тобы дағдыларды дамытып, шығарылымдарға қосқан үлесін қолайлы деңгейге дейін арттыруы керек. Міне, біз тапсырманы орындалды деп есептей аламыз.
Бұл талап етілетін нәтижеге апаратын энергияны үнемдейтін жол болып көрінетін сияқты: міне, DevOps, команданың өнімділік көрсеткіштері, міне, жинақталған тәжірибе... Бірақ іс жүзінде біз DevOps әлі де философия туралы екенін тағы бір растауды алдық. , және «gitlab процесіне қосылмаған, ansible, nexus және одан әрі тізімнің төменгі жағында».
Іс-шаралар жоспарын тағы бір рет талдап, біз өзімізде аутсорсингтің өзіндік түрін құрып жатқанымызды түсіндік. Сондықтан жоғарыда сипатталған алгоритмге процесті реинжиниринг, сонымен қатар осы процесте жетекші рөлге жету үшін бүкіл даму бағыты бойынша сараптаманы дамыту қосылды. Ең оңай нұсқа емес, бірақ бұл идеологиялық тұрғыдан дұрыс даму жолы.
Ішкі даму неден басталады?
Бұл жұмыс істеуге ыңғайлы жүйе емес еді. Архитектуралық тұрғыдан бұл бір үлкен реляциялық емес ДҚБЖ болды, қажет болған жағдайда шақырылатын және қара жәшік принципі бойынша жұмыс істейтін көптеген жеке орындалатын объектілерден (скрипттер, процедуралар, пакеттер және т.б.) тұратын: ол сұраныс пен мәселелерді қабылдайды. жауап. Басқа да қиындықтарды атап өтуге болады:
- экзотикалық тіл (MUMPS);
- Консоль интерфейсі;
- Танымал автоматтандыру құралдарымен және фреймворктармен интеграцияның болмауы;
- Деректер көлемі ондаған терабайтпен;
- Сағатына 2 миллионнан астам операцияның жүктемесі;
- Маңыздылығы - Іскерлік-Критикалық.
Сонымен қатар, біздің тарапымызда бастапқы код қоймасы болған жоқ. Мүлдем. Құжаттама болды, бірақ барлық негізгі білім мен құзыреттер сыртқы ұйым жағында болды.
Біз оның ерекшеліктері мен төмен таралуын ескере отырып, жүйенің дамуын нөлден дерлік меңгере бастадық. 2018 жылдың қазан айында басталды:
- Құжаттаманы және кодты генерациялау негіздерін оқыды;
- Біз жеткізушіден алған қысқаша даму курсын оқыдық;
- Бастапқы даму дағдыларын меңгерген;
- Біз команданың жаңа мүшелері үшін оқу құралын құрастырдық;
- Біз команданы «жауынгерлік» режимге қосуға келістік;
- Код сапасын бақылау мәселесі шешілді;
- Даму үшін стенд ұйымдастырдық.
Біз үш ай бойы тәжірибе жинақтап, жүйеге енуге жұмсадық, ал 2019 жылдың басынан бастап ішкі даму жарқын болашаққа, кейде қиындықпен, бірақ сенімді және мақсатты түрде өз қозғалысын бастады.
Репозиторийді тасымалдау және автотесттер
Бірінші DevOps тапсырмасы репозиторий болып табылады. Біз қол жеткізуді қамтамасыз ету туралы тез келістік, бірақ бір магистральдық тармағы бар қазіргі SVN-ден бірнеше тармақтар үлгісіне көшу және Git Flow-ті дамыту арқылы мақсатты Git-ке көшу қажет болды. Сондай-ақ бізде жеке инфрақұрылымы бар 2 команда, сонымен қатар шетелдегі сатушы командасының бір бөлігі бар. Мен екі Гитпен өмір сүріп, синхрондауды қамтамасыз етуім керек болды. Мұндай жағдайда ол екі жамандықтың кішісі болды.
Репозиторийдің көші-қоны бірнеше рет кейінге қалдырылды, ол майдандағы әріптестердің көмегімен сәуір айында ғана аяқталды. Git Flow көмегімен біз бастапқыда қарапайым нәрселерді сақтауды ұйғардық және түзету, әзірлеу және шығару арқылы классикалық схемаға тоқталдық. Олар шеберден бас тартуды ұйғарды (ака прод тәрізді). Төменде біз неге бұл опция біз үшін оңтайлы болғанын түсіндіреміз. Жұмысшы ретінде екі командаға ортақ сатушыға тиесілі сыртқы репозиторий пайдаланылды. Ол кестеге сәйкес ішкі репозиториймен синхрондалған. Енді Git және Gitlab көмегімен процестерді автоматтандыру мүмкін болды.
Автотесттер мәселесі таңқаларлық оңай шешілді - бізге дайын негіз ұсынылды. Жүйенің ерекшеліктерін ескере отырып, бөлек операцияны шақыру бизнес-процестің түсінікті бөлігі болды және сонымен бірге бірлік сынағы қызметін атқарды. Тек сынақ деректерін дайындау және сценарийлерді шақырудың және нәтижелерді бағалаудың қажетті тәртібін орнату ғана қалды. Операция статистикасы, процестердің сынилігі және қолданыстағы регрессия әдістемесі негізінде қалыптасқан сценарийлер тізімі толтырылған сайын автоматты сынақтар пайда бола бастады. Енді біз құбырды салуға кірісе аламыз.
Бұл қалай болды: автоматтандыруға дейінгі үлгі
Іске асыру процесінің бар үлгісі - бұл бөлек әңгіме. Әрбір модификация жеке қосымша орнату бумасы ретінде қолмен тасымалданды. Содан кейін Jira-да қолмен тіркеу және орталарда қолмен орнату болды. Жеке пакеттер үшін бәрі түсінікті болды, бірақ шығарылымды дайындаумен бәрі қиынырақ болды.
Құрастыру дербес объектілер болып табылатын жеке жеткізілімдер деңгейінде жүзеге асырылды. Кез келген өзгеріс жаңа жеткізу болып табылады. Басқа нәрселермен қатар, негізгі шығарылым құрамының 60-70 пакеттеріне 10-15 техникалық нұсқалар қосылды - шығарылымға бірдеңені қосу немесе шығару кезінде алынған және шығарылымнан тыс сатылымдардағы өзгерістерді көрсететін нұсқалар.
Жеткізулердегі нысандар бір-бірімен, әсіресе орындалатын кодта, бір-бірінен аз ғана бірегей болып табылады. Орнатылған кодқа да, орнатуы енді ғана жоспарланған кодқа да көптеген тәуелділіктер болды.
Кодтың қажетті нұсқасын алу үшін орнату тәртібін қатаң сақтау қажет болды, оның барысында нысандар физикалық түрде бірнеше рет, шамамен 10-12 рет қайта жазылды.
Пакеттердің пакетін орнатқаннан кейін параметрлерді баптандыру үшін нұсқауларды қолмен орындауға тура келді. Шығарылымды жеткізуші жинап, орнатқан. Шығарылымның құрамы іске асыру сәтіне дейін нақтыланды, бұл «ажырату» пакеттерін құруға әкелді. Нәтижесінде, жеткізілімдердің айтарлықтай бөлігі «ажыратулардың» өзіндік құйрығымен босатудан босатуға ауысты.
Енді бұл тәсілмен – шығару басқатырғышын пакет деңгейінде құрастыру – бір ғана негізгі тармақтың практикалық мәні болмағаны анық. Өндіріске орнату бір жарым сағаттан екі сағатқа дейін қол еңбегін қажет етті. Кем дегенде орнатушы деңгейінде нысанды өңдеу тәртібі көрсетілгені жақсы: өрістер мен құрылымдар олар үшін деректер мен процедуралардан бұрын енгізілген. Дегенмен, бұл тек бөлек пакетте жұмыс істеді.
Бұл тәсілдің логикалық нәтижесі объектілердің қисық нұсқалары түріндегі міндетті орнату ақаулары, қажетсіз кодтар, жетіспейтін нұсқаулар және объектілердің есепке алынбаған өзара әсерлері болды, олар шығарылғаннан кейін қызба жойылды.
Алғашқы жаңартулар: құрастыру және жеткізу
Автоматтандыру осы жол бойындағы құбыр арқылы кодты жіберуден басталды:
- Дайын жеткізілімді қоймадан алыңыз;
- Оны арнайы ортаға орнату;
- Автотесттерді орындау;
- Орнату нәтижесін бағалаңыз;
- Сынақ пәрменінің жағында келесі құбырды шақырыңыз.
Келесі конвейер тапсырманы Jira жүйесінде тіркеп, пәрмендердің тапсырманы орындау уақытына байланысты таңдалған сынақ циклдеріне таратылуын күтуі керек. Триггер – берілген мекенжайға жеткізуге дайындығы туралы хат. Бұл, әрине, айқын балдақ болды, бірақ маған бір жерден бастау керек болды. 2019 жылдың мамыр айында кодты тасымалдау орталарымызды тексеруден басталды. Процесс басталды, оны лайықты пішінге келтіру ғана қалды:
- Әрбір модификация орнату бумасына сәйкес келетін және мақсатты негізгі тармаққа біріктірілетін жеке тармақта орындалады;
- Құбырды іске қосу триггері біріктіру сұрауы арқылы негізгі тармақта жаңа міндеттеменің пайда болуы болып табылады, оны ішкі топтың қызметшілері жабады;
- Репозиторийлер бес минут сайын синхрондалады;
- Орнату пакетін құрастыру басталады - жеткізушіден алынған ассемблер көмегімен.
Осыдан кейін кодты тексеру және беру, құбырды іске қосу және өз тарапымызда жинау бойынша қадамдар болды.
Бұл опция шілде айында іске қосылды. Өтпелі кезеңдегі қиындықтар сатушы мен алдыңғы қатарда біраз наразылық тудырды, бірақ келесі айда біз барлық өрескел жиектерді жойып, командалар арасында процесті орната алдық. Бізде қазір тапсыру және жеткізу бойынша құрастыру бар.
Тамыз айында біз өз құбырымызды пайдалана отырып, өндіріске жеке пакетті бірінші орнатуды аяқтадық, ал қыркүйек айынан бастап, бөлек шығарылмайтын пакеттердің барлық орнатулары біздің CD құралы арқылы орындалды. Сонымен қатар, біз жеткізушіге қарағанда кішірек командамен шығарылым құрамының 40% ішкі тапсырмалардың үлесіне қол жеткізе алдық - бұл сөзсіз жетістік. Ең маңызды міндет қалды - шығарылымды жинау және орнату.
Соңғы шешім: жинақталған орнату пакеттері
Біз жеткізушінің нұсқауларын жазудың автоматтандыру екенін жақсы түсіндік; бізге процестің өзін қайта қарау керек болды. Шешім анық болды - қажетті нұсқалардың барлық нысандары бар шығарылым тармағынан жинақталған қорды жинау.
Біз тұжырымдаманы дәлелдеуден бастадық: біз өткен іске асыру мазмұнына сәйкес шығарылым пакетін қолмен жинадық және оны орталарымызға орнаттық. Бәрі ойдағыдай болды, тұжырымдама өміршең болып шықты. Содан кейін біз инициализация параметрлерін сценарий жасау және оларды міндеттемеге қосу мәселесін шештік. Біз жаңа бума дайындадық және оны контурды жаңартудың бөлігі ретінде сынақ орталарында сынадық. Орнату іске асыру тобының пікірлерінің кең ауқымына қарамастан сәтті болды. Ең бастысы, бізге қараша айындағы шығарылымда құрастырылыммен өндіріске шығуға рұқсат берілді.
Бір айдан астам уақыт қалды, қолмен таңдалған керек-жарақтар уақыт таусылып жатқанын анық көрсетті. Олар құрастыруды шығару тармағынан жасауға шешім қабылдады, бірақ оны неге бөлу керек? Бізде Prod тәрізді өнім жоқ, ал бар филиалдар жақсы емес - қажет емес кодтар көп. Бізге прод-лайктарды тез арада қысқарту керек, бұл үш мыңнан астам міндеттеме. Қолмен құрастыру мүлдем мүмкін емес. Біз өнімді орнату журналы арқылы өтетін және филиалға міндеттемелерді жинайтын сценарийдің сызбасын жасадық. Үшінші рет ол дұрыс жұмыс істеді және «файлмен аяқтағаннан» кейін филиал дайын болды.
Орнату пакетіне өз құрылысшымызды жазып, оны бір аптада бітірдік. Содан кейін орнатушыны жүйенің негізгі функционалдығынан өзгертуге тура келді, себебі ол ашық бастапқы болып табылады. Бірқатар тексерулер мен өзгертулерден кейін нәтиже сәтті деп танылды. Осы уақытта шығарылымның құрамы қалыптасты, оны дұрыс орнату үшін сынақ схемасын өндірістік схемамен теңестіру қажет болды және бұл үшін жеке сценарий жазылды.
Әрине, бірінші орнату туралы көптеген пікірлер болды, бірақ жалпы код жұмыс істеді. Ал үшінші орнатудан кейін бәрі жақсы көріне бастады. Композицияны бақылау және объектілердің нұсқасын басқару қолмен режимде бөлек бақыланды, бұл осы кезеңде әбден ақталды.
Қосымша қиындық ескерілуі керек шығарылымдардың көптігі болды. Бірақ Prod тәрізді тармақ пен Rebase көмегімен тапсырма ашық болды.
Бірінші рет, тез және қатесіз
Біз шығарылымға оптимистік көзқараспен және әртүрлі схемалардағы оннан астам сәтті қондырғылармен жақындадық. Бірақ белгіленген мерзімге бір күн қалғанда, сатушы шығарылымды қабылданған әдіспен орнатуға дайындау жұмысын аяқтамағаны белгілі болды. Егер қандай да бір себептермен құрастыруымыз жұмыс істемесе, шығару үзіледі. Оның үстіне, біздің күш-жігерімізбен, бұл әсіресе жағымсыз. Бізде шегінуге жол болмады. Сондықтан біз балама нұсқаларды ойластырып, іс-шаралар жоспарын дайындап, орнатуды бастадық.
Бір қызығы, 800-ден астам нысаннан тұратын бүкіл шығарылым бірінші рет және небәрі 10 минутта дұрыс басталды. Біз журналдарды тексеруге бір сағат жұмсадық, бірақ қателерді таппадық.
Келесі күні шығарылым чатында үнсіздік болды: іске асыру проблемалары жоқ, қисық нұсқалар немесе «орынсыз» код. Бұл тіпті ыңғайсыз болды. Кейінірек кейбір пікірлер пайда болды, бірақ басқа жүйелермен және алдыңғы тәжірибемен салыстырғанда олардың саны мен басымдығы айтарлықтай төмен болды.
Кумулятивтік әсердің қосымша әсері құрастыру және сынау сапасының жоғарылауы болды. Толық шығарылымның бірнеше рет орнатылуына байланысты құрастыру ақаулары мен орналастыру қателері дер кезінде анықталды. Толық шығарылым конфигурацияларында тестілеу қосымша орнату кезінде пайда болмайтын объектілердің өзара әсер етуіндегі ақауларды қосымша анықтауға мүмкіндік берді. Бұл сөзсіз сәтті болды, әсіресе шығарылымға біздің 57% үлесімізді ескерсек.
Қорытындылар мен қорытындылар
Бір жылдан аз уақыт ішінде біз:
- Экзотикалық жүйені пайдалана отырып, толыққанды ішкі дамуды құру;
- Жеткізушіге сыни тәуелділікті жою;
- Өте жағымсыз мұра үшін CI/CD іске қосыңыз;
- Іске асыру процестерін жаңа техникалық деңгейге көтеру;
- Орналастыру уақытын айтарлықтай қысқарту;
- Іске асыру қателерінің санын айтарлықтай азайту;
- Өзіңізді дамудың жетекші сарапшысы ретінде сенімді түрде жариялаңыз.
Әрине, сипатталған нәрселердің көпшілігі ақымақ сияқты көрінеді, бірақ бұл жүйенің ерекшеліктері және ондағы процестің шектеулері. Қазіргі уақытта өзгерістер IS профилінің өнімдері мен қызметтеріне әсер етті (бас шоттар, пластикалық карталар, жинақ шоттары, эскроу, қолма-қол несиелер), бірақ бұл тәсілді DevOps тәжірибесін енгізу міндеті қойылған кез келген АЖ-де қолдануға болады. Жиынтық үлгіні көптеген жеткізілімдерден кейінгі енгізулер (соның ішінде шығарылмайтын үлгілер) үшін қауіпсіз көшіруге болады.
Ақпарат көзі: www.habr.com