Известно, че компетентността на CTO се проверява единствено при второто изпълнение на тази роля. Защото е едно да работиш няколко години в компания, да еволюираш заедно с нея и, оставайки в същия културен контекст, постепенно да поемаш повече отговорности. И съвсем друго — да влезеш веднага на поста технически директор в компания с наследство от стари технологии и куп проблеми, старателно скрити под килима.

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

Леон разказва много колоритно на руски, така че ако имате 35-40 минути, горещо препоръчвам да гледате видеото. Текстовата версия за спестяване на време е по-долу.

Първата версия на доклада беше добре структурирано описание на работа с хора и процеси, съдържащо полезни препоръки. Но тя не предаваше всичките изненади, които се срещнаха по пътя. Затова промених формата и изложих проблемите, които в новата компания възникнаха пред мен, като дявол от кутийка, и методите за тяхното решение в хронологичен ред.

Месец преди

Както много добри истории, тази започна с алкохол. Седяхме с познати в бара и, както е обичайно в средите на IT специалистите, всеки се оплакваше от проблемите си. Един от тях току-що бе сменил работата и разказваше за проблемите си с технологиите, хората и екипа. Колкото повече слушах, толкова повече осъзнавах, че той просто трябва да ме наеме, защото точно такива проблеми съм решавал през последните 15 години. Казах му го и на следващия ден се срещнахме в работна обстановка. Компанията се наричаше Teaching Strategies.

Teaching Strategies е лидер на пазара на образователни програми за деца от раждането до тригодишна възраст. Традиционната "хартиена" компания съществува от около 40 години, а цифровата SaaS версия на платформата – от 10. Напоследък започна процесът на адаптиране на цифровата технология към стандартите на компанията. "Новата" версия стартира през 2017 г. и беше почти като старата, само че работеше по-зле.

Най-интригуващото е, че трафикът на тази компания е много предсказуем — всеки ден, всяка година може много точно да се прогнозира колко хора ще дойдат и кога. Например, между 13 и 15 часа всички деца в детските градини отиват да спят, а учителите започват да въвеждат информация. И така става всеки ден, освен през уикендите, защото през уикендите почти никой не работи.

Изприказвайки малко напред, ще отбележа, че започнах работа в периода на най-голям годишен трафик, което е интересно по различни причини.

Платформата, която изглеждаше, че е на около 2 години, имаше своеобразен стек: ColdFusion & SQL Server 2008. ColdFusion, ако не знаете, а най-вероятно не знаете, — това е нещо като enterprise PHP, което излезе в средата на 90-те и от тогава не бях чувал за него. Освен това имаше: Ruby, MySQL, PostgreSQL, Java, Go, Python. Но основният монолит работеше на ColdFusion и SQL Server.

Проблеми

Колкото повече говорех със служителите на компанията за работата и за проблемите, с които се сблъскваха, толкова повече разбирах, че проблемите не са само технически. Добре, стара технология — работило се е и с по-стари, но имаше проблеми с екипа и с процесите, и компанията започваше да го осъзнава.

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

Следите на тежкото наследство присъстваха не само в системите. В компанията имаше legacy процеси, legacy хора, legacy култура. Всичко това трябваше да се промени. Помислих си, че определено няма да бъде скучно, и реших да опитам.

Два дни преди

Два дни преди да започна новата работа, дойдох в офиса, попълних последните документи, запознах се с екипа и открих, че екипът по това време се бори с проблем. Той се състоеше в това, че средното време за зареждане на страниците е скочило до 4 сек, тоест два пъти.

Съдейки по графика, явно нещо се е случило, а не е ясно какво. Оказа се, че проблемът е в мрежовата латентност в дата центъра: 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 Server — същият от който току-що бяха прочетени данни.

Ден десети

Първата седмица прекарах с проблемите, които трябваше да реша веднага. Някъде около втората седмица за първи път дойдох на стендъп, за да общувам с екипа, да видя какво се случва и как върви целият процес.

