Ma'lumki, CTOning malakasi bu rolni ikkinchi marta bajarganida sinovdan o'tkaziladi. Chunki kompaniyada bir necha yil ishlash, u bilan birga rivojlanish va bir xil madaniy kontekstda bo'lish, asta-sekin ko'proq mas'uliyatni olish boshqa narsa. Va to'g'ridan-to'g'ri kompaniyaning texnik direktori lavozimiga kirish butunlay boshqa narsa va gilam ostida tozalangan bir qancha muammolar bor.

Shu ma'noda, u baham ko'rgan Leon Fire tajribasi DevOpsConf, aniq noyob emas, balki uning tajribasi va 20 yil davomida sinab ko'rishga muvaffaq bo'lgan turli xil rollar soni bilan ko'paytirilishi juda foydali. Kesim ostida 90 kundan ortiq voqealar xronologiyasi va boshqa birov bilan sodir bo'lganda kulish qiziqarli bo'lgan, lekin shaxsan uchrashish unchalik qiziq bo'lmagan ko'plab hikoyalar keltirilgan.

Leon rus tilida juda rang-barang gapiradi, shuning uchun sizda 35-40 daqiqa bo'lsa, men videoni tomosha qilishni maslahat beraman. Quyida vaqtni tejash uchun matnli versiya.

Hisobotning birinchi versiyasi foydali tavsiyalarni o'z ichiga olgan odamlar va jarayonlar bilan ishlashning yaxshi tuzilgan tavsifi edi. Ammo u yo'lda duch kelgan barcha kutilmagan hodisalarni etkazmadi. Shuning uchun men formatni o'zgartirdim va yangi kompaniyadagi jack-in-thebox kabi oldimda paydo bo'lgan muammolarni va ularni xronologik tartibda hal qilish usullarini taqdim etdim.

Bir oy oldin

Ko'pgina yaxshi hikoyalar singari, bu ham spirtli ichimliklar bilan boshlangan. Biz do'stlarimiz bilan barda o'tirdik va IT mutaxassislari kutganidek, hamma o'z muammolari haqida yig'lardi. Ulardan biri hozirgina ish joyini o'zgartirib, texnologiya, odamlar va jamoa bilan bog'liq muammolari haqida gapirdi. Qanchalik ko'p tinglaganim sayin, u shunchaki meni ishga olishi kerakligini angladim, chunki bular men so'nggi 15 yil davomida hal qilgan muammolarim. Men unga aytdim va ertasi kuni biz ish muhitida uchrashdik. Kompaniya Teaching Strategies deb nomlangan.

O'qitish strategiyalari tug'ilishdan uch yoshgacha bo'lgan juda yosh bolalar uchun o'quv dasturlari bozorida etakchi hisoblanadi. An'anaviy "qog'oz" kompaniyasi allaqachon 40 yoshda, platformaning raqamli SaaS versiyasi esa 10 yoshda.Nisbatan yaqinda raqamli texnologiyalarni kompaniya standartlariga moslashtirish jarayoni boshlandi. "Yangi" versiya 2017 yilda ishga tushirildi va deyarli eskisiga o'xshardi, faqat u yomonroq ishladi.

Eng qizig'i shundaki, bu kompaniyaning trafigini juda oldindan aytish mumkin - kundan-kunga, yildan-yilga qancha odam kelishini va qachon kelishini juda aniq taxmin qilishingiz mumkin. Misol uchun, soat 13:15 dan XNUMX:XNUMX gacha bolalar bog'chalarining barcha bolalari uyquga ketishadi va o'qituvchilar ma'lumot kiritishni boshlaydilar. Va bu dam olish kunlaridan tashqari har kuni sodir bo'ladi, chunki dam olish kunlari deyarli hech kim ishlamaydi.

Bir oz oldinga qarab, men o'z ishimni turli sabablarga ko'ra qiziqarli bo'lgan eng yuqori yillik trafik davrida boshlaganimni ta'kidlayman.

2 yoshda bo'lgan platforma o'ziga xos stekga ega edi: 2008 yildan ColdFusion va SQL Server. ColdFusion, agar siz bilmasangiz va ehtimol siz bilmagan bo'lsangiz, 90-yillarning o'rtalarida paydo bo'lgan korporativ PHP bo'lib, o'shandan beri men bu haqda eshitmaganman. Bundan tashqari: Ruby, MySQL, PostgreSQL, Java, Go, Python. Lekin asosiy monolit ColdFusion va SQL Serverda ishlagan.

Muammolar

Kompaniya xodimlari bilan ish va qanday muammolarga duch kelganligi haqida qanchalik ko'p gaplashsam, muammolar nafaqat texnik xususiyatga ega ekanligini angladim. Xo'sh, texnologiya eski - va ular buning ustida ishlamadilar, lekin jamoada va jarayonlarda muammolar bor edi va kompaniya buni tushuna boshladi.

