Познато е дека компетентноста на CTO се тестира дури по втор пат кога тој ја извршува оваа улога. Затоа што едно е да работиш во компанија неколку години, да еволуираш со неа и, да се бидеш во истиот културен контекст, постепено да добиваш поголема одговорност. А сосема друго е да се дојде директно на позицијата технички директор во компанија со наследен багаж и еден куп проблеми уредно покриени под тепих.

Во оваа смисла, искуството на Леон Фајр, кое тој го сподели DevOpsConf, не баш уникатен, но помножен со неговото искуство и бројот на различни улоги што успеал да ги проба во текот на 20 години, е многу корисно. Подолу е прикажана хронологија на настани во текот на 90 дена и многу приказни на кои е забавно да се смееш кога ќе му се случат на некој друг, но кои не се толку забавни да се соочат лично.

Леон зборува многу живописно на руски, па ако имате 35-40 минути, препорачувам да го погледнете видеото. Текстуална верзија за да заштедите време подолу.

Првата верзија на извештајот беше добро структуриран опис на работата со луѓе и процеси, кој содржи корисни препораки. Но, таа не ги пренесе сите изненадувања кои се сретнаа на патот. Затоа, го сменив форматот и ги претставив проблемите што се појавија пред мене како дигалка во новата компанија и методите за нивно решавање по хронолошки редослед.

Еден месец пред тоа

Како и многу добри приказни, така и оваа започна со алкохол. Седевме со пријателите во кафеана и очекувано меѓу информатичарите, сите плачеа за своите проблеми. Еден од нив штотуку ја смени работата и зборуваше за своите проблеми со технологијата, со луѓето и со тимот. Колку повеќе слушав, толку повеќе сфаќав дека тој треба само да ме вработи, бидејќи тоа се типови на проблеми што ги решавам во последните 15 години. Му кажав така, а следниот ден се сретнавме во работна средина. Компанијата беше наречена Teaching Strategies.

Стратегиите за настава е лидер на пазарот во наставната програма за многу мали деца од раѓање до тригодишна возраст. Традиционалната компанија за „хартиена“ веќе има 40 години, а дигиталната SaaS верзија на платформата е стара 10. Релативно неодамна започна процесот на прилагодување на дигиталната технологија на стандардите на компанијата. „Новата“ верзија лансирана во 2017 година и беше речиси како старата, само што работеше полошо.

Најинтересно е што сообраќајот на оваа компанија е многу предвидлив - од ден на ден, од година во година, можете многу јасно да предвидите колку луѓе ќе дојдат и кога. На пример, помеѓу 13 и 15 часот, сите деца во градинките си легнуваат и наставниците почнуваат да внесуваат информации. И ова се случува секој ден, освен викендите, бидејќи речиси никој не работи за викенд.

Гледајќи малку напред, ќе забележам дека мојата работа ја започнав во периодот на највисок годишен сообраќај, што е интересно од различни причини.

Платформата, која се чинеше дека е стара само 2 години, имаше необичен стек: ColdFusion и SQL Server од 2008 година. ColdFusion, ако не знаете, а најверојатно не знаете, е претпријатие PHP што излезе во средината на 90-тите, и оттогаш не сум ни слушнал за него. Исто така, имаше: Ruby, MySQL, PostgreSQL, Java, Go, Python. Но, главниот монолит работеше на ColdFusion и SQL Server.

Проблеми

Колку повеќе разговарав со вработените во компанијата за работата и какви проблеми наидов, толку повеќе сфаќав дека проблемите не се само од технички карактер. Добро, технологијата е стара - и тие не работеа на тоа, но имаше проблеми со тимот и со процесите, а компанијата почна да го разбира ова.

Традиционално, нивните техничари седеа во аголот и работеа некаква работа. Но, се повеќе и повеќе бизнис почна да оди преку дигиталната верзија. Затоа, во последната година пред да започнам со работа, во компанијата се појавија нови: одбор на директори, CTO, CPO и QA директор. Односно, компанијата почна да инвестира во технолошкиот сектор.

Трагите од тешкото наследство не беа само во системите. Компанијата имаше наследени процеси, наследени луѓе, наследена култура. Сето ова мораше да се смени. Мислев дека дефинитивно нема да биде досадно и решив да се обидам.

Два дена пред тоа

