DevOps - VTB-ийн туршлагыг ашиглан хэрхэн бүрэн хэмжээний дотоод хөгжлийг бий болгох вэ

DevOps практикүүд ажилладаг. Бид хувилбарыг суурилуулах хугацааг 10 дахин багасгахад үүнд итгэлтэй байсан. Бидний VTB-д ашигладаг FIS Profile системд суулгацыг 90 минут биш харин 10 минут зарцуулдаг. Хувилбарыг бүтээх хугацаа хоёр долоо хоногоос хоёр өдөр болж буурсан. Байнгын хэрэгжилтийн доголдлын тоо бараг хамгийн бага хэмжээнд хүртэл буурсан. “Гар хөдөлмөр”-өөс ангид байж, худалдагчаас хараат байдлаас ангижрахын тулд бид таягтай ажиллаж, гэнэтийн шийдлийг олох хэрэгтэй болсон. Зүсэлтийн доор бид бүрэн хэмжээний дотоод бүтээн байгуулалтыг хэрхэн бий болгосон тухай дэлгэрэнгүй түүхийг харуулав.

DevOps - VTB-ийн туршлагыг ашиглан хэрхэн бүрэн хэмжээний дотоод хөгжлийг бий болгох вэ
 

Пролог: DevOps бол философи юм

Өнгөрсөн нэг жилийн хугацаанд бид ВТБ-д DevOps практикийг дотоод хөгжүүлэлт, хэрэгжүүлэх ажлыг зохион байгуулах талаар маш их ажил хийсэн.

  • Бид 12 системийн дотоод хөгжлийн процессыг барьсан;
  • Бид 15 дамжуулах хоолойг ашиглалтад оруулсны дөрөвийг нь үйлдвэрлэлд нэвтрүүлсэн;
  • Автоматжуулсан 1445 туршилтын хувилбар;
  • Дотоодын багуудын бэлтгэсэн хэд хэдэн хувилбарыг бид амжилттай хэрэгжүүлсэн.

DevSecOps практикийг дотооддоо хөгжүүлэх, хэрэгжүүлэх ажлыг зохион байгуулахад хамгийн хэцүү зүйл бол FIS Profile систем буюу харилцаа холбоогүй DBMS дээрх жижиглэнгийн бүтээгдэхүүний процессор юм. Гэсэн хэдий ч бид бүтээн байгуулалтыг хийж, дамжуулах хоолойг эхлүүлж, бүтээгдэхүүн дээр тусад нь гаргахгүй багцуудыг суулгаж, хувилбаруудыг хэрхэн угсарч сурсан. Даалгавар нь амаргүй, гэхдээ сонирхолтой бөгөөд хэрэгжүүлэхэд тодорхой хязгаарлалтгүй байсан: систем энд байна - та дотооддоо бүтээн байгуулалтыг бий болгох хэрэгтэй. Цорын ганц нөхцөл бол CD-г бүтээмжтэй орчинд ашиглахаас өмнө ашиглах явдал юм.

Эхлээд хэрэгжүүлэх алгоритм нь энгийн бөгөөд ойлгомжтой мэт санагдсан:

  • Бид анхны хөгжлийн туршлагаа хөгжүүлж, кодын багаас ноцтой согоггүйгээр хүлээн зөвшөөрөгдсөн чанарын түвшинд хүрдэг;
  • Бид аль болох одоо байгаа үйл явцтай нэгдэх;
  • Тодорхой үе шатуудын хооронд код шилжүүлэхийн тулд бид дамжуулах хоолойг таслаж, түүний нэг үзүүрийг үргэлжлэл рүү түлхэж өгдөг.

Энэ хугацаанд шаардлагатай хэмжээний хөгжүүлэлтийн баг ур чадвараа хөгжүүлж, хувилбарт оруулах хувь нэмрийг зөвшөөрөгдөх хэмжээнд хүртэл нэмэгдүүлэх ёстой. Ингээд л бид даалгавраа дуусгасан гэж үзэж болно.

