Məlumdur ki, CTO-nun səriştəsi yalnız ikinci dəfə bu vəzifəni yerinə yetirəndə yoxlanılır. Çünki bir şirkətdə bir neçə il işləmək, onunla birlikdə təkamül etmək və eyni mədəni kontekstdə olmaqla, tədricən daha çox məsuliyyət daşımaq bir şeydir. Və köhnə baqajı və xalçanın altına səliqəli şəkildə süpürülən bir çox problemi olan bir şirkətdə birbaşa texniki direktor vəzifəsinə gəlmək tamamilə başqa bir şeydir.

Bu mənada onun paylaşdığı Leon Fire təcrübəsi DevOpsConf, tam unikal deyil, lakin təcrübəsinə və 20 il ərzində sınamağa müvəffəq olduğu müxtəlif rolların sayına görə çox faydalıdır. Kesimin altında 90 gün ərzində baş verən hadisələrin xronologiyası və başqasının başına gələndə gülmək əyləncəli, lakin şəxsən qarşılaşmaq o qədər də əyləncəli olmayan bir çox hekayə var.

Leon rus dilində çox rəngarəng danışır, ona görə də 35-40 dəqiqə vaxtınız varsa, videoya baxmağı məsləhət görürəm. Aşağıdakı vaxta qənaət etmək üçün mətn versiyası.

Hesabatın ilk variantı faydalı tövsiyələri özündə əks etdirən insanlar və proseslərlə işin yaxşı strukturlaşdırılmış təsviri idi. Lakin o, yol boyu qarşılaşdığı bütün sürprizləri çatdırmadı. Ona görə də formatı dəyişdim və yeni şirkətdə bir jack-in-thebox kimi qarşıma çıxan problemləri və onların həlli üsullarını xronoloji ardıcıllıqla təqdim etdim.

Bir ay əvvəl

Bir çox yaxşı hekayələr kimi, bu da spirtlə başladı. Dostlarla barda oturmuşduq və İT mütəxəssisləri arasında gözlənildiyi kimi, hamı öz problemləri üçün ağlayırdı. Onlardan biri iş yerini təzəcə dəyişmişdi və texnologiya, insanlar və komanda ilə bağlı problemlərindən danışırdı. Daha çox dinlədikcə daha çox başa düşdüm ki, o, sadəcə məni işə götürməlidir, çünki bu, mənim son 15 ildə həll etdiyim problemlərdir. Bunu ona dedim və ertəsi gün iş mühitində görüşdük. Şirkət Teaching Strategies adlanırdı.

Teaching Strategies, doğuşdan üç yaşa qədər çox gənc uşaqlar üçün kurrikulumda bazar lideridir. Ənənəvi “kağız” şirkətinin artıq 40, platformanın rəqəmsal SaaS versiyasının isə 10 yaşı var.Nisbətən bu yaxınlarda rəqəmsal texnologiyanın şirkət standartlarına uyğunlaşdırılması prosesi başlayıb. "Yeni" versiya 2017-ci ildə istifadəyə verildi və demək olar ki, köhnə versiyaya bənzəyirdi, yalnız daha pis işləyirdi.

Ən maraqlısı odur ki, bu şirkətin trafiki çox proqnozlaşdırıla biləndir - gündən-günə, ildən-ilə neçə adamın nə vaxt gələcəyini çox aydın şəkildə proqnozlaşdırmaq olar. Məsələn, saat 13:15-XNUMX:XNUMX arasında uşaq bağçalarında bütün uşaqlar yatmağa gedir və müəllimlər məlumat daxil etməyə başlayırlar. Və bu, həftə sonları istisna olmaqla, hər gün olur, çünki həftə sonları demək olar ki, heç kim işləmir.

Bir az irəliyə baxaraq qeyd edim ki, mən işimə müxtəlif səbəblərdən maraqlı olan ən yüksək illik trafik dövründə başlamışam.

Cəmi 2 yaşı olan platformanın özünəməxsus yığını var idi: 2008-ci ildən ColdFusion & SQL Server. ColdFusion, əgər bilmirsinizsə və çox güman ki, bilmirsinizsə, 90-cı illərin ortalarında çıxan müəssisə PHP-dir və o vaxtdan bəri mən bu barədə eşitməmişəm. Həmçinin bunlar var idi: Ruby, MySQL, PostgreSQL, Java, Go, Python. Lakin əsas monolit ColdFusion və SQL Server üzərində işləyirdi.

Problemləri

