Dasturchilar Marsdan, adminlar Veneradan

Dasturchilar Marsdan, adminlar Veneradan

Tasodiflar tasodifiy va haqiqatan ham boshqa sayyorada bo'lgan ...

Men backend dasturchisi administratorlar bilan jamoada qanday ishlashi haqida uchta muvaffaqiyat va muvaffaqiyatsizlik hikoyalarini baham ko'rmoqchiman.

Birinchi hikoya.
Veb-studiya, xodimlar sonini bir qo'l bilan hisoblash mumkin. Bugun siz maket dizaynerisiz, ertaga siz backendersiz, ertaga adminsiz. Bir tomondan, siz katta tajribaga ega bo'lishingiz mumkin. Boshqa tomondan, barcha sohalarda malaka yetishmaydi. Men hali ham birinchi ish kunini eslayman, men hali ham yashilman, xo'jayin: "Ochiq macun", deydi, lekin bu nima ekanligini bilmayman. Adminlar bilan muloqot olib tashlandi, chunki siz o'zingiz adminsiz. Keling, ushbu vaziyatning ijobiy va salbiy tomonlarini ko'rib chiqaylik.

+ Barcha kuch sizning qo'lingizda.
+ Serverga kirish uchun hech kimdan iltimos qilishning hojati yo'q.
+ Barcha yo'nalishlarda tez reaktsiya vaqti.
+ Ko'nikmalarni yaxshilaydi.
+ Mahsulot arxitekturasi haqida to'liq tushunchaga ega bo'ling.

- Yuqori mas'uliyat.
- ishlab chiqarishni buzish xavfi.
— Hamma sohada yaxshi mutaxassis bo‘lish qiyin.

Qiziq emas, davom etaylik

Ikkinchi hikoya.
Katta kompaniya, yirik loyiha. 5-7 xodim va bir nechta rivojlanish guruhlari bo'lgan ma'muriyat bo'limi mavjud. Bunday kompaniyaga ishga kelganingizda, har bir admin siz bu yerga mahsulot ustida ishlash uchun emas, balki biror narsani buzish uchun kelgan deb o'ylaydi. Imzolangan NDA ham, suhbatdagi tanlov ham boshqacha ko'rsatmaydi. Yo'q, bu odam o'pish ishlab chiqarishimizni buzish uchun bu erga o'zining iflos qo'llari bilan kelgan. Shuning uchun, bunday odam bilan sizga minimal muloqot kerak, hech bo'lmaganda, javob sifatida siz stiker tashlashingiz mumkin. Loyiha arxitekturasi haqidagi savollarga javob bermang. Jamoa rahbari so'ramaguncha ruxsat bermaslik tavsiya etiladi. Va so'raganda, ular so'raganidan ham kamroq imtiyozlar bilan qaytarib beradi. Bunday administratorlar bilan deyarli barcha aloqalar rivojlanish bo'limi va ma'muriyat bo'limi o'rtasidagi qora tuynuk tomonidan so'riladi. Muammolarni tezda hal qilishning iloji yo'q. Lekin siz shaxsan kela olmaysiz - administratorlar 24/7 kuni juda band. (Har doim nima qilyapsiz?) Ba'zi ishlash xususiyatlari:

  • Ishlab chiqarishda o'rtacha joylashtirish vaqti 4-5 soat
  • Ishlab chiqarishda maksimal joylashtirish vaqti 9 soat
  • Ishlab chiquvchi uchun ishlab chiqarishdagi dastur xuddi ishlab chiqarish serverining o'zi kabi qora qutidir. Hammasi qancha?
  • Chiqarishlarning past sifati, tez-tez xatolar
  • Ishlab chiquvchi chiqarish jarayonida ishtirok etmaydi

Xo'sh, men nimani kutdim, albatta, yangi odamlar ishlab chiqarishga ruxsat etilmaydi. Xo'sh, yaxshi, sabr-toqat qozonganimizdan so'ng, biz boshqalarning ishonchini qozona boshlaymiz. Lekin negadir adminlar bilan ishlar unchalik oson emas.

