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

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

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

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

Един месец преди

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

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 s за потребителите. Не знаех защо се случи това, но във всеки случай стана известно, че проблемът е в центъра за данни.

Ден първи

Минаха два дни и в първия ми работен ден открих, че проблемът не е изчезнал.

За два дни страниците на потребителите се зареждат средно за 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 билета на час за груминг сесия вече беше добър резултат.

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

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

• Намаляване на изправянето и митингите.
• Предметни познания за продукта.
• Чувство за собственост. Когато хората постоянно се занимаваха със системите, те знаеха, че някой друг най-вероятно ще трябва да работи с техните грешки, но не и те самите.
• Сътрудничество между групите. Излишно е да казвам, че QA не комуникираше много с програмисти преди, продуктът си вършеше собствените си неща и т.н. Сега те имат обща точка на отговорност.

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

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

В процеса на промяна на структурата на отбора открих как да броя ИсторияТочки. 1 SP се равняваше на един ден и всеки билет съдържаше SP както за разработка, така и за QA, тоест поне 2 SP.

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

Открихме грешка: в един от отчетите, където е въведена началната и крайната дата на периода, за който е необходим отчетът, не е отчетен последният ден. Тоест някъде в заявката не беше <=, а просто <. Казаха ми, че това са три Story Points, т.е 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, защото те ще открият грешки там, и времето, което PR ще отнеме, и времето, докато хората, които трябва да прегледат ще бъде натоварено - тоест всичко, каквото е възможно.

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

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

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

Ден шестдесети

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

Особен интерес предизвика сметката за облачните услуги. Вярвам, че основната причина за високата сметка за облак са разработчиците, които имат неограничен достъп до сървъри за първи път в живота си. Не е нужно да питат: „Моля, дайте ми тестов сървър“, те могат да го вземат сами. Плюс това, разработчиците винаги искат да изградят толкова готина система, че Facebook и Netflix да ревнуват.

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

Леон Файър в туитър, Facebook и среда.

Има две стратегии по отношение на наследството: избягване на работа с него на всяка цена или смело преодоляване на свързаните с него трудности. Ние c DevOpsConf Ние вървим по втория път, променяме процеси и подходи. Присъединете се към нас YouTube, пощенски списък и телеграмаи заедно ще внедрим DevOps култура.

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