КТО-ның құзыреті бұл қызметті екінші рет атқарғанда ғана тексерілетіні белгілі. Өйткені компанияда бірнеше жыл жұмыс істеу, онымен бірге даму және бір мәдени контексте бола отырып, бірте-бірте көбірек жауапкершілік алу бір нәрсе. Бұрынғы жүгі бар және кілемнің астынан сыпырылған көптеген проблемалары бар компанияның техникалық директоры лауазымына тікелей келу - бұл мүлдем басқа.

Осы тұрғыдан алғанда, ол бөліскен Леон Файр тәжірибесі DevOpsConf, дәл бірегей емес, бірақ оның тәжірибесі мен 20 жыл ішінде сынап көрген әртүрлі рөлдердің санына байланысты бұл өте пайдалы. Кесектің астында 90 күннен астам оқиғалардың хронологиясы және олар басқа біреумен болған кезде күлетін, бірақ бетпе-бет жүздесу соншалықты қызықты емес көптеген оқиғалар бар.

Леон орыс тілінде өте түрлі-түсті сөйлейді, сондықтан сізде 35-40 минут болса, бейнені көруге кеңес беремін. Төмендегі уақытты үнемдеу үшін мәтіндік нұсқа.

Есептің бірінші нұсқасы пайдалы ұсыныстарды қамтитын адамдармен және процестермен жұмыс істеудің жақсы құрылымдалған сипаттамасы болды. Бірақ ол жолда кездескен барлық тосын сыйларды жеткізбеді. Сондықтан мен форматты өзгертіп, жаңа компаниядағы ұяшық сияқты алдымда пайда болған мәселелерді және оларды хронологиялық тәртіпте шешу әдістерін ұсындым.

Бір ай бұрын

Көптеген жақсы әңгімелер сияқты, бұл да алкогольден басталды. Біз достарымызбен барда отырдық, ал IT мамандары күткендей, барлығы өз проблемаларын айтып жылап жатты. Олардың бірі жаңа ғана жұмысын ауыстырып, технологиямен, адамдармен және командамен проблемалары туралы айтып жатты. Мен тыңдаған сайын оның мені жұмысқа алуы керек екенін түсіндім, өйткені бұл менің соңғы 15 жыл бойы шешіп келе жатқан мәселелердің түрлері. Мен оған айттым, ал келесі күні біз жұмыс ортасында кездестік. Компания оқыту стратегиялары деп аталды.

Teaching Strategies - туғаннан үш жасқа дейінгі өте кішкентай балаларға арналған оқу бағдарламалары нарығында көшбасшы. Дәстүрлі «қағаз» компаниясы 40 жаста, ал платформаның цифрлық SaaS нұсқасына 10 жыл. Салыстырмалы түрде жақында цифрлық технологияны компания стандарттарына бейімдеу процесі басталды. «Жаңа» нұсқасы 2017 жылы іске қосылды және ескі нұсқаға ұқсас болды, тек ол нашар жұмыс істеді.

Ең қызығы, бұл компанияның трафигі өте болжамды - күннен күнге, жылдан жылға қанша адам келетінін және қашан келетінін нақты болжауға болады. Мысалы, сағат 13-ден 15-ге дейін балабақшадағы барлық балалар ұйықтайды, ал мұғалімдер ақпарат енгізе бастайды. Және бұл демалыс күндерін қоспағанда, күн сайын болады, өйткені демалыс күндері дерлік ешкім жұмыс істемейді.

Біраз алға қарай, мен өз жұмысымды әртүрлі себептермен қызықты болатын ең жоғары жылдық трафик кезеңінде бастағанымды атап өткім келеді.

Небәрі 2 жаста болған платформаның өзіндік стекі болды: 2008 жылғы ColdFusion және SQL Server. ColdFusion, егер сіз білмесеңіз және сіз білмесеңіз, бұл 90-жылдардың ортасында шыққан кәсіпорын PHP, содан бері мен бұл туралы естіген де емеспін. Сондай-ақ болды: Ruby, MySQL, PostgreSQL, Java, Go, Python. Бірақ негізгі монолит ColdFusion және SQL серверінде жұмыс істеді.

проблемалар