1-harakat. Admin ko'rinmas.
Chiqarish kuni, ishlab chiquvchi va administrator aloqa qilmaydi. Adminning savoli yo'q. Lekin nega buni keyinroq tushunasiz. Admin printsipial odam, messenjerlari yo'q, telefon raqamini hech kimga bermaydi va ijtimoiy tarmoqlarda profili yo'q. Hech qayerda uning surati ham yo'q, siz nimaga o'xshaysiz do'stim? Biz mas'ul menejer bilan taxminan 15 daqiqa hayron bo'lib o'tirib, ushbu Voyager 1 bilan aloqa o'rnatishga harakat qilamiz, keyin korporativ elektron pochtada u tugatganligi haqida xabar paydo bo'ladi. Pochta orqali yozishmoqchimiz? Nega yo'q? Qulay, shunday emasmi? Xo'sh, mayli, sovib ketaylik. Jarayon allaqachon ketmoqda, orqaga qaytish yo'q. Xabarni qayta o'qing. "Men tugatdim". Nimani tugatdingiz? Qayerda? Seni qayerdan izlashim kerak? Bu erda nima uchun ozod qilish uchun 4 soat normal ekanligini tushunasiz. Biz rivojlanish zarbasiga duchor bo'lamiz, lekin biz nashrni tugatamiz. Endi ozod qilish istagi yo'q.

Akt 2. Bu versiya emas.
Keyingi nashr. Tajriba orttirgandan so'ng, biz ma'murlar uchun server uchun kerakli dasturiy ta'minot va kutubxonalar ro'yxatini yaratishni boshlaymiz, ba'zilari uchun versiyalarni ko'rsatamiz. Har doimgidek, administrator u erda biror narsani tugatganligi haqida zaif radio signalini olamiz. Regressiya testi boshlanadi, uning o'zi bir soat davom etadi. Hammasi ishlayotganga o'xshaydi, lekin bitta muhim xato bor. Muhim funksiya ishlamaydi. Keyingi bir necha soat daflar bilan raqsga tushish, qahva maydonchasida fol ochish va har bir kod parchasini batafsil ko'rib chiqish edi. Admin hammasini qilganini aytadi. Egri ishlab chiquvchilar tomonidan yozilgan dastur ishlamaydi, lekin server ishlaydi. Unga savollaringiz bormi? Bir soat oxirida biz administratorga ishlab chiqarish serveridagi kutubxona versiyasini chat va bingoga yuborishini olamiz - bu bizga kerak bo'lgan narsa emas. Biz administratordan kerakli versiyani o'rnatishni so'raymiz, ammo javoban biz OS paket menejerida ushbu versiya yo'qligi sababli buni qila olmasligini olamiz. Bu erda, xotirasining chuqurligidan menejer boshqa administrator bu muammoni allaqachon kerakli versiyani qo'lda yig'ish orqali hal qilganini eslaydi. Lekin yo'q, biznikilar buni qilmaydi. Qoidalar taqiqlaydi. Karl, biz bu erda bir necha soat o'tirdik, vaqt chegarasi qancha?! Biz yana bir zarba olamiz va qandaydir tarzda nashrni tugatamiz.

3-qism, qisqacha
Shoshilinch chipta, asosiy funksionallik ishlab chiqarishdagi foydalanuvchilardan biri uchun ishlamaydi. Biz bir-ikki soat o'ylaymiz va tekshiramiz. Rivojlanish muhitida hamma narsa ishlaydi. php-fpm jurnallarini ko'rib chiqish yaxshi fikr bo'lishi aniq tushuncha mavjud. O'sha paytda loyihada ELK yoki Prometey kabi log tizimlari yo'q edi. Biz ma'muriyat bo'limiga chipta ochamiz, ular serverdagi php-fpm jurnallariga kirish huquqini beradi. Bu erda biz biron bir sababga ko'ra kirishni so'rayotganimizni tushunishingiz kerak, qora tuynuk va administratorlar 24/7 band bo'lganini eslay olmaysizmi? Agar siz ulardan jurnallarni o'zlari ko'rib chiqishlarini so'rasangiz, bu "bu hayotda emas" ustuvor vazifadir. Chipta yaratildi, biz ma'muriyat bo'limi boshlig'idan darhol javob oldik: "Siz ishlab chiqarish jurnallariga kirishga hojat yo'q, xatosiz yozing." Parda.

