Bir şeyin vəziyyətini necə başa düşmək olar?
Müxtəlif məlumat mənbələrindən, məsələn, veb-saytlardakı nəşrlərdən və ya təcrübədən formalaşan fikrinizə etibar edə bilərsiniz. Həmkarlardan, tanışlardan soruşa bilərsiniz. Digər variant konfransların mövzularına baxmaqdır: proqram komitəsi sənayenin fəal nümayəndələridir, ona görə də müvafiq mövzuların seçilməsində onlara etibar edirik. Ayrı bir sahə tədqiqat və hesabatlardır. Amma bir problem var. Dünyada DevOps-un vəziyyəti ilə bağlı araşdırmalar hər il aparılır, xarici şirkətlər tərəfindən hesabatlar dərc olunur və Rusiyanın DevOps-u haqqında demək olar ki, heç bir məlumat yoxdur.
Ancaq belə bir araşdırmanın aparıldığı gün gəldi və bu gün nəticələr haqqında danışacağıq. Rusiyadakı DevOps-un vəziyyəti şirkətlər tərəfindən birgə öyrənildi ""Və"". Express 42 texnologiya şirkətlərinə DevOps təcrübələrini və alətlərini tətbiq etməyə və inkişaf etdirməyə kömək edir və Rusiyada DevOps haqqında ilk danışanlardan biri olmuşdur. Tədqiqatın müəllifləri İqor Kuroçkin və Vitali Xabarov “Express 42”də təhlil və konsaltinqlə məşğul olurlar, eyni zamanda müxtəlif şirkətlərdə əməliyyat və təcrübə ilə bağlı texniki biliklərə malikdirlər. 8 il ərzində həmkarlar müxtəlif problemləri, eləcə də müxtəlif mədəni və mühəndislik yetkinliyi olan onlarla şirkət və layihəyə - startaplardan tutmuş müəssisələrə qədər baxıblar.
İqor və Vitali öz hesabatlarında tədqiqat prosesində hansı problemlərin olduğunu, onları necə həll etdiklərini, həmçinin DevOps tədqiqatının prinsipcə necə aparıldığını və Express 42-nin niyə özünü aparmağa qərar verdiyini söylədi. Onların hesabatına baxmaq olar .
DevOps Araşdırması
Söhbət İqor Kuroçkin tərəfindən başladı.
Biz müntəzəm olaraq DevOps konfranslarında tamaşaçılardan soruşuruq: "Bu il üçün DevOps status hesabatını oxumusunuz?" Çox az adam əllərini qaldırdı və araşdırmamız göstərdi ki, yalnız üçüncüsü onları öyrənir. Əgər belə hesabatları heç vaxt görməmisinizsə, dərhal deyək ki, hamısı çox oxşardır. Çox vaxt belə ifadələr var: "Keçən illə müqayisədə ..."
Burada birinci problemimiz var, ondan sonra isə daha iki:
- Keçən il üçün məlumatımız yoxdur. Rusiyada DevOps-un vəziyyəti heç kimi maraqlandırmır;
- Metodologiya. Fərziyyələri necə yoxlamaq, sualları necə qurmaq, təhlil etmək, nəticələri müqayisə etmək, əlaqələri tapmaq aydın deyil;
- Terminologiya. Bütün hesabatlar ingilis dilindədir, tərcümə tələb olunur, ümumi DevOps çərçivəsi hələ icad olunmayıb və hər kəs öz hesabatını təqdim edir.
Gəlin bütün dünyada DevOps vəziyyəti təhlillərinin necə aparıldığına nəzər salaq.
Tarixi məlumat
DevOps tədqiqatı 2011-ci ildən aparılır. Konfiqurasiya idarəetmə sistemlərinin yaradıcısı olan Kukla onları ilk keçirdi. O dövrdə infrastrukturun kod şəklində təsviri üçün əsas vasitələrdən biri idi. 2013-cü ilə qədər bu tədqiqatlar sadəcə qapalı sorğular idi və ictimai hesabatlar yox idi.
2013-cü ildə DevOps ilə bağlı bütün əsas kitabların naşiri olan IT Revolution ortaya çıxdı. Puppet ilə birlikdə onlar ilk dəfə 4 əsas ölçünün göründüyü ilk State of DevOps nəşrini hazırladılar. Növbəti il, sənaye təcrübələri və alətləri üzrə müntəzəm texnologiya radarları ilə tanınan konsaltinq firması ThoughtWorks işə qoşuldu. Və 2015-ci ildə metodologiyası olan bir bölmə əlavə edildi və təhlili necə apardıqları aydın oldu.
2016-cı ildə tədqiqatın müəllifləri öz şirkətləri olan DORA (DevOps Research and Assessment) yaradaraq illik hesabat dərc ediblər. Növbəti il DORA və Puppet son birgə hesabatlarını yayımladılar.
Və sonra maraqlı bir şey başladı:
2018-ci ildə şirkətlər bölündü və iki müstəqil hesabat yayımlandı: biri Kukladan, ikincisi Google ilə birlikdə DORA-dan. DORA əsas ölçülərə və şirkət miqyasında fəaliyyətə təsir edən əsas ölçülər, performans profilləri və mühəndislik təcrübələri ilə öz metodologiyasından istifadə etməyə davam etmişdir. Və Kukla prosesin təsviri və DevOps-un təkamülü ilə öz yanaşmasını təklif etdi. Lakin hekayə kök salmadı, 2019-cu ildə Kukla bu metodologiyadan imtina etdi və hesabatların əsas təcrübələri və onların nöqteyi-nəzərindən DevOps-a necə təsir etdiyini sadalayan yeni versiyasını buraxdı. Sonra başqa bir hadisə baş verdi: Google DORA-nı satın aldı və birlikdə başqa bir hesabat yayımladılar. Ola bilsin ki, siz onu görmüsünüz.
Bu il işlər çətinləşdi. Kuklanın öz anketini başlatdığı bilinir. Bunu bizdən bir həftə tez etdilər və artıq bitdi. Biz orada iştirak etdik və onların hansı mövzularla maraqlandığına baxdıq. İndi Kukla analizini aparır və hesabatı dərc etməyə hazırlaşır.
Lakin hələ də DORA və Google-dan heç bir açıqlama yoxdur. Adətən sorğu başlayanda may ayında DORA-nın qurucularından biri olan Nikol Forsqrenin başqa şirkətə keçməsi barədə məlumat gəldi. Buna görə də bu il DORA-dan heç bir araşdırma və hesabat olmayacağını güman etdik.
Rusiyada işlər necədir?
Biz DevOps araşdırması etməmişik. Konfranslarda danışdıq, digər insanların tapıntılarını təkrarladıq və Raiffeisenbank 2019-cu il üçün "DevOps vəziyyəti" ni tərcümə etdi (onların elanını Habré-də tapa bilərsiniz), çox sağ olun. Və hamısı budur.
Buna görə də biz Rusiyada DORA metodologiyası və tapıntılarından istifadə edərək öz araşdırmamızı apardıq. Araşdırmamız üçün, o cümlədən terminologiya və tərcümənin sinxronlaşdırılması üçün Raiffeisenbank-dan olan həmkarlarımızın hesabatından istifadə etdik. Və sənaye ilə bağlı suallar DORA hesabatlarından və builki Kukla sorğusundan götürülüb.
Tədqiqat prosesi
Hesabat yalnız son hissədir. Bütün tədqiqat prosesi dörd əsas addımdan ibarətdir:
Hazırlıq mərhələsində biz sənaye ekspertlərindən müsahibə götürdük və fərziyyələrin siyahısını hazırladıq. Onların əsasında suallar tərtib edilib və bütün avqust ayı üçün sorğuya start verilib. Sonra hesabatın özünü təhlil edib hazırladıq. DORA üçün bu proses 6 ay çəkir. 3 ay ərzində görüşdük və indi başa düşürük ki, bizim kifayət qədər vaxtımız var: yalnız təhlil apararaq hansı sualları verməli olduğunuzu başa düşürsünüz.
Участники
Bütün xarici reportajlar iştirakçıların portreti ilə başlayır və əksəriyyəti Rusiyadan deyil. Rusiyalı respondentlərin faizi ildən-ilə 5-1% arasında dəyişir və bu, heç bir nəticə çıxarmağa imkan vermir.
Accelerate State of DevOps 2019 hesabatından xəritə:
Tədqiqatımızda biz 889 nəfərlə müsahibə apara bildik - bu, kifayət qədər çoxdur (DORA hesabatlarında hər il təxminən min insanı sorğulayır) və burada məqsədə nail olduq:
Düzdür, bütün iştirakçılarımız sona çatmadı: tamamlanma faizi yarıdan bir qədər az oldu. Amma hətta bu reprezentativ nümunə əldə etmək və analiz aparmaq üçün kifayət idi. DORA hesabatlarında doldurma faizlərini açıqlamır, buna görə də burada müqayisə yoxdur.
Sənayelər və vəzifələr
Respondentlərimiz onlarla sənayeni təmsil edir. Yarısı informasiya texnologiyalarında işləyir. Bunun ardınca maliyyə xidmətləri, ticarət, telekommunikasiya və s. Vəzifələr arasında mütəxəssislər (inkişafçı, sınaqçı, əməliyyat mühəndisi) və idarəetmə işçiləri (komandaların, qrupların, ərazilərin rəhbərləri, direktorlar) var:
Hər iki nəfərdən biri orta şirkətdə işləyir. Hər üçüncü şəxs böyük şirkətlərdə işləyir. Əksəriyyəti 9 nəfərə qədər komandalarda işləyir. Ayrı-ayrılıqda, əsas fəaliyyətlər haqqında soruşduq və əksəriyyəti bir şəkildə əməliyyatla bağlıdır və təxminən 40% inkişafla məşğuldur:
Beləliklə, biz müxtəlif sənayelərin, şirkətlərin, komandaların nümayəndələrinin müqayisəsi və təhlili üçün məlumat topladıq. Təhlil barədə həmkarım Vitali Xabarov məlumat verəcək.
Təhlil və müqayisə
Vitali Xabarov: Sorğumuzu tamamlayan, anketləri dolduran və fərziyyələrimizin sonrakı təhlili və sınaqdan keçirilməsi üçün bizə məlumat verən bütün iştirakçılara çox təşəkkür edirik. Müştərilərimiz və müştərilərimiz sayəsində sənaye narahatlıqlarını müəyyən etməyə və tədqiqatımızda sınaqdan keçirdiyimiz fərziyyələri formalaşdırmağa kömək edən zəngin təcrübəmiz var.
Təəssüf ki, bir tərəfdən sualların siyahısını, digər tərəfdən isə məlumatları götürə, birtəhər onları müqayisə edib: “Bəli, hər şey belə işləyir, biz haqlı idik” deyib dağılışmaq olmaz. Xeyr, səhv etmədiyimizə və qənaətimizin etibarlı olmasına əmin olmaq üçün metodologiya və statistik üsullara ehtiyac var. Sonra bu məlumatlar əsasında sonrakı işimizi qura bilərik:
Əsas Metriklər
"DevOps vəziyyətini sürətləndirmək" kitabında ətraflı təsvir etdikləri DORA metodologiyasını əsas götürdük. Əsas ölçülərin Rusiya bazarı üçün uyğun olub-olmadığını, DORA-nın "Rusiyada sənaye xarici sənayeyə necə uyğundur?" sualına cavab vermək üçün istifadə etdiyi kimi istifadə edilə biləcəyini yoxladıq.
Əsas ölçülər:
- Yerləşdirmə tezliyi. Tətbiqin yeni versiyası istehsal mühitinə nə qədər tez-tez yerləşdirilir (təmizləmələr və insidentlərə cavab istisna olmaqla, planlaşdırılan dəyişikliklər)?
- Çatdırılma vaxtı. Dəyişikliyin edilməsi (funksionallığın kod kimi yazılması) ilə dəyişikliyin istehsal mühitinə tətbiqi arasında orta vaxt nə qədərdir?
- Bərpa vaxtı. Hadisə, xidmətin deqradasiyası və ya proqram istifadəçilərinə təsir edən səhv aşkar edildikdən sonra tətbiqi istehsal mühitinə bərpa etmək orta hesabla nə qədər vaxt aparır?
- Uğursuz dəyişikliklər. İstehsal mühitində yerləşdirmələrin neçə faizi tətbiqin deqradasiyasına və ya insidentlərə gətirib çıxarır və düzəliş tələb edir (dəyişikliklərin geri qaytarılması, düzəliş və ya yamağın hazırlanması)?
DORA öz araşdırmasında bu göstəricilərlə təşkilati performans arasında əlaqə tapıb. Biz də bunu öz tədqiqatımızda sınaqdan keçiririk.
Ancaq dörd əsas göstəricinin nəyəsə təsir edə biləcəyinə əmin olmaq üçün başa düşməlisiniz - bunlar bir-biri ilə əlaqəlidirmi? DORA bir xəbərdarlıqla müsbət cavab verdi: uğursuz dəyişikliklər (Change Failure Rate) və digər üç göstərici arasındakı əlaqə bir qədər zəifdir. Təxminən eyni şəkli aldıq. Əgər çatdırılma vaxtı, yerləşdirmə tezliyi və bərpa vaxtı bir-biri ilə korrelyasiyaya malikdirsə (biz bu korrelyasiyanı Pearson korrelyasiyası və Chaddock şkalası vasitəsilə qurmuşuq), onda uğursuz dəyişikliklərlə belə güclü korrelyasiya yoxdur.
Prinsipcə, respondentlərin əksəriyyəti istehsalatda kifayət qədər az sayda insidentlər olduğunu cavablandırmağa meyllidirlər. Müvəffəqiyyətsiz dəyişikliklər baxımından respondent qrupları arasında hələ də əhəmiyyətli fərqin olduğunu sonra görəcəyik, lakin bu bölgü üçün hələlik bu metrikadan istifadə edə bilmərik.
Biz bunu onunla əlaqələndiririk ki, (təhlillər və bəzi müştərilərimizlə ünsiyyət zamanı məlum olub) insident sayılanların qavranılmasında cüzi fərq var. Əgər texniki pəncərə zamanı xidmətimizin fəaliyyətini bərpa edə bilsək, bunu insident saymaq olarmı? Yəqin ki, yox, çünki hər şeyi düzəltdik, əlayıq. Tətbiqimizi bizim üçün normal, tanış rejimdə 10 dəfə təkrarlamalı olsaq, bunu insident hesab edə bilərikmi? Deyəsən yox. Buna görə də, uğursuz dəyişikliklərin digər ölçülərlə əlaqəsi məsələsi açıq qalır. Biz onu daha da təkmilləşdirəcəyik.
Burada vacib olan odur ki, çatdırılma vaxtları, bərpa müddətləri və yerləşdirmə tezliyi arasında əhəmiyyətli korrelyasiya tapdıq. Buna görə də, respondentləri daha da performans qruplarına bölmək üçün bu üç göstəricini götürdük.
Qramda asmaq nə qədərdir?
İerarxik klaster analizindən istifadə etdik:
- Respondentləri n ölçülü fəzaya paylayırıq, burada hər bir respondentin koordinatı onların suallara cavablarıdır.
- Hər bir respondent kiçik klaster elan edilir.
- Bir-birinə ən yaxın olan iki klasteri daha böyük bir çoxluqda birləşdiririk.
- Növbəti klaster cütünü tapırıq və onları daha böyük klasterdə birləşdiririk.
Bütün respondentlərimizi ehtiyac duyduğumuz klasterlərin sayına görə qruplaşdırırıq. Dendroqramın (klasterlər arasındakı əlaqə ağacı) köməyi ilə biz iki qonşu klaster arasındakı məsafəni görürük. Bizə qalan bu çoxluqlar arasında müəyyən bir məsafə həddini təyin edib: “Bu iki qrup bir-birindən kifayət qədər fərqlənir, çünki aralarındakı məsafə nəhəngdir”.
Ancaq burada gizli bir problem var: klasterlərin sayına heç bir məhdudiyyətimiz yoxdur - biz 2, 3, 4, 10 klaster ala bilərik. Və ilk fikir bu idi - niyə bütün respondentlərimizi DORA kimi 4 qrupa bölməyək. Amma biz müəyyən etdik ki, bu qruplar arasında fərqlər əhəmiyyətsiz olur və biz əmin ola bilmərik ki, respondent həqiqətən qonşuya deyil, onun qrupuna aiddir. Biz hələ Rusiya bazarını dörd qrupa ayıra bilmərik. Buna görə də, statistik cəhətdən əhəmiyyətli fərq olan üç profil üzərində qərar verdik:
Sonra profili qruplar üzrə müəyyən etdik: hər qrup üçün hər bir metrik üçün medianı götürdük və performans profilləri cədvəlini tərtib etdik. Əslində, biz hər qrupdakı orta iştirakçının performans profillərini əldə etdik. Biz üç effektivlik profilini müəyyən etdik: Aşağı, Orta, Yüksək:
Burada biz fərziyyəmizi təsdiqlədik ki, 4 əsas göstərici performans profilini müəyyən etmək üçün uyğundur və onlar həm Qərb, həm də Rusiya bazarlarında işləyir. Qruplar arasında fərq var və statistik cəhətdən əhəmiyyətlidir. Mən vurğulayıram ki, ilkin olaraq respondentləri bu parametrə görə bölməsək də, orta göstərici baxımından uğursuz dəyişikliklərin metrikası baxımından performans profilləri arasında ciddi fərq var.
Sonra sual yaranır: bütün bunlardan necə istifadə etmək olar?
Necə istifadə
Hər hansı bir komanda, 4 əsas ölçü götürsək və onu cədvələ tətbiq etsək, 85% hallarda tam uyğunluq əldə etməyəcəyik - bu, sadəcə orta iştirakçıdır və reallıqda olan deyil. Hamımız (və hər komanda) bir az fərqliyik.
Yoxladıq: respondentlərimizi və DORA performans profilini götürdük və neçə respondentin bu və ya digər profilə uyğun olduğuna baxdıq. Respondentlərin yalnız 16%-nin mütləq profillərdən birinə düşdüyünü gördük. Qalanların hamısı ortada bir yerə səpələnmişdir:
Bu, səmərəlilik profilinin məhdud əhatə dairəsinə malik olması deməkdir. İlk yaxınlaşmada harada olduğunuzu başa düşmək üçün bu cədvəldən istifadə edə bilərsiniz: "Oh, görünür, biz Orta və ya Yüksək səviyyəyə daha yaxınıq!" Bundan sonra hara gedəcəyinizi başa düşsəniz, bu kifayət edə bilər. Ancaq məqsədiniz daimi, davamlı təkmilləşmədirsə və siz harada inkişaf edəcəyinizi və nə edəcəyinizi daha dəqiq bilmək istəyirsinizsə, əlavə vəsait lazımdır. Biz onları kalkulyator adlandırdıq:
- DORA kalkulyatoru
- Kalkulyator Express 42* (inkişaf mərhələsindədir)
- Öz inkişafı (öz daxili kalkulyatorunuzu yarada bilərsiniz).
Onlar nəyə lazımdır? Başa düşmək:
- Təşkilatımız daxilindəki komanda standartlarımıza uyğundurmu?
- Yoxdursa, şirkətimizin sahib olduğu təcrübə çərçivəsində ona kömək edə, sürətləndirə bilərikmi?
- Əgər belədirsə, daha yaxşısını edə bilərikmi?
Siz həmçinin şirkət daxilində statistika toplamaq üçün onlardan istifadə edə bilərsiniz:
- Hansı komandalarımız var?
- Komandaları profillərə bölmək;
- Baxın: Oh, bu əmrlər aşağı səviyyədədir (bir az dartılmır), lakin bunlar əladır: hər gün, səhvsiz yerləşdirirlər, bir saatdan az bir müddətə malikdirlər.
Və sonra öyrənə bilərsiniz ki, bizim şirkət daxilində hələ lazımi səviyyədə olmayan komandalar üçün lazımi təcrübə və alətlər var.
Yaxud şirkət daxilində özünüzü əla hiss etdiyinizi, çoxlarından yaxşı olduğunuzu başa düşsəniz, o zaman bir az daha geniş görünə bilərsiniz. Bu, sadəcə Rusiya sənayesidir: özümüzü sürətləndirmək üçün Rusiya sənayesində lazımi təcrübə əldə edə bilərikmi? Express 42 kalkulyatoru burada kömək edəcək (o, inkişaf mərhələsindədir). Əgər Rusiya bazarını üstələyibsinizsə, onda baxın və dünya bazarına.
Yaxşı. Əgər siz DORA kalkulyatorunda Elit qrupundasınızsa, nə etməlisiniz? Burada yaxşı bir həll yoxdur. Siz çox güman ki, sənayenin önündəsiniz və daha da sürətləndirmək və etibarlılıq daxili R&D və daha çox resurs xərcləməklə mümkündür.
Ən şirininə - müqayisəyə keçək.
Müqayisə
Biz əvvəlcə Rusiya sənayesini Qərb sənayesi ilə müqayisə etmək istəyirdik. Birbaşa müqayisə etsək, görərik ki, profillərimiz daha azdır və onlar bir-birinə bir az daha qarışıb, sərhədlər bir az daha bulanıqdır:
Elit ifaçılarımız Yüksək ifaçılar arasında gizlənirlər, lakin onlar oradadırlar - bunlar əhəmiyyətli zirvələrə çatmış elit, təkbuynuzlulardır. Rusiyada Elit profillə Yüksək profil arasındakı fərq hələ kifayət qədər əhəmiyyətli deyil. Düşünürük ki, gələcəkdə bu ayrılıq mühəndislik mədəniyyətinin artması, mühəndislik təcrübələrinin həyata keçirilməsinin keyfiyyəti və şirkətlər daxilində təcrübənin artması səbəbindən baş verəcək.
Rusiya sənayesi daxilində birbaşa müqayisəyə keçsək, yüksək profilli komandaların hər cəhətdən daha yaxşı olduğunu görə bilərik. Bu göstəricilərlə təşkilati performans arasında əlaqə olduğuna dair fərziyyəmizi də təsdiqlədik: Yüksək profilli komandaların nəinki məqsədlərə çatmaq, həm də onları aşmaq ehtimalı daha yüksəkdir.
Gəlin yüksək profilli komandalar olaq və bununla dayanmayaq:
Lakin bu il xüsusi ildir və biz şirkətlərin pandemiyada necə davrandığını yoxlamaq qərarına gəldik: Yüksək profilli komandalar daha yaxşı işləyir və özlərini sənaye ortalamasından daha yaxşı hiss edirlər:
- yeni məhsulların buraxılma ehtimalı 1,5-2 dəfə,
- Tətbiq infrastrukturunun etibarlılığını və/və ya performansını yaxşılaşdırmaq ehtimalı 2 dəfə çoxdur.
Yəni, onların artıq daha sürətli inkişaf etmələrinə, yeni məhsulların bazara çıxarılmasına, mövcud məhsulların dəyişdirilməsinə və bununla da yeni bazarlar və yeni istifadəçilərin fəth edilməsinə kömək etdikləri səlahiyyətlər:
Komandalarımıza başqa nə kömək etdi?
Mühəndislik təcrübələri
Test etdiyimiz hər bir təcrübə üçün əhəmiyyətli tapıntılar haqqında sizə məlumat verəcəyəm. Bəlkə də komandalara başqa bir şey kömək etdi, amma biz DevOps-dan danışırıq. Və DevOps daxilində biz müxtəlif profilli komandalar arasında fərq görürük.
Xidmət kimi platforma
Platforma yaşı ilə komanda profili arasında əhəmiyyətli bir əlaqə tapmadıq: Platformalar həm aşağı komandalar, həm də yüksək komandalar üçün təxminən eyni vaxtda meydana çıxdı. Lakin sonuncu üçün platforma proqram kodu vasitəsilə idarə etmək üçün orta hesabla daha çox xidmət və daha çox proqramlaşdırma interfeysi təqdim edir. Platforma komandaları isə öz tərtibatçılarına və komandalarına platformadan istifadə etməyə, problemlərini və platforma ilə bağlı insidentləri daha tez-tez həll etməyə və digər komandaları öyrətməyə daha çox kömək edirlər.
İnfrastruktur kod kimi
Burada hər şey olduqca standartdır. İnfrastruktur kodunun işinin avtomatlaşdırılması ilə infrastruktur anbarında nə qədər məlumatın saxlanması arasında əlaqə tapdıq. Yüksək profilli əmrlər depolarda daha çox məlumat saxlayır: bu, infrastruktur konfiqurasiyası, CI / CD boru kəməri, ətraf mühit parametrləri və qurma parametrləridir. Onlar bu məlumatları daha tez-tez saxlayır, infrastruktur kodu ilə daha yaxşı işləyir və infrastruktur kodu ilə işləmək üçün daha çox proses və tapşırıqları avtomatlaşdırır.
Maraqlıdır ki, biz infrastruktur testlərində ciddi fərq görmədik. Mən bunu yüksək profilli komandaların ümumilikdə daha çox sınaq avtomatlaşdırmasına malik olması ilə əlaqələndirirəm. Bəlkə də onları ayrı-ayrılıqda infrastruktur testləri ilə yayındırmaq lazım deyil, daha çox tətbiqləri yoxladıqları testlər və onların sayəsində nəyi və harada pozduqlarını artıq görürlər.
İnteqrasiya və Çatdırılma
Ən darıxdırıcı bölmə, çünki biz təsdiq etdik ki, nə qədər çox avtomatlaşdırmaya sahibsinizsə, kodla nə qədər yaxşı işləsəniz, daha yaxşı nəticələr əldə etmək ehtimalınız bir o qədər yüksəkdir.
memarlıq
Mikroservislərin performansa necə təsir etdiyini görmək istədik. Əslində, onlar etmirlər, çünki mikroxidmətlərdən istifadə performans göstəricilərinin artması ilə əlaqəli deyil. Mikroservislər həm yüksək profilli əmrlər, həm də aşağı profilli əmrlər üçün istifadə olunur.
Lakin əhəmiyyətli olan odur ki, Yüksək komandalar üçün mikroservis arxitekturasına keçid onlara öz xidmətlərini müstəqil şəkildə inkişaf etdirməyə və yaymağa imkan verir. Əgər arxitektura tərtibatçılara komandadan kənar kimisə gözləmədən avtonom hərəkət etməyə imkan verirsə, bu, sürəti artırmaq üçün əsas səriştədir. Bu halda mikroservislər kömək edir. Və sadəcə onların həyata keçirilməsi böyük rol oynamır.
Bütün bunları necə kəşf etdik?
DORA metodologiyasını tam şəkildə təkrarlamaq üçün iddialı planımız var idi, lakin resurslarımız çatışmırdı. Əgər DORA çoxlu sponsorluqdan istifadə edirsə və onların araşdırmaları yarım il çəkirsə, biz araşdırmalarımızı qısa müddətdə etdik. Biz DORA kimi bir DevOps modeli qurmaq istəyirdik və bunu gələcəkdə edəcəyik. İndiyə qədər biz istilik xəritələri ilə məhdudlaşdıq:
Biz hər bir profildəki komandalar arasında mühəndislik təcrübələrinin paylanmasına baxdıq və gördük ki, yüksək profilli komandalar orta hesabla mühəndislik təcrübələrindən daha çox istifadə edir. Bütün bunlar haqqında ətraflı oxuya bilərsiniz .
Dəyişiklik üçün mürəkkəb statistikadan sadə olanlara keçək.
Başqa nə kəşf etdik?
Tools
Müşahidə edirik ki, əmrlərin əksəriyyəti Linux ailəsinin ƏS-ləri tərəfindən istifadə olunur. Lakin Windows hələ də trenddədir - respondentlərimizin ən azı dörddə biri onun bu və ya digər versiyalarının istifadəsini qeyd edib. Görünür, bazarın bu ehtiyacı var. Ona görə də siz bu kompetensiyaları inkişaf etdirə və konfranslarda təqdimatlar edə bilərsiniz.
Orkestrlər arasında bu heç kimə sirr deyil, Kubernetes liderdir (52%). Növbəti sıradakı orkestr Docker Swarm-dır (təxminən 12%). Ən məşhur CI sistemləri Jenkins və GitLab-dır. Ən populyar konfiqurasiya idarəetmə sistemi Ansible-dir, onun ardınca sevimli Shell gəlir.
Amazon hazırda aparıcı bulud hostinq provayderidir. Rus buludlarının payı getdikcə artır. Gələn il Rusiya bulud provayderlərinin necə hiss edəcəyini, onların bazar payının artıb-artmayacağını görmək maraqlı olacaq. Onlar, istifadə edilə bilər və bu yaxşıdır:
Mən sözü İqora verirəm, o, daha çox statistika verəcək.
Təcrübələrin yayılması
İqor Kuroçkin: Ayrı-ayrılıqda, biz respondentlərdən nəzərdən keçirilən mühəndislik təcrübələrinin şirkətdə necə paylandığını göstərmələrini xahiş etdik. Əksər şirkətlərdə fərqli nümunələr toplusundan ibarət qarışıq yanaşma mövcuddur və pilot layihələr çox populyardır. Profillər arasında cüzi fərq də gördük. Yüksək profilin nümayəndələri kiçik mütəxəssis qrupları iş proseslərini, alətləri dəyişdirdikdə və digər komandalarla uğurlu təcrübələri bölüşdükdə “Aşağıdan Təşəbbüs” modelindən daha çox istifadə edirlər. Medium-da bu, icmaların və mükəmməllik mərkəzlərinin yaradılması vasitəsilə bütün şirkətə təsir edən yuxarıdan aşağıya doğru təşəbbüsdür:
Çevik və DevOps
Agile və DevOps arasındakı əlaqə məsələsi sənayedə tez-tez müzakirə olunur. Bu məsələ 2019/2020-ci illər üçün Çevik Vəziyyət Hesabatında da qaldırılıb, ona görə də Agile və DevOps fəaliyyətlərinin şirkətlərdə necə əlaqəli olduğunu müqayisə etmək qərarına gəldik. Çevik olmayan DevOps-un nadir olduğunu gördük. Respondentlərin yarısı üçün Agile-nin yayılması daha əvvəl başladı və təxminən 20% eyni vaxtda başlanğıcı müşahidə etdi və Aşağı profilin əlamətlərindən biri Agile və DevOps təcrübələrinin olmaması olacaq:
Komanda topologiyaları
Keçən ilin sonunda kitab "”, komanda topologiyalarını təsvir etmək üçün çərçivə təklif edir. Bunun Rusiya şirkətlərinə aid olub-olmaması bizim üçün maraqlı oldu. Və biz sual verdik: "Hansı nümunələri tapırsınız?".
Respondentlərin yarısında infrastruktur qrupları, eləcə də inkişaf, sınaq və istismar üçün ayrı-ayrı qruplar müşahidə olunur. Ayrı-ayrı DevOps komandaları 45% qeyd etdi, onların arasında High nümayəndələri daha çox yayılmışdır. Daha sonra High-da daha çox rast gəlinən çarpaz funksional komandalar gəlir. Ayrı-ayrı SRE əmrləri Yüksək, Orta profillərdə görünür və Aşağı profildə nadir hallarda görünür:
DevQaOps nisbəti
Biz bu sualı Facebook-da Skyeng platforma komandasının komanda rəhbərindən gördük - o, şirkətlərdə tərtibatçıların, testerlərin və idarəçilərin nisbəti ilə maraqlandı. Biz bunu soruşduq və profillərə əsaslanan cavablara baxdıq: Yüksək profilli nümayəndələrdə hər bir tərtibatçı üçün daha az test və əməliyyat mühəndisi var:
2021 il üçün planlar
Gələn il üçün planlarda respondentlər aşağıdakı fəaliyyətləri qeyd etdilər:
Burada DevOps Live 2020 konfransı ilə kəsişməni görə bilərsiniz. Biz proqramı diqqətlə nəzərdən keçirdik:
- İnfrastruktur məhsul kimi
- DevOps transformasiyası
- DevOps təcrübələrinin paylanması
- DevSecOps
- Keys klubları və müzakirələr
Amma təqdimatımızın vaxtı bütün mövzuları əhatə etməyə kifayət etmir. Pərdə arxasında qalanlar:
- Xidmət və məhsul kimi platforma;
- Kod, mühit və bulud kimi infrastruktur;
- Davamlı İnteqrasiya və Çatdırılma;
- Memarlıq;
- DevSecOps nümunələri;
- Platforma və çarpaz funksional komandalar.
həcmli, 50 səhifəlik bir kitabımız var və siz bunu daha ətraflı görə bilərsiniz.
Yekunlaşdıraraq
Ümid edirik ki, araşdırmamız və hesabatımız sizi inkişaf, sınaq və əməliyyatlara yeni yanaşmalar ilə sınaqdan keçirməyə ruhlandıracaq, həmçinin naviqasiya etməyə, özünüzü tədqiqatın digər iştirakçıları ilə müqayisə etməyə və öz yanaşmalarınızı təkmilləşdirə biləcəyiniz sahələri müəyyən etməyə kömək edəcək.
Rusiyada DevOps-un vəziyyəti ilə bağlı ilk araşdırmanın nəticələri:
- Əsas ölçülər. Biz aşkar etdik ki, əsas ölçülər (çatdırılma vaxtı, yerləşdirmə tezliyi, bərpa vaxtı və dəyişiklik uğursuzluqları) inkişaf, sınaq və əməliyyat proseslərinin effektivliyini təhlil etmək üçün uyğundur.
- Profillər Yüksək, Orta, Aşağı. Toplanmış məlumatlara əsaslanaraq, biz statistik olaraq yüksək, Orta, Aşağı qrupları ölçülər, təcrübələr, proseslər və alətlər baxımından fərqli xüsusiyyətlərə malik olaraq ayıra bilərik. Yüksək profilin nümayəndələri Aşağıdan daha yaxşı nəticələr göstərirlər. Məqsədlərinə çatmaq və aşmaq ehtimalı daha yüksəkdir.
- Göstəricilər, pandemiya və 2021-ci il üçün planlar. Bu ilin xüsusi göstəricisi şirkətlərin pandemiya ilə necə mübarizə aparmasıdır. Yüksək nümayəndələr daha yaxşı nəticə göstərdilər, istifadəçilərin artan əlaqəsini yaşadılar və müvəffəqiyyətin əsas səbəbləri səmərəli inkişaf prosesləri və güclü mühəndislik mədəniyyəti idi.
- DevOps təcrübələri, alətləri və onların inkişafı. Şirkətlərin növbəti il üçün əsas planlarına DevOps təcrübələrinin və alətlərinin inkişafı, DevSecOps təcrübələrinin tətbiqi və təşkilati strukturda dəyişikliklər daxildir. DevOps təcrübələrinin effektiv tətbiqi və inkişafı pilot layihələrin, icmaların və mükəmməllik mərkəzlərinin formalaşdırılması, şirkətin yuxarı və aşağı səviyyələrində təşəbbüslərin köməyi ilə həyata keçirilir.
Rəylərinizi, hekayələrinizi və rəylərinizi eşitmək istərdik. Tədqiqatda iştirak edən hər kəsə təşəkkür edirik və gələn il iştirakınızı gözləyirik.
Mənbə: www.habr.com