Отново се откриха интересни неща. Екипът се състоеше от: 18 разработчици; 8 тестери; 3 мениджъри; 2 архитекта. И всички те участваха в общи ритуали, т.е. над 30 човека идваха на стендъп всяка сутрин и разказваха какво са правили. Ясно е, че срещата не отнемаше 5 и не 15 минути. Никой не слушаше другия, защото всички работят по различни системи. В такъв формат 2-3 тикета на час по време на grooming сесия вече бяха добър резултат.

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

В резултат получихме:

• Съкращаване на стендаповете и срещите.
• Темата знание на продукта.
• Чувство за собственост. Когато преди хората постоянно се ротират между системите, знаят, че работата им по техните бъгове вероятно ще се наложи на някой друг, но не и на тях самите.
• Сътрудничество между групите. Не е нужно да се споменава, че 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 г., който вече не се поддържа от юли.

Ден четиридесет и пет

Към средата на втория месец се освободи достатъчно време, за да седна и да направя стойностstreamсъответствие напълно за целия процес. Това са задължителни стъпки, които трябва да предприемем от създаването на продукта до доставката му на клиента, като всички те трябва да бъдат описани възможно най-подробно.

Разделяш процеса на малки парченца и гледаш какво отнема твърде много време, какво може да се оптимизира, усъвършенства и т.н. Например, колко време отнема запитването от продукта, преминаването през grooming, когато стигне до тикета, който разработчиците могат да вземат, QA и т.н. Така подробно гледаш на всяка отделна стъпка и мислиш какво може да се оптимизира.

Когато го направих, две неща ми направиха впечатление:

• висок процент на връщане на тикетите от QA обратно към разработчиците;
• прегледът на pull request-ите отнемаше твърде много време.

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

„Няма как да подобриш това, което не можеш да измериш.“

Как да обосновем колко сериозен е проблемът? Отнема ли дни или часове?

За да можем да измерим, добавихме няколко стъпки в Jira процеса: „готово за разработка“ и „готово за QA“, за да измерим колко време всеки тикет чака и колко пъти се връща на определен етап.

Също така добавихме „в преглед“, за да знаем колко средно тикетите са на преглед, и от това да изпълняваме следващите стъпки. Имахме системни метрики, сега добавихме нови метрики и започнахме да измерваме:

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

Това наистина помага да се разбере какво върви добре и какво не.

Ден петдесет

Всичко това, разбира се, е добре и интересно, но към края на втория месец се случи нещо, което в принципе беше предсказуемо, макар и да не очаквах такъв мащаб. Хората започнаха да напускат, защото на върха се смениха хората. В ръководството дойдоха нови лица, които започнаха да правят промени, а старите напускаха. А обикновено в компания, която съществува няколко години, всички са приятели и се познават.

Това беше очаквано, но масштабът на уволненията бе изненадващ. Например, в една седмица двама тимлида едновременно подадоха заявления за напускане по собствено желание. Затова ми се наложи не само да забравя другите проблеми, а и да се фокусирам върху създаването на екип. Това е дългосрочен и труден проблем, но трябваше да се адресира, защото исках да запазя хората, които останаха (или поне повечето от тях). Трябваше да реагирам на напускането на хората, за да поддържам морала в екипа.

В теорията това е добре: идва нов човек, който има пълна свобода и може да оцени уменията на екипа и да замени кадри. На практика обаче не може просто така да се доведат нови хора по много причини. Винаги е необходим баланс.

• Старото и новото. Необходимо е да се запазят старите хора, които могат да се променят и да поддържат мисията. Но в същото време е нужно да се внесе нова кръв; за това ще говорим малко по-късно.
• Опит. Много говорих с добри джуниори, които горяха от желание да се присъединят към нас. Но не можех да ги наема, защото нямаше достатъчно сеньори, които да подкрепят джуниорите и да бъдат ментори за тях. Първо трябваше да събера компетентния екип и едва след това младите.
• Дворец и пръстен.

Нямам добър отговор на въпроса какъв баланс е правилен, как да го поддържам, колко хора да оставя и как да натискам. Това е чисто индивидуален процес.

Ден петдесет и първи

Започнах да наблюдавам екипа, за да разбера кой е на разположение, и отново си припомних:

„Повечето проблеми са проблеми с хората“.

Открих, че в екипа, както при разработчиците, така и при Ops, има три основни проблема:

• Недоволство от текущото положение.
• Липса на отговорност — защото никой никога не свързва резултатите от работата на изпълнителите с влиянието върху бизнеса.
• Страх от промяна.

Промените винаги ни извеждат от зоната на комфорт, а колкото по-млади са хората, толкова повече не харесват промените, защото не разбират защо и как. Най-честият отговор, който чух, беше: „Ние никога не сме го правили по този начин“. Стигаше се дотам, че дори най-малките промени не минаваха без нечие недоволство. И не беше важно колко промените се отразяваха на тяхната работа, хората казваха: „Не, защо? Това няма да проработи“.

Но не можете да станете по-добри, ако не промените нищо.

Имах напълно абсурден разговор с един служител, разказвах му за идеите си за оптимизация, на което той ми каза:
— А, не видя ли какво беше при нас миналата година!
— И какво от това?
— Сега е много по-добре, отколкото беше.
— Така че, не може ли да бъде още по-добре?
— А защо?

Добър въпрос — защо? Като че ли, ако сега е по-добре, отколкото беше, значи всичко е достатъчно добре. Това води до отсъствие на отговорност, което по принцип е напълно нормално. Както казах, техническият екип беше малко встрани. В компанията смятаха, че трябва да бъдат, но никой никога не е задавал стандарти.В техническата поддръжка никога не бяха виждали SLA, затова за екипа беше напълно „приемливо“ (и това най-много ме изненада):

• 12 секунди за зареждане;
• 5-10 минути престой всеки релиз;
• отстраняването на критични проблеми отнема дни и седмици;
• липса на дежурни 24/7 / on-call.

Никой никога не се опитваше да попита защо да не направим това по-добре, и никой никога не разбираше, че не трябва да бъде така.

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

Към всичко това, хората се страхуваха от провал, да изглеждат некомпетентни. Това се изразява в това, че те, първо, при никакви обстоятелства не моли за помощ.Колко пъти говорихме в групата и индивидуално, и аз казвах: „Задайте въпрос, ако не знаете как да направите нещо“. Уверен съм в себе си и знам, че мога да реша всеки проблем, но ще отнеме време. Затова, ако мога да питам някого, който знае как да го реши за 10 минути, ще попитам. Колкото по-малко опит имаш, толкова повече се страхуваш да питаш, защото мислиш, че ще те сметнат за некомпетентен.

Тази страх да зададеш въпрос приема интересни форми. Например, питаш: „Как е положението с тази задача?“ — „Остава още няколко часа, вече завършвам“. На следващия ден отново питаш, получаваш отговор, че всичко е наред, но се е получила една малка проблемка, до края на деня определено ще бъде готово. Минава още един ден и докато не притиснеш човека до стената и не го накараш да говори с някого, това продължава. Човекът иска да реши задачата сам, смята, че ако не я реши сам, ще бъде голям провал.

Точно затова разработчиците завишават оценките. Това беше нещо като анекдот, когато обсъждахме определена задача, ми дадоха такава цифра, че много се изненадах. На което ми казаха, че в оценките разработчикът включва и времето, необходимо за завръщането на тикета от QA, защото те ще намерят там грешки, и времето, което ще отнеме PR, и времето, в което хората, които трябва да го прегледат, ще бъдат заети — тоест всичко, което може да се случи.

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

В отговор въведох следните практики:

• Правило от 30 минути. Ако за половин час не може да решите проблема, помолете някого за помощ. Това работи с променлив успех, защото хората все пак не питат, но поне процесът започва.
• Изключете всичко освен същността, в оценката на срока за изпълнение на задачата, тоест да се счита само времето, необходимо за написване на кода.
• Непрекъснато обучение за тези, които прекалено анализират. Това е просто постоянна работа с хора.

Шестдесетият ден

Докато се занимавах с всичко това, дойде време да се разбера с бюджета. Разбира се, намерих много интересни неща относно къде харчехме парите. Например, имахме цяла стойка в отделен дата център, на която стоеше един FTP сървър, използван от един клиент. Оказа се, че „... се местехме, а той остана, не го сменихме“. Това беше преди 2 години.