Два дена пред да започнам со нова работа, пристигнав во канцеларијата, ја пополнив последната документација, се сретнав со тимот и открив дека тимот се бори со проблем во тоа време. Тоа беше дека просечното време на вчитување на страницата скокна на 4 секунди, односно 2 пати.

Судејќи според графиконот, нешто јасно се случило и не е јасно што. Се испостави дека проблемот е мрежната латентност во центарот за податоци: латентноста од 5 ms во центарот за податоци се претвори во 2 секунди за корисниците. Не знаев зошто се случи ова, но во секој случај се дозна дека проблемот е во центарот за податоци.

Еден ден

Поминаа два дена и на првиот работен ден открив дека проблемот не исчезнал.

За два дена, страниците на корисниците се вчитуваа во просек за 4 секунди. Прашувам дали нашле што е проблемот.

- Да, отворивме билет.
- И?
- Па, уште не ни одговорија.

Тогаш сфатив дека сè што ми беше кажано претходно е само мал врв на сантата мраз со која треба да се борам.

Има добар цитат кој многу добро одговара на ова:

„Понекогаш за да ја промените технологијата, треба да ја промените организацијата“.

Но, бидејќи почнав да работам во најпрометниот период од годината, морав да ги разгледам двете опции за решавање на проблемот: и брзо и долгорочно. И почнете со она што е критично во моментов.

Ден три

Значи, вчитувањето трае 4 секунди, а од 13 до 15 најголемите врвови.

На третиот ден во овој временски период, брзината на преземање изгледаше вака:

Од моја гледна точка, ништо не функционираше воопшто. Од гледна точка на сите други работи малку побавно од вообичаеното. Но, тоа едноставно не се случува така - тоа е сериозен проблем.

Се обидов да го убедам тимот, на што ми одговорија дека едноставно им требаат повеќе сервери. Ова, се разбира, е решение за проблемот, но не е секогаш единственото и најефективното. Прашав зошто нема доволно сервери, колкав е обемот на сообраќај. Ги екстраполирав податоците и открив дека имаме приближно 150 барања во секунда, што, во принцип, спаѓа во разумни граници.

Но, не смееме да заборавиме дека пред да го добиете вистинскиот одговор, треба да го поставите вистинското прашање. Моето следно прашање беше: колку преден сервери имаме? Одговорот „малку ме збуни“ - имавме 17 frontend сервери!

- Се срамам да прашам, но 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 Server за кеширање - истиот од кој штотуку се читаа податоците.

Ден десет

Првата недела се занимавав со проблеми кои требаше да се решат токму сега. Некаде во втората недела првпат дојдов на стенд-ап за да комуницирам со тимот, да видам што се случува и како се одвива целиот процес.

Повторно е откриено нешто интересно. Тимот се состоеше од: 18 програмери; 8 тестери; 3 менаџери; 2 архитекти. И сите учествуваа во заеднички ритуали, односно секое утро на стенд ап доаѓаа повеќе од 30 луѓе и кажуваа што прават. Јасно е дека средбата не траеше 5 или 15 минути. Никој никого не слушаше затоа што секој работи на различни системи. Во оваа форма, 2-3 билети на час за сесија за чешлање веќе беше добар резултат.

Првото нешто што го направивме беше да го поделиме тимот на неколку производни линии. За различни делови и системи, доделивме посебни тимови, во кои беа вклучени програмери, тестери, менаџери на производи и деловни аналитичари.

Како резултат добивме:

• Намалување на стенд-ап и митинзи.
• Предметно познавање на производот.
• Чувство на сопственост. Кога луѓето постојано чепкаа во системите, знаеја дека некој друг најверојатно ќе мора да работи со нивните грешки, но не и самите.
• Соработка помеѓу групи. Непотребно е да се каже дека QA претходно не комуницираше многу со програмерите, производот си го направи своето, итн. Сега тие имаат заедничка точка на одговорност.

Главно се фокусиравме на ефикасноста, продуктивноста и квалитетот - тоа се проблемите што се обидовме да ги решиме со трансформацијата на тимот.

Ден единаесет

Во процесот на промена на структурата на тимот, открив како да бројам ПриказнаПоени. 1 СП беше еднакво на еден ден, а секој билет содржеше СП и за развој и за QA, односно најмалку 2 СП.

Како го открив ова?

Најдовме грешка: во еден од извештаите, каде што се внесени датумот на почеток и крај на периодот за кој е потребен извештајот, последниот ден не се зема предвид. Односно, некаде во барањето немало <=, туку едноставно <. Ми кажаа дека ова се три точки на приказна, т.е 3 денови.

