Плюси / мінуси припинення робочого процесу DevOps?

Я намагаюсь оцінити, чи є хорошою ідеєю відійти від робочого процесу в стилі девепс до традиційного dev-then-ops (не впевнений, як ви це називаєте).

Ми - невеликий департамент на 5 осіб, який знаходиться в 4000 традиційних медіа-компаніях (наприклад, непрограмне забезпечення). Два роки тому ми почали розробляти програмне забезпечення, яке дозволило нашому відділу значно розширити виробництво. Ми були досить успішними, і більша компанія починає помічати. На сьогоднішній день ми несемо повну відповідальність за розробку, розробку та впровадження того, що стало платформою мікрослужб AWS для служб ~ 10. Наша команда не ідентифікує себе як DevOps, але без сумніву, ми живемо життям DevOps, кожен розробник добре знайомий як з кодом, так і з системою, на якій він працює.

Одне з питань, з яким ми стикаємося незабаром, - це те, яка «ефективність» ділиться між нами та ІТ-відділом для нашої материнської компанії. Наш власник проекту зазвичай надає перевагу аутсорсингу над внутрішнім навчанням, тому в нашому випадку ця ефективність, ймовірно, означає отримати якомога більше ІТ-роботи «за нашими планками». На даний момент я б сказав, що наша команда має 70/30% розбиття між досвідом кодування та інфраструктури. ІТ-відділ надійно перебуває в царині ІТ, не маючи видимого переходу на розробку програмного забезпечення.

Наш власник проекту (нетехнічна особа) сподівається, що, передавши якомога більше роботи ІТ-команді, ми побачимо підвищення продуктивності ~ 1: 1 за кожну годину роботи, яку ми втратили. Я скептично ставлюсь до цього. Наш продукт все ще є попередньою бета-версією (незважаючи на те, що він уже є важливим діловим активом), і, оскільки ми обмежуємо досвід роботи з ІТ-відділом, зазвичай існують значні затримки в таких простостях, як зміни дозволу на файлові системи.

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

У нашій ситуації, які ймовірні плюси / недоліки залишатися з DevOps підходом проти передачі ІТ?

Це не дуже гарна ідея.

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

Розділено:

1. Ви втратите швидкість.
   ІТ відповідатиме власному стандарту. Нове завдання (для них) буде дотримуватися того самого «млявого» шаблону, який має вся їхня робота. Будьте готові, вони вважають це складним - так що навіть менша швидкість, ніж стандартні прості дії.
2. Ви не зможете завантажити.
   ІТ покладеться на вас, хлопці, за кожну аномалію. Ви докладете зусиль, щоб прискорити одного хлопця на швидкість - і наступне, що ви зараз будете повторювати, оскільки наступне завдання / проблема / день знову з’явиться новий хлопець.
3. Буде потрібно документація, але це не допоможе.
   Знову поведінка шаблону полягатиме в тому, що короткі посібники не зможуть наздогнати кожну аномалію, а ґрунтовні тексти не будуть читатись занадто довго. Таким чином, будь-яка інвестиція тут буде збитком, а також величезними зусиллями, необхідними для впровадження удосконалень для того, щоб ваші інструменти «зменшили якість».

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

Якщо вищезгадане звучить цинічно, ну, боюся, я там був. Неодноразово.

Що робити замість цього?

Ходіть по магазинах в ІТ-відділ, знайдіть собі корисного кандидата і тримайте цього хлопця "в позиці", щоб зняти навантаження.

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

У середньому вам знадобиться 1 додатковий розробник на кожні 4 людини, щоб підтримувати однаковий рівень розвитку функцій (38% проти 49% часу, витраченого на нову роботу). Ваш середній час для відновлення після невдачі впаде до 25 разів. Ваша робота буде на 20% менше приємною, і ви будете на 40% частіше рекомендувати свою роботу другові. Тільки цих трьох фактів має бути достатньо.

Що ви втратите, ввівшись в ІТ-організацію, це "Dev" частина вашої маленької команди DevOps. Коли команди сегментуються на штучні ролі NetOps, SysOps та Dev, ви створюєте наступні проблеми:

1. Необхідна тяганина та ізоляція - щоб зробити що-небудь, розробникам доведеться подати квиток на ІТ та чекати, коли вони його втілять. Вони більше не зможуть самостійно реалізовувати та взаємодіяти з ними - аж до їхніх прикладів Dev та QA, що обмежуватимуть інфраструктуру, яку вони можуть кодувати. Вони застрягають на бар'єрі VM замість того, щоб мати можливість кодувати повний стек. Якщо те, що вони подають в ІТ, виглядає як код DevOps, вони будуть погано оснащені для обробки та можуть повернутися до ручного розгортання.
2. Нехтування. Крім того, вони можуть просто розгорнути його так, як є, а потім знехтувати звіром, оскільки вони не знають, як з ним взаємодіяти - і вони не розробники, тому код не є їхньою проблемою.
3. Недоліки - Однією з найчастіше вигідних переваг DevOps є його програмний характер. Звичайно, може знадобитися більше часу для розгортання цього сервера, розглядаючи його як код, але це автоматизує людські помилки. Шлях, який він пішов у розробку, це те, що він перейде в QA / Тест - це шлях, який він піде в продажі, тим самим зменшивши відключення. Коли розробники втрачають доступ до мережевого обладнання, їм потрібно розгорнути свою послугу або обчислювальну інфраструктуру, не тільки це забирає більше часу, але і вводить більше помилкових людей, що спричинить більше відключень.
4. Документація - У деяких сенсах код DevOps - це самодокументація. Ви знаєте, як сервер був побудований і розгорнутий, оскільки код вам підказує. Через 5 років, коли настане час для оновлення до CentOS 8 чи іншого, ніхто більше не знатиме, як розгорнути вашу програму - в тому числі на мережевому, зберігальному, моніторинговому та резервному копіях.

Коротше кажучи, вам слід запропонувати власнику вашого проекту витратити час, щоб прочитати « Міфічний чоловік-місяць», щоб відключити його чи її, про те, що ви побачите співвідношення в продуктивності 1: 1 та проект «Фенікс», який добре оприлюднений (і розважальна) ілюстрація того, що отримується та втрачається за допомогою використання DevOps нетехнічною мовою для нетехнічних людей. Якщо у власника проекту є доступ до комунальних аудіокниг The Phoenix Project.

Я б запропонував вам прийняти когось із ІТ-команди та провести повне навчання в новій системі.

Після того, як вони повністю зрозуміють систему, тоді є сенс її завантажувати на них.

В іншому випадку ви станете Центром підтримки ІТ - і витратите багато часу на перестрілки, вивчаючи тонкощі нової системи.