Вядома, што кампетэнтнасць CTO правяраецца толькі на другі раз выкананні гэтай ролі. Таму што адна справа некалькі гадоў працаваць у кампаніі, разам з ёй эвалюцыянаваць і, знаходзячыся ва ўсё тым жа культурным кантэксце, паступова атрымліваць больш адказнасці. І зусім іншае прыйсці адразу на пасаду тэхдырэктара ў кампанію з багажом legacy і кучай праблем, акуратна замеценых пад дыван.

У гэтым сэнсе досвед Лявона Фаера, якім ён дзяліўся на DevOpsConf, не тое каб прама ўнікальны, але памножаны на стаж і колькасць розных роляў, якія ён за 20 гадоў паспеў на сябе прымерыць, вельмі карысны. Пад катам храналогія падзей за 90 дзён і шмат баек, з якіх прыемна пасмяяцца, калі яны адбываюцца з кімсьці іншым, але з якімі не так ужо весела сутыкацца асабіста.

Лявон вельмі каларытна расказвае па-руску, таму калі ў вас ёсць 35-40 хвілін, то рэкамендую глядзець відэа. Тэкставая версія для эканоміі часу ніжэй.

Першая версія даклада была добра структураваным апісаннем працы з людзьмі і працэсамі, якія змяшчаюць карысныя рэкамендацыі. Але яна не перадавала ўсіх сюрпрызаў, якія сустракаліся па дарозе. Таму я памяняў фармат і выклаў праблемы, якія ў новай кампаніі выскоквалі перада мной, як чорт з табакеркі, і метады іх вырашэння ў храналагічным парадку.

За месяц да

Як і многія добрыя гісторыі, гэтая пачалася з алкаголю. Мы сядзелі са знаёмымі ў бары, і як належыць у асяроддзі айцішнікаў, кожны плакаўся аб сваіх праблемах. Адзін з іх толькі што змяніў працу і расказваў аб сваіх праблемах і з тэхналогіямі, і з людзьмі, і з камандай. Чым даўжэй я слухаў, тым больш разумеў, што яму трэба проста наняць мяне, бо менавіта такія праблемы я рашаў апошнія 15 гадоў. Я так яму і сказаў, і на наступны дзень мы сустрэліся ўжо ў працоўным становішчы. Кампанія звалася Teaching Strategies.

Teaching Strategies лідзіруе на рынку навучальных праграм для дзяцей зусім ранняга ўзросту - ад нараджэння да трох гадоў. Традыцыйнай "папяровай" кампаніі ўжо гадоў 40, а лічбавай SaaS-версіі платформы 10. Адносна нядаўна пачаўся працэс адаптацыі лічбавай тэхналогіі ў стандарты кампаніі. "Новая" версія запусцілася ў 2017 г. і была амаль як старая, толькі працавала горш.

Самае цікавае, што трафік у гэтай кампаніі вельмі прагназуемы - дзень пры дні, з года ў год можна вельмі выразна спрагназаваць, колькі людзей прыйдуць і калі. Напрыклад, паміж 13 і 15 гадзінамі дня ўсе дзеці ў дзіцячых садках ідуць спаць, а настаўнікі пачынаюць уводзіць інфармацыю. І так адбываецца кожны дзень, акрамя выходных, бо ў выходныя амаль ніхто не працуе.

Забягаючы крыху наперад заўважу, я пачаў сваю працу ў перыяд самага вялікага гадавога трафіку, што цікава па розных прычынах.

Платформа, якой было толькі два гады, мела своеасаблівы стэк: ColdFusion & SQL Server 2 года. ColdFusion, калі не ведаеце, а хутчэй за ўсё не ведаеце, - гэта такі enterprise PHP, які выйшаў у сярэдзіне 2008-х, і з тых часоў я пра яго нават не чуў. Таксама тамака былі: Ruby, MySQL, PostgreSQL, Java, Go, Python. Але асноўны маналіт працаваў на ColdFusion і SQL Server.

Праблемы

Чым больш я размаўляў з супрацоўнікамі кампаніі аб працы і аб тым, якія праблемы сустракаюцца, тым больш разумеў, што праблемы носяць не толькі тэхнічны характар. Добра, тэхналогія старая - і не на такім працавалі, але былі праблемы з камандай і з працэсамі, і кампанія гэта пачынала разумець.