После ова ние:

• Системот за оценување на Story Points е ревидиран. Сега поправките за помали грешки што можат брзо да се пренесат низ системот побрзо стигнуваат до корисникот.
• Почнавме да спојуваме поврзани билети за развој и тестирање. Претходно, секој билет, секоја бубачка беше затворен екосистем, не врзан за ништо друго. Промената на три копчиња на една страница можеше да биде три различни тикети со три различни процеси за QA наместо еден автоматизиран тест по страница.
• Почнавме да работиме со програмери на пристап за проценка на трошоците за работна сила. Три дена да се смени едно копче не е смешно.

Дваесетти ден

Некаде во средината на првиот месец, ситуацијата малку се стабилизира, сфатив што во основа се случува, и веќе почнав да гледам во иднината и да размислувам за долгорочни решенија.

Долгорочни цели:

• Управувана платформа. Стотици барања на секоја страница не се сериозни.
• Предвидливи трендови. Имаше периодични врвови во сообраќајот кои на прв поглед не беа во корелација со други метрика - требаше да разбереме зошто се случи ова и да научиме да предвидуваме.
• Проширување на платформата. Бизнисот постојано расте, се повеќе корисници доаѓаат, а сообраќајот се зголемува.

Во минатото често се зборувало: „Ајде да преработиме сè на [јазик/рамка], сè ќе функционира подобро!

Во повеќето случаи ова не функционира, добро е ако препишувањето воопшто функционира. Затоа, требаше да создадеме патоказ - специфична стратегија која илустрира чекор по чекор како ќе се постигнат деловните цели (што ќе правиме и зошто), кои:

• ја одразува мисијата и целите на проектот;
• дава приоритет на главните цели;
• содржи распоред за нивно постигнување.

Пред ова, никој не разговараше со тимот за целта на какви било промени. Ова бара правилни метрики за успех. За прв пат во историјата на компанијата, поставивме KPI за техничката група и овие индикатори беа врзани за организациски.

Односно, организациските KPI се поддржани од тимови, а тимските KPI се поддржани од поединечни KPI. Во спротивно, ако технолошките KPI не се совпаѓаат со организациските, тогаш секој си го влече ќебето на себе.

На пример, еден од организациските KPI е зголемување на пазарниот удел преку нови производи.

Како можете да ја поддржите целта да имате повеќе нови производи?

• Прво, сакаме да потрошиме повеќе време за развој на нови производи наместо да ги поправаме дефектите. Ова е логично решение кое лесно се мери.
• Второ, сакаме да поддржиме зголемување на обемот на трансакциите, бидејќи колку е поголем уделот на пазарот, толку повеќе корисници и, соодветно, повеќе сообраќај.

Потоа, поединечните KPI кои можат да се извршат во рамките на групата, на пример, ќе бидат на местото од каде што доаѓаат главните дефекти. Ако се фокусирате конкретно на овој дел, можете да се уверите дека има многу помалку дефекти, а потоа ќе се зголеми времето за развој на нови производи и повторно за поддршка на организациските KPI.

Така, секоја одлука, вклучително и препишување код, мора да ги поддржи специфичните цели што ни ги постави компанијата (организациски раст, нови функции, регрутирање).

За време на овој процес, на виделина излезе една интересна работа, која стана вест не само за техничари, туку и воопшто во компанијата: сите билети мора да бидат фокусирани на барем еден KPI. Односно, ако производот вели дека сака да направи нова функција, треба да се постави првото прашање: „Каков KPI поддржува оваа функција? Ако не, тогаш извинете - се чини како непотребна карактеристика.

Ден триесет

На крајот на месецот, открив уште една нијанса: никој од мојот тим на Ops никогаш не ги видел договорите што ги склучуваме со клиентите. Може да прашате зошто треба да ги гледате контактите.

• Прво, затоа што SLA се наведени во договорите.
• Второ, SLA се сите различни. Секој клиент дојде со свои барања, а одделот за продажба потпиша без да гледа.

Друга интересна нијанса е што во договорот со еден од најголемите клиенти стои дека сите верзии на софтвер поддржани од платформата мора да бидат n-1, односно не најновата, туку претпоследната верзија.

Јасно е колку бевме далеку од n-1 ако платформата се базираше на ColdFusion и SQL Server 2008, кој веќе воопшто не беше поддржан во јули.

