виклик показників розгортання до DevOps

TL; DR, як ви доказуєте, що девепс, зокрема автоматизація розгортання, покращує показники відмов?

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

Але інтуїтивно ми всі знаємо, що це не добре. У звіті про стан девепсів за 2017 рік зазначено, що приблизно 31-45% " коефіцієнт відмови зміни ". Хоча це інтуїтивно звучить як правильно, чи відстежуються вони як випадки? Ні. Оскільки вони фіксуються досить швидко, як правило, під час перевірки. Набагато рідше реально відкрутити розгортання.

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

Отже, як довести девепс, зокрема автоматизацію розгортання, покращує рівень відмов?

(PS намагався позначити це "# devops-capability-model")

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

1. Доступ для виконання оновлень до цільових областей розгортання (тобто виробництва) обмежений вибраними автоматизованими системами, які мають відповідні аудиторські траси (= ведення журналів) будь-якого типу оновлень областей, якими вони керують.

2. Типові члени команди (ідентифікатори користувачів), які раніше (з авторизацією) могли проводити ці оновлення, з будь-якої причини забороняються оновлення до цільових областей розгортання. Натомість будуть створені НОВІ (додаткові) ідентифікатори користувачів, які матимуть усі необхідні дозволи для (ще) виконання таких оновлень вручну, коли це буде потрібно. Але щоб реально мати можливість використовувати ці нові ідентифікатори користувачів (= виконати вхід з ними), учасник команди, який хоче виконати вхід з таким новим ідентифікатором користувача, повинен буде виконати "якийсь" додатковий крок, щоб отримати доступ до пароля для такий новий ідентифікатор користувача В ідеалі цей додатковий крок також автоматизований (використовуйте власну уяву, як це повинно виглядати), але якщо щось інше не вдається: просто зв’яжіться (= електронна пошта, дзвінок і т.д.), захисник необхідного пароля, включаючи "який випуск у них є" виправити "

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

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

Оновлення :

Цитата з вашого додаткового коментаря під цією відповіддю:

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

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

• безпека роботи.
• погані речі / практики, які вони воліють зберігати прихованими.
• владу вони не хочуть втрачати.

У звіті про стан девепсів за 2017 рік говориться, що приблизно 31-45% "рівень відмови зміни" Хоча це інтуїтивно звучить як правильно, чи відстежуються вони як випадки? Ні. Оскільки вони фіксуються досить швидко, як правило, під час перевірки.

Проблема, яка швидко виправляється, все ще залишається проблемою. Якщо ви не повідомляєте про це як таке, це проблема.

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

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

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

TL; DR, як ви доказуєте, що девепс, зокрема автоматизація розгортання, покращує показники відмов?

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

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