Düzünü desəm, İvan monitorinq departamentindən olan həmkarlarının əbəs cəhdlərinə tez-tez gülürdü. Onlar şirkət rəhbərliyinin onlara nail olmağı əmr etdiyi ölçüləri həyata keçirmək üçün çox səy göstərdilər. O qədər məşğul idilər ki, başqasının heç nə etməsini istəmirdilər.
Ancaq rəhbərlik üçün bu kifayət etmədi - onlar daima daha çox yeni ölçülər sifariş etdilər, çox tez əvvəllər edilənlərdən istifadə etməyi dayandırdılar.
Son vaxtlar hamı LeadTime - biznes xüsusiyyətlərinin çatdırılması vaxtı haqqında danışır. Metrik çılğın bir rəqəm göstərdi - bir tapşırığı çatdırmaq üçün 200 gün. Hamı necə də oohed və aahed və əllərini göyə qaldırdı!
Bir müddət sonra səs-küy tədricən azaldı və rəhbərlik başqa bir metrik yaratmaq əmri aldı.
İvana tamamilə aydın idi ki, yeni metrik qaranlıq bir küncdə sakitcə öləcək.
Doğrudan da, İvan düşündü, nömrəni bilmək heç kimə heç nə demir. 200 gün və ya 2 gün - heç bir fərq yoxdur, çünki rəqəmlə səbəbi müəyyən etmək və yaxşı və ya pis olduğunu başa düşmək mümkün deyil.
Bu, tipik bir ölçü tələsidir: görünür, yeni bir metrik varlığın mahiyyətini izah edəcək və hansısa gizli sirri izah edəcək. Hamı buna çox ümid edir, amma nədənsə heç nə olmur. Bəli, çünki sirri metriklərdə tapmaq olmaz!
İvan üçün bu, keçmiş mərhələ idi. Bunu başa düşdü ölçmələr üçün və bütün sirləri axtarmaq lazımdır , yəni. bu metrikanın formalaşmasıdır.
Onlayn mağaza üçün təsir obyekti pul gətirən müştəriləri, DevOps üçün isə boru kəmərindən istifadə edərək paylamalar yaradan və yayan komandalar olacaq.
Bir gün salonda rahat kresloda oturan İvan, təsir obyektinin komandalar olduğunu nəzərə alaraq DevOps ölçülərini necə görmək istədiyini diqqətlə düşünmək qərarına gəldi.
DevOps Metriklərinin Məqsədi
Aydındır ki, hər kəs çatdırılma müddətini azaltmaq istəyir. 200 gün, əlbəttə ki, yaxşı deyil.
Bəs necə, sual budur?
Şirkətdə yüzlərlə komanda çalışır və hər gün minlərlə paylama DevOps boru kəmərindən keçir. Faktiki çatdırılma vaxtı paylama kimi görünəcək. Hər komandanın öz vaxtı və öz xüsusiyyətləri olacaq. Bu qarışıqlığın arasında necə bir şey tapa bilərsiniz?
Cavab təbii olaraq ortaya çıxdı - problemli komandaları tapmalı və onlarla nə baş verdiyini və bunun niyə bu qədər uzun sürdüyünü anlamalı və "yaxşı" komandalardan hər şeyi tez necə edəcəyini öyrənməliyik. Bunu etmək üçün siz DevOps stendlərinin hər birində komandaların keçirdikləri vaxtı ölçməlisiniz:
“Sistemin məqsədi komandaları tribunalardan keçdikləri vaxta əsasən seçmək olacaq, yəni. Nəticədə, biz bir nömrə deyil, seçilmiş vaxtla əmrlərin siyahısını almalıyıq.
Ümumilikdə stenddə nə qədər vaxt sərf edildiyini və tribunalar arasında fasilələrə nə qədər vaxt sərf edildiyini öyrənsək, komandaları tapıb, onlara zəng edib səbəbləri daha ətraflı anlayıb aradan qaldıra bilərik”, - deyə İvan düşündü.
DevOps üçün çatdırılma müddətini necə hesablamaq olar
Onu hesablamaq üçün DevOps prosesini və onun mahiyyətini araşdırmaq lazım idi.
Şirkət məhdud sayda sistemlərdən istifadə edir və məlumat yalnız onlardan əldə edilə bilər və başqa heç bir yerdən.
Şirkətdəki bütün vəzifələr Jira-da qeydə alınıb. Tapşırıq qəbul edildikdə, onun üçün bir filial yaradıldı və həyata keçirildikdən sonra BitBucket və Pull Request üçün öhdəlik götürüldü. PR (Pull Request) qəbul edildikdə, paylama avtomatik olaraq yaradıldı və Nexus deposunda saxlanıldı.
Sonra, paylama, avtomatik və əl ilə sınaqların düzgünlüyünü yoxlamaq üçün Jenkins-dən istifadə edərək bir neçə stenddə yayıldı:
İvan stendlərdə vaxtı hesablamaq üçün hansı sistemlərdən hansı məlumatların götürülə biləcəyini təsvir etdi:
- Nexus-dan – Dağıtım yaratma vaxtı və komanda kodunu ehtiva edən qovluğun adı
- Jenkins-dən – Hər bir işin başlama vaxtı, müddəti və nəticəsi, stend adı (iş parametrlərində), mərhələlər (iş addımları), Nexus-da paylanmaya keçid.
- İvan Jira və BitBucket-i boru kəmərinə daxil etməmək qərarına gəldi, çünki... onlar hazır paylamanın stendlərdə yayılması ilə deyil, daha çox inkişaf mərhələsi ilə əlaqəli idi.
Mövcud məlumatlara əsasən aşağıdakı diaqram tərtib edilmişdir:
Dağıtımların yaradılmasına nə qədər vaxt lazım olduğunu və onların hər birinə nə qədər vaxt sərf olunduğunu bilməklə, siz bütün DevOps boru kəmərindən (tam dövr) keçməyin ümumi xərclərini asanlıqla hesablaya bilərsiniz.
İvanın əldə etdiyi DevOps göstəriciləri bunlardır:
- Yaradılan paylamaların sayı
- Stendə “gələn” və stenddən “keçmiş” paylanma payı
- Stenddə sərf olunan vaxt (stend dövrü)
- Tam dövr (bütün stendlər üçün ümumi vaxt)
- İş müddəti
- Tribunalar arasında fasilə
- Eyni stenddə işə başlayanlar arasındakı fasilə
Bir tərəfdən, ölçülər DevOps boru kəmərini vaxt baxımından çox yaxşı xarakterizə etdi, digər tərəfdən çox sadə hesab edildi.
Görülmüş işdən razı qalan İvan təqdimat etdi və rəhbərlikə təqdim etməyə getdi.
O, tutqun və əlləri aşağı geri qayıtdı.
"Bu, fiaskodur, qardaş" deyə istehzalı həmkarı gülümsədi...
Daha çox məqalədə oxuyun ".
Mənbə: www.habr.com