Şirkət işçiləri ilə iş və hansı problemlərlə rastlaşdıqca danışdıqca, problemlərin təkcə texniki xarakter daşımadığını anladım. Yaxşı, texnologiya köhnədir - və onlar üzərində işləmədilər, lakin komandada və proseslərdə problemlər var idi və şirkət bunu anlamağa başladı.

Ənənəvi olaraq, onların texniki işçiləri küncdə oturub bir növ iş görürdülər. Lakin getdikcə daha çox iş rəqəmsal versiyadan keçməyə başladı. Buna görə də, işə başlamazdan əvvəl keçən il şirkətdə yeniləri meydana çıxdı: direktorlar şurası, CTO, CPO və QA direktoru. Yəni şirkət texnologiya sektoruna sərmayə qoymağa başladı.

Ağır bir mirasın izləri təkcə sistemlərdə deyildi. Şirkətin miras prosesləri, miras qalmış insanları, miras mədəniyyəti var idi. Bütün bunlar dəyişdirilməli idi. Mən bunun darıxdırıcı olmayacağını düşündüm və sınamağa qərar verdim.

İki gün əvvəl

Yeni işə başlamazdan iki gün əvvəl ofisə gəldim, son sənədləri doldurdum, komanda ilə görüşdüm və komandanın həmin vaxt problemlə mübarizə apardığını aşkar etdim. Orta hesabla səhifə yükləmə müddəti 4 saniyəyə, yəni 2 dəfə artdı.

Qrafikə görə, bir şey aydın oldu və nə olduğu aydın deyil. Məlum olub ki, problem data mərkəzində şəbəkə gecikməsidir: data mərkəzində 5 ms gecikmə istifadəçilər üçün 2 saniyəyə çevrilib. Bunun niyə baş verdiyini bilmirdim, amma hər halda problemin məlumat mərkəzində olduğu məlum oldu.

İlk gün

İki gün keçdi və ilk iş günümdə problemin aradan qalxmadığını gördüm.

İki gün ərzində istifadəçilərin səhifələri orta hesabla 4 saniyəyə yüklənir. Problemin nə olduğunu tapıb tapmadıqlarını soruşuram.

- Bəli, bilet açdıq.
- VƏ?
- Yaxşı, hələ bizə cavab verməyiblər.

Sonra başa düşdüm ki, əvvəllər mənə deyilənlərin hamısı döyüşməli olduğum aysberqin kiçik bir hissəsidir.

Buna çox uyğun gələn yaxşı bir sitat var:

"Bəzən texnologiyanı dəyişdirmək üçün təşkilatı dəyişməlisən."

Amma ilin ən gərgin vaxtında işə başladığım üçün problemin həlli üçün hər iki varianta baxmalı oldum: həm tez, həm də uzunmüddətli. Və indi kritik olandan başlayın.

Üçüncü gün

Beləliklə, yükləmə 4 saniyə davam edir və 13-dən 15-ə qədər ən böyük zirvələr.

Bu müddət ərzində üçüncü gündə yükləmə sürəti belə görünürdü:

Mənim nöqteyi-nəzərimdən heç nə alınmadı. Hər kəsin nöqteyi-nəzərindən o, həmişəkindən bir qədər yavaş işləyirdi. Ancaq bu, sadəcə olaraq baş vermir - bu, ciddi bir problemdir.

Komandanı inandırmağa çalışdım, onlar cavab verdilər ki, sadəcə olaraq daha çox server lazımdır. Bu, əlbəttə ki, problemin həllidir, lakin həmişə yeganə və ən təsirli deyil. Soruşdum ki, niyə serverlər azdır, trafikin həcmi nə qədərdir. Mən məlumatları ekstrapolyasiya etdim və tapdım ki, saniyədə təxminən 150 sorğumuz var ki, bu da prinsipcə ağlabatan hədlərə düşür.

Ancaq unutmamalıyıq ki, düzgün cavab almadan əvvəl düzgün sual vermək lazımdır. Növbəti sualım bu idi: neçə frontend serverimiz var? Cavab "məni bir az çaşdırdı" - 17 frontend serverimiz var idi!

— Soruşmağa utanıram, amma 150-nin 17-yə bölünməsi təxminən 8 verir? Deyirsiniz ki, hər server saniyədə 8 sorğuya icazə verir və sabah saniyədə 160 sorğu olarsa, bizə daha 2 server lazım olacaq?

Təbii ki, əlavə serverlərə ehtiyacımız yox idi. Həll kodun özündə və səthində idi:

var currentClass = classes.getCurrentClass();
return currentClass;