Мен компания қызметкерлерімен жұмыс туралы және қандай проблемалар туындағаны туралы көбірек сөйлескен сайын, проблемалар тек техникалық сипатта емес екенін түсіндім. Жарайды, технология ескі - және олар онымен жұмыс істемеді, бірақ командада және процестерде проблемалар болды және компания мұны түсіне бастады.

Дәстүр бойынша олардың техниктері бұрышта отырып, қандай да бір жұмыстарды атқарды. Бірақ көбірек бизнес цифрлық нұсқадан өте бастады. Сондықтан мен жұмыс істей бастағанға дейін соңғы жылы компанияда жаңалары пайда болды: директорлар кеңесі, CTO, CPO және QA директоры. Яғни, компания технология саласына инвестиция сала бастады.

Ауыр мұраның іздері тек жүйелерде болған жоқ. Компанияның бұрынғы процестері, мұрагерлері, мұра мәдениеті болды. Мұның бәрін өзгерту керек болды. Мен бұл скучно емес деп ойладым және оны сынап көруді шештім.

Екі күн бұрын

Жаңа жұмысқа кірісуге екі күн қалғанда мен кеңсеге келіп, соңғы құжаттарды толтырдым, командамен кездестім және команданың сол кездегі мәселемен күресіп жатқанын білдім. Бұл бетті жүктеудің орташа уақыты 4 секундқа, яғни 2 есеге секірді.

Графикке қарағанда, бірдеңе болғаны анық және не екені белгісіз. Мәселе деректер орталығындағы желінің кешігуінде болып шықты: деректер орталығындағы 5 мс кідіріс пайдаланушылар үшін 2 секундқа айналды. Мен мұның неліктен болғанын білмедім, бірақ кез келген жағдайда мәселе деректер орталығында екені белгілі болды.

Бірінші күн

Екі күн өтті, мен жұмыстың бірінші күнінде мәселенің шешілмегенін білдім.

Екі күн ішінде пайдаланушылардың беттері орташа есеппен 4 секундта жүктелді. Мен олар мәселенің не екенін тапты ма деп сұраймын.

- Иә, біз билетті аштық.
- ЖӘНЕ?
– Е, олар бізге әлі жауап берген жоқ.

Содан кейін мен бұрын айтылғандардың бәрі мен күресуге тура келетін айсбергтің кішкене бір ұшы ғана екенін түсіндім.

Бұған өте жақсы сәйкес келетін жақсы дәйексөз бар:

«Кейде технологияны өзгерту үшін ұйымды өзгертуге тура келеді».

Бірақ мен жұмысты жылдың ең қарбалас уақытында бастағандықтан, мәселені шешудің екі нұсқасын да қарастыруға тура келді: жылдам және ұзақ мерзімді. Және дәл қазір маңызды нәрседен бастаңыз.

Үшінші күні

Сонымен, жүктеу 4 секундқа созылады, ал 13-тен 15-ке дейін ең үлкен шыңдар.

Осы уақыт аралығындағы үшінші күні жүктеу жылдамдығы келесідей болды:

Менің көзқарасым бойынша, ештеңе жұмыс істемеді. Басқалардың көзқарасы бойынша ол әдеттегіден сәл баяу жұмыс істеді. Бірақ олай болмайды - бұл күрделі мәселе.

Мен команданы сендіруге тырыстым, олар оларға көбірек серверлер қажет деп жауап берді. Бұл, әрине, мәселенің шешімі, бірақ бұл әрқашан жалғыз және ең тиімді емес. Неліктен серверлер жеткіліксіз, трафик көлемі қандай деп сұрадым. Мен деректерді экстраполяцияладым және бізде секундына шамамен 150 сұрау бар екенін анықтадым, бұл негізінен ақылға қонымды шектеулерге сәйкес келеді.

Бірақ дұрыс жауап алмас бұрын, дұрыс сұрақ қою керектігін ұмытпауымыз керек. Менің келесі сұрағым: бізде қанша фронт-сервер бар? Жауап «мені аздап таң қалдырды» - бізде 17 интерфейс сервері болды!

— Мен сұрауға ұяламын, бірақ 150-ні 17-ге бөлгенде шамамен 8 шығады ма? Әр сервер секундына 8 сұранысқа мүмкіндік береді, ал ертең секундына 160 сұраныс болса, бізге тағы 2 сервер керек болады дейсіз бе?

Әрине, бізге қосымша серверлер қажет емес еді. Шешім кодтың өзінде және бетінде болды:

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