Традыцыйна тэхнары ў іх сядзелі ў куце і займаліся нейкай сваёй працай. Але ўсё больш і больш бізнэсу пачало праходзіць менавіта праз лічбавую версію. Таму ў кампаніі за апошні год да пачатку маёй працы з'явіліся новыя: рада дырэктараў, CTO, CPO і QA-дырэктар. Гэта значыць кампанія пачала ўкладвацца ў тэхналагічную сферу.

Сляды цяжкай спадчыны былі не толькі ў сістэмах. У кампаніі былі legacy-працэсы, legacy-людзі, legacy-культура. Усё гэта трэба было мяняць. Я падумаў, што сумна дакладна не будзе і вырашыў паспрабаваць.

За два дні да

За два дні да пачатку новай працы я прыехаў у офіс, запоўніў апошнія паперы, пазнаёміўся з камандай і выявіў, што каманда тым часам змагаецца з праблемай. Яна складалася ў тым, што сярэдні час загрузкі старонак падскочыла да 4 з, гэта значыць у 2 разы.

Судзячы па графіку, відавочна нешта здарылася, прычым незразумела што. Аказалася, што праблема была ў network latency у дата-цэнтры: 5 мс latency у дата-цэнце пераўтварыліся ў 2 з для карыстальнікаў. Чаму так адбылося, я не ведаў, але ва ўсякім разе стала вядома, што праблема ў дата-цэнтры.

дзень першы

Прайшло два дні, і ў свой першы працоўны дзень я выявіў, што праблема нікуды не падзелася.

Два дні ў карыстальнікаў старонкі грузіліся ў сярэднім па 4 с. Пытаю, ці знайшлі, у чым праблема.

- Так, мы адкрылі тыкет.
- І?
- Ну, яны нам пакуль яшчэ не адказалі.

Тут я зразумеў, што ўсё, пра што мне да гэтага расказвалі, гэта толькі маленькі кончык айсберга, з якім трэба змагацца.

Ёсць добрая цытата, якая вельмі падыходзіць да гэтага выпадку:

"Часам для змены тэхналогіі трэба мяняць арганізацыю".

Але так як я пачаў працу ў самую загружаную пару года, трэба было глядзець на абодва варыянты рашэння праблемы: і хуткае, і ў далёкатэрміновай перспектыве. І пачынаць з таго, што крытычна прама зараз.

дзень трэці

Такім чынам, загрузка доўжыцца 4 секунды, а з 13 да 15 найвялікшыя пікі.

На трэці дзень у гэты адрэзак часу хуткасць загрузкі выглядала так:

З майго пункту гледжання ўвогуле нічога не працавала. З пункту гледжання ўсіх астатніх працавала крыху павольней, чым звычайна. Але проста так так не бывае - гэта сур'ёзная праблема.

Я спрабаваў упэўніць каманду, на што мне адказвалі, што проста трэба больш сервераў. Гэта, вядома, вырашэнне праблемы, але далёка не заўсёды адзінае і самае эфектыўнае. Я спытаў, чаму не хапае сервераў, які аб'ём трафіку. Я экстрапаляваў дадзеныя і атрымаў, што ў нас прыкладна 150 запытаў у секунду, што ў прынцыпе ўкладваецца ў разумныя межы.

Але трэба не забывацца, што перад тым, як атрымаць правільны адказ, трэба задаць правільнае пытанне. Маё наступнае пытанне было: колькі ў нас frontend-сервераў. Адказ мяне «трохі збянтэжыў» – у нас было 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 цікета за гадзіну на grooming session ужо былі добрым вынікам.

Першае, што мы зрабілі, - гэта падзялілі каманду на некалькі па лініі прадуктаў. Для розных секцый і сістэм мы вылучылі асобныя каманды, якія ўключалі распрацоўшчыкаў, тэсціроўшчыкаў, продакт-мэнэджараў, бізнес-аналітыкаў.

У выніку атрымалі:

• Скарачэнне стэндапаў і мітынгаў.
• Прадметнае веданне прадукта.
• Пачуццё ўласнасці. Калі раней людзі ўвесь час ратаваліся па сістэмах, яны ведалі, што працаваць з іх багамі хутчэй за ўсё давядзецца камусьці яшчэ, але не ім самім.
• Супрацоўніцтва паміж групамі. Можна не казаць, што QA з праграмістамі да гэтага не моцна размаўлялі, продакт рабіў сваю ўласную справу і г.д. Цяпер у іх з'явілася агульная кропка адказнасці.