Энэ бол шаардлагатай үр дүнд хүрэх эрчим хүчний хэмнэлттэй зам юм шиг санагдаж байна: энд DevOps байна, энд багийн гүйцэтгэлийн хэмжүүрүүд энд байна, энд хуримтлагдсан туршлага байна ... Гэвч практик дээр бид DevOps нь философийн тухай хэвээр байгаа гэсэн өөр нэг баталгааг хүлээн авлаа. , мөн "gitlab процесст холбогдоогүй, ansible, nexus болон жагсаалтаас доош."

Үйл ажиллагааны төлөвлөгөөнд дахин дүн шинжилгээ хийсний дараа бид дотооддоо аутсорсинг борлуулагчийг бий болгож байгаагаа ойлгосон. Тиймээс дээр дурьдсан алгоритмд процессын дахин инженеринг нэмж, энэ үйл явцад тэргүүлэх үүрэг гүйцэтгэхийн тулд хөгжлийн бүх маршрутын дагуу туршлагаа хөгжүүлсэн. Хамгийн хялбар сонголт биш, гэхдээ энэ бол үзэл суртлын хувьд зөв хөгжлийн зам юм.
 

Дотоодын бүтээн байгуулалт хаанаас эхэлдэг вэ? 

Энэ нь ажиллахад хамгийн ээлтэй систем биш байсан. Архитектурын хувьд энэ нь нэг том хамааралгүй DBMS байсан бөгөөд шаардлагатай бол дуудагдсан бие даасан олон тооны биелэгдэх боломжтой объектуудаас (скрипт, процедур, багц гэх мэт) бүрдсэн бөгөөд хар хайрцагны зарчмаар ажилладаг: хүсэлт хүлээн авч, асуудал гаргадаг. хариу үйлдэл. Анхаарал татахуйц бусад бэрхшээлүүд нь:

  • Экзотик хэл (MUMPS);
  • Консолын интерфейс;
  • Алдартай автоматжуулалтын хэрэгсэл, хүрээтэй интеграцчлал дутмаг;
  • Өгөгдлийн хэмжээ хэдэн арван терабайт;
  • Цагт 2 сая гаруй үйл ажиллагааны ачаалал;
  • Ач холбогдол - Бизнесийн чухал ач холбогдолтой.

Үүний зэрэгцээ манай талд эх кодын хадгалах газар байгаагүй. Бүх. Баримт бичиг байсан ч бүх гол мэдлэг, чадварууд нь гадны байгууллагын талд байсан.
Бид системийн хөгжүүлэлтийг түүний онцлог, бага тархалтыг харгалзан бараг эхнээс нь эзэмшиж эхэлсэн. 2018 оны XNUMX-р сард эхэлсэн:

  • Баримтжуулалт, код үүсгэх үндсийг судалсан;
  • Бид худалдагчаас хүлээн авсан хөгжлийн богино курсыг судалсан;
  • Анхны хөгжлийн ур чадварыг эзэмшсэн;
  • Бид багийн шинэ гишүүдэд зориулсан сургалтын гарын авлагыг эмхэтгэсэн;
  • Бид багийг "байлдааны" горимд оруулахаар тохиролцсон;
  • Кодын чанарын хяналттай холбоотой асуудлыг шийдсэн;
  • Хөгжлийн төлөө стенд зохион байгууллаа.

Бид гурван сарын турш мэдлэг чадвараа хөгжүүлж, системд шимтэж, 2019 оны эхнээс дотооддоо бүтээн байгуулалт гэрэлт ирээдүй рүү чиглэсэн хөдөлгөөнөө заримдаа хүндрэлтэй ч гэсэн өөртөө итгэлтэй, зорилготойгоор эхлүүлсэн.

Хадгалах газрын шилжилт ба автотест

DevOps-ийн эхний даалгавар бол хадгалах газар юм. Бид хандалт хийхээр хурдан тохиролцсон боловч одоогийн SVN-ээс нэг гол салбартай Git-д шилжих, хэд хэдэн салбаруудын загварт шилжиж, Git Flow-ийг хөгжүүлэх шаардлагатай болсон. Бид мөн өөрийн гэсэн дэд бүтэцтэй 2 багтай, мөн гадаадад байгаа борлуулагчийн багийн нэг хэсэгтэй. Би хоёр Гиттэй амьдарч, синхрончлолыг хангах ёстой байсан. Ийм нөхцөлд энэ нь хоёр муугийн хамгийн бага нь байсан.