Funksiya var idi getCurrentClass(), çünki saytda hər şey bir sinif kontekstində işləyir - bu doğrudur. Bunun üçün hər səhifədə bir funksiya var idi 200+ sorğu.

Bu şəkildə həll yolu çox sadə idi, heç bir şeyi yenidən yazmağa belə ehtiyac yox idi: sadəcə eyni məlumatı yenidən istəməyin.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Mən çox sevindim, çünki qərara gəldim ki, yalnız üçüncü gün əsas problemi tapmışam. Nə qədər sadəlövh olsam da, bu bir çox problemdən yalnız biri idi.

Lakin bu ilk problemin həlli qrafiki xeyli aşağı saldı.

Eyni zamanda, başqa optimallaşdırmalar da edirdik. Görünəndə düzəldilə bilən çox şey var idi. Məsələn, eyni üçüncü gündə sistemdə bir önbellek olduğunu aşkar etdim (əvvəlcə bütün sorğuların birbaşa verilənlər bazasından gəldiyini düşündüm). Keş haqqında düşünəndə standart Redis və ya Memcached haqqında düşünürəm. Ancaq belə düşünən tək mən idim, çünki bu sistem keşləmə üçün MongoDB və SQL Serverdən istifadə edirdi - verilənlərin indicə oxunduğu eyni.

Onuncu gün

İlk həftə indi həll edilməli olan problemlərlə məşğul oldum. İkinci həftədə haradasa komanda ilə ünsiyyət qurmaq, nə baş verdiyini və bütün prosesin necə getdiyini görmək üçün ilk dəfə stand-upa gəldim.

Yenidən maraqlı bir şey aşkar edildi. Komanda aşağıdakılardan ibarət idi: 18 tərtibatçı; 8 test cihazı; 3 menecer; 2 memar. Və onların hamısı ümumi rituallarda iştirak edirdilər, yəni hər səhər 30-dan çox insan stendə gəlib nə etdiklərini danışırdı. Görüşün 5 və ya 15 dəqiqə çəkmədiyi aydındır. Hər kəs fərqli sistemlərdə işlədiyi üçün heç kim heç kimə qulaq asmadı. Bu formada baxım seansı üçün saatda 2-3 bilet artıq yaxşı nəticə idi.

Etdiyimiz ilk şey komandanı bir neçə məhsul xəttinə bölmək oldu. Fərqli bölmələr və sistemlər üçün tərtibatçılar, sınaqçılar, məhsul menecerləri və biznes analitiklərindən ibarət ayrıca komandalar ayırdıq.

Nəticədə əldə etdik:

• Ayağa qalxma və mitinqlərin azaldılması.
• Məhsul haqqında mövzu bilikləri.
• Sahibkarlıq hissi. İnsanlar hər zaman sistemlərlə məşğul olanda bilirdilər ki, çox güman ki, başqası onların səhvləri ilə işləməli olacaq, lakin özləri deyil.
• Qruplar arasında əməkdaşlıq. Söz yox ki, QA əvvəllər proqramçılarla çox ünsiyyət qurmurdu, məhsul öz işini görürdü və s. İndi onların ortaq məsuliyyət nöqtəsi var.

Biz əsas diqqəti səmərəlilik, məhsuldarlıq və keyfiyyətə yönəltmişik - bunlar komandanın transformasiyası ilə həll etməyə çalışdığımız problemlərdir.

On birinci gün

Komandanın strukturunu dəyişmək prosesində saymağı kəşf etdim HekayəPoints. 1 SP bir günə bərabər idi və hər biletdə həm inkişaf, həm də QA üçün SP, yəni ən azı 2 SP var idi.

Bunu necə kəşf etdim?

Bir səhv tapdıq: hesabatın lazım olduğu dövrün başlanğıc və bitmə tarixinin daxil edildiyi hesabatların birində son gün nəzərə alınmır. Yəni sorğunun bir yerində <= yox, sadəcə olaraq < var idi. Mənə dedilər ki, bu, üç hekayə nöqtəsidir, yəni 3 gün.

Bundan sonra biz:

• Story Points reytinq sisteminə yenidən baxıldı. İndi sistemdən tez keçə bilən kiçik səhvlər üçün düzəlişlər istifadəçiyə daha tez çatır.
• Biz inkişaf və sınaq üçün əlaqəli biletləri birləşdirməyə başladıq. Əvvəllər hər bilet, hər səhv qapalı ekosistem idi, başqa heç nə ilə bağlı deyildi. Bir səhifədə üç düymənin dəyişdirilməsi hər səhifədə bir avtomatlaşdırılmış test əvəzinə üç fərqli QA prosesi ilə üç fərqli bilet ola bilərdi.
• Biz əmək xərclərinin hesablanmasına yanaşma üzərində tərtibatçılarla işləməyə başladıq. Üç gün bir düyməni dəyişdirmək gülməli deyil.