У асноўным мы факусаваліся на эфектыўнасці, прадукцыйнасці і якасці - менавіта гэтыя праблемы мы спрабавалі вырашыць трансфармацыяй каманды.

Дзень адзінаццаты

У працэсе змены структуры каманды я выявіў, як падлічваюць ГісторыяАчкі. 1 SP быў роўны аднаму дню, а кожны тыкет у іх утрымоўваў SP і на распрацоўку, і на QA, гэта значыць прынамсі 2 SP.

Як я гэта выявіў?

Знайшлі баг: у адной са справаздач, дзе ўводзіцца дата пачатку і канца перыяду, за які патрэбная справаздача, не ўлічваецца апошні дзень. Гэта значыць дзесьці ў запыце стаяла не <=, а проста <. Мне сказалі, што гэта тры Story Points, гэта значыць 3 дня.

Пасля гэтага мы:

• Перагледзелі сістэму адзнакі Story Points. Цяпер выпраўленне дробных багаў, якія можна хутка прапусціць праз сістэму, хутчэй даходзіць да карыстальніка.
• Пачалі аб'ядноўваць звязаныя цікеты для распрацоўкі і тэсціравання. Раней кожны тыкет, кожны баг быў замкнёнай экасістэмай, непрывязанай ні да чаго іншага. Змена трох кнопак на адной старонцы магла быць трыма рознымі тыкетамі з трыма рознымі QA-працэсамі замест аднаго аўтаматычнага тэста на старонцы.
• Сталі працаваць з распрацоўшчыкамі над падыходам да ацэнкі працавыдаткаў. Тры дні, каб памяняць адну кнопку - гэта не смешна.

Дзень дваццаты

Недзе да сярэдзіны першага месяца сітуацыя крыху стабілізавалася, я разабраўся з тым, што ў асноўным адбываецца, і ўжо пачаў глядзець у будучыню і думаць і доўгатэрміновых рашэннях.

Доўгатэрміновыя мэты:

• Кіраваная платформа. Сотні запытаў на кожнай старонцы - гэта несур'ёзна.
• Прадказальныя тэндэнцыі. Былі перыядычныя пікі трафіку, якія на першы погляд не карэлявалі з іншымі метрыкамі - трэба было зразумець, чаму такое здараецца і навучыцца прадказваць.
• Пашырэнне платформы. Бізнэс увесь час расце, прыходзіць усё больш карыстачоў, павялічваецца трафік.

У мінулым часта казалі: "Давайце ўсё перапішам на [мова/фрэймворк], усё стане працаваць лепш!"

У большасці выпадкаў гэта не спрацоўвае, добра, калі перапісанае ўвогуле будзе працаваць. Таму нам трэба было стварыць roadmap - канкрэтную стратэгію, якая ілюструе крок за крокам, як будуць дасягнуты бізнес-мэты (што мы будзем рабіць і для чаго), якая:

• адлюстроўвае місію і мэты праекта;
• прыярытэзуе асноўныя мэты;
• змяшчае графік іх дасягнення.

Да гэтага ніхто не размаўляў з камандай аб тым, для якой мэты робяцца любыя змены. Для гэтага патрэбны правільныя паказчыкі поспеху. Першы раз у гісторыі кампаніі мы паставілі KPI для тэхнічнай групы, прычым гэтыя паказчыкі прывязалі да арганізацыйных.

Гэта значыць арганізацыйныя KPI падтрымліваюцца камандамі, а камандныя KPI падтрымліваюцца ўжо індывідуальнымі. У адваротным выпадку, калі тэхналагічныя KPI не сыходзяцца з арганізацыйнымі, то кожны цягне коўдру на сябе.

Напрыклад, адзін з арганізацыйных KPI - гэта павелічэнне долі рынку з дапамогай новых прадуктаў.

Чым можна падтрымаць мэту мець больш новых прадуктаў?

• Па-першае, мы хочам марнаваць больш часу на распрацоўку новых прадуктаў замест таго, каб чыніць дэфекты. Гэтае лагічнае рашэнне, якое лёгка вымяраецца.
• Па-другое, мы хочам падтрымліваць павелічэнне аб'ёму транзакцый, таму што чым больш доля на рынку, тым больш карыстальнікаў і, адпаведна, тым больш трафіку.

