Bir dəfə biz bir obyektdə müştəriyə elektron sənəd dövriyyəsi sistemi təqdim etdik. Və sonra başqa bir obyektə. Və daha bir. Və dördüncü və beşinci. Bizi o qədər daşıdıq ki, 10 paylanmış obyektə çatdıq. Bu, çox güclü oldu... xüsusən də dəyişiklikləri çatdırmağa çatanda. İstehsal dövrəsinə çatdırılmanın bir hissəsi olaraq, sınaq sisteminin 5 ssenarisi nəticədə 10 saat və 6-7 işçi tələb etdi. Bu cür xərclər bizi mümkün qədər nadir hallarda tədarük etməyə məcbur etdi. Üç illik əməliyyatdan sonra biz buna dözə bilmədik və layihəni bir çimdik DevOps ilə rəngləndirməyə qərar verdik.
İndi bütün sınaqlar 3 saat ərzində baş verir və orada 3 nəfər iştirak edir: mühəndis və iki sınaqçı. Təkmilləşdirmələr aydın şəkildə rəqəmlərlə ifadə edilir və çox sevilən TTM-in azalmasına səbəb olur. Təcrübəmizə görə, DevOps-dan faydalana bilən müştərilər, hətta bu haqda bilənlərdən daha çoxdur. Buna görə də, DevOps-u insanlara yaxınlaşdırmaq üçün biz bu yazıda daha ətraflı danışacağımız sadə konstruktor hazırladıq.
İndi sizə daha ətraflı danışaq. Bir enerji şirkəti 10 iri obyektdə texniki sənəd idarəetmə sistemini tətbiq edir. Bu miqyaslı layihələri DevOps olmadan idarə etmək asan deyil, çünki əl əməyinin böyük bir hissəsi işi xeyli gecikdirir və həmçinin keyfiyyəti azaldır - bütün əl işləri səhvlərlə doludur. Digər tərəfdən, yalnız bir quraşdırmanın olduğu layihələr var, lakin hər şey avtomatik olaraq, daim və uğursuzluq olmadan işləməlidir - məsələn, böyük monolit təşkilatlarda eyni sənəd axını sistemləri. Əks təqdirdə, kimsə parametrləri əl ilə edəcək, yerləşdirmə təlimatlarını unudacaq - və nəticədə istehsalda parametrlər itiriləcək və hər şey çökəcək.
Adətən biz müştəri ilə müqavilə əsasında işləyirik və bu halda maraqlarımız bir qədər fərqlənir. Müştəri layihəyə ciddi şəkildə büdcə və texniki şərtlər daxilində baxır. Texniki spesifikasiyalara daxil edilməyən müxtəlif DevOps təcrübələrinin faydalarını ona izah etmək çətin ola bilər. Əgər o, əlavə biznes dəyəri olan sürətli buraxılışlarla və ya avtomatlaşdırma boru kəmərinin tikintisi ilə maraqlanırsa?
Təəssüf ki, əvvəlcədən təsdiqlənmiş xərclə işləyərkən bu maraq həmişə tapılmır. Təcrübəmizdə, vicdansız və diqqətsiz bir podratçının inkişafını götürməli olduğumuz bir hal var idi. Dəhşətli idi: ən müasir mənbə kodları yox idi, eyni sistemin kod bazası müxtəlif qurğularda fərqli idi, sənədlər qismən yox idi və qismən də dəhşətli keyfiyyətdə idi. Əlbəttə ki, müştərinin mənbə kodu, montaj, buraxılışlar və s. üzərində nəzarəti yox idi.
İndiyə qədər hər kəs DevOps haqqında bilmir, lakin biz onun üstünlüklərindən, real resurs qənaətindən danışan kimi bütün müştərilərin gözləri işıqlanır. Beləliklə, DevOps daxil olan sorğuların sayı zamanla artır. Burada müştərilərlə eyni dildə asanlıqla danışmaq üçün uyğun inkişaf boru kəmərinin qurulmasına kömək edəcək biznes problemləri və DevOps təcrübələrini tez bir zamanda birləşdirməliyik.
Beləliklə, bir tərəfdən bir sıra problemlərimiz var, digər tərəfdən DevOps biliklərimiz, təcrübələrimiz və alətlərimiz var. Təcrübəni niyə hamı ilə paylaşmayaq?
DevOps konstruktorunun yaradılması
Agile-in öz manifestosu var. ITIL-in öz metodologiyası var. DevOps daha az şanslıdır - o, hələ şablonlar və standartlar əldə etməyib. Baxmayaraq ki onların inkişafı və əməliyyat təcrübələrinin qiymətləndirilməsi əsasında şirkətlərin yetkinlik dövrünü müəyyən edir.
Xoşbəxtlikdən, 2014-cü ildə tanınmış Gartner şirkəti və əsas DevOps təcrübələrini və onlar arasındakı əlaqələri təhlil etdi. Buna əsaslanaraq infoqrafik yayımladım:
Biz bunu özümüz üçün əsas götürdük . Dörd sahənin hər birində alətlər dəsti var - biz onları verilənlər bazasında topladıq, ən populyarlarını, inteqrasiya nöqtələrini və uyğun optimallaşdırma mexanizmlərini müəyyənləşdirdik. Ümumilikdə belə çıxdı 36 təcrübə və 115 alət, dörddə biri açıq mənbə və ya pulsuz proqram təminatıdır. Sonra, hər bir sahədə nələrə nail olduğumuzdan və nümunə olaraq, yazıya başladığımız texniki sənəd idarəetməsinin yaradılması layihəsində bunun necə həyata keçirildiyi barədə danışacağıq.
Proseslər
Bədnam EDMS layihəsində texniki sənədlərin idarə edilməsi sistemi 10 obyektin hər birində eyni sxem üzrə yerləşdirilib. Quraşdırmaya 4 server daxildir: verilənlər bazası serveri, proqram serveri, tam mətnin indeksləşdirilməsi və məzmunun idarə edilməsi. Quraşdırmada onlar bir qovşaq daxilində işləyirlər və obyektlərdəki məlumat mərkəzində yerləşirlər. Bütün obyektlər infrastruktur baxımından bir qədər fərqlənir, lakin bu, qlobal qarşılıqlı əlaqəyə mane olmur.
Əvvəlcə DevOps təcrübələrinə uyğun olaraq, infrastrukturu yerli olaraq avtomatlaşdırdıq, sonra çatdırılmanı sınaq dövrəsinə, sonra isə müştərinin məhsuluna gətirdik. Hər bir proses addım-addım işlənib hazırlanmışdır. Ətraf mühit parametrləri avtomatik yeniləmə üçün paylama dəstinin tərtib edildiyini nəzərə alaraq mənbə kodu sistemində sabitlənir. Konfiqurasiya dəyişiklikləri halında, mühəndislər sadəcə versiyaya nəzarət sisteminə müvafiq dəyişikliklər etməlidirlər - və sonra avtomatik yeniləmə problemsiz baş verəcəkdir.
Bu yanaşma sayəsində test prosesi xeyli sadələşdirilmişdir. Əvvəllər layihədə stendləri əl ilə yeniləməkdən başqa heç nə etməyən sınaqçılar var idi. İndi sadəcə gəlirlər, görürlər ki, hər şey işləyir və daha faydalı işlər görürlər. Hər bir yeniləmə avtomatik olaraq sınaqdan keçirilir - səth səviyyəsindən biznes ssenarisinin avtomatlaşdırılmasına qədər. Nəticələr TestRail-də ayrıca hesabatlar şəklində yerləşdirilir.
Культура
Davamlı təcrübə ən yaxşı test dizaynı nümunəsi ilə izah olunur. Hələ mövcud olmayan sistemi sınaqdan keçirmək yaradıcı işdir. Test planı yazarkən, necə düzgün test edəcəyinizi və hansı filialları izləyəcəyinizi başa düşməlisiniz. Həm də çeklərin optimal sayını müəyyən etmək üçün vaxt və büdcə arasında tarazlıq tapın. Lazımi testləri dəqiq seçmək, istifadəçinin sistemlə necə qarşılıqlı əlaqə quracağını düşünmək, ətraf mühiti və mümkün xarici amilləri nəzərə almaq vacibdir. Davamlı təcrübə olmadan etmək mümkün deyil.
İndi qarşılıqlı əlaqə mədəniyyəti haqqında. Əvvəllər iki əks tərəf var idi - mühəndislər və tərtibatçılar. Tərtibatçılar dedilər: “Onun necə işə salınacağı bizi maraqlandırmır. Siz mühəndissiniz, ağıllısınız, əmin olun ki, o, nasazlıqsız işləsin”. Mühəndislər cavab verdi: “Siz tərtibatçılar çox diqqətsizsiniz. Gəlin daha diqqətli olaq və buraxılışlarınızı daha az oynadacağıq. Çünki hər dəfə bizə sızan bir kod versəniz, necə qarşılıqlı əlaqə quracağımız bizə aydın deyil”.. Bu, DevOps perspektivindən fərqli olaraq qurulmuş mədəni qarşılıqlı əlaqə məsələsidir. Burada həm mühəndislər, həm də tərtibatçılar daim dəyişən, lakin eyni zamanda etibarlı proqram təminatına yönəlmiş vahid komandanın bir hissəsidir.
Eyni komanda daxilində mütəxəssislər bir-birinə kömək etməkdə qərarlıdırlar. Əvvəlki kimi? Məsələn, təxminən 50 səhifə uzunluğunda bir neçə qalın yerləşdirmə təlimatı hazırlanırdı.Mühəndis onu oxudu, bir şey başa düşmədi, lənət etdi və səhər saat üçdə tərtibatçıdan şərh istədi. Tərtibatçı şərh etdi və həm də lənət etdi - sonda heç kim xoşbəxt olmadı. Üstəlik, təbii olaraq, bəzi səhvlər oldu, çünki təlimatlarda hər şeyi xatırlaya bilməzsiniz. İndi isə mühəndis tərtibatçı ilə birlikdə tətbiqi proqram təminatı infrastrukturunun avtomatlaşdırılmış şəkildə yerləşdirilməsi üçün skript yazır. Və onlar bir-biri ilə praktiki olaraq eyni dildə danışırlar.
Xalq
Komandanın ölçüsü yeniləmənin əhatə dairəsi ilə müəyyən edilir. Komanda çatdırılmanın formalaşması zamanı işə götürülür, ona ümumi layihə komandasından maraqlananlar daxildir. Sonra hər bir mərhələyə cavabdeh olanlarla bir yeniləmə planı yazılır və komanda irəlilədikcə hesabat verir. Bütün komanda üzvləri bir-birini əvəz edə bilər. Komandanın bir hissəsi olaraq, bizim də ehtiyat tərtibatçımız var, lakin o, demək olar ki, heç vaxt qoşulmaq məcburiyyətində deyil.
Texnologiya
Texnoloji diaqramda bir neçə məqam vurğulanır, lakin onların altında bir dəstə texnologiya var - onların təsvirləri ilə bütöv bir kitab nəşr edə bilərsiniz. Beləliklə, ən maraqlılarını qeyd edəcəyik.
Kod kimi infrastruktur
İndi, yəqin ki, bu konsepsiya heç kəsi təəccübləndirməyəcək, lakin əvvəllər infrastrukturların təsviri çox arzuolunan idi. , sınaq mühitləri unikal idi, onları əzizləyir və əzizləyirdilər, toz hissəcikləri onları sovururdu.
İndi heç kim sınaqdan qorxmur. Virtual maşınların əsas şəkilləri var, mühitlərin yerləşdirilməsi üçün hazır ssenarilər var. Bütün şablonlar və skriptlər versiyaya nəzarət sistemində saxlanılır və dərhal yenilənir. Əvvəllər, bir paketi stendə çatdırmaq lazım olduqda, konfiqurasiya boşluğu yarandı. İndi sadəcə mənbə koduna bir xətt əlavə etməlisiniz.
İnfrastruktur skriptləri və boru kəmərləri ilə yanaşı, sənədləşdirmə üçün Kod kimi Sənədləşdirmə yanaşması da istifadə olunur. Bunun sayəsində yeni insanları layihəyə qoşmaq, onları, məsələn, test planında təsvir olunan funksiyalar əsasında sistemlə tanış etmək, həmçinin test işlərindən təkrar istifadə etmək asandır.
Davamlı çatdırılma və monitorinq
DevOps haqqında, biz davamlı çatdırılma və monitorinqin həyata keçirilməsi üçün alətləri necə seçdiyimizdən danışdıq. Çox vaxt heç nəyi yenidən yazmağa ehtiyac yoxdur - əvvəllər yazılmış skriptlərdən istifadə etmək, komponentlər arasında düzgün inteqrasiya qurmaq və ümumi idarəetmə konsolu yaratmaq kifayətdir. Və bütün proseslər bir düymədən və ya cədvəldən istifadə edərək işə salına bilər.
İngilis dilində Continuous Delivery və Continuous Deployment kimi müxtəlif anlayışlar mövcuddur. Hər ikisini "davamlı çatdırılma" kimi tərcümə etmək olar, amma əslində aralarında cüzi fərq var. Paylanmış enerji şirkətinin texniki sənəd dövriyyəsi üçün layihəmizdə daha doğrusu Çatdırılmadan istifadə olunur - istehsal üçün quraşdırma əmrlə baş verdikdə. Yerləşdirmədə quraşdırma avtomatik olaraq baş verir. Bu layihədə ümumiyyətlə Davamlı Çatdırılma halına gəldi DevOps-un mərkəzi hissəsi.
Ümumiyyətlə, müəyyən parametrləri toplamaqla DevOps təcrübələrinin nə üçün faydalı olduğunu aydın şəkildə başa düşə bilərsiniz. Bunu isə rəqəmləri həqiqətən sevən rəhbərliyə çatdırın. Başlanğıcların ümumi sayı, skript mərhələlərinin icra müddəti, uğurlu buraxılışların payı - bütün bunlar birbaşa olaraq hər kəsin bazara çıxarmaq üçün sevimli vaxtına, yəni versiyaya nəzarət sisteminə öhdəliyin verilməsindən bir versiyanın buraxılmasına qədər olan vaxta birbaşa təsir göstərir. istehsal mühiti. Lazımi vasitələrin tətbiqi ilə mühəndislər qiymətli göstəriciləri poçtla alır və layihə meneceri onları tablosunda görür. Beləliklə, siz dərhal yeni alətlərin faydalarını qiymətləndirə bilərsiniz. Siz DevOps dizaynerindən istifadə edərək onları infrastrukturunuzda sınaya bilərsiniz.
Bizim kimə lazım olacaq ?
Özümüzü iddia etməyək: başlanğıc üçün o, bizim üçün faydalı oldu. Artıq dediyimiz kimi, siz müştəri ilə eyni dildə danışmalısınız və biz DevOps dizaynerinin köməyi ilə belə bir söhbətin əsasını tez bir zamanda çıxara bilərik. Biznes mütəxəssisləri nəyə ehtiyac duyduqlarını özləri qiymətləndirə və bununla da daha sürətli inkişaf edə biləcəklər. İstənilən istifadəçinin nə seçdiyini başa düşməsi üçün bir dəstə təsvir əlavə edərək, dizayneri mümkün qədər təfərrüatlı etməyə çalışdıq.
Dizaynerin formatı tikinti proseslərində və avtomatlaşdırmada şirkətin mövcud inkişaflarını nəzərə almağa imkan verir. Yalnız mövcud proseslərlə yaxşı inteqrasiya edən və sadəcə boşluqları doldura bilən həllər seçə bilsəniz, hər şeyi sökməyə və yenidən qurmağa ehtiyac yoxdur.
Yəqin ki, inkişafınız artıq daha yüksək səviyyəyə keçib və alətimiz çox "kapitan" kimi görünəcək. Amma biz bunu özümüz üçün faydalı hesab edirik və ümid edirik ki, bəzi oxucular üçün faydalı olacaq. xatırladırıq dizaynerə - bir şey varsa, ilkin məlumatları daxil etdikdən dərhal sonra diaqramı alırsınız. Rəy və əlavələrinizə görə minnətdar olacağıq.
Mənbə: www.habr.com