Функция болды getCurrentClass(), өйткені сайттағы барлық нәрсе сынып контекстінде жұмыс істейді - бұл дұрыс. Бұл үшін әр бетте бір функция болды 200+ сұраныс.

Шешім осылайша өте қарапайым болды, тіпті ештеңені қайта жазудың қажеті жоқ еді: тек сол ақпаратты қайта сұрамаңыз.

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

Мен өте қуаныштымын, өйткені мен негізгі мәселені үшінші күні таптым деп шештім. Мен аңғал болсам да, бұл көп мәселелердің бірі ғана еді.

Бірақ бұл бірінші мәселені шешу графикті әлдеқайда төмен түсірді.

Сонымен қатар, біз басқа да оңтайландырулар жасадық. Түзетілетін дүниелер көп болды. Мысалы, сол үшінші күні мен жүйеде кэш бар екенін білдім (бастапқыда мен барлық сұраулар тікелей дерекқордан келеді деп ойладым). Мен кэш туралы ойлағанда, мен стандартты Redis немесе Memcached туралы ойлаймын. Бірақ мен ғана солай ойладым, өйткені бұл жүйе кэштеу үшін MongoDB және SQL серверін пайдаланды - деректер жаңа ғана оқылған.

Он күн

Бірінші аптада мен дәл қазір шешуді қажет ететін мәселелермен айналыстым. Екінші аптаның бір жерінде мен командамен сөйлесу, не болып жатқанын және бүкіл процестің қалай өтіп жатқанын көру үшін бірінші рет стендке келдім.

Тағы бір қызық нәрсе табылды. Команда құрамында: 18 әзірлеуші; 8 тестілеуші; 3 менеджер; 2 сәулетші. Және олардың барлығы ортақ рәсімдерге қатысты, яғни 30-дан астам адам күн сайын таңертең стендке шығып, не істегендерін айтты. Кездесу 5-15 минутқа созылмағаны анық. Ешкім ешкімді тыңдамады, өйткені әркім әртүрлі жүйелерде жұмыс істейді. Бұл пішінде күтім сеансына сағатына 2-3 билет қазірдің өзінде жақсы нәтиже болды.

Біз жасаған бірінші нәрсе команданы бірнеше өнім желісіне бөлу болды. Әртүрлі бөлімдер мен жүйелер үшін әзірлеушілер, сынақшылар, өнім менеджерлері және бизнес-сарапшылар кіретін жеке топтар бөлдік.

Нәтижесінде біз алдық:

• Тікелей көтерілулер мен митингілерді азайту.
• Өнім туралы пәндік білім.
• Меншік сезімі. Адамдар үнемі жүйелермен айналысқанда, олар басқа біреудің қателерімен жұмыс істеуі мүмкін екенін біледі, бірақ өздері емес.
• Топтар арасындағы ынтымақтастық. Айта кету керек, QA бұрын бағдарламашылармен көп араласпаған, өнім өз жұмысын жасады және т.б. Енді олардың ортақ жауапкершілігі бар.

Біз негізінен тиімділікке, өнімділікке және сапаға назар аудардық - бұл команданы өзгерту арқылы шешуге тырысқан мәселелер.

Он бірінші күн

Топ құрылымын өзгерту барысында мен санауды білдім әңгімеPoints. 1 SP бір күнге тең болды және әрбір билетте әзірлеу үшін де, QA үшін де SP, яғни кемінде 2 SP болды.

Мен мұны қалай таптым?

Біз қатені таптық: есеп қажет кезеңнің басталу және аяқталу күні енгізілген есептердің бірінде соңғы күн ескерілмейді. Яғни, сұраудың бір жерінде <= емес, жай < болды. Маған бұл үш оқиғаның нүктесі екенін айтты, яғни 3 күн.

Осыдан кейін біз:

• Story Points бағалау жүйесі қайта қаралды. Енді жүйе арқылы жылдам өтуге болатын кішігірім қателерді түзету пайдаланушыға жылдамырақ жетеді.
• Біз әзірлеу және тестілеу үшін тиісті билеттерді біріктіре бастадық. Бұрын әрбір билет, әрбір қате басқа ештеңеге байланбаған жабық экожүйе болатын. Бір беттегі үш түймені өзгерту бір бетте бір автоматтандырылған сынақтың орнына үш түрлі QA процесі бар үш түрлі билет болуы мүмкін.
• Біз әзірлеушілермен еңбек шығындарын бағалау тәсілі бойынша жұмыс істей бастадық. Бір түймені өзгерту үшін үш күн күлкілі емес.

