Відомо, що компетентність CTO перевіряється лише вдруге виконання цієї ролі. Тому що одна справа кілька років працювати в компанії, разом з нею еволюціонувати і, перебуваючи у тому самому культурному контексті, поступово отримувати більше відповідальності. І зовсім інше — прийти одразу на посаду техдиректора в компанію з багажем legacy та купою проблем, які акуратно помітили під килим.

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

Леон дуже колоритно розповідає російською мовою, тому якщо у вас є 35-40 хвилин, то рекомендую дивитися відео. Текстова версія для економії часу нижче.

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

За місяць до

Як і багато хороших історії, ця почалася з алкоголю. Ми сиділи зі знайомими в барі, і як належить у середовищі айтішників, кожен плакався про свої проблеми. Один із них щойно змінив роботу та розповідав про свої проблеми і з технологіями, і з людьми, і з командою. Що довше я слухав, то більше розумів, що йому треба просто найняти мене, бо саме такі проблеми я вирішував останні 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 секунд, тобто в 2 рази.

Судячи з графіка, явно щось трапилося, причому незрозуміло що. Виявилося, що проблема була в мережі 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 є дві стратегії: всіма силами уникати роботи з ним, або сміливо долати супутні труднощі. Ми з DevOpsConf йдемо другим шляхом, змінюючи процеси і підходи. Приєднуйтесь до нас у YouTube, розсилці и телеграмі, і разом впроваджуватимемо культуру DevOps.

Джерело: habr.com