An'anaga ko'ra, ularning texniklari burchakda o'tirib, qandaydir ishlarni qilishdi. Ammo tobora ko'proq biznes raqamli versiyadan o'ta boshladi. Shuning uchun, men ish boshlashimdan oldingi so'nggi yilda kompaniyada yangilari paydo bo'ldi: direktorlar kengashi, CTO, CPO va QA direktori. Ya'ni, kompaniya texnologiya sohasiga sarmoya kirita boshladi.

Og'ir merosning izlari nafaqat tizimlarda edi. Kompaniyada meros jarayonlari, meros odamlari, meros madaniyati bor edi. Bularning barchasini o'zgartirish kerak edi. Bu, albatta, zerikarli bo'lmaydi, deb o'yladim va sinab ko'rishga qaror qildim.

Ikki kun oldin

Yangi ish boshlashdan ikki kun oldin men ofisga keldim, oxirgi hujjatlarni to'ldirdim, jamoa bilan uchrashdim va o'sha paytda jamoa muammo bilan kurashayotganini aniqladim. Bu sahifani yuklashning o'rtacha vaqti 4 soniyaga, ya'ni 2 martaga ko'tarildi.

Grafikga ko'ra, biror narsa aniq sodir bo'ldi va nima aniq emas. Ma’lum bo‘lishicha, muammo ma’lumotlar markazidagi tarmoqning kechikishida bo‘lgan: ma’lumotlar markazidagi 5 ms kechikish foydalanuvchilar uchun 2 soniyaga aylangan. Nima uchun bu sodir bo'lganini bilmasdim, lekin har qanday holatda ham muammo ma'lumotlar markazida ekanligi ma'lum bo'ldi.

Birinchi kun

Ikki kun o'tdi va ishning birinchi kunida muammo hal qilinmaganini angladim.

Ikki kun davomida foydalanuvchilarning sahifalari oʻrtacha 4 soniyada yuklangan. Muammo nima ekanligini topdilarmi, deb so'rayman.

- Ha, biz chipta ochdik.
- VA?
- Xo'sh, ular bizga hali javob berishmadi.

Keyin tushundimki, menga ilgari aytilganlarning barchasi men kurashishim kerak bo'lgan aysbergning kichik bir qismi edi.

Bunga juda mos keladigan yaxshi iqtibos bor:

"Ba'zan texnologiyani o'zgartirish uchun tashkilotni o'zgartirish kerak."

Ammo men yilning eng gavjum vaqtida ish boshlaganim uchun muammoni hal qilishning ikkala variantini ham ko'rib chiqishga majbur bo'ldim: tez va uzoq muddatli. Va hozir eng muhim narsadan boshlang.

Uchinchi kun

Shunday qilib, yuklash 4 soniya davom etadi va 13 dan 15 gacha eng katta cho'qqilar.

Uchinchi kuni ushbu vaqt oralig'ida yuklab olish tezligi quyidagicha edi:

Mening nuqtai nazarimdan, hech narsa ishlamadi. Boshqalarning fikricha, u odatdagidan biroz sekinroq ishlayotgan edi. Ammo bu shunchaki sodir bo'lmaydi - bu jiddiy muammo.

Men jamoani ishontirishga harakat qildim, ular ularga shunchaki ko'proq serverlar kerakligini aytishdi. Bu, albatta, muammoning yechimidir, lekin bu har doim ham yagona va eng samarali emas. Nega serverlar yetarli emasligini, trafik hajmi qandayligini so‘radim. Men ma'lumotlarni ekstrapolyatsiya qildim va bizda soniyada taxminan 150 ta so'rov borligini aniqladim, bu printsipial jihatdan oqilona chegaralarga to'g'ri keladi.

Ammo shuni unutmasligimiz kerakki, to'g'ri javob olishdan oldin, siz to'g'ri savol berishingiz kerak. Mening keyingi savolim: bizda nechta frontend server bor? "Meni biroz hayratda qoldirdi" degan javob - bizda 17 ta frontend server bor edi!

- Men so'rashga uyalaman, lekin 150 ni 17 ga bo'lish taxminan 8 ni beradi? Har bir server sekundiga 8 ta so'rovga ruxsat beradi, ertaga sekundiga 160 ta so'rov bo'lsa, bizga yana 2 ta server kerak bo'ladi, deyapsizmi?

Albatta, bizga qo'shimcha serverlar kerak emas edi. Yechim kodning o'zida va sirtda edi:

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

Funktsiya bor edi getCurrentClass(), chunki saytdagi hamma narsa sinf kontekstida ishlaydi - bu to'g'ri. Va buning uchun har bir sahifada bitta funktsiya mavjud edi 200 dan ortiq so'rovlar.