İyirminci gün

Birinci ayın ortalarında bir yerdə vəziyyət bir az sabitləşdi, mən əsasən nə baş verdiyini anladım və artıq gələcəyə baxmağa və uzunmüddətli həll yolları haqqında düşünməyə başladım.

Uzunmüddətli hədəflər:

• İdarə olunan platforma. Hər səhifədə yüzlərlə müraciət ciddi deyil.
• Proqnozlaşdırıla bilən tendensiyalar. İlk baxışdan digər ölçülərlə əlaqəli olmayan dövri trafik pikləri var idi - bunun niyə baş verdiyini anlamaq və proqnozlaşdırmağı öyrənmək lazım idi.
• Platformanın genişləndirilməsi. Biznes daim böyüyür, getdikcə daha çox istifadəçi gəlir və trafik artır.

Keçmişdə tez-tez deyilirdi: "Hər şeyi [dildə/çərçivədə] yenidən yazaq, hər şey daha yaxşı işləyəcək!"

Əksər hallarda bu işləmir, yenidən yazma ümumiyyətlə işləsə yaxşıdır. Buna görə də, biz bir yol xəritəsi yaratmalı olduq - biznes məqsədlərinə necə nail olunacağını (nə edəcəyimizi və niyə) addım-addım təsvir edən xüsusi strategiya:

• layihənin missiyasını və məqsədlərini əks etdirir;
• əsas məqsədləri prioritetləşdirir;
• onlara nail olmaq üçün cədvəli ehtiva edir.

Bundan əvvəl heç kim komanda ilə hansısa dəyişikliyin məqsədi barədə danışmamışdı. Bu, düzgün uğur göstəricilərini tələb edir. Şirkət tarixində ilk dəfə olaraq texniki qrup üçün KPI-ları təyin etdik və bu göstəricilər təşkilati göstəricilərlə əlaqələndirildi.

Yəni təşkilati KPI-lar komandalar tərəfindən, komanda KPI-ləri isə fərdi KPI-lar tərəfindən dəstəklənir. Əks təqdirdə, texnoloji KPI-lər təşkilati olanlarla üst-üstə düşmürsə, hər kəs yorğanı öz üzərinə çəkir.

Məsələn, təşkilati KPI-lərdən biri yeni məhsullar vasitəsilə bazar payını artırmaqdır.

Daha çox yeni məhsul əldə etmək məqsədini necə dəstəkləyə bilərsiniz?

• Birincisi, biz qüsurları düzəltmək əvəzinə yeni məhsulların hazırlanmasına daha çox vaxt sərf etmək istəyirik. Bu, ölçmək asan olan məntiqi bir həlldir.
• İkincisi, biz tranzaksiya həcminin artmasına dəstək olmaq istəyirik, çünki bazar payı nə qədər çox olarsa, bir o qədər çox istifadəçi və müvafiq olaraq daha çox trafik.

Sonra qrup daxilində icra edilə bilən fərdi KPI-lər, məsələn, əsas qüsurların gəldiyi yerdə olacaqdır. Xüsusilə bu bölməyə diqqət yetirsəniz, qüsurların daha az olduğuna əmin ola bilərsiniz və sonra yeni məhsulların hazırlanması və yenidən təşkilati KPI-ləri dəstəkləmək üçün vaxt artacaq.

Beləliklə, hər bir qərar, o cümlədən kodun yenidən yazılması, şirkətin bizim qarşımıza qoyduğu xüsusi məqsədləri (təşkilati artım, yeni funksiyalar, işə qəbul) dəstəkləməlidir.

Bu proses zamanı maraqlı bir şey üzə çıxdı və bu, təkcə texniki mütəxəssislər üçün deyil, ümumilikdə şirkət üçün xəbər oldu: bütün biletlər ən azı bir KPI-yə yönəldilməlidir. Yəni, bir məhsul yeni bir xüsusiyyət yaratmaq istədiyini söyləyirsə, ilk sual verilməlidir: "Bu xüsusiyyət hansı KPI-ni dəstəkləyir?" Yoxdursa, bağışlayın - bu, lazımsız bir xüsusiyyət kimi görünür.

Otuz gün

Ayın sonunda başqa bir nüans kəşf etdim: Əməliyyat komandamdakı heç kim müştərilərlə bağladığımız müqavilələri görməmişdir. Əlaqələrə niyə baxmaq lazım olduğunu soruşa bilərsiniz.