4 va undan keyingi harakat
Kutubxonalarning turli versiyalari, sozlanmagan dasturiy ta'minot, tayyorlanmagan server yuklari va boshqa muammolar tufayli biz ishlab chiqarishda hali ham o'nlab muammolarni to'playmiz. Albatta, kod xatolari ham mavjud, biz barcha gunohlar uchun administratorlarni ayblamaymiz, biz ushbu loyiha uchun yana bir odatiy operatsiyani eslatib o'tamiz. Bizda supervayzer orqali ishga tushirilgan juda ko'p fon ishchilari bor edi va ba'zi skriptlarni cronga qo'shish kerak edi. Ba'zida o'sha ishchilar ishlashni to'xtatdilar. Navbat serveridagi yuk chaqmoq tezligida o'sdi va qayg'uli foydalanuvchilar aylanayotgan yuklagichga qarashdi. Bunday ishchilarni tezda tuzatish uchun ularni qayta ishga tushirish kifoya edi, lekin yana buni faqat ma'mur qilish mumkin edi. Bunday asosiy operatsiya amalga oshirilayotganda, butun kun o'tishi mumkin edi. Bu erda, albatta, shuni ta'kidlash kerakki, egri dasturchilar ishchilarni qulab tushmasliklari uchun yozishlari kerak, lekin ular yiqilib tushganda, nima uchun ishlab chiqarishga kirish imkoni yo'qligi sababli ba'zan imkonsiz bo'lganini tushunish yaxshi bo'lar edi. albatta, va natijada ishlab chiquvchidan jurnallarning etishmasligi.

Transfiguratsiya.
Bularning barchasiga ancha vaqt chidaganimizdan so'ng, jamoa bilan birgalikda biz uchun muvaffaqiyatliroq bo'lgan yo'nalishni yo'naltira boshladik. Xulosa qilib aytganda, biz qanday muammolarga duch keldik?

  • Ishlab chiquvchilar va ma'muriyat bo'limi o'rtasida sifatli aloqa yo'qligi
  • Ma'lum bo'lishicha, ma'murlar (!), dastur qanday tuzilganligini, qanday bog'liqliklarga ega ekanligini va qanday ishlashini umuman tushunishmaydi.
  • Ishlab chiquvchilar ishlab chiqarish muhiti qanday ishlashini tushunmaydilar va natijada muammolarga samarali javob bera olmaydilar.
  • Joylashtirish jarayoni juda uzoq davom etadi.
  • Beqaror nashrlar.

Biz nima qildik?
Har bir reliz uchun Release Notes roʻyxati yaratildi, unda keyingi reliz ishlashi uchun serverda bajarilishi kerak boʻlgan ishlar roʻyxati kiritilgan. Ro'yxatda bir nechta bo'limlar, ma'mur, nashrga mas'ul shaxs va ishlab chiquvchi tomonidan bajarilishi kerak bo'lgan ishlar mavjud. Ishlab chiquvchilar barcha ishlab chiqarish serverlariga root bo'lmagan kirish huquqiga ega bo'lishdi, bu umuman rivojlanishni va ayniqsa muammolarni hal qilishni tezlashtirdi. Ishlab chiquvchilar, shuningdek, ishlab chiqarish qanday ishlashi, qanday xizmatlarga bo'linishi, replikatsiyalar qaerda va qancha turadi, degan tushunchaga ega. Ba'zi jangovar yuklar aniqroq bo'ldi, bu shubhasiz kodning sifatiga ta'sir qiladi. Chiqarish jarayonida aloqa tezkor messenjerlardan birining chatida sodir bo'ldi. Birinchidan, bizda barcha harakatlar jurnali bor edi, ikkinchidan, aloqa yaqinroq muhitda sodir bo'ldi. Harakatlar tarixiga ega bo'lish bir necha bor yangi xodimlarga muammolarni tezroq hal qilish imkonini berdi. Bu paradoks, lekin bu ko'pincha administratorlarning o'ziga yordam berdi. Men aniq aytishni o'z zimmasiga olmayman, lekin menimcha, administratorlar loyiha qanday ishlashini va qanday yozilishini ko'proq tushuna boshladilar. Ba'zida biz bir-birimiz bilan ba'zi tafsilotlarni baham ko'rardik. O'rtacha chiqish vaqti bir soatgacha qisqartirildi. Ba'zan biz 30-40 daqiqada tugatdik. Xatolar soni o'n barobar bo'lmasa, sezilarli darajada kamaydi. Albatta, avtotestlar kabi relizlar vaqtining qisqarishiga boshqa omillar ham ta'sir ko'rsatdi. Har bir nashrdan keyin biz retrospektivlarni o'tkazishni boshladik. Shunday qilib, butun jamoa nima yangilik, nima o'zgargan va nima olib tashlanganligi haqida tasavvurga ega bo'ladi. Afsuski, adminlar har doim ham ularga kelavermasdi, mana, adminlar band... Dasturchi sifatidagi ishimdan qoniqishim shubhasiz ortdi. O'zingizning vakolat sohangizdagi deyarli har qanday muammoni tezda hal qila olsangiz, o'zingizni yuqorida his qilasiz. Keyinchalik tushunaman, biz qaysidir ma'noda devops madaniyatini joriy qildik, albatta, to'liq emas, lekin transformatsiyaning o'sha boshlanishi ham ta'sirli edi.