Хадгалах газрыг шилжүүлэх ажлыг удаа дараа хойшлуулж, зөвхөн XNUMX-р сард фронтын хамт ажиллагсдын тусламжтайгаар дуусгасан. Git Flow-ийн тусламжтайгаар бид бүх зүйлийг энгийн байлгахаар шийдсэн бөгөөд засвар, хөгжүүлэлт, хувилбар бүхий сонгодог схем дээр тогтсон. Тэд мастераа (прод шиг) орхихоор шийджээ. Энэ сонголт яагаад бидний хувьд оновчтой болсныг доор тайлбарлах болно. Худалдагчийн харьяалагддаг, хоёр багийн хувьд нийтлэг байдаг гадаад агуулахыг ажилчны хувьд ашигласан. Энэ нь хуваарийн дагуу дотоод репозитортой синхрончлогдсон. Одоо Git болон Gitlab-ийн тусламжтайгаар процессуудыг автоматжуулах боломжтой болсон.

Автомат туршилтын асуудлыг гайхалтай амархан шийдсэн - бидэнд бэлэн хүрээ өгсөн. Системийн онцлогийг харгалзан тусдаа ажиллагааг дуудах нь бизнесийн үйл явцын ойлгомжтой хэсэг байсан бөгөөд нэгэн зэрэг нэгжийн тест болж байв. Үлдсэн зүйл бол туршилтын өгөгдлийг бэлтгэх, скриптүүдийг дуудаж, үр дүнг үнэлэх хүссэн дарааллыг тогтоох явдал байв. Үйл ажиллагааны статистик, үйл явцын эгзэгтэй байдал, одоо байгаа регрессийн аргачлалын үндсэн дээр бүрдсэн хувилбаруудын жагсаалтыг бөглөхөд автомат туршилтууд гарч ирэв. Одоо бид дамжуулах хоолойг барьж эхлэх боломжтой.

Хэрхэн байсан: автоматжуулалтын өмнөх загвар

Хэрэгжүүлэх үйл явцын одоо байгаа загвар нь тусдаа түүх юм. Өөрчлөлт бүрийг тусдаа нэмэлт суулгах багц болгон гараар шилжүүлсэн. Дараа нь Jira-д гарын авлагын бүртгэл, орчинд гараар суурилуулсан. Бие даасан багцуудын хувьд бүх зүйл тодорхой харагдаж байсан ч хувилбарыг бэлтгэх үед бүх зүйл илүү төвөгтэй болсон.

Угсралт нь бие даасан объект болох бие даасан хүргэлтийн түвшинд явагдсан. Аливаа өөрчлөлт нь шинэ хүргэлт юм. Бусад зүйлсийн дотор үндсэн хувилбарын 60-70 багцад 10-15 техникийн хувилбарыг нэмж оруулсан - хувилбараас ямар нэг зүйлийг нэмэх, хасах үед олж авсан хувилбарууд, мөн хувилбараас гадуурх борлуулалтын өөрчлөлтийг тусгасан хувилбарууд.

Хүргэлтийн доторх объектууд бие биентэйгээ давхцаж, ялангуяа гүйцэтгэх кодонд давхцаж байсан бөгөөд энэ нь тал хувь хүрэхгүй өвөрмөц байсан. Аль хэдийн суулгасан код болон шинээр суулгахаар төлөвлөж байсан кодоос олон хамааралтай байсан. 

Кодын шаардлагатай хувилбарыг авахын тулд суулгах дарааллыг чанд дагаж мөрдөх шаардлагатай байсан бөгөөд энэ хугацаанд объектуудыг олон удаа, зарим нь 10-12 удаа физик байдлаар дахин бичсэн байдаг.

Багцуудыг суулгасны дараа тохиргоог эхлүүлэхийн тулд зааврыг гараар дагах шаардлагатай болсон. Уг хувилбарыг худалдагч угсарч суулгасан. Хувилбарын найрлагыг хэрэгжүүлэхээс өмнө бараг тодорхой болгосон бөгөөд энэ нь "салгах" багцуудыг бий болгоход хүргэсэн. Үүний үр дүнд хангамжийн нэлээд хэсэг нь өөрийн "салгах" сүүлтэй хувилбараас чөлөөлөгдөх хооронд шилжсэн.

