Як взагалі зрозуміти стан чогось?
Можна покластися на свою думку, сформовану з різних джерел інформації, наприклад публікацій на сайтах або досвіду. Можна запитати колег, знайомих. Ще варіант — подивитися на теми конференцій: програмний комітет — активні представники індустрії, тому ми їм довіряємо у виборі актуальних тем. Окремий напрямок – це дослідження та звіти. Але є проблема. Дослідження стану DevOps щорічно проводяться у світі, звіти публікуються закордонними компаніями і про російську DevOps інформацію там майже немає.
Але настав той день, коли таке дослідження провели, і ми сьогодні розповімо про отримані результати. Стан DevOps в Росії досліджували спільно компанії» та «». Компанія «Експрес 42» допомагає технологічним компаніям впроваджувати та розвивати DevOps практики та інструменти і одна з перших почала розповідати про DevOps у Росії. Автори дослідження — Ігор Курочкін та Віталій Хабаров займаються у компанії «Експрес 42» аналізом та консалтингом, маючи при цьому технічний бекграунд з експлуатації та досвід роботи в різних компаніях. За 8 років колеги переглянули десятки компаній та проектів — від стартапу до ентерпрайзу — з різними проблемами, а також різною культурною та інженерною зрілістю.
У своїй доповіді Ігор та Віталій розповіли, які проблеми були у процесі дослідження, як вони їх вирішили, а також про те, як у принципі проводяться дослідження DevOps та чому «Експрес 42» вирішили провести своє. Їхній звіт можна подивитися .
Дослідження DevOps
Розмову розпочав Ігор Курочкін.
Ми регулярно ставимо запитання аудиторії на DevOps конференціях: Чи читали ви звіт стану DevOps за цей рік? Піднімають руки одиниці, а наше дослідження показало, що лише третина вивчають їх. Якщо ви ніколи не бачили таких звітів, скажемо відразу, що всі вони дуже схожі. Найчастіше там зустрічаються фрази на кшталт: «Порівняно з минулим роком…»
Тут у нас виникла перша проблема, а за нею ще дві:
- Ми не маємо даних за минулий рік. Стан DevOps у Росії нікому не цікавий;
- Методологія Незрозуміло, як перевіряти гіпотези, як ставити питання, як проводити аналіз, порівнювати результати, знаходити зв'язки;
- Термінологія. Всі звіти англійською мовою, потрібний переклад, спільного фреймворку з DevOps ще не винайшли і кожен вигадує своє.
Погляньмо, як взагалі проводилися аналізи станів DevOps у світі.
Історична довідка
Дослідження DevOps проводяться з 2011 року. Першою їх провела компанія Puppet – розробник систем управління конфігурацією. На той момент це був один із основних інструментів для опису інфраструктури у вигляді коду. До 2013 року ці дослідження були просто у вигляді опитувань у закритому форматі та без публічних звітів.
У 2013 році з'явилася компанія IT Revolution, видавець всіх основних книг з DevOps. Вони разом з Puppet підготували першу публікацію "State of DevOps", там вперше з'явилися 4 ключові метрики. Наступного року підключилася консалтингова компанія ThoughtWorks, відома своїми регулярними технологічними радарами з практик та інструментів в індустрії. А у 2015 році додався розділ із методологією, і стало зрозуміло, як вони виконують аналіз.
2016 року автори дослідження, створивши свою компанію DORA (DevOps Research and Assessment), опублікували щорічний звіт. Наступного року DORA та Puppet востаннє випустили спільний звіт.
А далі почалося цікаве:
У 2018 році компанії розділилися і вийшло два незалежні звіти: один від компанії Puppet, другий від компанії DORA спільно з Google. DORA продовжила використовувати свою методологію з ключовими метриками, профілями продуктивності та інженерними практиками, які впливають на ключові метрики та продуктивність усієї компанії. А Puppet запропонував свій підхід з описом процесу та еволюцією DevOps. Але історія не прижилася, в 2019 році Puppet від цієї методології відмовився і випустив нову версію звітів, в якій перерахував ключові практики і як вони впливають на DevOps з їхньої точки зору. Тоді ж трапилася ще одна подія: Google купила DORA, і разом вони випустили ще один звіт. Можливо ви його бачили.
Цього року все стало складно. Відомо, що Puppet запустив своє опитування. Вони це зробили на тиждень раніше, ніж ми, і він уже завершився. Ми взяли в ньому участь і переглянули, які теми їх цікавлять. Зараз Puppet виконує свій аналіз та готує публікацію звіту.
А ось анонсу від DORA та Google досі немає. У травні, коли зазвичай починалося опитування, надійшла інформація, що Ніколь Форсгрен, одна із засновників компанії DORA, перейшла в іншу компанію. Тому ми припустили, що цього року досліджень та звіту від DORA не буде.
Які справи в Росії?
У нас досліджень з DevOps не проводилося. Ми виступали на конференціях, переказуючи чужі висновки і Райффайзенбанк переклав «State of DevOps» за 2019 рік (ви можете знайти їхній анонс на Хабрі), велике їм спасибі. І це все.
Тому ми провели власне дослідження у Росії, використовуючи методології та висновки DORA. Ми використовували звіт колег із Райффайзенбанку для свого дослідження, у тому числі й для синхронізації термінології та перекладу. А актуальні для індустрії питання взяли зі звітів DORA та опитувальника Puppet цього року.
Процес дослідження
Звіт – це лише фінальна частина. Весь процес дослідження складається з чотирьох великих етапів:
На етапі підготовки ми опитали експертів з індустрії та підготували список гіпотез. На їх основі склали питання та запустили опитування на весь серпень. Потім ми проаналізували та підготували сам звіт. У DORA цей процес триває 6 місяців. Ми вклалися у 3 місяці, і зараз розуміємо, що часу нам ледь вистачило: тільки виконуючи аналіз, ти розумієш, які питання потрібно ставити.
Учасники
Усі закордонні звіти починаються з портрета учасників, і більшість із них — не з Росії. Відсоток російських респондентів плаває від 5 до 1% рік у рік, і це не дозволяє зробити будь-які висновки.
Карта зі звіту Accelerate State of DevOps 2019:
У нашому дослідженні нам вдалося опитати 889 осіб — це досить багато (DORA у своїх звітах щорічно опитує близько тисячі осіб) і тут ми досягли мети:
Щоправда, не всі наші учасники дійшли до кінця: відсоток заповнення вийшов трохи меншим за половину. Але й цього вистачило для отримання репрезентативної вибірки та проведення аналізу. DORA у своїх звітах не розкриває відсотка заповнення, тому тут порівняти не вдасться.
Галузі та посади
Наші респонденти репрезентують десяток галузей. Половина працює у сфері інформаційних технологій. Далі йдуть фінансові послуги, торгівля, телекомунікації та інші. Серед посад це фахівці (розробник, тестувальник, інженер експлуатації) та керуючий склад (керівники команд, груп, напрямків, директори):
Кожен другий працює у компанії середнього розміру. У великих компаніях працює кожний третій. Більшість працюють у командах до 9 осіб. Окремо ми питали про основні активності, і більшість так чи інакше пов'язана з експлуатацією, а розробкою займається близько 40%:
Так ми зібрали інформацію для порівняння та аналізу представників різних галузей, компаній, команд. Про аналіз розповість мій колега Віталій Хабаров.
Аналіз та порівняння
Віталій Хабаров: Дякую всім учасникам, які пройшли наше опитування, заповнили анкети і дали нам дані для подальшого аналізу та перевірки наших гіпотез. А завдяки нашим клієнтам та замовникам у нас є багатий досвід, який допоміг визначити хвилюючі індустрію питання та сформулювати гіпотези, які ми перевірили у нашому дослідженні.
На жаль, не можна просто взяти список питань з одного боку і дані — з іншого, якось їх зіставити, сказати: «Так, усе так і працює, ми мали рацію» і розійтися. Ні, потрібна методологія та статистичні методи, щоб бути впевненим, що ми не помилилися і наші висновки є достовірними. Тоді ми можемо на основі цих даних будувати нашу подальшу роботу:
Ключові метрики
За основу ми взяли методологію DORA, яку вони докладно описали у книзі Accelerate State of DevOps. Ми перевірили, а чи підходять ключові метрики для російського ринку, чи можна їх використовувати так само, як використовує DORA, щоб відповісти на запитання: "Наскільки індустрія в Росії відповідає зарубіжній індустрії?"
Ключові метрики:
- Частота розгортань. Як часто відбувається розгортання нової версії програми на продуктове оточення (планових змін, виключаючи хотфікси та реакцію на інциденти)?
- Термін поставки. Скільки в середньому проходить між коммітом зміни (написанням функціональності у вигляді коду) і розгортанням зміни на продуктовому оточенні?
- Час відновлення. Скільки в середньому займає відновлення програми на продуктовому оточенні після інциденту, деградації сервісу або виявлення помилки, що впливає на користувачів програми?
- Неуспішні зміни. Який відсоток розгортань на продуктовому оточенні призводить до деградації програми або інцидентів і вимагає усунення наслідків (відкат змін, розробку хотфіксу чи патчу)?
DORA у своїх дослідженнях знайшла зв'язок між цими метриками та організаційною ефективністю. Ми її теж перевіряємо у нашому дослідженні.
Але щоби переконатися, що чотири ключові метрики можуть на щось впливати, треба зрозуміти — а між собою вони якось пов'язані? DORA відповіла ствердно з одним застереженням: зв'язок між неуспішними змінами (Change Failure Rate) і трьома іншими метриками трохи слабший. У нас вийшла приблизно така сама картина. Якщо термін постачання, частота розгортання та час відновлення між собою корелюють (ми встановили цю кореляцію через кореляцію Пірсона та через шкалу Чеддока), то з неуспішними змінами такої сильної кореляції немає.
У принципі, більшість респондентів схильна відповідати, що вони досить-таки мала кількість інцидентів відбувається на продакшені. Хоча надалі ми побачимо, що між групами респондентів все одно є суттєва різниця за показником неуспішних змін, для цього поділу ми поки що не можемо використати цю метрику.
Ми це пов'язуємо з тим, що (як з'ясувалося у процесі аналізу та спілкування з деякими нашими замовниками) є невелика різниця у сприйнятті, що вважати інцидентом. Якщо ми встигли відновити працездатність нашого сервісу під час технічного вікна, чи можна вважати це інцидентом? Напевно, ні, бо ми всі виправили, ми молодці. Чи можна вважати інцидентом, якщо нам довелося у нормальному, звичному для нас режимі 10 разів перевикотити наш додаток? Здається ні. Тому питання взаємозв'язку неуспішних змін з іншими метриками залишається відкритим. Ми уточнюватимемо його надалі.
Тут важливо, що ми знайшли значну кореляцію між термінами постачання, часом відновлення та частотою розгортання. Тому ці три метрики ми взяли для подальшого поділу респондентів на групи з продуктивності.
Скільки вішати в грамах?
Ми використовували ієрархічний кластерний аналіз:
- Розподіляємо респондентів за n-мірним простором, де координата кожного респондента — їхні відповіді на запитання.
- Кожного респондента оголошуємо маленьким кластером.
- Об'єднуємо два найбільш наближені один до одного кластери в один кластер більше.
- Знаходимо наступну пару кластерів і об'єднуємо їх у кластер більше.
Так ми групуємо всіх наших респондентів у потрібну кількість кластерів. За допомогою дендрограми (дерево зв'язків між кластерами) бачимо відстань між двома сусідніми кластерами. Все, що нам залишається - встановити якийсь ліміт відстані між цими кластерами і сказати: «Ці дві групи між собою досить помітні тому, що відстань між ними гігантська».
Але тут є прихована проблема: ми не маємо обмежень на кількість кластерів — можемо отримати 2, 3, 4, 10 кластерів. І першою ідеєю було чому б не ділити всіх наших респондентів на 4 групи, як це робить DORA. Але з'ясували, що різницю між цими групами стають незначними, і ми можемо бути певні, що респондент справді належить своїй групі, а чи не сусідньої. Російський ринок ми поки що не можемо поділити на чотири групи. Тому ми зупинилися саме на трьох профілях, між якими є статистично значуща відмінність:
Далі ми за кластерами визначили профіль: ми взяли медіани для кожної метрики за кожною групою та склали табличку профілів ефективності. Практично вийшли профілі ефективності середнього учасника кожної групи. Ми виділили три профілю ефективності: Low, Medium, High:
Тут ми підтвердили нашу гіпотезу про те, що чотири ключові метрики підходять для визначення профілю ефективності, і вони працюють як на західному, так і на російському ринку. Різниця між групами є і вона статистично значуща. Підкреслю, що між профілями ефективності за метрикою неуспішних змін є значна різниця в середньому, навіть незважаючи на те, що ми спочатку не ділили респондентів за цим параметром.
Далі постає питання: як усім цим користуватися?
Як користуватися
Якщо взяти будь-яку команду, 4 ключові метрики і застосувати до таблиці, то в 85% випадків ми не отримаємо повного збігу — це лише середній учасник, а не те, що є насправді. Ми всі (і кожна команда) трохи відрізняємось.
Ми перевірили: взяли наших респондентів та профіль ефективності DORA і подивилися, скільки респондентів відповідають тому чи іншому профілю. Ми отримали, що лише 16% респондентів точно потрапили в один із профілів. Всі інші розкидані десь посередині між ними:
Це означає, що профіль ефективності є обмежена область застосування. Для розуміння, де ви знаходитесь в першому наближенні, можна використовувати цю таблицю: «О, здається, ми ближче до Medium або High!» Якщо ви розумієте, куди вам рухатись далі, цього може вистачити. Але якщо ваша мета - постійне, безперервне покращення, і ви хочете точніше знати, куди розвиватися і що робити, то потрібні додаткові кошти. Ми їх назвали калькулятори:
- Калькулятор DORA
- Калькулятор Експрес 42* (у розробці)
- Своя технологія (можна скласти свій внутрішній калькулятор).
Навіщо вони потрібні? Щоб зрозуміти:
- Команда усередині нашої організації відповідає нашим стандартам?
- Якщо ні, то чи можемо ми їй допомогти прискорити її в рамках тієї експертизи, яка є в нашій компанії?
- Якщо так, то чи можемо зробити ще краще?
Ще ви з їх допомогою можете зібрати статистику всередині компанії:
- Які у нас команди є;
- Поділити команди на профілі;
- Побачити: О, ці команди у нас underperforming (трохи не витягують), а ці класні: вони деплоять щодня, без помилок, lead time у них менше години.
І тоді ви можете з'ясувати, що всередині нашої компанії є необхідні експертиза та інструменти для тих команд, які поки що не дотягують.
Або, якщо ви розумієте, що всередині компанії ви почуваєтеся чудово, ви краще за багатьох, то можна поглянути трохи ширше. Це російська індустрія: чи можемо ми отримати необхідну експертизу в російській індустрії, щоб прискоритися самим? Тут допоможе калькулятор Експрес 42 (він у процесі розробки). Якщо ви переросли російський ринок, то дивіться та на світовий ринок.
Добре. А якщо ви знаходитесь у групі Elit за калькулятором DORA, то що робити? Гарного рішення тут немає. Швидше за все ви перебуваєте на передовій індустрії, і подальше прискорення та підвищення надійності можливі за рахунок внутрішнього R&D та витрат великих ресурсів.
Перейдемо до найсолодшого порівняння.
Порівняння
Ми спочатку хотіли порівняти російську індустрію із західною індустрією. Якщо порівнювати безпосередньо, то бачимо, що у нас менше профілів, і вони трохи більше перемішані між собою, кордони трохи розмиті:
Наші Elite-перформери приховані серед High-перформерів, але вони є еліта, єдинороги, які досягли значних висот. У Росії різниця між профілем Elite і профілем High поки що недостатньо значуща. Ми вважаємо, що у майбутньому цей поділ відбудеться у зв'язку з підвищенням інженерної культури, якості впровадження інженерних практик та експертизи всередині компаній.
Якщо переходити до прямого порівняння всередині російської промисловості, ми бачимо, що команди профілю High краще за всіма показниками. Також ми підтвердили нашу гіпотезу про те, що є зв'язок між цими метриками та організаційною ефективністю: команди профілю High значно частіше не лише досягають цілей, а й перевершують їх.
Давайте ставати командами профілю High і не зупинятися на досягнутому:
Але цей рік особливий, і ми вирішили перевірити, як компанії живуть в умовах пандемії: команди профілю High значно краще справляються і почуваються краще, ніж у середньому по індустрії:
- У 1,5-2 рази частіше випускали нові продукти,
- У 2 рази частіше підвищували надійність та/або продуктивність інфраструктури додатків.
Тобто ті компетенції, які вони вже були, допомогли їм розвиватися швидше, виводити нові продукти, модифікувати вже існуючі продукти, тим самим завойовуючи нові ринки та нових користувачів:
Що ще допомогло нашим командам?
Інженерні практики
Розповім про значні знахідки з кожної практики, які ми перевірили. Можливо, щось допомогло командам, але ми говоримо про DevOps. І в рамках DevOps ми бачимо різницю серед команд різних профілів.
Платформа як сервіс
Ми не виявили значного зв'язку між віком платформи та профілем команди: Платформи з'явилися приблизно в один і той же час і у Low-команд, і у High-команд. Але в останніх платформа надає в середньому більше сервісів та більше програмних інтерфейсів для керування через програмний код. А платформні команди частіше допомагають своїм розробникам та командам користуватися платформою, частіше вирішують їхні проблеми та інциденти, пов'язані з платформою, та навчають інші команди.
Інфраструктура як код
Тут усе досить стандартно. Ми знайшли взаємозв'язок між автоматизацією роботи інфраструктурного коду та тим, скільки інформації зберігається всередині інфраструктурного репозиторію. Команди профілю High зберігають у репозиторіях більше інформації: це конфігурація інфраструктури, CI/CD пайплайна, налаштування оточення і параметри складання. Вони частіше зберігають цю інформацію, краще працюють з інфраструктурним кодом та автоматизували більше процесів та завдань по роботі з інфраструктурним кодом.
Цікаво, що ми не побачили значної різниці щодо інфраструктурних тестів. Я пов'язую це з тим, що у команд профілю High загалом більше автоматизації тестування. Можливо, їм не варто відволікатися окремо на інфраструктурні тести, а достатньо тих тестів, якими вони перевіряють додатки, і завдяки їм уже бачать, що і де вони зламалися.
Інтеграція та постачання
Найнудніший розділ, тому що ми підтвердили: чим більше у вас автоматизації, чим краще ви працюєте з кодом, тим швидше отримуєте кращі показники.
Архітектура
Ми хотіли подивитись, наскільки мікросервіси впливають на продуктивність. Якщо по правді, не впливають, оскільки застосування мікросервісів не пов'язане з підвищенням показників ефективності. Мікросервіси використовуються як у команд профілю High, так і у команд профілю Low.
Але важливим є те, що для High-команд перехід на мікросервісну архітектуру дозволяє їм незалежно розробляти свої послуги і викочуватися. Якщо архітектура дозволяє розробникам діяти автономно, не чекати на когось зовнішнього по відношенню до команди, то це є ключовою компетенцією для підвищення швидкості. І тут мікросервіси допомагають. А просто їх використання великої ролі не грає.
Як ми це виявили?
Ми мали амбітний план повністю відтворити методологію DORA, але не вистачило ресурсів. Якщо DORA використовує велику спонсорську підтримку та дослідження у них займає півроку, своє дослідження ми провели у стислий термін. Ми хотіли створити модель DevOps, як це робить DORA, і ми зробимо це в майбутньому. Поки що ми обмежилися тепловими картами:
Ми переглянули, який розподіл інженерних практик у команд кожного профілю, і виявили, що команди профілю High в середньому частіше застосовують інженерні практики. Про все це можна докладніше прочитати в нашому .
Для різноманітності перейдемо зі складної статистики на просту.
Що ми знайшли ще?
Інструменти
Ми спостерігаємо, що найбільше команд використовує ОС сімейства Linux. Але Windows все ще в тренді – не менше чверті наших респондентів відзначили використання тієї чи іншої його версії. Здається, що ринок має цю потребу. Тому ви можете розвивати дані компетенції та виступати з доповідями на конференціях.
Серед оркестраторів ні для кого не секрет лідирує Kubernetes (52%). Наступний по черзі оркестратор - Docker Swarm (близько 12%). Найбільш популярні CI-системи - Jenkins та GitLab. Найбільш популярна система управління конфігурацією – Ansible, а за ним – наш з вами улюблений Shell.
Серед хмарних хостингів поки лідируючу позицію займає Amazon. Частка російських хмар поступово збільшується. Наступного року буде цікаво подивитися, як російські хмарні провайдери почуватимуться, чи підвищиться їхня частка ринку. Вони є, ними можна користуватися, і це добре:
Передаю слово Ігореві, який дасть ще трохи статистики.
Поширення практик
Ігор Курочкін: Окремо ми просили респондентів вказати, як розглянуті інженерні практики поширюються у компанії. У більшості компаній спостерігається змішаний підхід, що складається з різного набору патернів, а пілотні проекти мають велику популярність. Також ми побачили невелику різницю між профілями. Представники профілю High частіше використовують патерн "Ініціатива знизу", коли невеликі команди фахівців змінюють робочі процеси, інструменти, діляться успішними напрацюваннями з іншими командами. У Medium це - ініціатива зверху, що зачіпає всю компанію створення спільнот і центрів компетенцій:
Agile та DevOps
Питання зв'язку Agile і DevOps часто обговорюється у промисловості. Це питання порушується і у звіті State of Agile Report за 2019/2020 рік, тому ми вирішили порівняти, як пов'язані Agile та DevOps активності в компаніях. Ми з'ясували, що DevOps без Agile трапляється рідко. У половини респондентів поширення Agile почалося помітно раніше, а одночасний початок спостерігали близько 20%, а однією з ознак Low-профілю буде відсутність Agile та DevOps практик:
Командні топології
Наприкінці минулого року вийшла книга «», у якій запропоновано фреймворк для опису командних топологій. Нам стало цікаво, а чи застосовний він до російських компаній. І ми запитали: «Які патерни зустрічаються у вас?».
Інфраструктурні команди спостерігаються у половини респондентів, як і окремі команди розробки, тестування та експлуатації. Окремі DevOps команди відзначили 45%, серед яких представники High зустрічаються найчастіше. Далі йдуть кросфункціональні команди, які також частіше зустрічаються у High. Окремі команди SRE з'являються у профілях High, Medium і рідко зустрічаються у профілю Low:
Співвідношення DevQaOps
Це питання ми побачили в FaceBook у тимлід платформної команди Skyeng - його цікавило співвідношення розробників, тестувальників та адміністраторів у компаніях. Ми задали його і подивилися на відповіді з урахуванням профілів: у представників профілю High на кожного розробника припадає менше інженерів тестування та експлуатації:
Плани на 2021 рік
У планах наступного року респонденти відзначили такі активності:
Тут видно перетин з конференцією DevOps Live 2020. Ми уважно ознайомилися з програмою:
- Інфраструктура як продукт
- DevOps трансформація
- Розповсюдження DevOps практик
- DevSecOps
- Кейс-клуби та дискусії
Але часу нашого виступу не вистачить, щоби розглянути всі теми. За кадром залишилось:
- Платформа як і як продукт;
- Інфраструктура як код, оточення та хмари;
- Безперервна інтеграція та постачання;
- Архітектура;
- Патерни DevSecOps;
- Платформенні та крос-функціональні команди.
у нас вийшов об'ємним, на 50 сторінок, і ви можете переглянути його докладніше.
Підводимо підсумки
Ми сподіваємося, що наше дослідження та звіт надихнуть вас на експерименти з використанням нових підходів до розробки, тестування та експлуатації, а також допоможуть вам зорієнтуватися, порівняти себе з іншими учасниками дослідження та визначити галузі, в яких ви можете покращити власні підходи.
Результати першого дослідження стану DevOps у Росії:
- Ключові метрики. Ми з'ясували, що ключові метрики (термін постачання, частота розгортання, час відновлення та неуспішні зміни) підходять для аналізу ефективності процесів розробки, тестування та експлуатації.
- Профілі High, Medium, Low. На основі зібраних даних можна виділити статистично різні групи High, Medium, Low з відмітними ознаками за метриками, практиками, процесами і інструментами. Представники профілю High показують кращі результати ніж Low. У них більше шансів досягти та перевиконати поставлені цілі.
- Показники, пандемія та плани на 2021 рік. Особливий показник цього року, як компанії впоралися із пандемією. Представники High впоралися краще, зазнали зростання активності користувачів, а основними причинами успіху стали ефективні процеси розробки та потужна інженерна культура.
- DevOps практики, інструменти та їх розвиток. До основних планів компаній наступного року входять розвиток DevOps практик та інструментів, впровадження практик DevSecOps, зміна організаційної структури. А ефективне впровадження та розвиток DevOps практик виконується за допомогою пілотних проектів, формування спільнот та центрів компетенцій, ініціатив на верхньому та нижньому рівнях компанії.
Будемо раді почути ваші відгуки, історії, зворотний зв'язок. Дякуємо всім, хто брав участь у дослідженні, та сподіваємось на вашу участь у наступному році.
Джерело: habr.com