Як я можу переконати розробників у моїй команді прийняти "Ви будуєте це, ви запускаєте"?

Як я можу переконати розробників у моїй команді прийняти "Ви будуєте це, ви запускаєте"? Зважаючи на це, я маю на увазі цю цитату Вернера Фогеля :

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

Я спеціально думаю про набір розробників, які:

• Були найняті на роль розробника, майже не згадуючи завдань, пов'язаних з операційною системою.
• Традиційно "кинули код через стіну" команді операторів.
• Традиційно мають графік роботи 9-5 і активно ворогують з ідеєю "пейджерського обов'язку", беруть участь у відновленні аварій, пишуть посмертні тощо, особливо поза звичайним робочим часом. (Примітка. У мене на увазі лише дуже нечасті перебої в роботі; я не пропоную додавати допоміжну службу підтримки клієнтів до робочого навантаження цієї команди.)
• В даний час не несуть відповідальності за написання / підтримку моніторингу або оповіщення щодо своїх заявок.

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

Мене спеціально цікавлять методології, підкріплені прикладами реального світу. Як це було успішно реалізовано на інших робочих місцях, і чи є якісь канонічні кроки, які слід дотримуватися під час цього? Будь-які посилання на описи, які можуть підтримувати відповіді, були б дуже корисними.

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

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

Що стосується впливу на бізнес-культуру, найкращий спосіб, мабуть, за допомогою відомого методу "відварити жабу". Ви повинні впроваджувати ці завдання розробникам повільно, тому що я знаю, що я сам (як дев) мав би ризикнути перед усією цією новою відповідальністю.

По-перше, почніть із введення одного чи двох нових завдань, які потрібно виконувати лише у звичайний робочий час. Їм потрібно навчитися робити девепсів, що може бути цілком навчальним процесом для (до цього моменту) розробника, що працює лише з кодом, і може зажадати певного нагляду. Вони також, ймовірно, будуть вороже ставитись до зміни балансу між робочим та особистим життям, оскільки ви згадуєте, що вони звикли до 9-5. У цей момент запишіть дані про нові процеси для використання пізніше (змусити їх написати цей код, дані завжди корисні).

Пізніше, коли у вас закінчуються нові завдання, які потрібно ввести (так що перша, друга та четверта кулі пункти майже завершені), виведіть перші завдання, які ви представили як кандидати, які потрібно виконувати поза стандартною робочою годиною . Ви можете побачити деякі реакції в цьому, і ви навіть можете побачити деякий виснаження залежно від того, наскільки сильно ви натискаєте на це і наскільки сильно вкорінена культура роботи в кінці п’яти. Щоб захиститись від цього, сподіваємось, ваші дані підтримують думку про те, що робота поза стандартними годинами буде рідкісною, виникає лише в екстремальних ситуаціях і принесе велику користь як бізнесу, так і клієнтам. Якщо ваші дані цього не підтримують, то вам краще бути готовим боротися з наслідками цього вибору.

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

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

По суті, вона зводиться до декількох ключових етапів:

• проекти починаються як пускові поїзди. Намір (і очікування того, хто це фінансуватиме) полягає в тому, що він буде довго працювати. Я говорю довгі роки, нічого з цього "не витримуй команду 3 місяці, а потім відстоюй їх".

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

• Я майже завжди бачу, як поїзди виконують свій перший приріст як 100% команди, що змінюють проект / зміна, 2-й приріст вони виділяють відсоток часу на виконання роботи. Управління третього приросту усвідомлює, що у них ось-ось виникне проблема, і почати додавати команди, щоб спробувати впоратися із переливом Run, щоб дати своїм досвідченим розробникам та інженерам час, щоб продовжувати працювати над новими вимогами.

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

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

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

ІМХО You build it, you run itне слід сприймати буквально. Для початку - це майже звучить як покарання;)

Жодна особа або навіть невелика команда розробників не може з розумом підтримувати інструмент або набір інструментів, що використовуються в процесі розробки програмного забезпечення (тобто у виробництві!) Протягом тривалих періодів часу. Був там зробив те :)

Обов'язки по підтримці, як правило, розширюються в міру збільшення бази клієнтів для інструментів (набору). Якщо взяти на себе виключно ці обов'язки, команда девелопменту могла б зробити в основному підтримку, не маючи часу на розвиток у дорозі. Ефективно безвихідь - скільки розробників хотіло б дотримуватися таких обставин?

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