Тады індывідуальныя KPI, якія могуць выконвацца ўсярэдзіне груп будуць, напрыклад, будуць у тым месцы, адкуль ідуць асноўныя дэфекты. Калі сфакусавацца менавіта на гэтай секцыі, можна зрабіць так, што дэфектаў стане значна менш, і тады павялічыцца час на распрацоўку новых прадуктаў і ізноў жа на падтрымку арганізацыйных KPI.

Такім чынам, кожнае рашэнне, у тым ліку перапісаць код, павінна падтрымліваць канкрэтныя мэты, якія кампанія перад намі паставіла (рост арганізацыі, новыя функцыі, набор персаналу).

Падчас гэтага працэсу выявілася цікавая рэч, якая стала навіной не толькі для тэхнароў, але наогул у кампаніі: усе цітэты павінны быць арыентаваны як мінімум на адзін KPI. Гэта значыць калі продакт кажа, што жадае зрабіць новую фічу, першае пытанне павінна быць зададзена: "Які KPI гэтая фіча падтрымлівае?" Калі ніякі, то прабачце - здаецца, гэта непатрэбная фіча.

Дзень трыццаты

У канцы месяца я выявіў яшчэ адзін нюанс, што ніхто з маёй Ops-каманды ніколі не бачыў кантракты, якія мы заключаем з кліентамі. Вы можаце спытаць, навошта бачыць кантакты.

• Па-першае, таму што ў кантрактах прапісаны SLA.
• Па-другое, SLA усё розныя. Кожны кліент прыходзіў са сваімі патрабаваннямі, а аддзел продажаў падпісваў не гледзячы.

Яшчэ цікавы нюанс - у кантракце з адным з самых вялікіх кліентаў напісана, што ўсе версіі софту, якія падтрымлівае платформа, павінны быць n-1, гэта значыць не самая апошняя версія, а перадапошняя.

Зразумела, наколькі мы былі далёкія ад n-1, калі платформа была на ColdFusion і SQL Server 2008 гады, які ў ліпені перасталі падтрымліваць наогул.

Дзень сорак пяты

Недзе да сярэдзіны другога месяца ў мяне вызвалілася дастаткова часу, каб сесці і зрабіць значэннепатокадлюстраванне цалкам на ўвесь працэс. Гэта неабходныя крокі, якія трэба зрабіць, ад стварэння прадукта да дастаўкі яго спажыўцу, прычым распісаць іх трэба максімальна падрабязна.

Разбіваеш працэс на маленькія кавалкі і глядзіш, што займае зашмат часу, што можна аптымізаваць, палепшыць і г.д. Напрыклад, колькі часу займае запыт ад прадукта, праход праз grooming, калі ён дойдзе да цікета, які распрацоўшчык можа ўзяць, QA і г.д. Так падрабязна глядзіш на кожны асобны крок і думаеш, што можна аптымізаваць.

Калі я гэта рабіў, у вочы кінуліся дзве рэчы:

• высокі працэнт вяртання тыкетаў з QA назад распрацоўшчыкам;
• pull request review займалі зашмат часу.

Праблема была ў тым, што гэта былі высновы нібыта: здаецца, шмат часу займае, але мы не ўпэўненыя, колькі менавіта.

"Нельга палепшыць тое, што нельга вымераць".

Як даказаць, наколькі праблема сур'ёзная? З-за яе трацяцца дні ці гадзіны?

Каб гэта вымераць, дадалі пару крокаў у Jira-працэс: "ready for dev" і "ready for QA", каб вымяраць, колькі часу кожны тыкет чакае і колькі разоў вяртаецца на пэўны крок.

Таксама мы дадалі "in review", каб ведаць, колькі ў сярэднім цікеты знаходзяцца на review, і ад гэтага ўжо танцаваць. Сістэмныя метрыкі ў нас былі, зараз мы дадалі новыя метрыкі, і сталі вымяраць:

• Эфектыўнасць працэсу: прадукцыйнасць і запланавана/дастаўлена.
• Якасць працэсу: колькасць дэфектаў, дэфекты ад QA.

Гэта сапраўды дапамагае разумець, што праходзіць добра, а што дрэнна.

Дзень пяцідзесяты