Uchinchi hikoya
Ish boshlash. Bitta administrator, kichik rivojlanish bo'limi. Kelganimda men to'liq nol bo'laman, chunki ... Pochtadan boshqa joyga kirishim yo'q. Biz adminga yozamiz va kirishni so'raymiz. Bundan tashqari, u yangi xodim va login/parollarni berish zarurati haqida xabardor bo'lgan ma'lumotlar mavjud. Ular ombor va VPN dan kirish imkonini beradi. Nima uchun wiki, teamcity, rundesk-ga kirish huquqini berish kerak? Butun orqa qismni yozish uchun chaqirilgan odam uchun foydasiz narsalar. Vaqt o'tishi bilan biz ba'zi vositalarga kirish imkoniyatiga ega bo'lamiz. Kelishi, albatta, ishonchsizlik bilan qarshi oldi. Men chatlar va yetakchi savollar orqali loyiha infratuzilmasi qanday ishlashini asta-sekin his qilishga harakat qilyapman. Umuman olganda, men hech narsani tanimayman. Ishlab chiqarish avvalgidek qora quti. Ammo bundan ham ko'proq, hatto sinov uchun ishlatiladigan sahna serverlari ham qora qutidir. Biz u erda Git filialini joylashtirishdan boshqa hech narsa qila olmaymiz. Biz ilovamizni .env fayllari kabi sozlay olmaymiz. Bunday operatsiyalar uchun ruxsat berilmagan. Sinov serveridagi ilovangiz konfiguratsiyasida qatorni o'zgartirishni iltimos qilishingiz kerak. (Administratorlar o'zlarini loyihada muhim deb bilishlari juda muhim degan nazariya mavjud; agar ulardan konfiguratsiyadagi qatorlarni o'zgartirish so'ralmasa, ular shunchaki kerak bo'lmaydi). Xo'sh, har doimgidek, bu qulay emasmi? Bu tezda zerikarli bo'lib qoladi, administrator bilan to'g'ridan-to'g'ri suhbatdan so'ng, ishlab chiquvchilar yomon kod yozish uchun tug'ilganligini, tabiatan qobiliyatsiz shaxslar ekanligini va ularni ishlab chiqarishdan uzoqroq tutishini bilib olamiz. Lekin bu erda ham test serverlaridan, har holda. Mojaro tezda kuchayib bormoqda. Admin bilan aloqa yo'q. Uning yolg‘iz qolgani vaziyatni yanada og‘irlashtiradi. Quyidagi odatiy rasm. Chiqarish. Muayyan funksiyalar ishlamaydi. Nima bo'layotganini tushunish uchun bizga uzoq vaqt kerak bo'ladi, dasturchilarning turli g'oyalari chatga tashlanadi, ammo bunday vaziyatda administrator odatda ishlab chiquvchilar aybdor deb hisoblaydi. Keyin u chatda yozadi, kuting, men uni tuzatdim. Muammo nima bo'lganligi haqida ma'lumot bilan hikoya qoldirishni so'rashganda, biz zaharli bahonalarni olamiz. Masalan, burningizni tegishli bo'lmagan joyga yopishtirmang. Ishlab chiquvchilar kod yozishlari kerak. Loyihadagi ko'plab tana harakatlari bir kishi orqali o'tadi va faqat u hamma uchun zarur bo'lgan operatsiyalarni bajarishi mumkin bo'lgan vaziyat juda achinarli. Bunday odam dahshatli darboğazdir. Agar Devops g'oyalari bozorga chiqish vaqtini qisqartirishga intilsa, unda bunday odamlar Devops g'oyalarining eng ashaddiy dushmani hisoblanadi. Afsuski, bu erda parda yopiladi.

P.S. Odamlar bilan suhbatda ishlab chiquvchilar va administratorlar haqida bir oz gaplashgandan so'ng, men dardimni baham ko'rgan odamlarni uchratdim. Ammo bunaqasini hech qachon uchratmaganman, deganlar ham bor edi. Devops konferentsiyasida men Anton Isanindan (Alfa Bank) administratorlar shaklida muammoni qanday hal qilishlarini so'radim va u shunday dedi: "Biz ularni tugmalar bilan almashtirdik". Aytmoqchi podcast uning ishtiroki bilan. Men dushmanlardan ko'ra ko'proq yaxshi adminlar borligiga ishonishni istardim. Va ha, boshida rasm haqiqiy yozishmalardir.

Manba: www.habr.com

a Izoh qo'shish