Одоо энэ арга барилаар - хувилбарын тааварыг багцын түвшинд цуглуулснаар нэг мастер салбар нь практик утгагүй байсан нь тодорхой байна. Үйлдвэрлэлд суурилуулах нь нэг цаг хагасаас хоёр цаг хүртэл гар ажиллагаатай байсан. Наад зах нь суулгагчийн түвшинд объект боловсруулах дарааллыг зааж өгсөн нь сайн хэрэг: талбарууд болон бүтцийг тэдгээрийн өгөгдөл, процедурын өмнө оруулсан болно. Гэсэн хэдий ч, энэ нь зөвхөн тусдаа багц дотор ажилласан.

Энэхүү аргын логик үр дүн нь суллагдсаны дараа халуурч арилсан объектын тахир хувилбар, шаардлагагүй код, дутуу заавар, объектын харилцан нөлөөлөл хэлбэрээр суурилуулах зайлшгүй согогууд байв. 

Эхний шинэчлэлтүүд: угсарч, хүргэлт хийх

Автоматжуулалт нь энэ маршрутын дагуух хоолойгоор код дамжуулах замаар эхэлсэн:

  • Бэлэн хүргэлтийг агуулахаас авах;
  • Үүнийг зориулалтын орчинд суулгах;
  • Автомат тест хийх;
  • Суурилуулалтын үр дүнг үнэлэх;
  • Туршилтын командын хажуу талд байгаа дараах дамжуулах хоолойг дуудна уу.

Дараагийн дамжуулах хоолой нь Jira дахь даалгаврыг бүртгэж, даалгаврыг хэрэгжүүлэх хугацаанаас хамаарах сонгосон туршилтын гогцоонд хуваарилагдахыг хүлээх ёстой. Триггер - өгөгдсөн хаяг руу хүргэхэд бэлэн байгаа тухай захидал. Энэ нь мэдээжийн хэрэг, мэдээжийн хэрэг, гэхдээ би хаа нэгтээ эхлэх хэрэгтэй болсон. 2019 оны XNUMX-р сард кодын шилжүүлэг манай орчныг шалгаж эхэлсэн. Үйл явц эхэлсэн бөгөөд үүнийг зохих хэлбэрт оруулах л үлдлээ.

  • Өөрчлөлт бүрийг тусдаа салаагаар гүйцэтгэдэг бөгөөд энэ нь суулгацын багцад нийцэж, зорилтот мастер салбар руу нийлдэг;
  • Дамжуулах хоолойг эхлүүлэх гох нь нэгтгэх хүсэлтээр дамжуулан мастер салбар дахь шинэ амлалт гарч ирэх бөгөөд үүнийг дотоод багийн засварчид хаадаг;
  • Хадгалах сангууд таван минут тутамд нэг удаа синхрончлогддог;
  • Суурилуулалтын багцыг угсарч эхэлсэн - худалдагчаас хүлээн авсан ассемблер ашиглан.

Үүний дараа кодыг шалгаж, дамжуулах, хоолойгоо эхлүүлэх, манай талд угсрах алхмууд аль хэдийн байсан.

Энэ сонголтыг долдугаар сард эхлүүлсэн. Шилжилтийн үеийн хүндрэлүүд нь худалдагч болон урд талынхны дургүйцлийг төрүүлсэн боловч дараагийн сард бид бүх барзгар ирмэгийг арилгаж, багуудын дунд үйл явцыг бий болгож чадсан. Бид одоо угсралт, хүргэлтээр угсарч байна.
40-р сард бид дамжуулах хоолойгоо ашиглан үйлдвэрлэлийн тусдаа багцын анхны суулгацыг дуусгаж чадсан бөгөөд XNUMX-р сараас эхлэн тусгайлан гаргахгүй багцын бүх суулгацыг CD хэрэглүүрээр дамжуулан гүйцэтгэсэн. Нэмж дурдахад, бид борлуулагчаас цөөн багтай ажлынхаа XNUMX% -д нь дотоод даалгавруудын эзлэх хувийг биелүүлж чадсан - энэ бол тодорхой амжилт юм. Хамгийн ноцтой ажил бол хувилбарыг угсарч суулгах явдал байв.