Гэта ўсё, вядома, добра і цікава, але бліжэй да канца другога месяца здарылася тое, што ў прынцыпе, было прадказальна, хаця я і не чакаў такога маштабу. Людзі пачалі сыходзіць, таму што памянялася вярхушка. У кіраўніцтва прыйшлі новыя людзі, якія пачалі ўсё мяняць, і старыя звальняліся. А звычайна ў кампаніі, якой некалькі гадоў, усе сябры і ўсе адно аднаго ведаюць.

Гэта было чакана, але нечаканым быў маштаб звальненняў. Напрыклад, за адзін тыдзень два тымліды адначасова падалі заяву на звальненне па ўласным жаданні. Таму мне прыйшлося не тое, што забыцца пра іншыя праблемы, але сфакусавацца на стварэнні калектыву. Гэта доўгая і цяжкавырашальная праблема, але ёй трэба было займацца, таму што хацелася захаваць людзей, якія засталіся (ці большасць з іх). Трэба было неяк рэагаваць на тое, што людзі пайшлі, каб падтрымліваць мараль у камандзе.

У тэорыі гэта добра: прыходзіць новы чалавек, у якога ёсць поўны карт-бланш, які можа ацаніць навыкі каманды і замяніць кадры. Насамрэч нельга проста так прывесці новых людзей па вельмі шматлікіх прычынах. Заўсёды патрэбен баланс.

• Старога і новага. Трэба захаваць старых людзей, якія могуць памяняцца і падтрымліваць місію. Але ў той жа час трэба прыўнесці новую кроў, пра гэта мы пагаворым крыху пазней.
• Досведу. Я шмат гаварыў з добрымі джуніёрамі, якія гарэлі і хацелі да нас на працу. Але я не мог іх узяць, таму што было недастаткова сеньёраў, якія б падтрымлівалі джуніёраў і былі для іх ментарамі. Трэба было спачатку набраць верхавіну і толькі потым моладзь.
• Пуга і перніка.

У мяне няма добрага адказу на пытанне, які баланс правільны, як яго падтрымліваць, колькі людзей пакідаць і наколькі ціснуць. Гэта чыста індывідуальны працэс.

Дзень пяцьдзесят першы

Я стаў прыглядацца да каманды, каб зразумець, хто ў мяне ёсць, і ў чарговы раз успомніў:

«Большасць праблем - гэта праблемы з людзьмі».

Я выявіў, што ў камандзе, як такой – і ў распрацоўшчыкаў, і ў Ops – ёсць тры вялікія праблемы:

• Задаволенасць бягучым станам рэчаў.
• Адсутнасць адказнасці - Таму што ніхто ніколі не прыводзіў вынікі працы выканаўцаў да ўплыву на бізнэс.
• Боязь перамен.

Перамены заўсёды выводзяць з зоны камфорту, і чым маладзейшыя людзі, тым больш яны не любяць перамены, таму што яны не разумеюць, навошта, і не разумеюць, як. Самы часты адказ, які я чуў: "Мы так ніколі не рабілі". Прычым даходзіла да поўнага абсурду - найменшыя змены не праходзілі без таго, каб хтосьці не абурыўся. Прычым усё роўна, наколькі змены датычыліся менавіта іх працы, людзі казалі: «Не, навошта? Гэта не спрацуе».

Але нельга стаць лепш, нічога не мяняючы.

У мяне была абсалютна абсурдная размова з супрацоўнікам, я расказваў яму свае ідэі па аптымізацыі, на што ён мне сказаў:
- А, гэта ты не бачыў, што ў нас было летась!
- Ну і што?
- Цяпер значна лепш, чым было.
- Дык што, не можа быць яшчэ лепш?
- А навошта?

Добрае пытанне - навошта? Як быццам, калі зараз лепш, чым было, значыць, усё дастаткова добра. Гэта прыводзіць да адсутнасці адказнасці, што ў прынцыпе абсалютна нармальна. Як я сказаў, тэхгрупа была крыху ўбаку. У кампаніі лічылі, што яны павінныя быць, але ніхто ніколі не ўсталёўваў стандарты. У тэхпадтрымцы ніколі не бачылі SLA, таму для гурта было цалкам "прымальна" (і гэта мяне ўразіла больш за ўсё):

• 12 секунд загрузка;
• 5-10 хвілін downtime кожны рэліз;
• ухіленне крытычных непаладак займае дні і тыдні;
• адсутнасць дзяжурных 24х7/on-call.

Ніхто ніколі не спрабаваў спытаць, чаму б нам не зрабіць гэта лепшым, і ніхто ніколі не разумеў, што так не павінна быць.

