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