Четириесет и петти ден

Околу средината на вториот месец имав доволно време да седнам и да направам вредностпренос намапирање целосно за целиот процес. Ова се неопходните чекори што треба да се преземат, од создавање производ до негово доставување до потрошувачот, и тие треба да бидат опишани што подетално.

Го делите процесот на мали парчиња и гледате што ви одзема премногу време, што може да се оптимизира, подобри итн. На пример, колку време е потребно за барањето за производ да помине низ чешлање, кога ќе стигне до билет што може да го земе развивачот, QA итн. Така, детално го разгледувате секој поединечен чекор и размислувате што може да се оптимизира.

Кога го направив ова, две работи ми привлекоа внимание:

• висок процент на билети вратени од QA назад кај програмерите;
• Прегледите на барањата за повлекување траеја премногу долго.

Проблемот беше што тоа беа заклучоци како: Се чини дека треба многу време, но не сме сигурни колку долго.

„Не можете да го подобрите она што не можете да го измерите.

Како да се оправда колку е сериозен проблемот? Дали троши денови или часови?

За да го измериме ова, додадовме неколку чекори во процесот Jira: „подготвен за развој“ и „подготвен за QA“ за да се измери колку долго чека секој билет и колку пати се враќа на одреден чекор.

Додадовме и „во преглед“ за да знаеме колку билети се просечно за преглед, и од ова можете да почнете да танцувате. Имавме системска метрика, сега додадовме нови метрики и почнавме да мериме:

• Ефикасност на процесот: изведба и планирано/испорачано.
• Квалитет на процесот: број на дефекти, дефекти од QA.

Навистина помага да се разбере што оди добро, а што не оди добро.

Педесетти ден

Сето ова е, се разбира, добро и интересно, но кон крајот на вториот месец се случи нешто што, во принцип, беше предвидливо, иако не очекував таков размер. Луѓето почнаа да заминуваат затоа што се смени највисокото раководство. Нови луѓе дојдоа во раководството и почнаа да менуваат сè, а старите дадоа отказ. И обично во друштво старо неколку години, сите се пријатели и сите се познаваат.

Ова беше очекувано, но обемот на отпуштањата беше неочекуван. На пример, за една недела двајца лидери на тимови истовремено поднесоа оставки по своја волја. Затоа, морав не само да заборавам на другите проблеми, туку и да се фокусирам на создавање на тим. Ова е долг и тежок проблем за решавање, но мораше да се реши затоа што сакав да ги спасам луѓето што останаа (или повеќето од нив). Требаше некако да се реагира на тоа што луѓето си заминаа за да се одржи моралот во тимот.

Теоретски, ова е добро: доаѓа нова личност која има целосна карт-бланш, која може да ги процени вештините на тимот и да го замени персоналот. Всушност, не можете само да внесувате нови луѓе од толку многу причини. Балансот е секогаш потребен.

• Стари и нови. Треба да ги задржиме старите луѓе кои можат да се променат и да ја поддржат мисијата. Но, во исто време, треба да внесеме нова крв, ќе зборуваме за тоа малку подоцна.
• Искуство. Разговарав многу со добри јуниори кои беа желни и сакаа да работат со нас. Но, не можев да ги прифатам бидејќи немаше доволно постари лица да ги поддржат јуниорите и да дејствуваат како ментори за нив. Потребно беше прво да се регрутираат врвот, па дури потоа младите.
• Морков и стап.

Немам добар одговор на прашањето кој е вистинскиот баланс, како да се одржува, колку луѓе да се задржат и колку да се туркаат. Ова е чисто индивидуален процес.

Педесет и еден ден

Почнав внимателно да гледам во тимот за да сфатам кој имам и уште еднаш се сетив:

„Повеќето проблеми се проблеми со луѓето“.

Открив дека тимот како таков - и Dev и Ops - има три големи проблеми:

• Задоволство од моменталната состојба на работите.
• Недостаток на одговорност - затоа што никој никогаш не ги донел резултатите од работата на изведувачите за да влијае на бизнисот.
• Страв од промени.

Промените секогаш ве вадат од вашата комфорна зона, а колку се помлади, толку повеќе не ги сакаат промените затоа што не разбираат зошто и не разбираат како. Најчестиот одговор што сум го слушнал е: „Никогаш не сме го направиле тоа“. Згора на тоа, дојде до точка на целосна апсурдност - најмалите промени не можеа да се случат без некој да биде огорчен. И без разлика колку промените влијаеле на нивната работа, луѓето велеле: „Не, зошто? Ова нема да функционира“.

