DevOps-un tərifi çox mürəkkəbdir, ona görə də hər dəfə bu barədə müzakirəyə yenidən başlamalıyıq. Təkcə Habré-də bu mövzuda min nəşr var. Ancaq bunu oxuyursunuzsa, yəqin ki, DevOps-un nə olduğunu bilirsiniz. Çünki mən deyiləm. Salam mənim adım Aleksandr Titov (@) və biz sadəcə DevOps haqqında danışacağıq və mən öz təcrübəmi paylaşacağam.
Uzun müddətdir ki, hekayəmi necə faydalı etmək barədə düşünürəm, ona görə də burada çoxlu suallar olacaq - özümə və şirkətimizin müştərilərinə verdiyim suallar. Bu suallara cavab verməklə anlayış daha yaxşı olur. Mən sizə DevOps-un mənim nöqteyi-nəzərimdən nə üçün lazım olduğunu, yenə də mənim nöqteyi-nəzərdən onun nə olduğunu və mənim nöqteyi-nəzərimdən yenidən DevOps-a doğru irəlilədiyinizi necə başa düşəcəyinizi söyləyəcəyəm. Son nöqtə suallardan ibarət olacaq. Onlara özünüz cavab verərək, şirkətinizin DevOps-a doğru irəlilədiyini və ya hansısa şəkildə problemlərin olub olmadığını başa düşə bilərsiniz.
Bir vaxtlar birləşmə və satınalma dalğalarına minirdim. Əvvəlcə Qik adlı kiçik bir startapda işlədim, sonra onu Skype adlı bir qədər böyük şirkət aldı, sonra Microsoft adlı bir qədər böyük şirkət tərəfindən satın alındı. O anda DevOps ideyasının müxtəlif ölçülü şirkətlərdə necə dəyişdiyini görməyə başladım. Bundan sonra DevOps-a bazar nöqteyi-nəzərindən baxmaqda maraqlı oldum və həmkarlarımla birlikdə Express 42 şirkətini qurduq. Artıq 6 ildir ki, biz bazarın dalğaları ilə irəliləyirik.
Digər şeylər arasında mən DevOps Moskva icmasının təşkilatçılarından biriyəm və DevOps-Days 2017-nin təşkilatçısıyam, lakin 2018-i təşkil etməmişəm. Express 42 bir çox şirkətlə işləyir. Biz orada DevOps-u yetişdiririk, bunun necə baş verdiyini izləyirik, nəticələr çıxarırıq, təhlil edirik, nəticələrimizi hər kəsə söyləyirik və insanları DevOps təcrübələrində öyrədirik. Ümumiyyətlə, biz bununla bağlı təcrübə və təcrübəmizi artırmaq üçün əlimizdən gələni edirik.
Niyə DevOps
Hər kəsi düşündürən və hər zaman ilk sual budur - niyə? Bir çox insanlar DevOps-un sadəcə avtomatlaşdırma və ya hər bir şirkətdə mövcud olan oxşar bir şey olduğunu düşünür.
— Davamlı İnteqrasiyamız var idi - bu o deməkdir ki, bizdə artıq DevOps var idi və bütün bunlar nə üçün lazımdır? Xaricdə əylənirlər, amma işləməyimizə mane olurlar!
Cəmiyyətin və metodologiyanın 9 illik inkişafı, bunun hələ də marketinq parıltısı olmadığı aydın oldu, lakin bunun nə üçün lazım olduğu hələ də tam aydın deyil. Hər hansı bir alət və proses kimi, DevOps-un da son nəticədə nail olduğu xüsusi məqsədləri var.
Bütün bunlar dünyanın dəyişməsi ilə bağlıdır. O, korporativ yanaşmadan uzaqlaşır, şirkətlər bizim Sankt-Peterburq klassikimizin oxuduğu kimi, müəyyən strategiyaya uyğun olaraq, müəyyən strukturla, A nöqtəsindən B nöqtəsinə doğru bir xəyala doğru irəliləyir.
Prinsipcə, İT-də hər şey bu yanaşmaya uyğun qurulmalıdır. Burada İT yalnız prosesləri avtomatlaşdırmaq üçün istifadə olunur.
Avtomatlaşdırma tez-tez dəyişmir, çünki şirkət yaxşı keçib getdiyi zaman, dəyişməli nə var? İşləyir - ona toxunmayın. İndi dünyada yanaşmalar dəyişir və Agile adlanan yanaşma B son nöqtəsinin dərhal görünmədiyini göstərir.
Şirkət bazardan keçəndə, müştəri ilə işləyəndə daim bazarı araşdırır və son B nöqtəsini dəyişir. Üstəlik, şirkət öz istiqamətini nə qədər tez-tez dəyişsə, sonda bir o qədər uğurlu olur, çünki daha çox bazar seçir. nişlər.
Strategiya bu yaxınlarda öyrəndiyim maraqlı bir şirkət tərəfindən nümayiş etdirilir. One Box Shave bir qutuda ülgüc və təraş aksesuarları üçün abunə çatdırılması xidmətidir. Onlar müxtəlif müştərilər üçün öz “qutularını” necə fərdiləşdirməyi bilirlər. Bu, müəyyən bir proqram təminatı tərəfindən həyata keçirilir, sonra sifarişi malı istehsal edən Koreya fabrikinə göndərir.
Bu məhsul Unilever tərəfindən 1 milyard dollara alınıb. İndi o, Gillette ilə rəqabət aparır və Amerika bazarında istehlakçıların əhəmiyyətli bir hissəsini əlindən alıb. One Box Shave deyir:
- 4 bıçaq? ciddisən? Bu niyə lazımdır - bu təraşın keyfiyyətini yaxşılaşdırmır. Xüsusi seçilmiş krem, ətir və iki bıçaqlı yüksək keyfiyyətli ülgüc o axmaq 4 Gillette bıçağından daha çox problemi həll edir! Tezliklə 10-a çatacağıq?
Dünya belə dəyişir. Unilever iddia edir ki, onlarda bunu etməyə imkan verən sərin İT sistemi var. Sonda bir konsepsiya kimi görünür Bazar vaxtı, artıq heç kimin danışmadığı.
Vaxtdan bazara çıxarmağın məqsədi nə qədər tez-tez yerləşdirməyimiz deyil. Siz tez-tez yerləşdirə bilərsiniz, lakin buraxılış dövrləri uzun olacaq. Üç aylıq buraxılış dövrləri bir-birinin üstünə qoyulursa, onları bir həftə dəyişdirirsə, şirkət həftədə bir dəfə yerləşdirdiyi görünür. İdeyadan son icraya qədər isə 3 ay çəkir.
Bazara qədər vaxt ideyadan son icraya qədər olan vaxtı minimuma endirməkdən ibarətdir.
Bu halda proqram təminatı bazarla qarşılıqlı əlaqədə olur. One Box Shave veb saytının müştəri ilə qarşılıqlı əlaqəsi belədir. Onların satış işçiləri yoxdur - sadəcə ziyarətçilərin klikləyib istəklərini buraxdığı vebsayt. Müvafiq olaraq, yeni bir şey daim saytda yerləşdirilməli və istəklərə uyğun olaraq yenilənməlidir. Məsələn, Cənubi Koreyada Rusiyadan fərqli təraş edirlər və şam ağacının deyil, məsələn, yerkökü və vanilin qoxusunu xoşlayırlar.
Saytın məzmununu tez dəyişdirmək lazım olduğundan, proqram təminatının inkişafı çox dəyişir. Proqram vasitəsi ilə müştərinin nə istədiyini öyrənməliyik. Əvvəllər biz bunu bəzi dairəvi yollarla, məsələn, biznesin idarə edilməsi vasitəsilə öyrənirdik. Sonra biz onu dizayn etdik, tələbləri İT sisteminə qoyduq və hər şey gözəl idi. İndi fərqlidir - proqram təminatı mühəndislər də daxil olmaqla prosesdə iştirak edən hər kəs tərəfindən hazırlanır, çünki texniki spesifikasiyalar vasitəsilə onlar bazarın necə işlədiyini öyrənirlər və həmçinin öz fikirlərini bizneslə bölüşürlər.
Məsələn, Qik-də birdən öyrəndik ki, insanlar serverə əlaqə siyahılarını yükləməyi çox sevirlər və onlar bizə proqram təqdim etdilər. Əvvəlcə bu barədə düşünmədik. Klassik bir şirkətdə hər kəs bunun bir səhv olduğuna qərar verərdi, çünki spesifikasiyalar əla işləməli olduğunu söyləmədiyindən və ümumiyyətlə dizdə tətbiq olunduğundan, xüsusiyyəti söndürərdilər və dedilər: "Bu heç kimə lazım deyil, Ən əsası odur ki, əsas funksionallıq işləyir.” . Texnologiya şirkəti isə buna fürsət kimi baxır və buna uyğun olaraq proqram təminatını dəyişməyə başlayır.
1968-ci ildə uzaqgörən bir oğlan Melvin Konvey aşağıdakı fikri formalaşdırdı.
Sistemi yaradan təşkilat, həmin təşkilatın kommunikasiya strukturunu təkrarlayan dizaynla məhdudlaşdırılır.
Daha ətraflı desək, fərqli tipli sistemlər istehsal etmək üçün, həmçinin fərqli tipli bir şirkət daxilində rabitə strukturunuz olmalıdır. Əgər kommunikasiya strukturunuz yüksək iyerarxikdirsə, bu, sizə çox yüksək Vaxt-Bazar göstəricisini təmin edə bilən sistemlər yaratmağa imkan verməyəcək.
Oxuyun olar . DevOps mədəniyyətini və ya fəlsəfəsini anlamaq üçün vacibdir, çünki DevOps-da əsaslı şəkildə dəyişən yeganə şey komandalar arasında ünsiyyətin strukturudur.
Proses nöqteyi-nəzərindən DevOps-dan əvvəl bütün mərhələlər: analitika, inkişaf, sınaq, əməliyyat xətti idi.
DevOps vəziyyətində bütün bu proseslər eyni vaxtda baş verir.
Bazara çatma vaxtı bunu etməyin yeganə yoludur. Köhnə prosesdə işləyən insanlar üçün bu, bir qədər kosmik görünür və ümumiyyətlə belədir.
Bəs sizə nə üçün DevOps lazımdır?
Rəqəmsal məhsulun inkişafı üçün. Əgər şirkətinizdə rəqəmsal məhsul yoxdursa, DevOps-a ehtiyac yoxdur - bu çox vacibdir.
DevOps proqram təminatının ardıcıl istehsalının sürət məhdudiyyətlərini dəf edir. Onda bütün proseslər eyni vaxtda baş verir.
Çətinlik artır. DevOps evangelistləri sizə proqram təminatını buraxmağı asanlaşdıracağını söyləyəndə bu cəfəngiyyatdır.
DevOps ilə işlər daha da mürəkkəbləşəcək.
Avito stendindəki konfransda siz Docker konteynerini yerləşdirməyin nə olduğunu görə bilərsiniz - qeyri-real tapşırıq. Mürəkkəblik çətinləşir; eyni anda bir çox topla hoqqabazlıq etməlisiniz.
DevOps şirkətdəki prosesi və təşkilatı tamamilə dəyişir — daha doğrusu, dəyişən DevOps deyil, rəqəmsal məhsuldur. DevOps-a gəlmək üçün hələ də bu prosesi tamamilə dəyişdirməlisiniz.
Bir mütəxəssis üçün suallar
Sənin nəyin var? Bir şirkətdə işləyərkən və bir mütəxəssis kimi inkişaf edərkən özünüzə verə biləcəyiniz suallar.
Rəqəmsal məhsul yaratmaq üçün strategiyanız varmı? Əgər varsa, bu, artıq yaxşıdır. Bu o deməkdir ki, şirkətiniz DevOps-a doğru irəliləyir.
Şirkətiniz artıq rəqəmsal məhsul yaradırmı? Bu o deməkdir ki, siz daha yüksək səviyyəyə qalxa və hər şeyi daha maraqlı edə bilərsiniz – yenə DevOps nöqteyi-nəzərindən. Mən ancaq bu baxımdan danışıram.
Şirkətiniz rəqəmsal məhsul nişində bazar liderlərindən biridir? Spotify, Yandex, Uber indi texnoloji tərəqqinin zirvəsində olan şirkətlərdir.
Özünüzə bu sualları verin və bütün cavablar yoxsa, o zaman bu şirkətdə DevOps etməməlisiniz. Əgər DevOps mövzusu sizin üçün həqiqətən maraqlıdırsa, bəlkə... başqa şirkətə keçməlisiniz? Əgər şirkətiniz DevOps-a daxil olmaq istəyirsə, lakin siz bütün suallara “Xeyr” cavabını vermisinizsə, deməli bu, heç vaxt dəyişməyəcək o gözəl kərgədan kimidir.
Təşkilat
Dediyim kimi, Conway qanununa görə, şirkətin təşkili dəyişir. Təşkilati baxımdan DevOps-un şirkət içərisinə nüfuz etməsinə mane olan şeydən başlayacağam.
"Quyular" problemi
İngiliscə “Silo” sözü burada rus dilinə “yaxşı” kimi tərcümə olunur. Bu problemin mahiyyəti ondan ibarətdir ki komandalar arasında məlumat mübadiləsi aparılmır. Hər bir komanda naviqasiya üçün ümumi xəritə yaratmadan öz təcrübəsini dərindən araşdırır.
Müəyyən mənada bu, mənə Moskvaya yeni gəlmiş və metro xəritəsində necə hərəkət edəcəyini hələ bilməyən bir insanı xatırladır. Moskvalılar adətən öz ərazilərini çox yaxşı bilirlər və bütün Moskvada metro xəritəsindən istifadə edərək hərəkət edə bilirlər. Moskvaya ilk dəfə gələndə sizdə bu bacarıq yoxdur və sadəcə olaraq yönünü itirirsiniz.
DevOps bu oriyentasiya anından keçməyi və ümumi qarşılıqlı əlaqə xəritəsi yaratmaq üçün birlikdə işləyən bütün şöbələri təklif edir.
Buna iki amil mane olur.
Korporativ idarəetmə sisteminin nəticəsi. Ayrı-ayrı iyerarxik “quyularda” tikilir. Məsələn, bu sistemi dəstəkləyən şirkətlərdə müəyyən KPI-lər var. Digər tərəfdən, öz təcrübəsinin hüdudlarından kənara çıxmaqda çətinlik çəkən və bütün sistemi idarə etməkdə çətinlik çəkən insanın beyni buna mane olur. Sadəcə narahatdır. Təsəvvür edin ki, Banqkok hava limanındasınız - tez bir zamanda yolunuzu tapa bilməyəcəksiniz. DevOps-da naviqasiya etmək də çətindir və buna görə insanlar ora çatmaq üçün bələdçi tapmaq lazım olduğunu söyləyirlər.
Amma ən əsası odur ki, DevOps ruhu ilə aşılanmış, Fauleri və bir sıra başqa kitabları oxumuş mühəndis üçün “quyu” problemi belə ifadə olunur ki, "quyular" sizə "aşkar" şeylər etməyə imkan vermir. Biz DevOps Moskvadan sonra tez-tez bir araya gəlirik, bir-birimizlə danışırıq və insanlar şikayətlənir:
— Biz sadəcə olaraq CI-ni işə salmaq istəyirdik, lakin məlum oldu ki, rəhbərlik buna ehtiyac duymur.
Bu, məhz ona görə baş verir CI и Davamlı Çatdırılma prosesi bir çox imtahanın sərhədindədirlər. Sadəcə olaraq təşkilati səviyyədə “quyular” problemini aradan qaldırmadan, nə etsəniz də, nə qədər kədərli olsa da, irəli gedə bilməyəcəksiniz.
Şirkətdəki prosesin hər bir iştirakçısı: backend və frontend tərtibatçıları, sınaq, DBA, əməliyyat, şəbəkə, öz istiqamətində qazırlar və menecerdən başqa heç kimin ümumi xəritəsi yoxdur, birtəhər onlara nəzarət edir və “bölün” istifadə edərək idarə edir. və qalib gəl” metodu.
İnsanlar bəzi ulduzlar və ya bayraqlar üçün mübarizə aparır, hər kəs öz təcrübəsini qazır.
Nəticədə, bütün bunları birləşdirmək və ümumi boru kəməri çəkmək vəzifəsi ortaya çıxanda və ulduzlar və bayraqlar üçün mübarizə aparmağa ehtiyac qalmadıqda, sual yaranır - onsuz da nə etməli? Biz bir şəkildə razılığa gəlməliyik, amma bunu məktəbdə bizə heç kim öyrətməyib. Bizə məktəbdən dərs deyirlər: səkkizinci sinif - vay! - yeddinci siniflə müqayisədə! Burada da eynidir.
Sizin şirkətdə də belədir?
Bunu yoxlamaq üçün özünüzə aşağıdakı sualları verə bilərsiniz.
Komandalar ümumi alətlərdən istifadə edir və bu ümumi alətlərdə dəyişikliklərə töhfə verirmi?
Komandalar nə qədər tez-tez yenidən təşkil olunur - bir komandanın bəzi mütəxəssisləri digər komandaya keçir? Bu, DevOps mühitində normal hala gəlir, çünki bəzən bir insan başqa bir mütəxəssis sahəsinin nə etdiyini başa düşə bilmir. O, başqa şöbəyə keçir, iki həftə orada işləyir, özü üçün oriyentasiya və bu şöbə ilə qarşılıqlı əlaqə xəritəsi yaradır.
Dəyişiklik komitəsi yaradaraq vəziyyəti dəyişmək olarmı? Yoxsa ən yüksək rəhbərliyin və istiqamətin güclü əlini tələb edir? Bu yaxınlarda Facebook-da yazdım ki, bir az tanınan bank sifarişlər vasitəsilə alətləri necə tətbiq edir: biz sifariş yazırıq, bir il ərzində həyata keçiririk və nə baş verir. Bu, əlbəttə ki, uzun və kədərlidir.
Menecerlər üçün şirkətin nailiyyətlərini nəzərə almadan şəxsi nailiyyətlər əldə etmək nə dərəcədə vacibdir?
Bu suallara özünüz cavab versəniz, şirkətinizdə belə bir problemin olub-olmadığı daha aydın olar.
İnfrastruktur kod kimi
Bu problem keçdikdən sonra DevOps-da daha da irəliləmək çətin olan ilk vacib təcrübədir kod kimi infrastruktur.
Çox vaxt infrastruktur kod kimi aşağıdakı kimi qəbul edilir:
— Gəlin hər şeyi bash-da avtomatlaşdıraq, özümüzü skriptlərlə əhatə edək ki, adminlərin əl işi az olsun!
Amma bu doğru deyil.
Kod kimi infrastruktur o deməkdir ki, siz işlədiyiniz İT sistemini daim onun vəziyyətini başa düşmək üçün kod şəklində təsvir edirsiniz.
Digər komandalarla birlikdə hər kəsin anlaya biləcəyi və naviqasiya və naviqasiya edə biləcəyi kod şəklində xəritə yaradırsınız. Nə edildiyinin fərqi yoxdur - Chef, Ansible, Salt və ya Kubernetes-də YAML fayllarından istifadə - heç bir fərq yoxdur.
Konfransda 2GIS-dən olan həmkarı, fərdi sistemlərin strukturunu təsvir edən Kubernetes üçün öz daxili əşyalarını necə hazırladıqlarını söylədi. 500 sistemi təsvir etmək üçün onlara bu təsviri yaradan ayrıca alət lazım idi. Bu təsvir olduqda, hər kəs bir-biri ilə yoxlaya bilər, dəyişiklikləri izləyə bilər, onu necə dəyişdirmək və təkmilləşdirmək olar, nə çatışmır.
Razılaşın, fərdi bash skriptləri adətən bu anlayışı təmin etmir. İşlədiyim şirkətlərin birində hətta "yalnız yaz" skriptinin adı var idi - ssenari yazıldıqda, lakin onu oxumaq artıq mümkün deyil. Məncə bu sizə də tanışdır.
Kod olduğu kimi infrastruktur infrastrukturun cari vəziyyətini təsvir edən kod. Bir çox məhsul, infrastruktur və xidmət qrupları bu kod üzərində birlikdə işləyir və ən əsası, onların hamısı bu kodun əslində necə işlədiyini başa düşməlidir.
Kod ən yaxşı kod təcrübələrinə uyğun olaraq saxlanılır: birgə inkişaf, kodun nəzərdən keçirilməsi, XP-proqramlaşdırma, sınaq, çəkmə sorğuları, kod infrastrukturları üçün CI - bütün bunlar uyğundur və istifadə edilə bilər.
Kod bütün mühəndislər üçün ümumi dilə çevrilir.
Kodda infrastrukturun dəyişdirilməsi çox vaxt tələb etmir. Bəli, infrastruktur kodunun da texniki borcu ola bilər. Adətən komandalar bununla spagetti kodu kimi yazdıqları bir dəstə skript və ya hətta Ansible şəklində "kod kimi infrastruktur" tətbiq etməyə başladıqdan bir il yarım sonra qarşılaşırlar və onlar həmçinin qarışıq skriptləri də qarışdırırlar!
Vacibdir: Əgər bu materialı hələ sınamamısınızsa, bunu unutmayın Ansible bash deyil! Sənədləri diqqətlə oxuyun, bu barədə yazdıqlarını öyrənin.
İnfrastruktur kod kimi infrastruktur kodunun ayrı-ayrı təbəqələrə ayrılmasıdır.
Şirkətimizdə biz çox aydın və sadə olan 3 əsas təbəqəni ayırırıq, lakin onların sayı daha çox ola bilər. İnfrastruktur kodunuza baxıb bu vəziyyətin olub-olmadığını deyə bilərsiniz. Heç bir təbəqə vurğulanmırsa, bir az vaxt ayırmalı və bir az refaktor etməlisiniz.
əsas təbəqə - OS, ehtiyat nüsxələr və digər aşağı səviyyəli şeylər belə konfiqurasiya edilir, məsələn, Kubernetes əsas səviyyədə necə yerləşdirilir.
Xidmət səviyyəsi - bunlar tərtibatçıya təqdim etdiyiniz xidmətlərdir: xidmət kimi giriş, xidmət kimi monitorinq, xidmət kimi verilənlər bazası, xidmət kimi balanslaşdırıcı, xidmət kimi növbə, xidmət kimi davamlı çatdırılma - ayrı-ayrı komandaların təqdim etdiyi xidmətlər dəstəsi inkişafını təmin edə bilər. Bütün bunlar konfiqurasiya idarəetmə sisteminizdə ayrıca modullarda təsvir edilməlidir.
Tətbiqlərin edildiyi təbəqə və əvvəlki iki təbəqənin üstündə necə açılacağını təsvir edir.
Nəzarət sualları
Şirkətinizin ümumi infrastruktur deposu varmı? İnfrastrukturunuzda texniki borcları idarə edirsiniz? İnfrastruktur anbarında inkişaf təcrübələrindən istifadə edirsinizmi? İnfrastrukturunuz təbəqələrə bölünübmü? Siz Base-service-APP diaqramını yoxlaya bilərsiniz. Dəyişiklik etmək nə qədər çətindir?
Dəyişikliklər etmək üçün bir gün yarım lazım olduğunu hiss etmisinizsə, bu o deməkdir ki, sizin texniki borcunuz var və onunla işləmək lazımdır. İnfrastruktur kodunuzda texniki borc dırmığı ilə rastlaşdınız. Bəzi CCTL-ni dəyişdirmək üçün infrastruktur kodunun yarısını yenidən yazmaq lazım olanda bir çox belə hekayələri xatırlayıram, çünki yaradıcılıq və hər şeyi avtomatlaşdırmaq istəyi hər şeyin hər yerdə korroziyaya uğramasına, bütün tutacaqların çıxarıldığına və refaktor etmək lazımdır.
Davamlı Çatdırılma
Gəlin debeti kreditlə müqayisə edək. Əvvəlcə infrastrukturun təsviri gəlir, bu olduqca sadə ola bilər. Hər şeyi ətraflı təsvir etmək lazım deyil, lakin onunla işləmək üçün bəzi əsas təsvir tələb olunur. Əks halda, bundan sonra davamlı çatdırılma ilə nə edəcəyi aydın deyil. Bütün bu təcrübələr DevOps-a gəldiyiniz zaman eyni vaxtda baş verir, lakin bu, nəyə sahib olduğunuzu və onu necə idarə edəcəyinizi anlamaqdan başlayır. Bu, infrastrukturun kod kimi praktikasıdır.
Buna sahib olduğunuz və onu necə idarə edəcəyiniz aydınlaşdıqdan sonra, inkişaf etdirici kodunu mümkün qədər tez istehsala necə göndərəcəyinizi anlamağa başlayırsınız. Tərtibatçı ilə birlikdə deyirəm - "quyular" problemini xatırlayırıq, yəni bunu fərdi insanlar deyil, bir komanda ortaya qoyur.
Yanımızda olanda Vanya Evtuxoviç ilk kitabı gördüm Jez Humble və müəllif qrupları "Daimi Çatdırılma", 2009-cu ildə işıq üzü görən filmin başlığını rus dilinə necə çevirəcəyimizi uzun müddət düşündük. Bunu “Daimi çatdırmaq” kimi tərcümə etmək istəyirdilər, amma təəssüf ki, “Favamlı çatdırılma” kimi tərcümə olundu. Mənə elə gəlir ki, bizim adımızda təzyiqlə, rusca nəsə var.
Daimi çatdırılma vasitələri
Məhsul anbarında olan kod həmişə istehsala endirilə bilər. O, sönük olmaya bilər, amma həmişə buna hazırdır. Müvafiq olaraq, siz həmişə quyruq sümüyünüzün altında bəzi narahatlıq hissi ilə izah etmək çətin olan kod yazırsınız. İnfrastruktur kodunu yaydığınız zaman tez-tez görünür. Bəzi narahatlıq hissi mövcud olmalıdır - bu, kodu bir az fərqli yazmağa imkan verən beyin proseslərini işə salır. Bu, inkişaf daxilindəki qaydalarda qeyd edilməlidir.
Ardıcıl şəkildə çatdırmaq üçün sizə infrastruktur platformasında işləyən artefakt formatı lazımdır. İnfrastruktur platformasına müxtəlif formatlı "həyat tullantıları" atırsanız, o, birləşir, onu saxlamaq çətindir və texniki borc problemi yaranır. Artefaktın formatını uyğunlaşdırmaq lazımdır - bu həm də kollektiv işdir: hamımız bir araya gəlməliyik, beynimizdə xışıltı və bu formatı tapmalıyıq.
Artefakt davamlı olaraq təkmilləşdirilir və çatdırılma boru kəmərindən keçərkən istehsal mühitinə uyğun olaraq dəyişir. Bir artefakt boru kəməri boyunca hərəkət edərkən, daim onun üçün əlverişsiz olan bəzi şeylərlə qarşılaşır, bunlar istehsala qoyduğunuz artefaktın qarşılaşdığı şeyə bənzəyir. Klassik inkişafda bunu tətbiqetməni həyata keçirən sistem administratoru edirsə, DevOps prosesində bu, hər zaman baş verir: burada onu bəzi testlərlə sınaqdan keçirdilər, burada onu Kubernetes klasterinə atdılar, bu da az-çox oxşardır. istehsala, sonra birdən yük testinə başladılar.
Bu, bir qədər Pac-Man oyununu xatırladır - artefakt bir növ hekayədən keçir. Eyni zamanda, kodun həqiqətən hekayədən keçib-keçmədiyini və bir şəkildə istehsalınızla əlaqəli olub olmadığını nəzarət etmək vacibdir. İstehsaldan hekayələr Davamlı Çatdırılma prosesinə sürüklənə bilər: bir şey düşəndə belə idi, indi bu ssenarini sistem daxilində proqramlaşdıraq. Hər dəfə kod bu ssenaridən keçəcək və növbəti dəfə bu problemlə qarşılaşmayacaqsınız. Bu barədə müştərinizə çatandan çox əvvəl öyrənəcəksiniz.
Fərqli yerləşdirmə strategiyaları. Məsələn, kodu müxtəlif müştərilərdə fərqli şəkildə sınamaq, kodun necə işlədiyi haqqında məlumat almaq və 100 milyon istifadəçiyə yayıldığı vaxtdan xeyli əvvəl almaq üçün AB testindən və ya kanareyka yerləşdirmələrindən istifadə edirsiniz.
"Ardıcıl çatdırmaq" belə görünür.
Çatdırılma prosesi Dev, CI, Test, PreProd, Prod ayrıca mühit deyil, bunlar artefaktınızın keçdiyi yanmaz məbləğləri olan mərhələlər və ya stansiyalardır.
Baza Xidmət Tətbiqi kimi təsvir olunan infrastruktur kodunuz varsa, o, kömək edir bütün skriptləri unutma, və onları bu artefakt üçün kod kimi yazın, artefaktı təbliğ etmək və getdikcə dəyişdirin.
Özünü test sualları
95% hallarda xüsusiyyət təsvirindən istehsala buraxılana qədər vaxt bir həftədən azdır? Boru kəmərinin hər mərhələsində artefaktın keyfiyyəti yaxşılaşırmı? Onun keçdiyi bir hekayə varmı? Fərqli yerləşdirmə strategiyalarından istifadə edirsiniz?
Bütün cavablar bəlidirsə, deməli siz inanılmaz dərəcədə sərinsiniz! Cavablarınızı şərhlərdə yazın - şad olaram).
Əlaqə
Bu, ən çətin təcrübədir. DevOpsConf konfransında, bu barədə danışan Infobip-dən olan bir həmkarı sözlərində bir az çaşqın oldu, çünki bu, həqiqətən, hər şeyi izləmək lazım olduğuna dair çox mürəkkəb bir təcrübədir!
Məsələn, uzun müddət əvvəl mən Qikdə işləyəndə hər şeyi izləmək lazım olduğunu başa düşdük. Biz bunu etdik və hazırda Zabbix-də 150 əşyamız var və onlar daim nəzarətdə saxlanılır. Dəhşətli idi, texniki direktor barmağını məbədində bükdü:
- Uşaqlar, niyə anlaşılmaz bir şeylə serverə təcavüz edirsiniz?
Ancaq sonra bir hadisə baş verdi ki, bu, həqiqətən çox gözəl strategiyadır.
Xidmətlərdən biri davamlı olaraq sıradan çıxmağa başladı. Əvvəlcə o, qəzaya uğramadı, maraqlıdır, kod ora əlavə edilmədi, çünki o, praktiki olaraq heç bir iş funksiyasına malik olmayan əsas broker idi - sadəcə fərdi xidmətlər arasında mesajlar göndərdi. Xidmət 4 ay ərzində dəyişmədi və birdən “Seqmentasiya xətası” xətası ilə çökməyə başladı.
Biz şoka düşdük, Zabbix-də qrafiklərimizi açdıq və məlum oldu ki, bir həftə yarım əvvəl bu brokerin istifadə etdiyi API xidmətində sorğuların davranışı çox dəyişdi. Sonra gördük ki, müəyyən növ mesajların göndərilmə tezliyi dəyişib. Sonradan bildik ki, bunlar Android müştəriləridir. Soruşduq:
— Uşaqlar, bir həftə yarım əvvəl sizə nə olub?
Cavab olaraq, UI-ni necə yenidən dizayn etdikləri ilə bağlı maraqlı bir hekayə eşitdik. Çətin ki, kimsə dərhal HTTP kitabxanasını dəyişdiyini desin. Android müştəriləri üçün bu, vanna otağında sabun dəyişdirmək kimidir - onlar sadəcə xatırlamırlar. Nəticədə, 40 dəqiqəlik söhbətdən sonra onların HTTP kitabxanasını dəyişdiyini və onun standart vaxtlarının dəyişdiyini bildik. Bu, API serverində trafik davranışının dəyişməsinə səbəb oldu və bu, broker daxilində yarışa səbəb olan vəziyyətə gətirib çıxardı və o, çökməyə başladı.
Dərin monitorinq olmadan bunu açmaq ümumiyyətlə mümkün deyil. Əgər təşkilatda hələ də “quyu” problemi varsa, hamı bir-birinin üstünə pul atanda bu, illərlə davam edə bilər. Siz sadəcə olaraq serveri yenidən başladın, çünki problemi həll etmək mümkün deyil. Sizdə olan bütün hadisələri izlədikdə, izlədikdə, izlədikdə və monitorinqi sınaq kimi istifadə etdikdə - kod yazın və dərhal onu necə izləyəcəyinizi, həmçinin kod şəklində göstərin (kod olaraq artıq infrastrukturumuz var), hər şey aydın olur. xurma üzərində. Hətta belə mürəkkəb problemlər asanlıqla izlənilir.
İstehsalda deyil, çatdırılma prosesinin hər mərhələsində artefaktla nə baş verdiyinə dair bütün məlumatları toplayın.
Monitorinqi CI-yə yükləyin və bəzi əsas şeylər artıq orada görünəcək. Daha sonra siz onları Test, PredProd və yükləmə testində görəcəksiniz. Bütün mərhələlərdə məlumat toplayın, təkcə ölçülər, statistika deyil, həm də qeydlər: tətbiqin necə yayıldığı, anomaliyalar - hər şeyi toplayın.
Əks halda bunu başa düşmək çətin olacaq. Artıq dedim ki, DevOps daha mürəkkəbdir. Bu mürəkkəbliyin öhdəsindən gəlmək üçün normal analitikaya sahib olmalısınız.
Özünə nəzarət üçün suallar
Monitorinqiniz və qeydləriniz sizin üçün inkişaf alətidirmi? Kod yazarkən siz də daxil olmaqla tərtibatçılarınız ona necə nəzarət etmək barədə düşünürlərmi?
Müştərilərdən problemlər haqqında eşidirsiniz? Monitorinq və girişdən müştərini daha yaxşı başa düşürsən? Sistemin monitorinqi və qeydindən daha yaxşı başa düşürsünüzmü? Sadəcə olaraq sistemdə trendin artdığını görüb, daha 3 həftədən sonra hər şeyin öləcəyini başa düşdüyünüz üçün sistemi dəyişirsiniz?
Bu üç komponentə sahib olduqdan sonra şirkətinizdə hansı infrastruktur platforması olduğunu düşünə bilərsiniz.
İnfrastruktur platforması
Məsələ onda deyil ki, bu, hər bir şirkətin malik olduğu bir-birindən fərqli alətlər toplusudur.
İnfrastruktur platformasının mahiyyəti ondan ibarətdir ki, bütün komandalar bu vasitələrdən istifadə edir və onları birlikdə inkişaf etdirir.
Aydındır ki, infrastruktur platformasının ayrı-ayrı hissələrinin hazırlanmasına cavabdeh olan ayrı-ayrı komandalar var. Ancaq eyni zamanda, hər bir mühəndis infrastruktur platformasının inkişafı, performansı və təşviqi üçün məsuliyyət daşıyır. Daxili səviyyədə o, ümumi alətə çevrilir.
Bütün komandalar infrastruktur platformasını inkişaf etdirir və ona öz IDE kimi diqqətlə yanaşırlar. IDE-də hər şeyi gözəl və sürətli etmək üçün müxtəlif plaginlər quraşdırırsınız və isti düymələri konfiqurasiya edirsiniz. Sublime, Atom və ya Visual Studio Code-u açdığınız zaman kod xətaları yaranır və siz heç işləməyin mümkün olmadığını başa düşürsünüz, dərhal kədərlənirsiniz və IDE-ni düzəltməyə qaçırsınız.
İnfrastruktur platformanıza eyni şəkildə yanaşın. Əgər onunla səhv bir şey olduğunu başa düşsəniz, özünüz düzəldə bilmirsinizsə, sorğu buraxın. Sadə bir şey varsa, özünüz redaktə edin, çəkmə sorğusu göndərin, uşaqlar onu nəzərdən keçirəcək və əlavə edəcəklər. Bu, tərtibatçının başındakı mühəndislik alətlərinə bir az fərqli yanaşmadır.
İnfrastruktur platforması keyfiyyətin davamlı təkmilləşdirilməsi ilə artefaktın inkişafdan müştəriyə ötürülməsini təmin edir. IP istehsalda kodla baş verən hekayələr toplusu ilə proqramlaşdırılmışdır. İnkişaf illəri ərzində bu hekayələrin çoxu var, onlardan bəziləri unikaldır və yalnız sizə aiddir - onları Google-da tapmaq mümkün deyil.
Bu nöqtədə, infrastruktur platforması sizin rəqabət üstünlüyünüzə çevrilir, çünki onun daxilində rəqibin alətində olmayan bir şey var. IP-niz nə qədər dərin olsa, bazara çıxma vaxtı baxımından rəqabət üstünlüyünüz bir o qədər çox olar. Burada görünür satıcı kilidi problemi: Başqasının platformasını götürə bilərsiniz, lakin başqasının təcrübəsindən istifadə edərək, bunun sizin üçün nə qədər uyğun olduğunu başa düşməyəcəksiniz. Bəli, hər şirkət Amazon kimi platforma qura bilməz. Bu, şirkətin təcrübəsinin bazardakı mövqeyinə uyğun olduğu çətin bir xəttdir və orada satıcı kilidindən istifadə edə bilməzsiniz. Bu barədə düşünmək də vacibdir.
Sxem
Bu, DevOps şirkətində bütün təcrübə və prosesləri qurmağınıza kömək edəcək infrastruktur platformasının əsas diaqramıdır.
Nədən ibarət olduğuna baxaq.
Resurs orkestri sistemi, proqramlar və digər xidmətlərə CPU, yaddaş, disk təqdim edir. Bunun üzərinə - aşağı səviyyəli xidmətlər: monitorinq, giriş, CI/CD Mühərriki, artefakt saxlama, sistem kodu kimi infrastruktur.
Daha yüksək səviyyəli xidmətlər: xidmət olaraq verilənlər bazası, xidmət olaraq növbələr, xidmət olaraq Yük balansı, xidmət olaraq təsvirin ölçüsünün dəyişdirilməsi, xidmət olaraq Big Data fabriki. Bunun üzərinə - müştərinizə daim dəyişdirilmiş kodu çatdıran boru kəməri.
Siz proqram təminatınızın müştəri üçün necə işlədiyi barədə məlumat alırsınız, onu dəyişdirirsiniz, bu kodu yenidən təqdim edirsiniz, məlumat alırsınız - və beləliklə, həm infrastruktur platformasını, həm də proqram təminatınızı daim inkişaf etdirirsiniz.
Diaqramda çatdırılma boru kəməri bir çox mərhələdən ibarətdir. Ancaq bu, nümunə kimi verilmiş sxematik diaqramdır - onu bir-bir təkrarlamağa ehtiyac yoxdur. Mərhələlər xidmətlərlə sanki xidmətlər kimi qarşılıqlı əlaqədədir - platformanın hər bir kərpicinin öz hekayəsi var: resursların necə bölüşdürüldüyü, tətbiqin necə işə salındığı, resurslarla necə işlədiyi, monitorinqi və dəyişiklikləri.
Platformanın hər bir hissəsinin bir hekayə daşıdığını başa düşmək vacibdir və özünüzdən bu kərpicin hansı hekayəni daşıdığını soruşun, bəlkə də onu atıb üçüncü tərəf xidməti ilə əvəz etmək lazımdır. Məsələn, kərpic yerinə Okmetr quraşdırmaq mümkündürmü? Ola bilsin ki, uşaqlar bu təcrübəni bizdən daha çox inkişaf etdiriblər. Amma ola bilsin ki, bizim unikal təcrübəmiz var, biz Prometeyi quraşdırıb onu daha da inkişaf etdirməliyik.
Platformanın yaradılması
Bu mürəkkəb bir ünsiyyət prosesidir. Əsas təcrübələriniz olduqda, tələbləri və standartları inkişaf etdirən müxtəlif mühəndislər və mütəxəssislər arasında ünsiyyətə başlayırsınız və onları daim müxtəlif alət və yanaşmalara dəyişdirirsiniz. DevOps-da malik olduğumuz mədəniyyət burada vacibdir.
Mədəniyyət ilə hər şey çox sadədir - əməkdaşlıq və ünsiyyət haqqındadır, yəni bir-biri ilə ortaq sahədə işləmək istəyi, bir aləti birlikdə idarə etmək istəyi. Burada raket elmi yoxdur - hər şey çox sadədir, banaldır. Məsələn, biz hamımız girişdə yaşayırıq və onu təmiz saxlayırıq - belə bir mədəniyyət səviyyəsi.
Sənin nəyin var?
Yenə sualları özünüzə verə bilərsiniz.
İnfrastruktur platforması ayrılıbmı? Onun inkişafına kim cavabdehdir? İnfrastruktur platformanızın rəqabət üstünlüklərini başa düşürsünüzmü?
Bu sualları daim özünüzə verməlisiniz. Əgər bir şey üçüncü tərəfin xidmətlərinə ötürülə bilərsə, o, köçürülməlidir; əgər üçüncü tərəf xidməti hərəkətinizi əngəlləməyə başlayırsa, o zaman özünüzdə bir sistem qurmalısınız.
Beləliklə, DevOps...
... bu mürəkkəb sistemdir, onda olmalıdır:
- Rəqəmsal məhsul.
- Bu rəqəmsal məhsulu inkişaf etdirən biznes modulları.
- Kod yazan məhsul qrupları.
- Davamlı Çatdırılma təcrübələri.
- Xidmət kimi platformalar.
- İnfrastruktur xidmət kimi.
- İnfrastruktur kod kimi.
- DevOps-a daxil edilmiş etibarlılığı qorumaq üçün ayrıca təcrübələr.
- Hamısını təsvir edən geribildirim təcrübəsi.
Siz bu diaqramdan istifadə edərək, şirkətinizdə artıq hansısa formada olanı vurğulayaraq istifadə edə bilərsiniz: o inkişaf edibmi və ya hələ də inkişaf etdirilməlidir.
Bir neçə həftəyə bitəcək . RIT++ hissəsi kimi. Davamlı çatdırılma, kod kimi infrastruktur və DevOps transformasiyası haqqında çoxlu gözəl hesabatlar tapa biləcəyiniz konfransa gəlin. , son qiymət tarixi 20 may
Mənbə: www.habr.com