Эцсийн шийдэл: хуримтлагдсан суулгацын багц 

Бид худалдагчийн зааврыг бичих нь автоматжуулалт гэдгийг маш сайн ойлгосон тул бид процессыг дахин бодох хэрэгтэй болсон. Шийдэл нь тодорхой байсан - шаардлагатай хувилбаруудын бүх объект бүхий хувилбарын салбараас хуримтлагдсан хангамжийг цуглуулах.

Бид үзэл баримтлалын нотолгооноос эхэлсэн: бид хувилбарын багцыг өнгөрсөн хэрэгжүүлэлтийн агуулгын дагуу гар аргаар угсарч, орчиндоо суулгасан. Бүх зүйл амжилттай болж, үзэл баримтлал нь хэрэгжих боломжтой болсон. Дараа нь бид эхлүүлэх тохиргоог скрипт хийх, тэдгээрийг амлалтад оруулах асуудлыг шийдсэн. Бид контурын шинэчлэлтийн хүрээнд шинэ багц бэлтгэж, туршилтын орчинд туршиж үзсэн. Суулгац амжилттай болсон хэдий ч хэрэгжүүлэх багийн зүгээс өргөн хүрээний санал хүсэлтийг хүлээн авсан. Гэхдээ гол зүйл бол XNUMX-р сард нээлтээ хийхээр манай чуулгантай хамт үйлдвэрлэлд орох зөвшөөрөл өгсөн.

Сар гаруйхан хугацаа үлдээд байхад гар аргаар цуглуулсан хангамж нь цаг хугацаа дуусч байгааг тодорхой харуулж байв. Тэд уг бүтээлийг хувилбарын салбараас хийхээр шийдсэн боловч яагаад үүнийг салгах ёстой гэж? Бидэнд Prod шиг бүтээгдэхүүн байхгүй, одоо байгаа салбарууд нь сайн биш - маш олон шаардлагагүй код байдаг. Бид нэн даруй бүтээгдэхүүнд дуртайг бууруулах шаардлагатай байгаа бөгөөд энэ нь гурван мянга гаруй үүрэг хариуцлага юм. Өөрийнхөө гараар угсрах нь сонголт биш юм. Бид бүтээгдэхүүний суулгалтын бүртгэлээр дамжиж, салбар руу илгээсэн амлалтуудыг цуглуулдаг скриптийг зурсан. Гурав дахь удаагаа зөв ажиллаж, "файл хийж дуусгасны" дараа салбар бэлэн болсон. 

Бид угсралтын багцад зориулж өөрийн барилгачин бичиж, долоо хоногийн дотор дуусгасан. Дараа нь бид суулгагчийг системийн үндсэн функцээс өөрчлөх шаардлагатай болсон, учир нь энэ нь нээлттэй эх сурвалж юм. Хэд хэдэн шалгалт, өөрчлөлт хийсний дараа үр дүнг амжилттай гэж үзсэн. Энэ хооронд хувилбарын найрлага бүрдсэн бөгөөд үүнийг зөв суурилуулахын тулд туршилтын хэлхээг үйлдвэрлэлийн хэлхээтэй уялдуулах шаардлагатай болсон бөгөөд үүнд зориулж тусдаа скрипт бичсэн болно.

Мэдээжийн хэрэг, анхны суулгацын талаар маш олон сэтгэгдэл ирсэн боловч ерөнхийдөө код ажилласан. Гурав дахь суулгацын дараа бүх зүйл сайхан харагдаж эхлэв. Объектуудын найрлагын хяналт, хувилбарын хяналтыг гарын авлагын горимд тусад нь хянаж байсан бөгөөд энэ үе шатанд нэлээд үндэслэлтэй байв.

Нэмэлт сорилт бол анхааралдаа авах ёстой олон тооны бус хувилбарууд байсан. Гэвч Prod-like салбар болон Rebase-ийн тусламжтайгаар ажил ил тод болсон.

Анх удаа, хурдан бөгөөд алдаагүй