Bu yo'l bilan yechim juda oddiy edi, siz hech narsani qayta yozishingiz shart emas edi: shunchaki bir xil ma'lumotni qayta so'ramang.

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

Men juda xursand bo'ldim, chunki men uchinchi kuni asosiy muammoni topdim, deb qaror qildim. Men sodda bo'lsam ham, bu ko'p muammolardan biri edi.

Ammo bu birinchi muammoni hal qilish grafikni ancha pastga tushirdi.

Shu bilan birga, biz boshqa optimallashtirishlarni amalga oshirdik. Ko'z o'ngida tuzatilishi mumkin bo'lgan ko'p narsalar bor edi. Misol uchun, xuddi shu uchinchi kuni men tizimda kesh borligini aniqladim (dastlab barcha so'rovlar to'g'ridan-to'g'ri ma'lumotlar bazasidan keladi deb o'yladim). Kesh haqida o'ylaganimda, men standart Redis yoki Memcached haqida o'ylayman. Lekin men shunday deb o'ylagan yagona odam edim, chunki bu tizim keshlash uchun MongoDB va SQL Serverdan foydalangan - ma'lumotlar hozirgina o'qilgan.

O'ninchi kun

Birinchi haftada men hozir hal qilinishi kerak bo'lgan muammolar bilan shug'ullandim. Ikkinchi haftada qayerdadir, jamoa bilan muloqot qilish, nima bo'layotganini va butun jarayon qanday ketayotganini ko'rish uchun birinchi marta stendga keldim.

Yana bir qiziq narsa topildi. Jamoa tarkibiga quyidagilar kiradi: 18 ta dasturchi; 8 ta sinovchi; 3 ta menejer; 2 arxitektor. Va ularning barchasi umumiy marosimlarda ishtirok etishdi, ya'ni har kuni ertalab 30 dan ortiq kishi stendga kelib, nima qilganini aytib berishdi. Uchrashuv 5 yoki 15 daqiqa davom etmagani aniq. Hech kim hech kimni tinglamadi, chunki hamma turli xil tizimlarda ishlaydi. Ushbu shaklda, parvarish seansi uchun soatiga 2-3 chipta allaqachon yaxshi natija edi.

Biz qilgan birinchi narsa jamoani bir nechta mahsulot qatorlariga bo'lish edi. Turli bo'limlar va tizimlar uchun biz ishlab chiquvchilar, sinovchilar, mahsulot menejerlari va biznes tahlilchilaridan iborat alohida guruhlarni ajratdik.

Natijada biz oldik:

• Stend-up va mitinglarni kamaytirish.
• Mahsulot haqida mavzuni bilish.
• Egalik hissi. Odamlar doimo tizimlar bilan shug'ullanganlarida, ular o'zlari emas, balki boshqalar o'zlarining xatolari bilan ishlashlari kerakligini bilishgan.
• Guruhlar o'rtasidagi hamkorlik. Aytishga hojat yo'q, QA ilgari dasturchilar bilan ko'p muloqot qilmagan, mahsulot o'z ishini qilgan va hokazo. Endi ular umumiy mas'uliyat nuqtasiga ega.

Biz asosan samaradorlik, mahsuldorlik va sifatga e'tibor qaratdik - bu biz jamoani o'zgartirish bilan hal qilishga harakat qildik.

O'n birinchi kun

Jamoa tarkibini o'zgartirish jarayonida men qanday hisoblashni kashf qildim hikoyaballari. 1 SP bir kunga teng edi va har bir chiptada ham rivojlanish, ham QA uchun SP, ya'ni kamida 2 SP mavjud edi.

Buni qanday kashf qildim?

Biz xato topdik: hisobot kerak bo'lgan davrning boshlanish va tugash sanasi kiritilgan hisobotlarning birida oxirgi kun hisobga olinmaydi. Ya'ni, so'rovning biron bir joyida <= emas, balki oddiygina < bo'lgan. Menga aytishdiki, bu uchta hikoya nuqtasi, ya'ni 3 kun.

Shundan so'ng biz:

• Story Points reyting tizimi qayta ko'rib chiqildi. Endi tizim orqali tez o'tadigan kichik xatolar uchun tuzatishlar foydalanuvchiga tezroq etib boradi.
• Biz ishlab chiqish va sinov uchun tegishli chiptalarni birlashtira boshladik. Ilgari har bir chipta, har bir xato boshqa hech narsa bilan bog‘lanmagan yopiq ekotizim edi. Bitta sahifadagi uchta tugmani o'zgartirish har bir sahifada bitta avtomatlashtirilgan test o'rniga uch xil QA jarayoniga ega uchta turli chipta bo'lishi mumkin edi.
• Biz ishlab chiquvchilar bilan mehnat xarajatlarini baholash yondashuvi ustida ishlashni boshladik. Bitta tugmani o'zgartirish uchun uch kun kulgili emas.

Yigirmanchi kun

Birinchi oyning o'rtalarida bir joyda vaziyat biroz barqarorlashdi, men asosan nima bo'layotganini tushundim va allaqachon kelajakka qarashni va uzoq muddatli echimlar haqida o'ylashni boshladim.

Uzoq muddatli maqsadlar:

• Boshqariladigan platforma. Har bir sahifada yuzlab so'rovlar jiddiy emas.
• Bashorat qilinadigan tendentsiyalar. Vaqti-vaqti bilan tirbandlik cho'qqilari bor edi, ular birinchi qarashda boshqa ko'rsatkichlarga mos kelmaydi - biz nima uchun bu sodir bo'lganini tushunishimiz va bashorat qilishni o'rganishimiz kerak edi.
• Platformani kengaytirish. Biznes doimiy ravishda o'sib bormoqda, tobora ko'proq foydalanuvchilar kelmoqda va trafik ko'paymoqda.

Ilgari tez-tez aytilgan: "Keling, hamma narsani [tilda/ramkada] qayta yozaylik, hamma narsa yaxshiroq ishlaydi!"

Aksariyat hollarda bu ishlamaydi, agar qayta yozish umuman ishlasa yaxshi bo'ladi. Shuning uchun biz yo'l xaritasini - biznes maqsadlariga qanday erishishni bosqichma-bosqich ko'rsatuvchi aniq strategiyani yaratishimiz kerak edi (nima qilamiz va nima uchun), bu:

• loyihaning missiyasi va maqsadlarini aks ettiradi;
• asosiy maqsadlarga ustuvorlik beradi;
• ularga erishish jadvalini o'z ichiga oladi.

Bungacha hech kim jamoa bilan qandaydir o'zgarishlarning maqsadi haqida gapirmagan edi. Bu to'g'ri muvaffaqiyat ko'rsatkichlarini talab qiladi. Kompaniya tarixida birinchi marta biz texnik guruh uchun KPI o'rnatdik va bu ko'rsatkichlar tashkiliy ko'rsatkichlar bilan bog'liq edi.

Ya'ni, tashkiliy KPI jamoalar tomonidan qo'llab-quvvatlanadi va jamoa KPI individual KPI tomonidan qo'llab-quvvatlanadi. Aks holda, agar texnologik KPI tashkiliy bilan mos kelmasa, unda hamma adyolni o'ziga tortadi.

Masalan, tashkiliy KPIlardan biri yangi mahsulotlar orqali bozor ulushini oshirishdir.

Ko'proq yangi mahsulotlarga ega bo'lish maqsadini qanday qo'llab-quvvatlay olasiz?

• Birinchidan, biz kamchiliklarni tuzatish o'rniga yangi mahsulotlarni ishlab chiqishga ko'proq vaqt sarflamoqchimiz. Bu o'lchash oson bo'lgan mantiqiy yechim.
• Ikkinchidan, biz tranzaktsiyalar hajmini oshirishni qo'llab-quvvatlamoqchimiz, chunki bozor ulushi qancha ko'p bo'lsa, shuncha ko'p foydalanuvchilar va shunga mos ravishda trafik ko'payadi.

Keyin guruh ichida bajarilishi mumkin bo'lgan individual KPIlar, masalan, asosiy nuqsonlar paydo bo'lgan joyda bo'ladi. Agar siz ushbu bo'limga alohida e'tibor qaratsangiz, kamchiliklar kamroq ekanligiga ishonch hosil qilishingiz mumkin, keyin yangi mahsulotlarni ishlab chiqish va yana tashkiliy KPIlarni qo'llab-quvvatlash vaqti ko'payadi.

Shunday qilib, har bir qaror, shu jumladan kodni qayta yozish, kompaniya biz uchun qo'ygan aniq maqsadlarni (tashkiliy o'sish, yangi xususiyatlar, ishga yollash) qo'llab-quvvatlashi kerak.

