Bu yaxınlarda Logrocon-un ev sahibliyi etdiyi DevOpsForum 2019-da iştirak etdim. Bu konfransda iştirakçılar biznes və inkişaf və informasiya texnologiyaları xidməti mütəxəssisləri arasında effektiv qarşılıqlı əlaqə üçün həllər və yeni alətlər tapmağa çalışıblar.
Konfrans uğurla keçdi: həqiqətən çoxlu faydalı məruzələr, maraqlı təqdimat formatları və məruzəçilərlə çoxlu ünsiyyət var idi. Heç kimin mənə heç bir şey satmağa çalışmaması xüsusilə vacibdir, böyük konfranslarda çıxış edənlər son vaxtlar günahkardırlar.
Raiffeisenbank, Alfastrakhovanie-nin çıxışlarından bir parça, Mango Telecom-un avtomatlaşdırmanın tətbiqi təcrübəsi və kəsilmə altındakı digər detallar.
Mənim adım Yana, mən tester kimi işləyirəm, avtomatlaşdırma ilə yanaşı, DevOps ilə də məşğul oluram və konfranslara və görüşlərə getməyi sevirəm. Son iki il ərzində mən Oleq Buninin konfranslarında (HighLoad++, TeamLead Conf), Jug tədbirlərində (Heisenbug, JPoint), TestCon Moscow, DevOps Pro Moscow, Big Data Moskvada olmuşam.
Mən ilk növbədə konfransın proqramına diqqət çəkirəm. Mən məruzənin nədən ibarət olacağına daha az, daha çox məruzəçiyə baxıram. Hesabatın çox texnoloji və maraqlı olduğu ortaya çıxsa belə, hesabatdakı ən yaxşı təcrübələrdən bəzilərini şirkətinizdə tətbiq edə biləcəyiniz fakt deyil. Və sonra bir natiq lazımdır.
Raiffeisenbank-da boru kəmərinin sonunda işıq
Adətən, məni maraqlandıran kənarlarda natiqlər axtarıram. DevOpsForum 2019-da Raiffeisenbank-ın məruzəçisi Mixail Bizhan mənim marağımı çəkdi. Çıxışı zamanı o, komandalarını tədricən DevOps-a necə bağladıqlarından, buna nə üçün ehtiyac duyduqlarından və DevOps-un çevrilməsi ideyasını biznesə necə satmaqdan danışdı. Yaxşı, ümumiyyətlə, boru kəmərinin sonunda işığı necə görmək barədə danışdım.
Mixail Bizhan, Raiffeisenbank-ın avtomatlaşdırma direktoru
İndi onların şirkətlərində “DevOps” yoxdur. Yəni işləyir, amma bütün komandalarda yox. DevOps-u həyata keçirərkən, həm xüsusi mühəndislər baxımından, həm də məhsula olan ehtiyac və bu məhsulun qurulduğu platformanın yetkinliyi baxımından komandaların hazırlığına etibar edirlər. Misha DevOps-un nə üçün lazım olduğunu biznesə necə izah edəcəyini izah etdi.
Bank seqmentinin bir neçə artım sürücüsü var: xidmətlərin dəyəri və müştəri bazasının genişləndirilməsi. Xidmətlərin qiymətinin artırılması çox yaxşı sürücü deyil, lakin müştəri bazasının artırılması bunun əksidir. Rəqiblər obyektiv şəkildə sərin məhsul buraxsalar, bütün müştərilər ora gedirlər, sonra zaman keçdikcə bazar səviyyəsi qalxır. Ona görə də bazara yeni məhsulların təqdim edilməsi və onların tətbiqi sürəti bankların diqqət yetirdiyi əsas məsələdir. DevOps məhz bu üçündür və müəssisələr bunu başa düşürlər.
Növbəti vacib qeyd: DevOps həmişə bazara çıxma vaxtı azaltmır. DevOps tək işləyə bilməz, bu, inkişafdan istehsala (koddan müştəriyə) məhsulun yaradılması və bazara çıxarılması prosesinin sadəcə bir hissəsidir. Ancaq koddan əvvəl hər şey birbaşa DevOps ilə əlaqəli deyil. Yəni, marketoloqlar bazarı illərlə öyrənə və bütün həyatlarını rəqibləri tutmağa sərf edə bilərlər. Müştərinin nəyə ehtiyacı olduğunu tez başa düşmək və bu və ya digər funksiyanın həyata keçirilməsini planlaşdırmaq lazımdır - çox vaxt bu, DevOps-un işləməsi və şirkətin məqsədinə çatması üçün kifayət deyil. Buna görə də, ilk növbədə Raiffeisenbank bizneslə razılaşdı ki, DevOps-dan necə istifadə etməyi öyrənmək lazımdır. Avtomatlaşdırma naminə avtomatlaşdırma yeni müştərilər üçün mübarizədə çox kömək etməyəcək.
Ümumiyyətlə, Mişa hesab edir ki, DevOps-u həyata keçirmək lazımdır, lakin ağıllı şəkildə. Və biz hazır olmalıyıq ki, transformasiyanın əvvəlində komandanın məhsuldarlığı aşağı düşəcək, daha az pul qazanacaq, amma sonra özünü doğruldacaq.
Mango Telecom-da sınaqların avtomatlaşdırılması
Tester kimi mənim üçün başqa bir maraqlı hesabatı Mango Telecom-dan Eqor Maslov verdi. Təqdimat “SCRUM komandasında tam sınaq dövrünün avtomatlaşdırılması” adlanırdı. Egor DevOps-un xüsusi olaraq SCRUM üçün yaradıldığına inanır, lakin eyni zamanda DevOps-u SCRUM komandasına təqdim etmək olduqca problemlidir. Bu ona görə baş verir ki, SCRUM komandası həmişə hardasa işləyir, yeniliklərlə diqqəti yayındırmağa və prosesi yenidən qurmağa vaxt yoxdur. Problem həm də ondan ibarətdir ki, SCRUM komandada alt komandaların ayrılmasını nəzərdə tutmur (test qrupu, inkişaf qrupu və s.). Bundan əlavə, mövcud bir prosesi avtomatlaşdırmaq üçün sənədlərə ehtiyac var və SCRUM-da çox vaxt tamamilə sənədləşmə yoxdur - "məhsul bir növ yazıdan daha vacibdir."
SCRUM-a keçdikdən sonra testçilər funksiyaları necə sınaqdan keçirmək barədə tərtibatçılarla məsləhətləşməyə başladılar. Tədricən, funksionallığın həcmi artdı, heç bir sənədləşmə yox idi və onlar funksionallıqda testlərlə əhatə olunmayan çoxlu səhvləri tutmağa başladılar və ümumiyyətlə, kimin və nə vaxt sınaqdan keçirdiyi artıq bəlli deyildi. Bir sözlə - qarışıqlıq və tərəddüd. Biz sınaq avtomatlaşdırılmasına keçmək qərarına gəldik. Ancaq o zaman da tam uğursuzluq oldu. Onlar daxili sınaqçılara naməlum bir yığın üzərində yazan kənar avtomatlaşdırma mütəxəssislərini işə götürdülər. Avtotestlər üçün çərçivə, əlbəttə ki, işlədi, lakin autsorserlər getdikdən sonra bu, iki həftə davam etdi. Sonrakı ikinci nömrəli avtotestin tətbiqi cəhdi idi. Bu onunla başladı ki, hər şey şirkət daxilində, öz əlinizlə (düzgün vektor: daxili təcrübə toplamaq), SCRUM çərçivəsində qurulmalı və prosesdə sənədlər yaratmalıdır. Avtomatlaşdırma üçün yığın məhsulun yığınına bərabər olmalıdır (burada onu əlavə edirəm, JavaScript layihənizi başqa bir şeylə sınamayın). Sprintin sonunda onlar avtotestin bütün komanda ilə necə işlədiyini nümayiş etdirdilər (faydalı). Beləliklə, bütün komanda üzvlərinin avtomatlaşdırma prosesinə cəlb edilməsi, həmçinin avtotestlərə inam və bu avtotestin mütləq istifadə olunma şansı artdı (və daimi uğursuzluqlar səbəbindən bir ay ərzində şərh edilməyəcək).
Yeri gəlmişkən, DevOpsForum 2019-da açıq mikrofon var idi - çoxdan məlum olan və mənim fikrimcə, faydalı çıxış formatı. Siz belə gəzirsiniz, məruzələri dinləyirsiniz və sonra qərara gəlirsiniz ki, konfransda müəyyən mövzu və ya problemi müzakirə etməyə, problemin həllində müvafiq təcrübəni bölüşməyə dəyər.
Təşkilatçıların qısa hesabatlar axını etdiyini də müşahidə etdim. Hər hesabat 10 dəqiqədən çox çəkmir, ondan sonra suallar verilir. Bu yolla siz eyni anda bir çox mövzunu əhatə edə və sizi maraqlandıran natiqlərə suallar verə bilərsiniz.
Təqdimatlar arasında mən konfrans tərəfdaşlarının kabinələrini gəzdim və çox şey oğurladım/uddum. Oh, mən paylamanı sevirəm!
Alfastrakhovanie-də inkişaf direktoru ilə dəyirmi masa və DevOps məsələləri
Mənim üçün DevOpsForum 2019 tortunun üzərindəki buzlanma DevOps ekspertləri ilə bir saatlıq plenar iclas oldu. Dörd sessiya iştirakçısı DevOps-a müxtəlif rakurslardan baxmağa dəvət edildi: Anton İsanin (Alfastrakhovanie, inkişaf direktoru), Nailya Zamaşkina (Fintech Lab, əməliyyat direktoru), Oleq Eqorkin (Rostelecom, Çevik məşqçi) və Anton Martyanov (müstəqil ekspert, DevOps-a baxdı. iş nöqteyi-nəzərindən).
Mütəxəssislər insanlara daha yaxın oturdular və sonra hadisələr baş verdi: bütün bir saat ərzində tamaşaçılardan iştirakçılar öz suallarını verdilər və ekspertlər repi götürdülər. Bəzən real mübahisələr olurdu. Suallar çox fərqli idi, məsələn: DevOps mühəndislərinə ümumiyyətlə ehtiyac varmı, niyə onlar sistem administratoru kimi təlim keçə bilmirlər, DevOps hər kəsə təklif olunmalıdır, onun dəyəri nədir və s.
Sonra Anton İsaninlə şəxsən danışdım. Biz DevOps mədəniyyətini hər evə gətirməyin zəruriliyini müzakirə etdik və DevOps transformasiyasının qaranlıq tərəfini aşkar etdik.
Təsəvvür edək ki, hamı bir araya gəldi və qərara gəldi ki, DevOps həm məhsul, həm də biznes və komanda üçün lazımdır. Gəlin onu həyata keçirək. Hər şey düzəldi. Nəfəs aldıq. DevOps bizi müştəriyə yaxınlaşdırdı, indi biz onun bütün istəklərini tez yerinə yetirə bilərik. Nəticədə, ciddi qaydalara və tələblərə malik böyük bir əməliyyat şöbəmiz var və o, daim məhsulda qüsurlar tapır və çoxlu sorğular yaradır. Üstəlik, müştəri gözlənilmədən düyməni yaşıl əvəzinə sarı rəngə rəngləmək istəsə belə, bütün qüsurlara "təcili" status verilir. Layihə artır, buraxılışların sayı artır və buna uyğun olaraq müştərilər tərəfindən yeni funksionallıqda qüsurların və anlaşılmazlıqların sayı artır. Ops qüsurları bildirmək üçün daha 10 nəfəri, inkişaf isə onları bağlamaq üçün daha 15 nəfəri işə götürür. Və yeni funksiyalar təqdim etmək əvəzinə, komanda sonsuz SD-lərlə işləyir, funksionallığı istifadəçiyə izah edir və eyni zamanda dəstək verir. Nəticədə həm əməliyyatlar, həm də inkişaf işləyir, lakin müştəri və biznes bədbəxtdir: yeni funksiyalar ilişib qalır. Belə çıxır ki, DevOps mövcud görünür, lakin mövcud deyil.
DevOps-un tətbiqinin zəruriliyinə gəldikdə, Anton bunun birbaşa biznesin miqyasından asılı olduğunu açıq şəkildə bildirdi. İldə bir müştəriyə xidmət göstərmək şirkətə milyard gətirirsə, DevOps tələb olunmur (bir şərtlə ki, bu müştəriyə mütəmadi olaraq yeni dəyişikliklər etmək lazım deyil). Hər şey şokoladla örtülmüşdür. Ancaq biznes böyüyərsə və daha çox müştəri görünsə, o zaman riayət etməlisiniz. Bir qayda olaraq, şirkətdə əvvəlcə heç bir sərin əməliyyat yoxdur. Əvvəlcə məhsulu kəsdik və yalnız bundan sonra anlayırıq ki, məhsulun işləməsi üçün serverlərə diqqət yetirməli və təchizatlara nəzarət etməliyik. Bu zaman Ops yaranır. Ops-un ayrı bir bölmə olaraq inkişafa bir sıra maneələr qoymağa başlayacağını və bütün çatdırılmaların dayanmağa başlayacağını başa düşmək qalır. Yəni bu halda DevOps mədəniyyəti artıq aktualdır, lakin onun qaranlıq tərəfini də unutmaq olmaz.
Mənbə: www.habr.com