Жиырмасыншы күн

Бірінші айдың ортасында жағдай біршама тұрақтанды, мен не болып жатқанын түсіндім және болашаққа қарап, ұзақ мерзімді шешімдер туралы ойлана бастадым.

Ұзақ мерзімді мақсаттар:

• Управляемая платформа. Әр беттегі жүздеген өтініштер маңызды емес.
• Болжамды тенденциялар. Бір қарағанда басқа көрсеткіштермен сәйкес келмейтін мерзімді трафик шыңдары болды - біз бұл неліктен болғанын түсініп, болжауды үйренуіміз керек еді.
• Платформаны кеңейту. Бизнес үнемі өсіп келеді, пайдаланушылар көбейіп келеді және трафик артып келеді.

Бұрындары жиі айтатын: «Бәрін [тілде/рамкада] қайта жазайық, бәрі жақсы жұмыс істейді!»

Көп жағдайда бұл жұмыс істемейді, егер қайта жазу мүлдем жұмыс істесе жақсы. Сондықтан бізге бизнес мақсаттарына қалай қол жеткізілетінін кезең-кезеңмен бейнелейтін нақты стратегия – жол картасын жасау қажет болды (біз не істейміз және неге), ол:

• жобаның миссиясы мен мақсаттарын көрсетеді;
• негізгі мақсаттарға басымдық береді;
• оларға қол жеткізу кестесін қамтиды.

Бұған дейін ешкім командамен қандай да бір өзгерістердің мақсаты туралы сөйлескен жоқ. Бұл дұрыс табыс көрсеткіштерін қажет етеді. Компания тарихында бірінші рет біз техникалық топ үшін KPI белгіледік және бұл көрсеткіштер ұйымдастырушылық көрсеткіштермен байланысты болды.

Яғни, ұйымдық KPI командалар, ал командалық KPI жеке KPI қолдау көрсетеді. Әйтпесе, егер технологиялық KPI ұйымдастырушылықтармен сәйкес келмесе, онда әркім көрпені өзіне тартады.

Мысалы, ұйымдық KPI көрсеткіштерінің бірі жаңа өнімдер арқылы нарық үлесін арттыру болып табылады.

Жаңа өнімдерді көбейту мақсатын қалай қолдай аласыз?

• Біріншіден, біз ақауларды жөндеудің орнына жаңа өнімдерді әзірлеуге көбірек уақыт бөлгіміз келеді. Бұл өлшеуге оңай логикалық шешім.
• Екіншіден, біз транзакция көлемінің ұлғаюын қолдағымыз келеді, өйткені нарық үлесі неғұрлым көп болса, соғұрлым көп пайдаланушылар және сәйкесінше трафик көбейеді.

Сонда топ ішінде орындауға болатын жеке KPI, мысалы, негізгі ақаулар пайда болған жерде болады. Егер сіз осы бөлімге ерекше назар аударсаңыз, ақаулардың әлдеқайда аз екеніне көз жеткізуге болады, содан кейін жаңа өнімдерді әзірлеу және қайтадан ұйымдық KPI қолдау көрсету уақыты артады.

Осылайша, әрбір шешім, соның ішінде кодты қайта жазу, компания бізге қойған нақты мақсаттарды (ұйымдық өсу, жаңа мүмкіндіктер, жалдау) қолдауы керек.

Бұл процесс барысында бір қызық жайт белгілі болды, ол тек техникалық мамандар үшін ғана емес, жалпы компания үшін жаңалық болды: барлық билеттер кем дегенде бір KPI-ге бағытталуы керек. Яғни, егер өнім жаңа мүмкіндік жасағысы келетінін айтса, бірінші сұрақ қойылуы керек: «Бұл мүмкіндік қандай KPI қолдайды?» Егер жоқ болса, кешіріңіз - бұл қажет емес функция сияқты.

Отызыншы күн

Айдың соңында мен тағы бір нюанс таптым: менің операциялық командамдағы ешкім біздің клиенттермен жасайтын келісімшарттарды ешқашан көрген емес. Неліктен контактілерді көру керек екенін сұрауыңыз мүмкін.