Ushbu jarayon davomida qiziqarli narsa paydo bo'ldi, bu nafaqat texniklar uchun, balki umuman kompaniya uchun yangilik bo'ldi: barcha chiptalar kamida bitta KPIga yo'naltirilgan bo'lishi kerak. Ya'ni, agar mahsulot yangi xususiyat yaratmoqchi bo'lsa, birinchi savolni berish kerak: "Ushbu xususiyat qanday KPIni qo'llab-quvvatlaydi?" Agar yo'q bo'lsa, unda uzr - bu keraksiz xususiyatga o'xshaydi.

O'ttizinchi kun

Oyning oxirida men yana bir nuanceni topdim: mening Ops jamoasidagi hech kim mijozlar bilan tuzadigan shartnomalarimizni ko'rmagan. Siz nima uchun kontaktlarni ko'rishingiz kerakligini so'rashingiz mumkin.

• Birinchidan, chunki SLA shartnomalarda ko'rsatilgan.
• Ikkinchidan, SLAs hammasi boshqacha. Har bir mijoz o'z talablari bilan keldi va savdo bo'limi qaramasdan imzo chekdi.

Yana bir qiziqarli nuance shundaki, eng yirik mijozlardan biri bilan tuzilgan shartnomada platforma tomonidan qo'llab-quvvatlanadigan barcha dasturiy ta'minot versiyalari n-1 bo'lishi kerak, ya'ni oxirgi versiya emas, balki oxirgi versiya.