Бид хувилбарыг өөдрөгөөр харж, янз бүрийн хэлхээн дээр арав гаруй амжилттай суурилуулсан. Гэвч эцсийн хугацаа дуусахаас нэг өдрийн өмнө худалдагч нь хүлээн зөвшөөрөгдсөн хэлбэрээр угсралтын ажилд бэлтгэх ажлыг дуусгаагүй нь тогтоогджээ. Хэрэв ямар нэг шалтгааны улмаас бидний угсралт ажиллахгүй бол хувилбар тасалдана. Түүнээс гадна, бидний хүчин чармайлтаар, ялангуяа тааламжгүй юм. Бид ухрах арга байгаагүй. Тиймээс бид өөр хувилбаруудыг бодож, үйл ажиллагааны төлөвлөгөө боловсруулж, суурилуулалтыг эхлүүлсэн.

Гайхалтай нь, 800 гаруй объектоос бүрдсэн бүх хувилбар нь анх удаа, ердөө 10 минутын дотор зөв эхэлсэн. Бид логуудыг шалгахад нэг цаг зарцуулсан ч алдаа олдсонгүй.

Маргааш нь бүхэл бүтэн хувилбарын чат чимээгүй байв: хэрэгжүүлэхэд асуудал гараагүй, муруй хувилбарууд эсвэл "зохисгүй" код. Энэ нь бүр ямар нэгэн байдлаар эвгүй байсан. Хожим нь зарим тайлбарууд гарч ирсэн боловч бусад системүүд болон өмнөх туршлагаас харахад тэдгээрийн тоо, тэргүүлэх чиглэл нь мэдэгдэхүйц бага байсан.

Хуримтлагдах үр нөлөөний нэмэлт нөлөө нь угсралт, туршилтын чанарыг нэмэгдүүлэх явдал байв. Бүрэн хувилбарыг олон удаа суулгасан тул угсралтын согог, байршуулалтын алдааг цаг тухайд нь илрүүлсэн. Бүрэн хувилбарын тохиргоонд туршилт хийснээр нэмэлт суурилуулалтын явцад гарч ирээгүй объектуудын харилцан нөлөөллийн согогийг нэмэлт байдлаар тодорхойлох боломжтой болсон. Энэ нь гарцаагүй амжилттай байсан, ялангуяа бидний гаргахад 57% хувь нэмэр оруулсан.

Үр дүн ба дүгнэлт

Жил хүрэхгүй хугацаанд бид дараахь зүйлийг хийж чадсан.

  • Экзотик системийг ашиглан бүрэн хэмжээний дотоод хөгжлийг бий болгох;
  • Худалдагчийн эгзэгтэй хамаарлыг арилгах;
  • Маш найрсаг бус өв залгамжлалын хувьд CI/CD-г ажиллуул;
  • Хэрэгжүүлэх үйл явцыг техникийн шинэ түвшинд гаргах;
  • Байршуулах хугацааг мэдэгдэхүйц багасгах;
  • Хэрэгжилтийн алдааны тоог мэдэгдэхүйц бууруулах;
  • Өөрийгөө хөгжлийн тэргүүлэх мэргэжилтэн гэдгээ итгэлтэйгээр зарла.

Мэдээжийн хэрэг, тайлбарласан зүйлсийн ихэнх нь дэмий хоосон юм шиг харагддаг, гэхдээ эдгээр нь системийн онцлог шинж чанарууд бөгөөд түүнд байгаа үйл явцын хязгаарлалт юм. Одоогийн байдлаар өөрчлөлтүүд нь IS профайлын бүтээгдэхүүн, үйлчилгээнд (мастер данс, хуванцар карт, хадгаламжийн данс, эскроу, бэлэн мөнгөний зээл) нөлөөлсөн боловч DevOps практикийг хэрэгжүүлэх зорилт тавьсан аливаа IS-д энэ аргыг хэрэглэж болно. Хуримтлагдсан загварыг олон хүргэлтээс дараагийн хэрэгжүүлэлтүүдэд (түүний дотор гаргаагүй) аюулгүйгээр хуулбарлаж болно.

Эх сурвалж: www.habr.com

сэтгэгдэл нэмэх