• Birincisi, ona görə ki, SLA-lar müqavilələrdə göstərilib.
• İkincisi, SLA-ların hamısı fərqlidir. Hər müştəri öz tələbləri ilə gəldi və satış şöbəsi baxmadan imza atdı.

Daha bir maraqlı nüans ondan ibarətdir ki, ən böyük müştərilərdən biri ilə müqavilədə qeyd olunur ki, platforma tərəfindən dəstəklənən bütün proqram təminatı versiyaları n-1 olmalıdır, yəni son versiya deyil, sondan əvvəlki versiya.

Platforma ColdFusion və iyul ayında ümumiyyətlə dəstəklənməyən SQL Server 1 əsasında olsaydı, n-2008-dən nə qədər uzaq olduğumuz aydındır.

Qırx beşinci gün

İkinci ayın ortalarında oturub məşğul olmaq üçün kifayət qədər vaxtım oldu dəyəraxınXəritəçəkmə bütün proses üçün tamamilə. Bunlar məhsulun yaradılmasından istehlakçıya çatdırılmasına qədər atılması lazım olan zəruri addımlardır və mümkün qədər ətraflı təsvir edilməlidir.

Siz prosesi kiçik parçalara ayırırsınız və nəyin çox vaxt apardığını, nəyin optimallaşdırıla biləcəyini, təkmilləşdirilə biləcəyini və s. Məsələn, məhsul sorğusunun baxımdan keçməsi nə qədər vaxt aparır, o, tərtibatçının ala biləcəyi biletə nə vaxt çatır, QA və s. Beləliklə, hər bir fərdi addıma ətraflı baxırsınız və nəyin optimallaşdırıla biləcəyini düşünürsünüz.

Bunu edəndə iki şey diqqətimi çəkdi:

• QA-dan tərtibatçılara qaytarılan biletlərin yüksək faizi;
• çəkmə sorğusunun nəzərdən keçirilməsi çox uzun çəkdi.

Problem onda idi ki, bunlar belə nəticələr idi: Görünür, çox vaxt aparacaq, amma nə qədər vaxt aparacağına əmin deyilik.

"Ölçmədiyiniz şeyi təkmilləşdirə bilməzsiniz."

Problemin nə qədər ciddi olduğunu necə əsaslandırmaq olar? Günlər və ya saatlar sərf edirmi?

Bunu ölçmək üçün biz Jira prosesinə bir neçə addım əlavə etdik: hər bir biletin nə qədər gözlədiyini və neçə dəfə müəyyən addıma qayıtdığını ölçmək üçün “development üçün hazır” və “QA üçün hazır”.

Nəzərdən keçirilməsi üçün orta hesabla neçə bilet olduğunu bilmək üçün "nəzərdə" də əlavə etdik və siz rəqs etməyə başlaya bilərsiniz. Sistem ölçülərimiz var idi, indi yeni ölçülər əlavə etdik və ölçməyə başladıq:

• Prosesin səmərəliliyi: performans və planlaşdırılmış/təslim edilmişdir.
• Prosesin keyfiyyəti: qüsurların sayı, QA-dan qüsurlar.

Bu, həqiqətən nəyin yaxşı getdiyini və nəyin yaxşı getmədiyini anlamağa kömək edir.

Əllinci gün

Bütün bunlar, əlbəttə ki, yaxşı və maraqlıdır, amma ikinci ayın sonuna yaxın belə bir miqyas gözləmirdimsə də, prinsipcə, proqnozlaşdırıla bilən bir şey oldu. İnsanlar yuxarı rəhbərliyi dəyişdiyi üçün getməyə başladılar. Rəhbərliyə yeni insanlar gəldi və hər şeyi dəyişməyə başladılar, köhnələr isə işdən çıxdılar. Və adətən bir neçə illik bir şirkətdə hamı dostdur və hamı bir-birini tanıyır.

Bu gözlənilən idi, lakin ixtisarların miqyası gözlənilməz oldu. Məsələn, bir həftə ərzində iki komanda lideri eyni vaxtda öz istəkləri ilə istefa ərizələrini təqdim etdi. Ona görə də mən nəinki digər problemləri unutmalı, həm də diqqətimi üzərinə cəmləməli oldum komanda yaratmaq. Bu, həlli uzun və çətin bir problemdir, lakin mən qalan insanları (və ya onların əksəriyyətini) xilas etmək istədim, çünki həll edilməli idi. Komandada əhval-ruhiyyəni qorumaq üçün insanların getməsinə birtəhər reaksiya vermək lazımdı.