Команда підтримки 1-го рядка, звичайно, буде віддана команді розробників (знову ж таки, команда, а не одна особа!) З питань, які вони не можуть безпосередньо вирішити. Так, спочатку це може бути важко, але все покращиться. Це має бути співпраця - це частина того, про що йдеться у DevOps.

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

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

2. Середній бізнес (понад 150 інженерів, але єдина команда з операцій). На цьому етапі в компанії починає бути занадто високим, інженери, які створюють програмне забезпечення, не обов'язково тримаються за його допомогою. Ви більше не знаєте всіх, і важко ефективно спілкуватися з усіма, хто перебуває в операціях. Це почало б перетворюватися на хаос. На цьому етапі ви хочете звернутися до моделі Google, де кожна команда повинна операціоналізувати своє програмне забезпечення, але не обов’язково ним керувати. Вони оперуватимуть ним на початку, але велика частина побудови програмного забезпечення полягає у тому, щоб зменшити витрати на його експлуатацію до точки, коли навантаження достатньо невелика, щоб команда операцій могла підписати його запуск. Тільки тоді він вважається зробленим.

3. Велике підприємство з безліччю бізнес-підрозділів (де в кожній є власна команда з операцій): На цьому етапі ви можете повернутися до моделі Amazon, де кожна команда необхідна для розробки та управління власними службами. Кожен бізнес-підрозділ повинен бути достатньо малим, щоб усі знали один одного, тому близько 150 інженерів, і ви працюєте кожен, по суті, як стартап. В Amazon кожен сервіс AWS працює більш-менш окремо, і він працює для них.

Ви повинні з'ясувати, на якій стадії знаходиться ваша компанія та / або рухаєтесь, і діяти відповідно. Немає рішення "один розмір, який підходить усім".

Моя думка про це (якби я зіткнувся з такою заповіддю, або як би ти це не назвав), було б щось на зразок " What else would you expect?!?!". Тому що, випадково:

• Я б навіть не міг жити без цього, і
• Я люблю їсти власну (собачу) їжу.

Дозвольте мені пояснити трохи далі ...

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

• Я навряд чи що-небудь документував, що я зробив, щоб запустити систему. Якщо виникають запитання, я просто запитую систему (і вчу клієнта, як запитувати систему без моєї допомоги).
• Якщо мене зателефонують через X місяців / років (щоб оновити до нового випуску?), Я хочу знати (пам’ятаєте), що я робив раніше (і єдине, що я довіряю, - це те, що мені каже система, ака нагадує про мене).
• Мені потрібно лише раз запитати замовника про те, як робити конкретні речі на своєму сайті (конвенції про іменування важко запам’ятати) або переконати їх у наданні необхідних дозволів «системі» (не мені ...).
• Ви continuouslyQA тестуєте власну систему ... у виробництві. Цілком ймовірно, що ви відчуєте помилки, логічні помилки або відсутні функції (а що ні) самі. І це вкрай мотивує, щоб змусити їх якомога швидше звернутися ... наприклад, щоб стати більш продуктивними.
• ... і якщо ви хочете, я можу додати ще десяток причин ...

Однак перш ніж спробувати це вдома самостійно, пам’ятайте про деякі підводні камені, яких слід уникати:

• ви хочете, щоб усі приєдналися до партії (використовуйте систему), тому що лише 1 "виняток" (він же менеджер / власник компанії?) може зіпсувати партію (ви б могли подумати, що можете довіряти вашій системі, але тоді хтось щось зробив без запитань / використання системи). Цей випадок може коштувати вам днів, щоб відкрити ...
• нові користувачі можуть поскаржитися, що використовуючи цю (нову) систему, їм потрібно більше часу, щоб виконати свою роботу (порівняно з тим, що вони раніше використовували). І де б це не було сенсом, вони використовуватимуть це як привід, чому вони спізнюються завершити свою роботу. У цей момент вам краще мати верхнє управління, яке охоплюватиме вас, бо в іншому випадку ваш проект / система може отримати вину.
• переконайтеся, що ви знаєте свою власну систему та як налаштувати її відповідно до ваших потреб. Як зразок (в моєму випадку): ви хочете налаштувати систему так, щоб використовувати операційне середовище для доставки у ваше експериментальне середовище, а не навпаки ... Я бачив, що відбувалося в минулому ... використання (зловживання) тестової системи для доставки до високозахищених середовищ.