• Біріншіден, SLA келісім-шарттарда көрсетілген.
• Екіншіден, SLA барлығы әртүрлі. Әр клиент өз талаптарымен келді, сауда бөлімі қарамай қол қойды.

Тағы бір қызықты нюанс - ең ірі клиенттердің бірімен жасалған келісім-шартта платформа қолдайтын бағдарламалық жасақтаманың барлық нұсқалары n-1 болуы керек, яғни соңғы нұсқасы емес, соңғы нұсқасы болуы керек.

Платформа ColdFusion және SQL Server 1 негізінде жасалған болса, шілдеде мүлде қолдау көрсетілмейтін болса, n-2008 деңгейінен қаншалықты алыс екеніміз анық.

Қырық бесінші күн

Екінші айдың ортасында менде отыруға және істеуге жеткілікті уақыт болды құнағыныкартаға бүкіл процесс үшін толығымен. Бұл өнімді жасаудан бастап оны тұтынушыға жеткізуге дейінгі қажетті қадамдар және олар мүмкіндігінше егжей-тегжейлі сипатталуы керек.

Сіз процесті кішкене бөліктерге бөлесіз және не тым көп уақытты алатынын, нені оңтайландыруға, жақсартуға және т.б. Мысалы, өнімге сұраныстың күтімді тексеруден өтуі қанша уақытты алады, әзірлеуші ​​қабылдай алатын билетке қашан жетеді, QA және т.б. Сондықтан сіз әрбір жеке қадамды егжей-тегжейлі қарастырып, нені оңтайландыруға болатынын ойлайсыз.

Мен мұны істегенде екі нәрсе назарыма түсті:

• QA-дан әзірлеушілерге қайтарылған билеттердің жоғары пайызы;
• сұрауды қарау тым ұзаққа созылды.

Мәселе мынада: бұл көп уақытты қажет ететін сияқты, бірақ қанша уақытты білмейміз.

«Өлшей алмайтын нәрсені жақсарта алмайсың».

Мәселенің қаншалықты маңызды екенін қалай дәлелдеуге болады? Бұл күндерді немесе сағаттарды босқа өткізе ме?

Мұны өлшеу үшін біз Jira процесіне бірнеше қадам қостық: әр билеттің қанша уақыт күтетінін және оның белгілі бір қадамға қанша рет оралатынын өлшеу үшін «әзірлеуге дайын» ​​және «QA-ға дайын».

Сондай-ақ біз «қарауда» дегенді қостық, оның ішінде орташа есеппен қарауға қанша билет бар және осыдан билей бастай аласыз. Бізде жүйелік көрсеткіштер болды, енді біз жаңа көрсеткіштерді қосып, өлшеуді бастадық:

• Процестің тиімділігі: орындау және жоспарланған/жеткізу.
• Качество процесса: ақаулар саны, QA-дан ақаулар.

Бұл шынымен не жақсы, не жақсы емес екенін түсінуге көмектеседі.

Елуінші күн

Мұның бәрі, әрине, жақсы және қызықты, бірақ екінші айдың аяғында мен мұндай масштабты күтпесем де, болжауға болатын нәрсе болды. Жоғарғы басшылық ауысқандықтан адамдар кете бастады. Басқаруға жаңа адамдар келіп, бәрін өзгерте бастады, ал ескілері жұмыстан кетті. Әдетте бірнеше жыл болған компанияда барлығы дос және бәрі бірін-бірі таниды.

Бұл күткен еді, бірақ жұмыстан босатудың ауқымы күтпеген еді. Мысалы, бір аптаның ішінде екі топ басшысы бір уақытта өз еркімен жұмыстан кету туралы өтініш берді. Сондықтан мен басқа мәселелерді ұмытып қана қоймай, көңіл бөлуге тура келді команда құру. Бұл ұзақ және шешуі қиын мәселе, бірақ оны шешуге тура келді, өйткені мен қалған адамдарды (немесе олардың көпшілігін) құтқарғым келді. Командада моральдық ахуалды сақтау үшін адамдардың кеткеніне қандай да бір реакция жасау керек болды.

