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ə
Bir startap. Bir admin, kiçik bir inkişaf qrupu. İlk dəfə qoşulduğum zaman tamamilə sıfır idim, çünki elektron poçtumdan başqa heç bir şeyə girişim yox idi. Admindən giriş üçün yazdıq. O, həmçinin yeni işçinin giriş və parol vermə ehtiyacı barədə məlumatlı idi. Onlar mənə depoya giriş imkanı verdilər və VPNNiyə Wiki, TeamCity və RunDesk-ə giriş icazəsi verməlisiniz? Bütün arxa hissəni yazmaq üçün işə götürülmüş biri üçün faydasızdır. Yalnız zamanla bəzi vasitələrə giriş əldə edirik. Təbii ki, gəlişimə inamsızlıqla qarşılanıram. Layihənin infrastrukturunu söhbətlər və aparıcı suallar vasitəsilə yavaş-yavaş hiss etməyə çalışıram. Əsasən heç nə öyrənmirəm. İstehsal həmişəki kimi qara qutudur. Amma hətta test üçün istifadə olunan səhnə serverləri belə burada qara qutulardır. Git-dən filiallar yerləşdirməkdən başqa heç nə edə bilmərik. Həmçinin .env faylları kimi tətbiqimizi konfiqurasiya edə bilmirik. Bu cür əməliyyatlara giriş icazə verilmir. Test serverində tətbiqinizin konfiqurasiyasında bir sətri dəyişdirməyi xahiş etməlisiniz. (Adminlərin layihədəki ən vacib insanlar kimi hiss etmələrinin vacib olduğu bir nəzəriyyə var; əgər onlardan konfiqurasiya sətirlərini dəyişdirmələri istənilmirsə, sadəcə ehtiyac duyulmayacaqlar.) Həmişə olduğu kimi, rahat deyilmi? Bu, tez bir zamanda yorucu olur. Adminlə birbaşa söhbətdən sonra aşkar etdik ki, tərtibatçılar pis kod yazmaq üçün doğulurlar, təbiətcə səriştəsizdirlər və istehsaldan uzaq durmaq daha yaxşıdır. Və sonra test mühiti var. serverlər Hər ehtimala qarşı. Münaqişə tez bir zamanda şiddətlənir. Adminlə heç bir ünsiyyət yoxdur. Vəziyyət onun tək olması ilə daha da ağırlaşır. Sonra tipik ssenari gəlir. Buraxılış. Müəyyən bir funksiya işləmir. Nə baş verdiyini anlamağa uzun müddət çalışırıq, tərtibatçılar söhbətə müxtəlif ideyalar atırlar, amma admin adətən tərtibatçıların günahkar olduğunu düşünür. Sonra söhbətdə yazır: "Gözləyin, mən onu düzəltdim". Problem haqqında məlumat olan bir tarixçə qoymağı xahiş etdiyimiz zaman zəhərli bəhanələr alırıq. Deyirlər ki, "Aid olmayan yerə burnunuzu soxmayın". Tərtibatçılar kod yazmalıdırlar. Bir çox layihə prosesinin tək bir şəxsdən keçdiyi və yalnız hər kəsin ehtiyac duyduğu əməliyyatları yerinə yetirmək üçün giriş əldə etdiyi bir vəziyyət olduqca kədərlidir. Belə bir insan dəhşətli bir maneədir. Əgər DevOps-un ideyaları bazara çıxma müddətini azaltmağa çalışırsa, onda belə insanlar DevOps ideyalarının ən pis düşmənidir. Təəssüf ki, pərdə burada 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