Як бонус, была яшчэ адна праблема: адсутнасць вопыту. Сеньёры сышлі, а астатняя маладая каманда вырасла пры ранейшым рэжыме і была ім атручана.

Да ўсяго гэтага людзі яшчэ і баяліся патрываць няўдачу, здацца некампетэнтнымі. Гэта выяўляецца ў тым, што яны, па-першае, ні пры якіх абставінах не прасілі дапамогі. Колькі разоў мы размаўлялі ў групе і індывідуальна, і я казаў: «Задайце пытанне, калі не ведаеце, як нешта зрабіць». Я ўпэўнены ў сабе і ведаю, што магу вырашыць любую праблему, але гэта зойме час. Таму калі можна спытаць у кагосьці, хто ведае, як яе вырашыць за 10 хвілін, я спытаю. Чым менш у цябе досведу, тым больш ты баішся пытацца, таму што думаеш, што цябе палічаць некампетэнтным.

Гэтая боязь задаць пытанне праяўляецца ў цікавых формах. Напрыклад, пытаешся: "Як справы з гэтай задачай?" — «Засталося на пару гадзін, ужо заканчваю». На наступны дзень зноў пытаешся, атрымліваеш адказ, што ўсё добра, але ўзнікла адна проблемка, да канца дня сапраўды будзе гатова. Праходзіць яшчэ дзень, і пакуль не прыціснеш да сценкі і не прымусіш з кімсьці пагаварыць, так усё і працягваецца. Чалавеку жадаецца вырашыць задачу самому, ён лічыць, што калі сам не вырашыць, гэта будзе вялікай няўдачай.

Менавіта таму распрацоўшчыкі завышалі ацэнкі. Гэта быў той яшчэ анекдот, калі абмяркоўвалі пэўную задачу, мне выдалі такую ​​лічбу, што я вельмі здзівіўся. На што мне сказалі, што ў estimates распрацоўшчык уключае і час, які тыкет будзе вяртацца з QA, таму што яны знойдуць там памылкі, і час, які зойме PR, і час пакуль людзі, якія павінны яго прагледзець, будуць занятыя - гэта значыць усё , што толькі магчыма.

Па-другое, людзі, якія баяцца здацца некампетэнтным, залішне аналізуюць. Калі кажаш, што канкрэтна трэба зрабіць, пачынаецца: "Не, а што, калі мы тут падумаем?" У гэтым сэнсе наша кампанія не ўнікальная, гэта стандартная праблема моладзі.

У адказ я ўвёў наступныя практыкі:

• Правіла 30 хвілін. Калі за паўгадзіны вы не можаце вырашыць праблему, папытаеце каго-небудзь дапамагчы. Гэта працуе з пераменным поспехам, таму што народ усё роўна не просіць, але хаця б працэс пачаўся.
• Выключыць усё, акрамя сутнасці, У ацэнцы тэрміну выканання задачы, гэта значыць лічыць толькі тое, колькі часу зойме напісанне кода.
• Бесперапыннае навучанне для тых, хто залішне аналізуе. Гэта проста сталая праца з людзьмі.

Дзень шасцідзесяты

Пакуль я ўсім гэтым займаўся, надышоў час разабрацца з бюджэтам. Вядома, я знайшоў шмат цікавага ў тым, куды мы марнавалі грошы. Напрыклад, у нас была цэлая стойка ў асобным дата-цэнтры, на якой стаяў адзін FTP-сервер, які выкарыстоўваўся адным кліентам. Аказалася, што "… мы пераязджалі, а ён так і застаўся, мы яго не памянялі". Гэта было 2 гады таму.

Асаблівую цікавасць прадстаўляў рахунак за паслугі аблокі. Я ўпэўнены, што асноўная прычына вялікага рахунку за хмарныя паслугі - гэта распрацоўшчыкі, у якіх першы раз у жыцці ёсць неабмежаваны доступ да сервераў. Ім не трэба прасіць: "Дайце мне, калі ласка, тэставы сервер", – яны могуць самі ўзяць. Плюс да гэтага распрацоўшчыкі заўсёды хочуць пабудаваць такую ​​крутую сістэму, каб Facebook з Netflix абзайздросціліся.

Але ў распрацоўшчыкаў няма досведу закупкі сервераў і навыку вызначэння патрэбнага памеру сервераў, таму што ім гэта раней не было трэба. І звычайна яны не зусім разумеюць розніцу паміж scalability і performance.

