Про що не говорять у DevOps — анатомія «хвороб зростання»

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | DevOps!

Як Концептуальний Архітектор, останні три роки активно працюю в сферах коучингу та IT консалтингу. Особливий інтерес для мене представляє гармонізація DevOps з програмами Стратегічного та Антикризового планування-управління.

DevOps активно розвивається, приносячи в IT галузь численні переваги та відкриваючи нові горизонти. Однак, поряд з успіхами, вже помітні численні проблеми та труднощі, які супроводжують стрімкий розвиток.

На базі власного досвіду на спостережень, прояви цих проблем мають системний характер.
Можна відзначити, що DevOps, пройшовши етапи народження та початкового розвитку, наближається до стадії визрівання. Саме тепер починають відчуватися «хвороби росту».
На мою думку, вже проявився ряд проблем, пов’язаних з «хворобами росту»:
— Зменшення ефективності від використання DevOps.
— Відрив від первісної філософії DevOps. Замість акценту на командній роботі та досягненні бізнес-результатів, приоритет віддається технологічним новаціям замість того, щоб спиратися, в першу чергу, на активацію людського фактору. У відповідності до філософії DevOps — весь колектив компанії має бути активним і спрямованим на досягення кінцевого бізнес результату, а не на захист інтересів свого підрозділу.

Готую публікації по аналізу кожного з проблемних питань.

Я б прагнув зрозуміти, чи поділяє спільнота мої погляди та спостереження.
— Діліться своєю думкою, досвідом та проблемами, які ви відчуваєте у сфері DevOps.

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

падає ефективність? ну хз — може бенчмарк ннвірно вибраний бо напевно після того як впровадили автоматизацію, ci/cd мало би зменшитись об’єми ручної роботи і кількість помилок зроблених через «людський фактор». Можливо ще крім devops треба і в інших місцях покрутити — ну там на архітектуру рішення, на AQA, на TDD, на співвідношення Dev FE/BE/QA/Product Managers глянути?

А то я бачив як кривавий ентерпрайз хоче DevOps до старезного гівна мамонта припасувати типу Microsoft Dynamics AX09. То воно там ясно не допоможе — бо там ні Envів нормальних не зробиш ні скейлінгу, ні моніторингу людського а реліз завжди з даунтаймом. Бо то моноліт і закрита M$ екосистема зі всім своїм зробленим ще 15 років тому коли ні про CI/CD ні про клауди ні про git/agile ніхто в ентерпрайзі нічого не знав а всі зміни роблять інтегратори партнери а бізнес тим поосто користувався

Зменшення ефективності від використання DevOps.

Імхо ефективності і не було, майже, тому що
— багато проектів юзают AWS|GCP|Azure — тому ще це модно
— docker|kubernetes — тому що це модно
......
беремо той самий EKS — постійні оновлення версій, не завджи всі проекти піднімаються за лічені секунди, це веде до даунтайму — коли потрібно оновити воркер ноди, ідемо до команди розробників в’ясовувати як ми можемо зробити прискорення підйому сервісів, а фактично ніяк, а на..я тоді кубік ну і пішло поїхало.
З іншого боку — без всякий там модних штук на баш скриптах і дженкінсі написно з лайна і палок деплоймент 8 років тому в амазоні, без купіків, докерві — все працє і витрати на підтримку мінімальні, бо воно працює, немає вимог оновлювати фосом базу, версію контрал плйну, сертифікатів тощо....
Тут в цілому у вас релігійні питання і вони мають дуже багато відповідей і у кожного доповідоча будуть свої аргументи як то питання а де та філософія DevOps ? В чому вона ? А хто її стандартизував ? А чому бізнес робить задавання DevOps філософії та чому та філософія тягне за собою збільшення витрат на підтриску ?

Це не проблема EKS він не оновлює всі ноди одночасно, а коли ваші сервіси так розроблені то питання у розробниках та архітектурі. Так треба постійно оновлювати EKS та все інше, це питання безпеки. Якщо класти на безпеку то можна використовувати деплоймент якому 8 років.

то питання у розробниках та архітектурі

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

Так треба постійно оновлювати EKS та все інше, це питання безпеки.

Якщо його не використовувати — то питання відпадає. Не потрібно наймати девопса і тримати його поряд, тому що (і тут багато питань), бо багато питань виконає умовний сісадмін набагато дешевше.

Якщо класти на безпеку то можна використовувати деплоймент якому 8 років.

Можна і це не стосується бекпеки, якщо зроблено з головю — то система буде працювати багато років як в моєму прикладі і не буде порушень безпеки, економія тисяч — сотень- тисяч долларів і все ок.
PS про відкати, маніпуляції з боку менеджмента який свої дупи прикриває я не буду писати :)

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

дивіться відповіді на питання в новому пості «Про що не говорять у DevOps. Одним банкрутство, іншим успіх та зростання» dou.ua/forums/topic/45566

Підписатись на коментарі