Təsadüflər təsadüfi olur və həqiqətən də başqa planetdə olub...
Mən arxa plan tərtibatçısının adminlərlə bir komandada necə işləməsi ilə bağlı üç uğur və uğursuzluq hekayəsini bölüşmək istərdim.
Hekayə bir.
Web studio, işçilərin sayını bir əllə saymaq olar. Bu gün layout dizayneri, sabah dəstəkçi, o biri gün isə adminsən. Bir tərəfdən çox böyük təcrübə qazana bilərsiniz. Digər tərəfdən, bütün sahələrdə səriştəsizlik var. İşin ilk gününü hələ də xatırlayıram, mən hələ də yaşılam, müdir deyir: "Açıq macun", amma bunun nə olduğunu bilmirəm. Adminlərlə ünsiyyət istisnadır, çünki sən özün adminsən. Bu vəziyyətin müsbət və mənfi cəhətlərini nəzərdən keçirək.
+ Bütün güc sizin əlinizdədir.
+ Serverə giriş üçün heç kimə yalvarmağa ehtiyac yoxdur.
+ Bütün istiqamətlərdə sürətli reaksiya müddəti.
+ Bacarıqları yaxşılaşdırır.
+ Məhsulun arxitekturasını tam başa düşmək.
-Yüksək məsuliyyət.
- İstehsalın pozulması riski.
— Bütün sahələrdə yaxşı mütəxəssis olmaq çətindir.
Maraqlı deyil, davam edək
İkinci hekayə.
Böyük şirkət, böyük layihə. 5-7 işçidən və bir neçə inkişaf qruplarından ibarət bir idarə şöbəsi var. Belə bir şirkətdə işləməyə gələndə hər bir admin düşünür ki, siz bura məhsul üzərində işləmək üçün deyil, nəyisə sındırmaq üçün gəlmisiniz. Nə imzalanmış NDA, nə də müsahibədəki seçim başqa cür ifadə etmir. Yox, bu adam bura öz çirkli balaca əlləri ilə gəlib ki, öpüşmə istehsalımızı pozsun. Buna görə də, belə bir insanla minimum ünsiyyətə ehtiyacınız var, ən azı cavab olaraq bir stiker ata bilərsiniz. Layihənin arxitekturası ilə bağlı suallara cavab verməyin. Komanda rəhbəri xahiş edənə qədər giriş icazəsi verməmək məsləhətdir. O, soruşduqda, istədiklərindən daha az imtiyazla geri verəcəkdir. Bu cür adminlərlə demək olar ki, bütün ünsiyyət inkişaf şöbəsi ilə idarəetmə şöbəsi arasındakı qara dəlik tərəfindən əmilir. Problemləri dərhal həll etmək mümkün deyil. Ancaq şəxsən gələ bilməzsiniz - adminlər 24/7 çox məşğuldur. (Hər zaman nə edirsiniz?) Bəzi performans xüsusiyyətləri:
- İstehsalda orta yerləşdirmə müddəti 4-5 saatdır
- İstehsalda maksimum yerləşdirmə müddəti 9 saat
- Tərtibatçı üçün istehsalda olan proqram istehsal serverinin özü kimi qara qutudur. Cəmi neçə nəfər var?
- Buraxılışların aşağı keyfiyyəti, tez-tez səhvlər
- Tərtibatçı buraxılış prosesində iştirak etmir
Yaxşı, nə gözləyirdim, təbii ki, istehsala yeni adamlar buraxılmır. Yaxşı, səbr qazandıqdan sonra başqalarının etibarını qazanmağa başlayırıq. Amma nədənsə adminlərlə iş o qədər də sadə deyil.
Akt 1. Admin görünməzdir.
Buraxılış günü, tərtibatçı və admin əlaqə saxlamır. Adminin sualı yoxdur. Amma səbəbini sonra başa düşəcəksən. Admin prinsipial insandır, messencerləri yoxdur, telefon nömrəsini heç kimə vermir, sosial şəbəkələrdə profili yoxdur. Heç yerdə onun şəkli belə yoxdur, sən nəyə oxşayırsan dostum? Məsul menecerlə təxminən 15 dəqiqə çaşqınlıqla oturub bu Voyager 1 ilə əlaqə yaratmağa çalışırıq, sonra korporativ e-poçtda onun bitirdiyi mesaj görünür. Biz poçtla yazışacağıq? Niyə də yox? Rahatdır, elə deyilmi? Yaxşı, yaxşı, sərinləşək. Artıq proses gedir, geriyə dönüş yoxdur. Mesajı yenidən oxuyun. "Mən bitirdim". Nə bitirdin? Harada? Səni harda axtarmalıyam? Burada sərbəst buraxılması üçün 4 saatın niyə normal olduğunu başa düşürsünüz. İnkişaf şoku alırıq, amma buraxılışı bitiririk. Artıq azadlığa çıxmaq istəyi yoxdur.
Akt 2. Həmin versiya deyil.
Növbəti buraxılış. Təcrübə qazandıqdan sonra bəziləri üçün versiyaları göstərən inzibatçılar üçün server üçün lazımi proqram təminatı və kitabxanaların siyahılarını yaratmağa başlayırıq. Həmişə olduğu kimi, adminin orada nəyisə bitirdiyi barədə zəif radio siqnalı alırıq. Reqressiya testi başlayır, özü də təxminən bir saat çəkir. Hər şey işləyir, amma bir kritik səhv var. Vacib funksionallıq işləmir. Sonrakı bir neçə saat dəflərlə rəqs etmək, qəhvə meydançasında falçılıq və hər bir kod parçasının ətraflı nəzərdən keçirilməsi idi. Admin hər şeyi etdiyini deyir. Əyri tərtibatçıların yazdığı proqram işləmir, amma server işləyir. Ona sualınız varmı? Bir saatın sonunda admindən istehsal serverindəki kitabxananın versiyasını söhbətə və binqoya göndərməyi tapşırırıq - bu, bizə lazım olan deyil. Administratordan tələb olunan versiyanı quraşdırmasını xahiş edirik, lakin cavab olaraq alırıq ki, o, OS paket menecerində bu versiyanın olmaması səbəbindən bunu edə bilməz. Budur, yaddaşının boşluqlarından menecer xatırlayır ki, başqa bir admin sadəcə olaraq əl ilə lazımi versiyanı yığmaqla bu problemi həll etmişdi. Amma yox, bizimkilər bunu etməyəcək. Qaydalar qadağan edir. Karl, biz bir neçə saatdır burada oturmuşuq, vaxt limiti nədir?! Başqa bir şok alırıq və birtəhər buraxılışı bitiririk.
3-cü akt, qısa
Təcili bilet, əsas funksionallıq istehsalda olan istifadəçilərdən biri üçün işləmir. Bir-iki saat ovuşdurub yoxlayırdıq. İnkişaf mühitində hər şey işləyir. php-fpm qeydlərinə baxmaq yaxşı fikir olardı ki, aydın bir anlayış var. O dövrdə layihədə ELK və ya Prometheus kimi log sistemləri yox idi. Biz idarəetmə şöbəsinə bilet açırıq ki, onlar serverdə php-fpm qeydlərinə giriş imkanı versinlər. Burada başa düşməlisiniz ki, biz bir səbəbdən giriş istəyirik, qara dəliyin və adminlərin 24/7 məşğul olduğunu xatırlamırsınız? Onlardan jurnalların özlərinə baxmalarını xahiş etsəniz, bu, "bu həyatda deyil" prioriteti olan bir vəzifədir. Bilet yaradıldı, idarə şöbəsinin müdirindən dərhal cavab aldıq: "İstehsal jurnallarına giriş lazım deyil, səhvsiz yazın." Bir pərdə.
Akt 4 və daha sonra
Biz hələ də kitabxanaların müxtəlif versiyaları, konfiqurasiya edilməmiş proqram təminatı, hazırlanmamış server yükləmələri və digər problemlər səbəbindən istehsalda onlarla problem toplayırıq. Əlbəttə ki, kod səhvləri də var, biz bütün günahlara görə adminləri günahlandırmayacağıq, sadəcə həmin layihə üçün daha bir tipik əməliyyatı qeyd edəcəyik. Nəzarətçi vasitəsilə işə salınan kifayət qədər çox işçimiz var idi və bəzi skriptləri cron-a əlavə etmək lazım idi. Bəzən həmin işçilər işlərini dayandırırdılar. Növbə serverindəki yük ildırım sürəti ilə artdı və kədərli istifadəçilər fırlanan yükləyiciyə baxdılar. Bu cür işçiləri tez bir zamanda düzəltmək üçün onları sadəcə yenidən işə salmaq kifayət idi, amma yenə də bunu yalnız idarəçi edə bilərdi. Belə bir əsas əməliyyat aparılarkən, bütün gün keçə bilərdi. Burada, əlbəttə ki, qeyd etmək lazımdır ki, əyri proqramçılar işçilər yazmalıdırlar ki, qəzaya uğramasınlar, amma yıxılanda, istehsala çıxışın olmaması səbəbindən bəzən mümkün olmayan səbəbini başa düşmək yaxşı olardı. əlbəttə və nəticədə tərtibatçıdan qeydlərin olmaması.
Transfiqurasiya.
Bütün bunlara kifayət qədər uzun müddət dözdükdən sonra komanda ilə birlikdə bizim üçün daha uğurlu olan istiqamətə yönəlməyə başladıq. Ümumiləşdirsək, hansı problemlərlə üzləşdik?
- Tərtibatçılar və idarəetmə şöbəsi arasında keyfiyyətli ünsiyyətin olmaması
- Administratorlar, belə çıxır(!), tətbiqin necə qurulduğunu, hansı asılılıqlara sahib olduğunu və necə işlədiyini heç anlamırlar.
- Tərtibatçılar istehsal mühitinin necə işlədiyini başa düşmürlər və nəticədə problemlərə effektiv cavab verə bilmirlər.
- Yerləşdirmə prosesi çox uzun çəkir.
- Qeyri-sabit buraxılışlar.
Biz nə etmişik?
Hər buraxılış üçün növbəti buraxılışın işləməsi üçün serverdə görülməli olan işlərin siyahısını özündə əks etdirən Release Notes siyahısı yaradıldı. Siyahıda administrator, buraxılışa cavabdeh şəxs və tərtibatçı tərəfindən yerinə yetirilməli olan bir neçə bölmə var idi. Tərtibatçılar bütün istehsal serverlərinə kök olmayan giriş əldə etdilər ki, bu da ümumilikdə inkişafı və xüsusilə problemlərin həllini sürətləndirdi. Tərtibatçılar həmçinin istehsalın necə işlədiyini, hansı xidmətlərə bölündüyünü, replikaların harada və nə qədər başa gəldiyini başa düşürlər. Döyüş yüklərinin bəziləri daha aydın oldu, bu, şübhəsiz ki, kodun keyfiyyətinə təsir göstərir. Buraxılış prosesi zamanı ünsiyyət messencerlərdən birinin söhbətində baş verdi. Birincisi, bizdə bütün hərəkətlərin jurnalı var idi, ikincisi, ünsiyyət daha yaxın bir mühitdə baş verdi. Fəaliyyət tarixçəsinə sahib olmaq bir dəfədən çox yeni işçilərə problemləri daha sürətli həll etməyə imkan verdi. Bu bir paradoksdur, lakin bu çox vaxt adminlərin özlərinə kömək edirdi. Dəqiq deməyi öhdəmə götürməyəcəyəm, amma mənə elə gəlir ki, adminlər layihənin necə işlədiyini və necə yazıldığını daha çox anlamağa başlayıblar. Bəzən hətta bəzi detalları bir-birimizlə paylaşırdıq. Orta buraxılış müddəti bir saata endirildi. Bəzən 30-40 dəqiqəyə işimizi bitirirdik. Baqların sayı on dəfə olmasa da, əhəmiyyətli dərəcədə azalıb. Təbii ki, buraxılış vaxtının azalmasına digər amillər də təsir etdi, məsələn, avtotestlər. Hər buraxılışdan sonra retrospektivlər aparmağa başladıq. Beləliklə, bütün komandanın nəyin yeni, nəyin dəyişdirildiyi və nəyin silindiyi barədə təsəvvürü olsun. Təəssüf ki, adminlər həmişə onlara gəlmirdi, yaxşı, adminlər məşğuldur... Bir developer kimi işdən məmnunluğum şübhəsiz artdı. Bacarıq sahənizdə olan demək olar ki, hər hansı bir problemi tez bir zamanda həll edə bilsəniz, özünüzü yuxarıda hiss edirsiniz. Sonralar başa düşəcəyəm ki, biz müəyyən dərəcədə devops mədəniyyətini təqdim etmişik, əlbəttə ki, tamamilə yox, amma transformasiyanın başlanğıcı belə təsir edici idi.
Üçüncü hekayə
Başlamaq. Bir admin, kiçik inkişaf şöbəsi. Gələndə mən tam sıfıram, çünki... Mənim poçtdan başqa heç bir yerə çıxışım yoxdur. Adminə yazıb giriş xahiş edirik. Bundan əlavə, onun yeni işçidən xəbərdar olduğu və login/parolların verilməsi zərurəti barədə məlumat var. Repozitoriyadan və VPN-dən giriş imkanı verirlər. Niyə wiki, teamcity, rundesk-ə giriş verirsiniz? Bütün arxa hissəni yazmağa çağırılan bir şəxs üçün faydasız şeylər. Yalnız zaman keçdikcə bəzi vasitələrə giriş əldə edirik. Gəliş, təbii ki, inamsızlıqla qarşılandı. Söhbətlər və aparıcı suallar vasitəsilə layihənin infrastrukturunun necə işlədiyini yavaş-yavaş hiss etməyə çalışıram. Ümumiyyətlə, mən heç nə tanımıram. İstehsal əvvəlki kimi qara qutudur. Ancaq bundan əlavə, hətta sınaq üçün istifadə olunan səhnə serverləri də qara qutudur. Git-dən bir filial yerləşdirməkdən başqa heç nə edə bilmərik. Biz həmçinin tətbiqimizi .env faylları kimi konfiqurasiya edə bilmirik. Bu cür əməliyyatlar üçün giriş təmin edilmir. Test serverində tətbiqinizin konfiqurasiyasında xəttin dəyişdirilməsi üçün yalvarmalısınız. (Adminlərin layihədə özlərini vacib hiss etmələrinin həyati vacib olduğu nəzəriyyəsi var; əgər onlardan konfiqurasiyada sətirləri dəyişdirmək tələb olunmasa, onlara sadəcə ehtiyac olmayacaq). Yaxşı, həmişə olduğu kimi, rahat deyilmi? Bu tez darıxdırıcı olur, adminlə birbaşa söhbətdən sonra öyrənirik ki, tərtibatçılar pis kod yazmaq üçün doğulublar, təbiətcə bacarıqsız şəxslərdir və onları istehsaldan uzaq tutmaq daha yaxşıdır. Amma burada da hər ehtimala qarşı test serverlərindən. Münaqişə sürətlə böyüyür. Adminlə əlaqə yoxdur. Onun tək olması vəziyyəti daha da ağırlaşdırır. Aşağıdakı tipik bir şəkildir. Buraxın. Müəyyən funksionallıq işləmir. Nə baş verdiyini anlamaq bizə çox vaxt aparır, tərtibatçıların müxtəlif fikirləri çata atılır, lakin belə bir vəziyyətdə admin adətən tərtibatçıların günahkar olduğunu düşünür. Sonra çatda yazır, gözləyin, onu düzəltdim. Problemin nə olduğu ilə bağlı bir hekayə buraxmağı xahiş etdikdə, biz zəhərli bəhanələr alırıq. Necə ki, burnunuzu aid olmayan yerə soxmayın. Tərtibatçılar kod yazmalıdırlar. Bir layihədə çoxlu bədən hərəkətlərinin tək bir şəxsdən keçməsi və hər kəsin ehtiyac duyduğu əməliyyatları yerinə yetirmək imkanına malik olması son dərəcə acınacaqlıdır. Belə bir insan dəhşətli darboğazdır. Əgər Devops ideyaları bazara çıxma müddətini azaltmağa çalışırsa, belə insanlar Devops ideyalarının ən qatı düşmənidir. Təəssüf ki, burada pərdə bağlanır.
P.S. İnsanlarla söhbətlərdə tərtibatçılar və adminlər haqqında bir az danışdıqdan sonra ağrılarımı bölüşən insanlarla tanış oldum. Amma heç vaxt belə bir şeylə rastlaşmadıqlarını deyənlər də olub. Bir devops konfransında mən Anton İsanindən (Alfa Bank) adminlər şəklində darboğaz problemi ilə necə məşğul olduqlarını soruşdum və o, dedi: "Biz onları düymələrlə əvəz etdik." Yeri gəlmişkən onun iştirakı ilə. İnanmaq istərdim ki, düşmənlərdən çox yaxşı adminlər var. Bəli, başlanğıcdakı şəkil əsl yazışmadır.
Mənbə: www.habr.com