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

І все ж баги продовжують потрапляти на виробництво.

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

Математика добре зрозуміла. Система - ні.

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

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

Дедлайни релізів стискають вікна тестування. Функції передаються до QA наприкінці спринту, що залишає недостатньо часу для ретельного покриття. Тестове середовище не точно відображає виробничі умови - різні обсяги даних, різні інтеграції, різна поведінка користувачів. Граничні випадки втрачають пріоритет на користь покриття “щасливого шляху”. Набори для регресії застарівають, оскільки продукт розвивається швидше, ніж тести.

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

Помилки, які потрапляють у виробництво, не є випадковими

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

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

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

Відомі дороговартісні перебої в роботі Amazon - компанія втрачає близько 220 000 доларів на хвилину під час пікових перебоїв трафіку - не спричинені збоями в базовій функціональності. Вони спричинені каскадними збоями в складних розподілених системах в умовах навантаження, які важко змоделювати в передпродакшн-середовищі. Помилка, через яку Knight Capital Group втратила 440 мільйонів доларів за 45 хвилин у 2012 році, була помилкою розгортання - неперевіреним кодом, який активував неактивну систему і відправив торговий алгоритм у неконтрольовану спіраль. Сам код не був новим. Помилка була в процесі навколо нього.

Чому аргумент вартості сам по собі не змінює поведінку

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

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

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

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

Що насправді зменшує кількість виробничих помилок

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

Вони залучають QA раніше. Не як ворота в кінці циклу розробки, а як учасник у формуванні вимог та проектуванні. Помилки, виявлені до написання рядка коду, не потребують часу розробника на виправлення взагалі. Вартість не в 4-5 разів менша - вона фактично дорівнює нулю.

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

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

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

Дорога частина - це не вирішення проблеми

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

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

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

Саме це робить їх важкими для обліку - і легкими для недооцінки.

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