Вынікі інвентарызацыі:

• Выйшлі з аднаго дата-цэнтра.
• Скасавалі дамову з 3 лог-сэрвісамі. Таму што ў нас іх было 5 - кожны распрацоўшчык, які пачынаў з чымсьці гуляцца, браў новы.
• Выключылі 7 AWS-сістэм. Ізноў жа, памерлыя праекты ніхто не спыняў, яны ўсё так і працягвалі працаваць.
• Зменшылі выдаткі на софт у 6 разоў.

Дзень семдзесят пяты

Час ішоў, і праз два з паловай месяцы я павінен быў сустрэцца з парадай дырэктараў. Наша парада дырэктараў не лепшая і не горшая за іншых, яна як усе парады дырэктараў хоча ведаць усё. Людзі ўкладваюць грошы і жадаюць разумець, наколькі тое, што мы робім, укладваецца ў пастаўленыя KPI.

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

Праблема толькі ў тым, што я лічу, што сярэдняя велічыня - гэта чыстае зло. Але радзе дырэктараў гэта растлумачыць вельмі цяжка. Яны абвыклі апераваць агрэгаванымі лікамі, а не, напрыклад, роскідам часу загрузкі ў секунду.

У сувязі з гэтым былі цікавыя моманты. Напрыклад, я сказаў, што трэба падзяліць трафік паміж асобнымі вэб-серверамі ў залежнасці ад тыпу кантэнту.

Гэта значыць ColdFusion праходзіць праз праз Jetty і nginx і запускаў старонкі. А карцінкі, JS і CSS ідуць праз асобны nginx са сваімі канфігурацыямі. Гэта даволі стандартная практыка, пра якую я пісаў яшчэ пару гадоў таму. У выніку карцінкі загружаюцца значна хутчэй, і … сярэдняя хуткасць загрузкі павялічылася на 200 мс.

Гэта адбылося таму, што графік будуецца на аснове даных, якія ідуць з Jetty. Гэта значыць хуткі кантэнт у разлік не трапляе - сярэдняя велічыня падскочыла. Нам гэта было зразумела, мы пасмяяліся, але як растлумачыць радзе дырэктараў, чаму мы нешта зрабілі і стала горш на 12%?

Дзень восемдзесят пяты

Пад канец трэцяга месяца я зразумеў, што на адну рэч я зусім не разлічваў - гэта час. На ўсё, пра што я расказваў, патрабуецца час.

Гэта мой сапраўдны каляндар на тыдзень - проста працоўны тыдзень, не вельмі нагружаны. Часу на ўсё не хапае. Таму зноў-такі трэба набіраць людзей, якія дапамогуць справіцца з праблемамі.

Заключэнне

Гэта зусім не ўсё. У гэтым апавяданні я яшчэ нават не дайшоў да таго, як мы працавалі з прадуктам і спрабавалі настроіцца на агульную хвалю, ці як інтэгравалі тэхпадтрымку, ці як вырашалі іншыя тэхнічныя праблемы. Напрыклад, я зусім выпадкова даведаўся, што на самых вялікіх табліцах у базе дадзеных мы не карыстаемся SEQUENCE. У нас ёсць самапісная функцыя nextID, І выкарыстоўваецца яна не ў транзакцыі.

Быў яшчэ мільён падобных рэчаў, пра якія можна доўга казаць. Але самае важнае, пра што яшчэ варта сказаць, - гэта культура.

Менавіта культура ці яе адсутнасць вядзе да ўсіх астатніх праблем. Мы спрабуем пабудаваць культуру, дзе людзі:

• не баяцца няўдач;
• вучацца на памылках;
• супрацоўнічаюць з іншымі камандамі;
• праяўляюць ініцыятыву;
• бяруць адказнасць на сябе;
• вітаюць вынік як мэту;
• святкуюць поспех.

З гэтым усё астатняе прыйдзе.

Лявон Фаер у твітэры, facebook і на серада.

У стаўленні legacy ёсць дзве стратэгіі: усімі сіламі пазбягаць працы з ім, ці адважна пераадольваць спадарожныя цяжкасці. Мы c DevOpsConf ідзем па другім шляху, мяняючы працэсы і падыходы. Далучайцеся да нас у YouTube, рассылцы и тэлеграме, і будзем разам укараняць культуру DevOps.

Крыніца: habr.com