Особен интерес представляваше сметката за облачните услуги. Убеден съм, че основната причина за високата сметка за облачни услуги е, че разработчиците, за първи път в живота си, имат неограничен достъп до сървъри. Те не трябва да молят: „Може ли да получа тестов сървър?“, – те могат сами да го вземат. Освен това, разработчиците винаги искат да изградят толкова страхотна система, че Facebook и Netflix да завидят.

Но разработчиците нямат опит в закупуването на сървъри и умението да определят нужния размер на сървърите, тъй като никога не им е било необходимо. Обикновено те не съвсем разбират разликата между мащабируемост и производителност.

Резултатите от инвентаризацията:

• Излезли сме от един дата център.
• Разторгнали сме договора с 3 лог-сервиза. Защото имахме 5 — всеки разработчик, който започваше да експериментира, взимаше нов.
• Изключили сме 7 AWS системи. Отново, мъртви проекти не са били спирани, те продължаваха да работят.
• Намалихме разходите за софтуер шест пъти.

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

Времето минаваше и след два и половина месеца трябваше да се срещна с борда на директорите. Нашият борд на директорите не е по-добър и не е по-лош от другите, той, както всички бордове на директори, иска да знае всичко. Хората инвестират пари и искат да разбират какво правим и как то се вписва в зададените KPI.

Бордът на директорите получава много информация всеки месец: брой потребители, техния растеж, какви услуги ползват и как, производителност и продуктивност, накрая, средна скорост на зареждане на страницата.

Проблемът е, че смятам, че средната стойност е чисто зло. Но обяснението на това на борда на директорите е много трудно. Те са свикнали да оперират с агрегирани числа, а не, например, с разпределение на времето за зареждане в секунди.

В тази връзка имаше интересни моменти. Например, казах, че трябва да разделим трафика между отделните уеб сървъри в зависимост от типа съдържание.

Тоест, ColdFusion минава през Jetty и nginx и зарежда страниците. А изображенята, JS и CSS минават през отделен nginx с неговите конфигурации. Това е доста стандартна практика, за която... писах говорих преди две години. Резултатът е, че изображенията се зареждат много по-бързо и … средната скорост на зареждане се е увеличила с 200 мс.

Това се случи, защото графикът се изгражда на базата на данни, които идват от Jetty. Тоест бързото съдържание не се включва в сметките — средната стойност скочи. Ние разбрахме това, посмяхме се, но как да обясним на съвета на директорите защо сме направили нещо и резултатът стана по-лош с 12%?

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

Към края на третия месец осъзнах, че за едно нещо изобщо не бях предвидил — времето. За всичко, за което говорих, е необходимо време.

Това е истинският ми календар за седмицата — просто работна седмица, не много натоварена. Времето не стига за всичко. Затова отново трябва да наемем хора, които ще помогнат с проблемите.

Заключение

Това не е всичко. В тази история даже не съм стигнал до това как работихме с продукта и се опитвахме да се настроим на една и съща вълна, или как интегрирахме техническата поддръжка, или как решавахме други технически проблеми. Например, случайно разбрах, че на най-големите таблици в базата данни не използваме БРОЙ. Имаме самописна функция nextID, и тя не се използва в транзакцията.

Имаше още милион подобни неща, за които може да се говори дълго. Но най-важното, за което все още трябва да се спомене, е културата.

Точно културата или нейното отсъствие води до всички останали проблеми. Опитваме се да изградим култура, в която хората:

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

С това всичко останало ще дойде.

Леон Файер в Twitter, facebook и на medium.

Що се отнася до наследството, има две стратегии: с всички сили да избягваме работа с него, или смело да преодоляваме съпътстващите трудности. Ние вървим по втория път, променяйки процесите и подходите. Присъединете се към нас в DevOpsConf Telegram youtube, рассылка и , и ще внедряваме културата DevOps заедно., и ще внедряваме заедно културата на DevOps.

Източник: habr.com