Teorik olaraq, bu yaxşıdır: tam kart-blanşa malik, komandanın bacarıqlarını qiymətləndirə və kadrları əvəz edə bilən yeni bir şəxs gəlir. Əslində, bir çox səbəbə görə yeni insanları cəlb edə bilməzsiniz. Balans həmişə lazımdır.

• Köhnə və yeni. Biz missiyanı dəyişə bilən və dəstəkləyən yaşlı insanları saxlamalıyıq. Ancaq eyni zamanda, yeni qan gətirməliyik, bu barədə bir az sonra danışacağıq.
• Təcrübə. Mən həvəsli və bizimlə işləmək istəyən yaxşı gənclərlə çox danışdım. Ancaq mən onları götürə bilmədim, çünki yeniyetmələrə dəstək olmaq və onlara mentorluq etmək üçün kifayət qədər yaşlılar yox idi. Əvvəlcə yuxarıları, sonra isə gəncləri işə götürmək lazım idi.
• Kök və çubuq.

Düzgün balans nədir, onu necə saxlamaq, neçə adam saxlamaq və nə qədər itələmək kimi suallara yaxşı cavabım yoxdur. Bu sırf fərdi prosesdir.

Əlli birinci gün

Kim olduğumu başa düşmək üçün komandaya diqqətlə baxmağa başladım və bir daha xatırladım:

“Problemlərin çoxu insanların problemləridir”.

Mən başa düşdüm ki, komandanın - həm Dev, həm də Ops - üç böyük problemi var:

• Mövcud vəziyyətdən məmnunluq.
• Məsuliyyətin olmaması - çünki heç kim ifaçıların işinin nəticələrini biznesə təsir etmək üçün gətirməyib.
• Dəyişiklik qorxusu.

Dəyişiklik həmişə sizi rahatlıq zonanızdan kənara çıxarır və gənclər nə qədər gənc olsalar, dəyişikliyi bir o qədər sevmirlər, çünki səbəbini və necə olduğunu başa düşmürlər. Eşitdiyim ən ümumi cavab "biz bunu heç vaxt etməmişik" olur. Üstəlik, tam absurdluq həddinə çatdı - ən kiçik dəyişikliklər kimsə qəzəblənmədən baş verə bilməzdi. Dəyişikliklər onların işinə nə qədər təsir etsə də, insanlar: “Yox, niyə? Bu işləməyəcək”.

Amma heç nəyi dəyişmədən yaxşılaşa bilməzsən.

Bir işçi ilə tamamilə absurd söhbət etdim, ona optimallaşdırma ilə bağlı fikirlərimi söylədim, o da mənə dedi:
- Oh, keçən il nə olduğumuzu görmədin!
- Nə olsun?
"İndi əvvəlkindən daha yaxşıdır."
- Deməli, daha yaxşı ola bilməz?
- Nə üçün?

Yaxşı sual - niyə? Sanki indi əvvəlkindən yaxşıdır, deməli hər şey kifayət qədər yaxşıdır. Bu, məsuliyyətsizliyə gətirib çıxarır ki, bu da prinsipcə tamamilə normaldır. Dediyim kimi, texniki qrup bir az kənarda qaldı. Şirkət onların mövcud olmalı olduğuna inanırdı, lakin heç kim standartları təyin etməyib. Texniki dəstək heç vaxt SLA-nı görmədi, buna görə də qrup üçün olduqca "məqbul" idi (və bu məni ən çox vurdu):

• 12 saniyə yükləmə;
• Hər buraxılışda 5-10 dəqiqə fasilə;
• Kritik problemlərin aradan qaldırılması günlər və həftələr çəkir;
• 24x7 / çağırış üzrə növbətçi heyətin çatışmazlığı.

Heç kim niyə bunu daha yaxşı etmədiyimizi soruşmağa çalışmadı və heç kim bunun belə olması lazım olmadığını başa düşmədi.

Bonus olaraq daha bir problem var idi: təcrübənin olmaması. Böyüklər getdi, yerdə qalan gənc komanda da əvvəlki rejimdə böyüyüb, ondan zəhərlənib.