Теориялық тұрғыдан бұл жақсы: команданың дағдыларын бағалай алатын және персоналды ауыстыра алатын толық карт-бланшы бар жаңа адам келеді. Шын мәнінде, сіз көптеген себептермен жаңа адамдарды әкеле алмайсыз. Баланс әрқашан қажет.

• Ескі және жаңа. Біз миссияны өзгерте алатын және қолдайтын қарттарды қалдыруымыз керек. Бірақ сонымен бірге жаңа қан әкелу керек, бұл туралы сәл кейінірек айтатын боламыз.
• Тәжірибе. Бізбен жұмыс істеуге ынталы, жақсы жастармен көп сөйлестім. Бірақ мен оларды қабылдай алмадым, өйткені жасөспірімдерді қолдайтын және оларға тәлімгер ретінде әрекет ететін үлкендер жеткіліксіз болды. Әуелі жоғары жақтағыларды, содан кейін ғана жастарды алу керек еді.
• Сәбіз және таяқша.

Дұрыс тепе-теңдік деген не, оны қалай сақтау керек, қанша адам ұстау керек және қанша итеру керек деген сұрақтарға менде жақсы жауап жоқ. Бұл таза жеке процесс.

Елу бірінші күн

Менде кім бар екенін түсіну үшін командаға мұқият қарай бастадым және тағы бір рет есіме түсті:

«Көбінесе мәселе – адамдар мәселесі».

Мен команданың - Dev және Ops екеуінің де үш үлкен проблемасы бар екенін білдім:

• Қазіргі жағдайға қанағаттанушылық.
• Жауапкершіліктің жоқтығы - өйткені ешкім ешқашан орындаушылар жұмысының нәтижесін бизнеске әсер ету үшін әкелген емес.
• Өзгерістен қорқу.

Өзгеріс әрқашан сізді жайлылық аймағыңыздан шығарады, ал жастар неғұрлым жас болса, соғұрлым олар өзгерісті ұнатпайды, себебі олар неге екенін және қалай екенін түсінбейді. Мен естіген ең көп тараған жауап: «Біз мұны ешқашан жасаған емеспіз». Оның үстіне, ол абсурдтық шегіне жетті - ең кішкентай өзгерістер біреудің ашуынсыз мүмкін емес еді. Ал өзгерістер олардың жұмысына қаншалықты әсер еткенімен, адамдар: «Жоқ, неге? Бұл жұмыс істемейді ».

Бірақ ештеңені өзгертпестен жақсы бола алмайсың.

Мен қызметкермен абсурдтық әңгіме жүргіздім, мен оған оңтайландыру туралы идеяларымды айттым, ол маған айтты:
-Ой, сен өткен жылы бізде не болғанын көрмедің!
- Енді не?
«Қазір ол бұрынғыдан әлдеқайда жақсы».
- Демек, одан да жақсы болуы мүмкін емес пе?
- Не үшін?

Жақсы сұрақ - неге? Бұрынғыға қарағанда қазір жақсы болған сияқты, сонда бәрі жақсы. Бұл жауапкершіліктің болмауына әкеледі, бұл негізінен қалыпты жағдай. Жоғарыда айтқанымдай, техникалық топ біраз шетте қалды. Компания олар болуы керек деп есептеді, бірақ стандарттарды ешкім белгілеген емес. Техникалық қолдау ешқашан SLA-ны көрмеген, сондықтан ол топ үшін «қолайлы» болды (және бұл маған ең қатты әсер етті):

• 12 секунд жүктеу;
• Әрбір шығарылымның 5-10 минут үзіліс уақыты;
• Маңызды проблемаларды жою күндер мен апталарды алады;
• 24x7/шақыру бойынша кезекші персоналдың жетіспеушілігі.

Ешкім неге біз мұны жақсырақ жасамаймыз деп сұрауға тырыспады және бұлай болу керек емес екенін ешкім түсінбеді.

Бонус ретінде тағы бір мәселе болды: тәжірибенің болмауы. Үлкендер кетті, ал қалған жас команда бұрынғы режим кезінде өсіп, соған уланды.

Мұның үстіне адамдар да сәтсіздікке ұшырап, қабілетсіз болып көрінуден қорықты. Бұл, біріншіден, олардан көрінеді ешбір жағдайда көмек сұрамады. Қанша рет топ болып, жеке сөйлестік, мен: «Бірдеңе істеуді білмесең, сұрақ қой» дедім. Мен өзіме сенімдімін және кез келген мәселені шеше алатынымды білемін, бірақ бұл уақытты қажет етеді. Сондықтан 10 минутта шешуді білетін адамнан сұрасам, сұраймын. Тәжірибеңіз аз болған сайын, сұраудан қорқасыз, өйткені сіз өзіңізді қабілетсіз деп санайсыз.