Но, не можете да бидете подобри без да промените ништо.

Имав апсолутно апсурден разговор со вработен, му ги кажав моите идеи за оптимизација, на што тој ми рече:
- О, не видовте што имавме минатата година!
- Па што?
„Сега е многу подобро отколку што беше“.
- Значи, не може да биде подобро?
- За што?

Добро прашање - зошто? Како сега да е подобро отколку што беше, тогаш сè е доволно добро. Ова води до недостаток на одговорност, што во принцип е апсолутно нормално. Како што кажав, техничката група беше малку настрана. Компанијата веруваше дека тие треба да постојат, но никој никогаш не ги поставил стандардите. Техничката поддршка никогаш не го виде SLA, така што беше сосема „прифатливо“ за групата (и ова најмногу ме погоди):

• 12 секунди вчитување;
• 5-10 минути прекин на секое ослободување;
• Решавањето на критичните проблеми трае со денови и недели;
• недостаток на дежурен персонал 24x7 / на повик.

Никој никогаш не се обидел да праша зошто не го правиме тоа подобро, и никој никогаш не сфатил дека не мора да биде вака.

Како бонус, имаше уште еден проблем: недостаток на искуство. Сениорите си заминаа, а преостанатиот млад тим порасна под претходниот режим и беше отруен од него.

Згора на сето ова, луѓето се плашеа и да не успеат и да се покажат неспособни. Тоа се изразува со тоа што, прво, тие во никој случај не побарал помош. Колку пати сме разговарале како група и поединечно, а јас сум рекол: „Поставете прашање ако не знаете како да направите нешто“. Сигурен сум во себе и знам дека можам да го решам секој проблем, но ќе треба време. Затоа, ако можам да прашам некој што знае да го реши за 10 минути, ќе прашам. Колку помалку искуство имате, толку повеќе се плашите да прашате затоа што мислите дека ќе ве сметаат за некомпетентни.

Овој страв од поставување прашања се манифестира на интересни начини. На пример, прашувате: „Како се справувате со оваа задача? - „Уште неколку часа, јас веќе завршувам“. Следниот ден повторно прашувате, добивате одговор дека се е во ред, но имаше еден проблем, дефинитивно ќе биде готов до крајот на денот. Поминува уште еден ден, и додека не бидете приковани за ѕид и не принудени да разговарате со некого, ова продолжува. Човек сака сам да реши некој проблем; тој верува дека ако не го реши сам, тоа ќе биде голем неуспех.

Затоа програмерите ги надуваа проценките. Тоа беше истата анегдота, кога разговараа за одредена задача, ми дадоа таква фигура што бев многу изненаден. На што ми беше кажано дека во проценките на инвеститорот, инвеститорот го вклучува времето дека билетот ќе биде вратен од QA, бидејќи таму ќе најдат грешки, и времето што ќе им одземе на ПР и времето додека луѓето кои треба да ги прегледаат ќе биде зафатено - односно сè, што и да е можно.

Второ, луѓе кои се плашат да не изгледаат неспособни наданализирај. Кога ќе кажете што точно треба да се направи, почнува: „Не, што ако размислиме за тоа овде?“ Во оваа смисла, нашата компанија не е единствена, ова е стандарден проблем за младите луѓе.

Како одговор, ги воведов следните практики:

• Правило 30 минути. Ако не можете да го решите проблемот за половина час, побарајте некој да ви помогне. Ова функционира со различен степен на успех, бидејќи луѓето сè уште не прашуваат, но барем процесот е започнат.
• Елиминирајте сè освен суштината, при проценката на крајниот рок за завршување на задачата, односно размислете само колку време ќе биде потребно за да се напише кодот.
• Доживотно учење за оние кои преанализираат. Тоа е само постојана работа со луѓе.

Шеесетти ден

Додека го правев сето ова, време беше да го сфатам буџетот. Се разбира, најдов многу интересни работи во тоа каде ги потрошивме нашите пари. На пример, имавме цела решетка во посебен центар за податоци со еден FTP сервер, кој го користеше еден клиент. Се испостави дека „... се преселивме, но тој остана таков, не го сменивме“. Тоа беше пред 2 години.