Agar platforma ColdFusion va SQL Server 1-ga asoslangan bo'lsa, iyul oyida umuman qo'llab-quvvatlanmaydigan bo'lsa, biz n-2008dan qanchalik uzoqda ekanligimiz aniq.

Qirq beshinchi kun

Taxminan ikkinchi oyning o'rtalarida men o'tirish va qilish uchun etarli vaqtga ega bo'ldim qiymatioqimxaritalash butun jarayon uchun to'liq. Bu mahsulotlarni yaratishdan tortib, uni iste'molchiga yetkazib berishgacha bo'lgan zarur qadamlar bo'lib, ular iloji boricha batafsil tavsiflanishi kerak.

Siz jarayonni kichik bo'laklarga bo'lasiz va nimaga juda ko'p vaqt kerakligini, nimani optimallashtirish, yaxshilash va hokazolarni ko'rasiz. Masalan, mahsulot so'rovi parvarishlashdan o'tishi uchun qancha vaqt ketadi, u qachon ishlab chiquvchi olishi mumkin bo'lgan chiptaga etadi, QA va hokazo. Shunday qilib, siz har bir qadamni batafsil ko'rib chiqasiz va nimani optimallashtirish mumkinligi haqida o'ylaysiz.

Buni qilganimda, ikkita narsa e'tiborimni tortdi:

• QA dan ishlab chiquvchilarga qaytarilgan chiptalarning yuqori foizi;
• tortish so'rovini ko'rib chiqish juda uzoq davom etdi.

Muammo shundaki, bu shunday xulosalar edi: Bu ko'p vaqt talab qiladiganga o'xshaydi, lekin biz qancha vaqt ketishini bilmaymiz.

"Siz o'lchay olmaydigan narsani yaxshilay olmaysiz."

Muammo qanchalik jiddiy ekanligini qanday oqlash mumkin? Kunlar yoki soatlar behuda ketadimi?

Buni o'lchash uchun biz Jira jarayoniga bir nechta qadamlarni qo'shdik: har bir chipta qancha vaqt kutishini va ma'lum bir bosqichga necha marta qaytishini o'lchash uchun "ishlab chiqishga tayyor" va "QA uchun tayyor".

Ko'rib chiqish uchun o'rtacha qancha chipta borligini bilish uchun biz "ko'rib chiqish" ni ham qo'shdik va bundan siz raqsga tushishni boshlashingiz mumkin. Bizda tizim ko'rsatkichlari bor edi, endi biz yangi ko'rsatkichlarni qo'shdik va o'lchashni boshladik:

• Jarayon samaradorligi: ishlash va rejalashtirilgan/etkazib berilgan.
• Jarayon sifati: nuqsonlar soni, QA dan nuqsonlar.

Bu, albatta, nima yaxshi va nima yaxshi emasligini tushunishga yordam beradi.

Ellikinchi kun

Bularning barchasi, albatta, yaxshi va qiziqarli, lekin ikkinchi oyning oxiriga kelib, men bunday miqyosni kutmagan bo'lsam ham, aslida oldindan aytib bo'ladigan narsa yuz berdi. Yuqori rahbariyat o‘zgargani uchun odamlar keta boshladi. Boshqaruvga yangi odamlar kirib, hamma narsani o'zgartirishni boshladilar, eskilari esa ishdan ketishdi. Va odatda bir necha yillik kompaniyada hamma do'st va hamma bir-birini taniydi.

