Чому розробка протистоїть операціям?

Я ще студент, але не знаю операцій, і моя англійська все ще погана.

Моє запитання: Чому розробка протидіє операціям ? Коли розвиваються протилежні операції?

Суть DevOps полягає в тому, що розробка не повинна протидіяти операціям, натомість вони повинні підтримувати один одного.

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

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

Tldr: DevOps має на меті звести нанівець теорію про те, що розробка протистоїть операціям , створивши менталітет, коли операції та розробки працюють разом, щоб часто розгортати продукти своєчасно та легко відтворювати.

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

• Основна мета розвитку - внести зміни.
• Основна мета операцій - підтримувати стабільність навколишнього середовища.

Ці дві речі конфліктують. Незважаючи на це, розвиток і операції не повинні протиставляти один одному. Вони повинні працювати разом, щоб забезпечити досягнення обох цілей. Це і є мета DevOps.

Напруженість між розвитком та операціями часто викликана невідповідністю стимулів та спробами оптимізації в колективі.

За розробниками часто судять за швидкістю та кількістю питань, через які вони можуть потрапити та об'єднатись у сховище коду, і їх винагорода часто не прив’язана до того, що код дійсно працює або працює правильно. Набагато менше масштабування, продуктивності та інших факторів.

Операції часто судять про стабільність навколишнього середовища та про те, наскільки добре працює код у виробництві, але рідко про якість процесу для швидкого внесення змін.

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

DevOps певним чином є набором рішень цієї проблеми:

• Деякі з них можуть бути організаційними, де процеси та стимули колективів можуть змінюватися. Наприклад, якщо робота розробників позначена лише як виконана, коли вона впродовж певного часу працює у виробництві, проблем не було, і операційна команда погоджується взяти право власності на код. Аналогічно, про операції можна судити більше про швидкість, з якою приймається код, тоді як навколишнє середовище все ще знаходиться в межах певної межі стабільності.
• Інша частина рішення може полягати в спілкуванні та перехресному поліруванні, де ви вбудовуєте операційних людей у ​​команду розвитку та навпаки. Ви ламаєте стіну між цими командами, і інженери DevOps часто є результатом такого типу мостів.
• Інструменти, що підтримують такі процеси, як безперервна інтеграція та безперервна розгортання, - це ще одна частина рішення, яка може підвищити швидкість змін, зберігаючи високу якість та швидке відновлення виробничого середовища у разі виникнення будь-яких проблем через відкат коду або швидкий хід виправлення у виробництво.

Більшість організацій мають справу зі складністю, розбиваючи свою організацію на функціональні частини і вимагаючи, щоб кожна частина з'ясувала, як вдосконалити себе. Це часто називають підходом «силосу».

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

Оскільки керівникам кожного функціонального силосу призначено вдосконалюватись за рахунок скорочення витрат або збільшення швидкості, їх реакція часто:

• Я повністю перевантажений виправленням проблем з останніх зусиль із вдосконалення. Залиш мене в спокої.
• Що ви хочете, щоб я займався, виконував свої обов'язки або працював над проектами з удосконалення? Я не встигаю робити і те, і інше.
• Тільки не знову! Ось ще одна програма місяця.

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

Навіть коли менеджер завершує свою частину проекту вдосконалення, він зустрічається з іншими функціональними областями та іншими організаціями (постачальниками, підрядниками тощо), які не виконували свою роботу. Це зменшує або повністю заперечує результати.

Ця міжфункціональна напруга не обмежується зусиллями з удосконалення. Це саме в основі повсякденного прийняття рішень і оцінки ефективності управління в організації. Ось один приклад із реального життя:

Менеджеру з фінансів було сказано: "покращити". Він вирішив заблокувати наймаючих підрядників, які коштують дорожче ніж номінальна ціна, прийнята на ринку. Він реалізував нову політику і стверджував, що заощадив 1 мільйон доларів цього року. Оскільки розробники та ІТ не можуть найняти підрядників, які допоможуть їм використовувати оркестрацію контейнерів та контейнерів, оскільки ці підрядники дорогі. Менеджер ІТ-операцій у тій же компанії підрахував, що не поліпшення їх інфраструктури коштуватиме компанії понад $ 100 000 додаткових витрат щомісяця. За такою швидкістю щорічні заощадження підрядних працівників були з'їдені до кінця року.

Ви можете собі уявити, що зв’язок між цими двома функціональними областями був не зовсім люб'язним.

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

У цій системі відліку витрати розглядаються як дотримання правила "добавки". Витрати кожного силосу додаються разом, що дорівнює загальній вартості організації. Тому менеджери розглядають будь-яке зниження витрат у своїй області як «добре», оскільки вони бачать прямий переклад на економію витрат для компанії в цілому. У цій системі орієнтації зусилля з удосконалення розповсюджуються скрізь, щоб атакувати витрати та витрати на всю організацію.

Прекрасний приклад, коли команда розробників починає працювати Agile і надсилає код на QA та Operations кожні два тижні замість кожного кварталу, як раніше. QA та Операції не готові до такої зміни, і їх звинувачують у відшаруванні. Знову ж таки, це не дуже сприяє любові між людьми у розвитку та операціях.