Бұл сұрақ қоюдан қорқу қызықты жолдармен көрінеді. Мысалы, сіз: «Бұл тапсырманы қалай орындап жатырсыз?» Деп сұрайсыз. - «Бірнеше сағат қалды, мен қазірдің өзінде аяқтадым». Келесі күні тағы сұрайсың, бәрі жақсы, бірақ бір мәселе болды, ол міндетті түрде күннің соңына дейін дайын болады деп жауап аласыз. Тағы бір күн өтеді, сіз қабырғаға қадалып, біреумен сөйлесуге мәжбүр болғанша, бұл жалғаса береді. Адам мәселені өзі шешкісі келеді, егер ол оны өзі шешпесе, бұл үлкен сәтсіздікке ұшырайды деп сенеді.

Міне, сондықтан әзірлеушілер бағалауды жоғарылатты. Бұл сол бір анекдот еді, олар белгілі бір тапсырманы талқылап жатқанда, олар маған соншалықты сан берді, мен қатты таң қалдым. Маған әзірлеушінің бағалауында әзірлеуші ​​билеттің QA-дан қайтарылатын уақытын қамтиды деп айтты, өйткені олар қателерді табады, PR-ға кететін уақыт және қарау керек адамдар ол бос емес болады - яғни бәрі , мүмкін болатын нәрсе.

Екіншіден, қабілетсіз болып көрінуден қорқатын адамдар артық талдау. Сіз нақты не істеу керектігін айтқан кезде, ол: «Жоқ, егер біз бұл туралы ойласақ ше?» Бұл тұрғыдан алғанда біздің компания бірегей емес, бұл жастар үшін стандартты мәселе.

Жауап ретінде мен келесі тәжірибелерді енгіздім:

• Ереже 30 минут. Егер жарты сағатта мәселені шеше алмасаңыз, біреуден көмек сұраңыз. Бұл әртүрлі дәрежедегі табыспен жұмыс істейді, өйткені адамдар әлі де сұрамайды, бірақ кем дегенде процесс басталды.
• Мәннен басқаның бәрін жойыңыз, тапсырманы орындау мерзімін бағалауда, яғни кодты жазуға қанша уақыт кететінін ғана қарастырыңыз.
• Өмір бойы білім алу артық талдау жасайтындар үшін. Бұл тек адамдармен тұрақты жұмыс.

Алпысыншы күн

Осының бәрін істеп жатқанда, бюджетті анықтаудың уақыты келді. Әрине, мен ақшаны қайда жұмсағанымыз туралы көптеген қызықты нәрселер таптым. Мысалы, бізде бір клиент пайдаланатын бір FTP сервері бар жеке деректер орталығында тұтас сөре болды. «...біз көштік, бірақ ол солай қалды, біз оны өзгерткен жоқпыз» болып шықты. 2 жыл бұрын болды.

Бұлтты қызметтерге арналған заң жобасы ерекше қызығушылық тудырды. Менің ойымша, жоғары бұлтты шоттың басты себебі - өмірінде бірінші рет серверлерге шексіз қол жеткізуге болатын әзірлеушілер. Оларға: «Маған сынақ серверін беріңізші» деп сұраудың қажеті жоқ, олар оны өздері қабылдай алады. Сонымен қатар, әзірлеушілер әрқашан Facebook пен Netflix қызғанатындай керемет жүйені құрғысы келеді.

Бірақ әзірлеушілердің серверлерді сатып алу тәжірибесі және серверлердің қажетті өлшемін анықтау дағдысы жоқ, өйткені оларға бұрын бұл қажет емес еді. Және олар әдетте ауқымдылық пен өнімділік арасындағы айырмашылықты толық түсінбейді.

Түгендеу нәтижелері:

• Біз сол деректер орталығынан шықтық.
• Біз 3 журнал қызметімен келісімшартты бұздық. Өйткені бізде олардың бесеуі болды - бір нәрсемен ойнай бастаған әрбір әзірлеуші ​​жаңасын алды.
• 7 AWS жүйесі жабылды. Қайтадан, өлі жобаларды ешкім тоқтатқан жоқ, барлығы жұмысын жалғастырды.
• Бағдарламалық қамтамасыз ету құны 6 есеге қысқарды.

Жетпіс бесінші күн

Уақыт өтті, екі жарым айдан кейін директорлар кеңесімен кездесуге тура келді. Біздің директорлар кеңесі басқалардан жақсы немесе жаман емес; барлық директорлар кеңестері сияқты ол бәрін білгісі келеді. Адамдар ақша салады және біздің істеп жатқан ісіміз белгіленген KPI-ге қаншалықты сәйкес келетінін түсінгісі келеді.

Совет директоров получает много информации каждый месяц: количество пользователей, их рост, какими сервисами они пользуются и как, производительность и продуктивность, наконец, среднюю скорость загрузки страницы.

Жалғыз мәселе, мен орташа таза зұлымдық деп сенемін. Бірақ мұны директорлар кеңесіне түсіндіру өте қиын. Олар, мысалы, секундына жүктеу уақытының таралуы емес, жинақталған сандармен жұмыс істеуге дағдыланған.

Осыған байланысты қызықты тұстар болды. Мысалы, мен трафикті мазмұн түріне байланысты бөлек веб-серверлер арасында бөлу керек екенін айттым.

Яғни ColdFusion Jetty және nginx арқылы өтіп, беттерді іске қосады. Ал кескіндер, JS және CSS өз конфигурациялары бар бөлек nginx арқылы өтеді. Бұл мен айтып отырған өте стандартты тәжірибе жазды бірнеше жыл бұрын. Нәтижесінде суреттер әлдеқайда жылдам жүктеледі және... орташа жүктеу жылдамдығы 200 мс артты.

Бұл диаграмма Jetty-мен бірге келетін деректер негізінде жасалғандықтан болды. Яғни, жылдам мазмұн есептеуге кірмейді - орташа мән секірді. Бұл бізге түсінікті болды, біз күлдік, бірақ директорлар кеңесіне неліктен бірдеңе жасап, жағдай 12% нашарлағанын қалай түсіндіре аламыз?

Сексен бесінші күн

Үшінші айдың соңында мен мүлдем есептемеген бір нәрсе бар екенін түсіндім: уақыт. Мен айтқанның бәрі уақытты қажет етеді.

Бұл менің нағыз апталық күнтізбем – тек жұмыс аптасы, өте бос емес. Барлығына уақыт жетпейді. Сондықтан тағы да қиындықтарды жеңуге көмектесетін адамдарды жалдау керек.

қорытынды

Бұл бәрі емес. Бұл әңгімеде мен өніммен қалай жұмыс істегенімізді және жалпы толқынға бейімделуге тырысқанымызды немесе техникалық қолдауды қалай біріктіргенімізді немесе басқа техникалық мәселелерді қалай шешкенімізді білмедім. Мысалы, мен дерекқордағы ең үлкен кестелерде біз пайдаланбайтынымызды кездейсоқ білдім SEQUENCE. Бізде өздігінен жазылатын функция бар nextID, және ол транзакцияда пайдаланылмайды.

Был еще миллион подобных вещей, о которых можно долго говорить. Но самое важное, о чем еще стоит сказать, — это культура.

Мәдениет немесе оның жетіспеушілігі барлық басқа мәселелерге әкеледі. Біз мәдениетті құруға тырысамыз, онда адамдар:

• сәтсіздіктерден қорықпайды;
• қателерден сабақ алу;
• басқа командалармен бірлесіп жұмыс істеу;
• бастама көтеру;
• жауапкершілікті алу;
• нәтижені мақсат ретінде қарсы алу;
• табысын тойлау.

Осымен басқаның бәрі келеді.

Леон Өрт twitter-де, Facebook мен орта.

Мұраға қатысты екі стратегия бар: кез келген жағдайда онымен жұмыс істеуден аулақ болыңыз немесе байланысты қиындықтарды батыл түрде жеңіңіз. Біз с DevOpsConf идем по второму пути, меняя процессы и подходы. Присоединяйтесь к нам в YouTube, жіберу тізімі и жеделхат, және біз бірге DevOps мәдениетін енгіземіз.

Ақпарат көзі: www.habr.com