Од особен интерес беше сметката за облак услуги. Верувам дека главната причина за високата сметка за облак се програмерите кои имаат неограничен пристап до серверите за прв пат во нивните животи. Тие не треба да прашуваат: „Ве молам дајте ми тест-сервер“, тие можат сами да го земат. Плус, програмерите секогаш сакаат да изградат таков кул систем што Фејсбук и Нетфликс ќе бидат љубоморни.

Но, програмерите немаат искуство во купување сервери и вештина за одредување на потребната големина на сервери, бидејќи претходно не им требале. И тие обично не ја разбираат сосема разликата помеѓу приспособливоста и перформансите.

Резултати од пописот:

• Го напуштивме истиот центар за податоци.
• Го раскинавме договорот со 3 логови услуги. Бидејќи имавме 5 од нив - секој развивач што почна да си игра со нешто, зема нов.
• 7 AWS системи беа исклучени. Повторно, никој не ги запре мртвите проекти; сите тие продолжија да работат.
• Намалени трошоци за софтвер за 6 пати.

Седумдесет и петти ден

Помина времето, а за два и пол месеци требаше да се сретнам со бордот на директори. Нашиот одбор на директори не е ниту подобар ниту полош од другите; како и сите одбори на директори, тој сака да знае сè. Луѓето инвестираат пари и сакаат да разберат колку она што го правиме се вклопува во поставените KPI.

Одборот на директори добива многу информации секој месец: бројот на корисници, нивниот раст, какви услуги и како користат, перформанси и продуктивност и, конечно, просечна брзина на вчитување на страници.

Единствениот проблем е што верувам дека просекот е чисто зло. Но, многу е тешко ова да му се објасни на бордот на директори. Тие се навикнати да работат со збирни бројки, а не, на пример, со ширење на времињата на вчитување во секунда.

Имаше неколку интересни точки во овој поглед. На пример, реков дека треба да го поделиме сообраќајот помеѓу посебни веб-сервери во зависност од видот на содржината.

Односно, ColdFusion поминува низ Jetty и nginx и ги лансира страниците. И сликите, JS и CSS поминуваат низ посебен nginx со свои конфигурации. Ова е прилично стандардна практика за која зборувам пишува пред неколку години. Како резултат на тоа, сликите се вчитуваат многу побрзо и... просечната брзина на вчитување се зголеми за 200 ms.

Ова се случи бидејќи графикот е изграден врз основа на податоците што доаѓаат со Jetty. Тоа е, брзата содржина не е вклучена во пресметката - просечната вредност скокна. Ова ни беше јасно, се смеевме, но како да му објасниме на управниот одбор зошто направивме нешто и работите се влошија за 12%?

Ден осумдесет и пет

На крајот на третиот месец, сфатив дека има една работа на која воопшто не сум сметала: времето. Се што зборував бара време.

Ова е мојот вистински неделен календар - само работна недела, не многу зафатена. Нема доволно време за се. Затоа, повторно, треба да регрутирате луѓе кои ќе ви помогнат да се справите со проблемите.

Заклучок

Тоа не е се. Во оваа приказна, дури и не дојдов до тоа како работевме со производот и се обидовме да се прилагодиме на општиот бран, или како интегриравме техничка поддршка или како решивме други технички проблеми. На пример, сосема случајно дознав дека на најголемите табели во базата на податоци не ги користиме SEQUENCE. Имаме само-напишана функција nextID, и не се користи во трансакција.

Имаше уште милион слични работи за кои можевме долго да зборуваме. Но, најважното нешто што сè уште треба да се каже е културата.

Културата или недостатокот од неа доведува до сите други проблеми. Се обидуваме да изградиме култура каде што луѓето:

• не се плашат од неуспеси;
• учи од грешките;
• да соработува со други тимови;
• преземе иницијатива;
• преземе одговорност;
• поздравете го резултатот како цел;
• славејќи го успехот.

Со ова се друго ќе дојде.

Леон Фајр на твитер, Фејсбук и среден.

Постојат две стратегии во врска со наследството: избегнувајте да работите со него по секоја цена или храбро надминете ги поврзаните тешкотии. Ние в DevOpsConf Одиме по вториот пат, менувајќи ги процесите и пристапите. Придружете ни се на YouTube, мејлинг листа и телеграма, и заедно ќе имплементираме култура на DevOps.

Извор: www.habr.com