Bu kutilgan edi, ammo ishdan bo'shatish ko'lami kutilmagan edi. Misol uchun, bir hafta ichida bir vaqtning o'zida ikkita jamoa etakchisi o'z xohishi bilan iste'foga chiqish haqida ariza berdi. Shuning uchun men nafaqat boshqa muammolarni unutishim, balki e'tiborimni qaratishim kerak edi jamoa yaratish. Bu hal qilish uchun uzoq va qiyin muammo, lekin uni hal qilish kerak edi, chunki men qolgan odamlarni (yoki ularning ko'pchiligini) qutqarishni xohlardim. Jamoada ruhiy holatni saqlab qolish uchun odamlarning ketishiga qandaydir tarzda munosabat bildirish kerak edi.

Nazariy jihatdan, bu yaxshi: to'liq kart-blanshga ega bo'lgan, jamoaning mahoratini baholay oladigan va xodimlarni almashtira oladigan yangi odam keladi. Darhaqiqat, siz ko'p sabablarga ko'ra yangi odamlarni olib kela olmaysiz. Muvozanat har doim kerak.

• Eski va yangi. Missiyani o'zgartira oladigan va qo'llab-quvvatlay oladigan keksa odamlarni saqlashimiz kerak. Ammo ayni paytda biz yangi qonni olib kelishimiz kerak, bu haqda biroz keyinroq gaplashamiz.
• Tajriba. Men ishtiyoqi baland va biz bilan ishlashni istagan yaxshi o'smirlar bilan ko'p gaplashdim. Ammo men ularni qabul qila olmadim, chunki o'smirlarni qo'llab-quvvatlash va ularga murabbiylik qilish uchun kattalar etishmadi. Avval yuqori, keyin esa yoshlarni jalb qilish kerak edi.
• Sabzi va tayoq.

To'g'ri muvozanat nima, uni qanday saqlash kerak, qancha odamni ushlab turish va qancha turtki berish kerak degan savollarga yaxshi javobim yo'q. Bu mutlaqo individual jarayon.

Ellik birinchi kun

Men kimligimni tushunish uchun jamoaga diqqat bilan qaray boshladim va yana bir bor esladim:

"Ko'p muammolar odamlarning muammolaridir."

Men jamoada - Dev va Opsda uchta katta muammo borligini aniqladim:

• Ishlarning hozirgi holatidan qoniqish.
• Mas'uliyatning yo'qligi - chunki hech kim biznesga ta'sir qilish uchun ijrochilarning ishining natijalarini keltirmagan.
• O'zgarish qo'rquvi.

O'zgarish sizni har doim o'zingizning konfor zonangizdan olib chiqadi va yoshlar qanchalik yosh bo'lsa, ular o'zgarishlarni shunchalik yoqtirmaydilar, chunki ular nima uchun va qanday qilib tushunishmaydi. Men eshitgan eng keng tarqalgan javob: "Biz hech qachon bunday qilmaganmiz". Bundan tashqari, u butunlay bema'nilik darajasiga yetdi - eng kichik o'zgarishlar kimdir g'azablanmasdan sodir bo'lishi mumkin emas edi. O'zgarishlar ularning ishiga qanchalik ta'sir qilmasin, odamlar: "Yo'q, nega? Bu ishlamaydi."

Ammo hech narsani o'zgartirmasdan yaxshilana olmaysiz.

Men bir xodim bilan mutlaqo bema'ni suhbatlashdim, men unga optimallashtirish bo'yicha g'oyalarimni aytdim, u menga aytdi:
- Oh, o'tgan yili bizda nima borligini ko'rmadingiz!
- Nima bo'libdi?
"Endi u avvalgidan ancha yaxshi."
- Xo'sh, bundan ham yaxshiroq bo'lishi mumkin emasmi?
- Nima sababdan?

Yaxshi savol - nega? Go'yo hozir avvalgidan yaxshiroq, keyin hamma narsa etarli. Bu mas'uliyatning etishmasligiga olib keladi, bu printsipial jihatdan mutlaqo normaldir. Aytganimdek, texnik guruh biroz chetda edi. Kompaniya ular mavjud bo'lishi kerakligiga ishongan, ammo hech kim hech qachon standartlarni o'rnatmagan. Texnik qo'llab-quvvatlash hech qachon SLAni ko'rmagan, shuning uchun bu guruh uchun juda "maqbul" edi (va bu menga eng ko'p ta'sir qildi):

• 12 soniya yuklash;
• Har bir relizda 5-10 daqiqa uzilish;
• Muhim muammolarni bartaraf etish kunlar va haftalar davom etadi;
• 24x7 / chaqiruv bo'yicha navbatchi xodimlarning etishmasligi.

Hech kim hech qachon nima uchun biz buni yaxshiroq qilmaymiz deb so'rashga urinmagan va hech kim bu shunday bo'lishi shart emasligini tushunmagan.

Bonus sifatida yana bir muammo bor edi: tajriba etishmasligi. Kattalar ketishdi, qolgan yosh jamoa esa avvalgi tuzum davrida ulg‘ayib, undan zaharlanishdi.

Buning ustiga, odamlar muvaffaqiyatsizlikka uchraganidan, qobiliyatsiz bo'lib ko'rinishidan ham qo'rqishgan. Bu, birinchi navbatda, ularda ifodalanadi hech qanday holatda yordam so'ramagan. Biz necha marta guruh va yakka tartibda gaplashdik va men: "Agar biror narsa qilishni bilmasangiz, savol bering" dedim. Men o'zimga ishonaman va har qanday muammoni hal qila olishimni bilaman, lekin bu vaqt talab etadi. Shuning uchun, 10 daqiqada qanday hal qilishni biladigan odamdan so'rasam, so'rayman. Qanchalik kam tajribaga ega bo'lsangiz, so'rashdan shunchalik qo'rqasiz, chunki siz o'zingizni qobiliyatsiz deb hisoblaysiz.

Savol berishdan qo'rqish o'zini qiziqarli yo'llar bilan namoyon qiladi. Masalan, siz: "Bu vazifani qanday bajaryapsiz?" - "Bir necha soat qoldi, men allaqachon tugatyapman." Ertasi kuni yana so'raysiz, hammasi joyida degan javob olasiz, lekin bitta muammo bor edi, kun oxirigacha albatta tayyor bo'ladi. Yana bir kun o'tadi va siz devorga mahkam ushlanib, kimdir bilan gaplashishga majbur bo'lguningizcha, bu davom etadi. Inson muammoni o'zi hal qilishni xohlaydi, agar u buni o'zi hal qilmasa, bu katta muvaffaqiyatsizlik bo'lishiga ishonadi.

Shuning uchun ham ishlab chiquvchilar taxminlarni oshirib yuborishdi. Aynan o'sha anekdot edi, ular ma'lum bir vazifani muhokama qilishganda, ular menga shunday raqam berishdiki, men juda hayron bo'ldim. Menga aytilishicha, ishlab chiquvchining hisob-kitoblariga ko'ra, ishlab chiquvchi chipta QA dan qaytariladigan vaqtni o'z ichiga oladi, chunki ular u erda xatolar topadilar, PR uchun vaqt va ko'rib chiqishlari kerak bo'lgan vaqt. u band bo'ladi - ya'ni hamma narsa , mumkin bo'lgan narsa.

Ikkinchidan, qobiliyatsiz ko'rinishdan qo'rqadigan odamlar ortiqcha tahlil qilish. Aniq nima qilish kerakligini aytsangiz, u boshlanadi: "Yo'q, agar biz bu haqda o'ylasak nima bo'ladi?" Shu ma'noda bizning kompaniyamiz yagona emas, bu yoshlar uchun standart muammodir.

Bunga javoban men quyidagi amaliyotlarni joriy qildim:

• Qoida 30 daqiqa. Agar yarim soat ichida muammoni hal qila olmasangiz, kimdirdan yordam so'rang. Bu turli darajadagi muvaffaqiyat bilan ishlaydi, chunki odamlar hali ham so'ramaydilar, lekin hech bo'lmaganda jarayon boshlandi.
• Mohiyatdan tashqari hamma narsani yo'q qiling, vazifani bajarish muddatini taxmin qilishda, ya'ni kodni yozish uchun qancha vaqt ketishini hisobga oling.
• Doimiy o'rganish ortiqcha tahlil qiladiganlar uchun. Bu shunchaki odamlar bilan doimiy ishlash.

Oltmishinchi kun

Bularning barchasini bajarayotganimda, byudjetni aniqlash vaqti keldi. Albatta, men pulimizni qayerga sarflaganimiz haqida juda ko'p qiziqarli narsalarni topdim. Misol uchun, bizda bitta FTP serveri bo'lgan alohida ma'lumotlar markazida butun raf bor edi, undan bitta mijoz foydalanadi. Ma'lum bo'lishicha, "... biz ko'chdik, lekin u shunday qoldi, biz uni o'zgartirmadik". 2 yil oldin edi.

Bulutli xizmatlar uchun qonun loyihasi alohida qiziqish uyg'otdi. O'ylaymanki, yuqori bulutli to'lovning asosiy sababi hayotlarida birinchi marta serverlarga cheksiz kirish huquqiga ega bo'lgan ishlab chiquvchilardir. Ular: "Iltimos, menga test serverini bering", deb so'rashlari shart emas, ular buni o'zlari olishlari mumkin. Bundan tashqari, ishlab chiquvchilar har doim shunday ajoyib tizim yaratishni xohlashadiki, Facebook va Netflix hasad qiladi.

Ammo ishlab chiquvchilarda serverlarni sotib olish tajribasi va serverlarning kerakli hajmini aniqlash mahorati yo'q, chunki ular ilgari bunga muhtoj emas edilar. Va ular odatda miqyoslilik va ishlash o'rtasidagi farqni tushunmaydilar.

Inventarizatsiya natijalari:

• Biz xuddi shu ma'lumotlar markazini tark etdik.
• Biz 3 ta log xizmati bilan shartnomani bekor qildik. Chunki bizda ulardan 5 tasi bor edi - biror narsa bilan o'ynashni boshlagan har bir dasturchi yangisini oldi.
• 7 ta AWS tizimi yopildi. Shunga qaramay, hech kim o'lik loyihalarni to'xtatmadi, ularning barchasi ishlashda davom etdilar.
• Dasturiy ta'minot narxi 6 baravar kamaytirildi.

Yetmish beshinchi kun

Vaqt o'tdi va ikki yarim oy ichida men direktorlar kengashi bilan uchrashishga majbur bo'ldim. Bizning direktorlar kengashimiz boshqalardan yaxshiroq yoki yomon emas; barcha direktorlar kengashlari kabi u hamma narsani bilishni xohlaydi. Odamlar pul investitsiya qilishadi va biz qilayotgan ishimiz belgilangan KPIlarga qanchalik mos kelishini tushunishni xohlashadi.

Direktorlar kengashi har oyda juda ko'p ma'lumot oladi: foydalanuvchilar soni, ularning o'sishi, qanday xizmatlardan foydalanishi va qanday ishlashi, unumdorligi va unumdorligi va nihoyat, sahifani o'rtacha yuklash tezligi.

Yagona muammo shundaki, men o'rtacha sof yovuzlik ekanligiga ishonaman. Lekin buni direktorlar kengashiga tushuntirish juda qiyin. Ular, masalan, soniyada yuklanish vaqtlarining tarqalishi emas, balki yig'ilgan raqamlar bilan ishlashga odatlangan.

Bu borada qiziqarli fikrlar bor edi. Masalan, men trafikni kontent turiga qarab alohida veb-serverlar o'rtasida taqsimlashimiz kerakligini aytdim.

Ya'ni, ColdFusion Jetty va nginx orqali o'tadi va sahifalarni ishga tushiradi. Rasmlar, JS va CSS o'z konfiguratsiyasi bilan alohida nginx orqali o'tadi. Bu men aytayotgan juda standart amaliyot yozgan bir necha yil oldin. Natijada, rasmlar ancha tez yuklanadi va... o'rtacha yuklash tezligi 200 ms ga oshdi.

Bu grafik Jetty bilan birga kelgan ma'lumotlar asosida qurilganligi sababli sodir bo'ldi. Ya'ni, tezkor tarkib hisob-kitobga kiritilmagan - o'rtacha qiymat sakrab chiqdi. Bu biz uchun tushunarli edi, biz kuldik, lekin direktorlar kengashiga nima uchun nimadir qilganimizni va ishlar 12% ga yomonlashganini qanday tushuntirish mumkin?

Sakson beshinchi kun

Uchinchi oyning oxirida men umuman hisoblamagan bitta narsa borligini angladim: vaqt. Men aytgan hamma narsa vaqt talab etadi.

Bu mening haqiqiy haftalik kalendarim - shunchaki ish haftasi, unchalik band emas. Hamma narsaga vaqt yetarli emas. Shuning uchun, yana, muammolarni engishda sizga yordam beradigan odamlarni yollashingiz kerak.

xulosa

Bu hammasi emas. Ushbu hikoyada men mahsulot bilan qanday ishlaganimizni va umumiy to'lqinga moslashishga harakat qilganimizni, texnik yordamni qanday birlashtirganimizni yoki boshqa texnik muammolarni qanday hal qilganimizni bilmadim. Masalan, men ma'lumotlar bazasidagi eng katta jadvallarda biz foydalanmasligimizni tasodifan bilib oldim SEQUENCE. Bizda o'z-o'zidan yozilgan funktsiya mavjud nextID, va u tranzaksiyada ishlatilmaydi.

Biz uzoq vaqt gaplashishimiz mumkin bo'lgan millionlab shunga o'xshash narsalar bor edi. Lekin hali aytish kerak bo'lgan eng muhim narsa - bu madaniyat.

Madaniyat yoki uning etishmasligi barcha boshqa muammolarga olib keladi. Biz odamlar quyidagi madaniyatni yaratishga harakat qilmoqdamiz:

• muvaffaqiyatsizliklardan qo'rqmang;
• xatolardan o'rganish;
• boshqa jamoalar bilan hamkorlik qilish;
• tashabbus ko'rsatish;
• mas'uliyatni o'z zimmasiga olish;
• natijani maqsad sifatida qabul qilish;
• muvaffaqiyatni nishonlash.

Shu bilan hamma narsa keladi.

Leon Fire twitterda, facebook va o'rta.

Meros bilan bog'liq ikkita strategiya mavjud: har qanday holatda ham u bilan ishlashdan qoching yoki bog'liq qiyinchiliklarni jasorat bilan enging. Biz c DevOpsConf Biz jarayon va yondashuvlarni o‘zgartirib, ikkinchi yo‘ldan bormoqdamiz. Bizga qo'shiling youtube, pochta ro'yxati и telegramma, va birgalikda biz DevOps madaniyatini amalga oshiramiz.

Manba: www.habr.com