Bütün bunların üzərinə insanlar da uğursuzluqdan, bacarıqsız görünməkdən qorxurdular. Bu, ilk növbədə, onların heç bir halda kömək istəmədi. Neçə dəfə qrup halında və tək-tək danışdıq və mən dedim: “Bir şeyi necə edəcəyinizi bilmirsinizsə, sual verin”. Mən özümə güvənirəm və bilirəm ki, istənilən problemi həll edə bilərəm, amma bu, vaxt aparacaq. Ona görə də 10 dəqiqəyə həllini biləndən soruşa bilsəm, soruşaram. Təcrübəniz nə qədər az olsa, soruşmaqdan bir o qədər qorxursunuz, çünki bacarıqsız sayılacağınızı düşünürsünüz.

Bu sual vermək qorxusu maraqlı formalarda özünü göstərir. Məsələn, soruşursunuz: "Bu tapşırığı necə edirsiniz?" - "Bir neçə saat qaldı, mən artıq bitirirəm." Ertəsi gün yenə soruşursan cavab alırsan ki, hər şey yaxşıdır, amma bir problem var idi, günün sonuna qədər mütləq hazır olacaq. Daha bir gün keçir və siz divara bərkidilib kiminləsə danışmağa məcbur olana qədər bu davam edir. İnsan bir problemi özü həll etmək istəyir, özü həll etməsə, bunun böyük uğursuzluq olacağına inanır.

Buna görə tərtibatçılar təxminləri şişirdilər. Elə həmin lətifə idi, hansısa tapşırığı müzakirə edəndə mənə elə bir rəqəm verdilər ki, çox təəccübləndim. Mənə dedilər ki, tərtibatçının təxminlərində tərtibatçı biletin QA-dan qaytarılacağı vaxtı, çünki orada səhvlər tapacaqlarını, PR-ın keçəcəyi vaxtı və nəzərdən keçirməli olan insanların vaxtını ehtiva edir. məşğul olacaq - yəni hər şey , mümkün olan hər şey.

İkincisi, bacarıqsız görünməkdən qorxan insanlar həddindən artıq təhlil etmək. Tam olaraq nə etmək lazım olduğunu deyəndə o başlayır: “Xeyr, bu barədə burada fikirləşsək nə olacaq?” Bu mənada şirkətimiz unikal deyil, bu gənclər üçün standart problemdir.

Cavab olaraq aşağıdakı təcrübələri təqdim etdim:

• Qayda 30 dəqiqə. Əgər problemi yarım saat ərzində həll edə bilmirsinizsə, kimsədən kömək istəyin. Bu, müxtəlif dərəcədə müvəffəqiyyətlə işləyir, çünki insanlar hələ də soruşmurlar, amma heç olmasa proses başlayıb.
• Mahiyyətdən başqa hər şeyi aradan qaldırın, tapşırığı yerinə yetirmək üçün son tarixi təxmin edərkən, yəni kodu yazmaq üçün yalnız nə qədər vaxt lazım olduğunu nəzərə alın.
• Davamlı öyrənmə həddindən artıq təhlil edənlər üçün. Sadəcə insanlarla daimi işdir.

Altmışıncı gün

Bütün bunları edərkən, büdcəni müəyyənləşdirmək vaxtı gəldi. Təbii ki, pulumuzu hara xərclədiyimizlə bağlı çox maraqlı şeylər tapdım. Məsələn, bir müştəri tərəfindən istifadə edilən bir FTP serveri olan ayrı bir məlumat mərkəzində bütöv bir rafımız var idi. Məlum oldu ki, “... köçdük, amma o belə qaldı, biz onu dəyişmədik”. 2 il əvvəl idi.

Bulud xidmətləri üçün qanun layihəsi xüsusi maraq doğurdu. Hesab edirəm ki, yüksək bulud hesabının əsas səbəbi həyatlarında ilk dəfə serverlərə məhdudiyyətsiz giriş əldə edən tərtibatçılardır. Onlardan soruşmağa ehtiyac yoxdur: "Zəhmət olmasa, mənə bir test serveri verin", özləri də götürə bilərlər. Üstəlik, tərtibatçılar həmişə elə sərin sistem qurmaq istəyirlər ki, Facebook və Netflix paxıllıq etsin.

Lakin tərtibatçıların serverlərin alınmasında təcrübəsi və serverlərin tələb olunan ölçüsünü müəyyən etmək bacarığı yoxdur, çünki əvvəllər buna ehtiyac yox idi. Və onlar adətən miqyaslılıq və performans arasındakı fərqi tam başa düşmürlər.

İnventarlaşdırma nəticələri:

• Eyni məlumat mərkəzini tərk etdik.
• Biz 3 log xidməti ilə müqaviləyə xitam verdik. Çünki onlardan 5-i bizdə idi - bir şeylə oynamağa başlayan hər bir tərtibatçı yenisini götürdü.
• 7 AWS sistemi bağlandı. Yenə ölü layihələri heç kim dayandırmadı, hamısı işləməyə davam etdi.
• Proqram təminatı xərcləri 6 dəfə azaldıldı.

Yetmiş beşinci gün

Vaxt keçdi və iki ay yarımdan sonra direktorlar şurası ilə görüşməli oldum. Direktorlar şuramız digərlərindən yaxşı və ya pis deyil; bütün idarə şuraları kimi o da hər şeyi bilmək istəyir. İnsanlar pul yatırır və gördüklərimizin müəyyən edilmiş KPI-lərə nə qədər uyğun olduğunu anlamaq istəyirlər.

Direktorlar şurası hər ay bir çox məlumat alır: istifadəçilərin sayı, onların artımı, hansı xidmətlərdən və necə istifadə etdikləri, performans və məhsuldarlıq və nəhayət, orta səhifə yükləmə sürəti.

Yeganə problem odur ki, mən ortalamanın xalis pis olduğuna inanıram. Amma bunu idarə heyətinə izah etmək çox çətindir. Onlar, məsələn, saniyədə yükləmə müddətlərinin yayılması ilə deyil, ümumiləşdirilmiş nömrələrlə işləməyə öyrəşiblər.

Bununla bağlı maraqlı məqamlar da var idi. Məsələn, mən dedim ki, məzmunun növündən asılı olaraq trafiki ayrı-ayrı veb serverlər arasında bölmək lazımdır.

Yəni ColdFusion Jetty və nginx-dən keçir və səhifələri işə salır. Və şəkillər, JS və CSS öz konfiqurasiyaları ilə ayrıca nginx-dən keçir. Bu, haqqında danışdığım kifayət qədər standart təcrübədir yazdı bir neçə il əvvəl. Nəticədə şəkillər çox daha sürətli yüklənir və... orta yükləmə sürəti 200 ms artıb.

Bu, qrafikin Jetty ilə gələn məlumatlar əsasında qurulduğu üçün baş verdi. Yəni sürətli məzmun hesablamaya daxil edilmir - orta dəyər atladı. Bu bizə aydın idi, güldük, bəs biz idarə heyətinə necə başa salaq ki, nə üçün bir şey etdik və 12% pisləşdi?

Səksən beşinci gün

Üçüncü ayın sonunda başa düşdüm ki, heç saymadığım bir şey var: vaxt. Haqqında danışdığım hər şey vaxt tələb edir.

Bu mənim əsl həftəlik təqvimimdir - sadəcə bir iş həftəsi, çox məşğul deyil. Hər şey üçün kifayət qədər vaxt yoxdur. Buna görə də, yenə də problemlərin öhdəsindən gəlməyə kömək edəcək insanları işə götürməlisiniz.

Nəticə

Bu hamısı deyil. Bu hekayədə mən məhsulla necə işlədiyimizi və ümumi dalğaya uyğunlaşmağa çalışdığımızı, texniki dəstəyi necə birləşdirdiyimizi və ya digər texniki problemləri necə həll etdiyimizi başa düşmədim. Məsələn, mən təsadüfən öyrəndim ki, verilənlər bazasında ən böyük cədvəllərdə biz istifadə etmirik SEQUENCE. Özümüzə yazılan funksiyamız var nextID, və əməliyyatda istifadə edilmir.

Uzun müddət danışa biləcəyimiz milyonlarla oxşar şeylər var idi. Ancaq hələ də deyilməli olan ən mühüm şey mədəniyyətdir.

Bütün digər problemlərə səbəb olan mədəniyyət və ya onun olmamasıdır. Biz insanların olduğu bir mədəniyyət yaratmağa çalışırıq:

• uğursuzluqlardan qorxmur;
• səhvlərdən öyrənmək;
• digər komandalarla əməkdaşlıq etmək;
• təşəbbüs göstərmək;
• məsuliyyət götürmək;
• nəticəni məqsəd kimi qarşılayır;
• uğurunu qeyd edir.

Bununla başqa hər şey gələcək.

Leon Atəşi twitterdə, facebook və mühit.

Mirasla bağlı iki strategiya var: nəyin bahasına olursa olsun onunla işləməkdən çəkinin və ya əlaqəli çətinlikləri cəsarətlə dəf edin. Biz c DevOpsConf Biz ikinci yolla gedirik, prosesləri, yanaşmaları dəyişirik. Bizə qoşulun youtube, Poçt siyahısı и teleqram, və birlikdə DevOps mədəniyyətini həyata keçirəcəyik.

Mənbə: www.habr.com