Команди, що підтримують високонавантажені системи, часто додають change failure rate (CFR) — частку невдалих змін — у звіти поруч з іншими інженерними метриками. Цінність цього показника розкривається тоді, коли команда читає його як сигнал. У SharksCode CFR підказує, на якому етапі процес випуску дає збій і що варто змінити в підготовці наступних релізів. СТО компанії розповів, як команда визначає невдалий реліз, оцінює ризик змін і перетворює досвід інцидентів на технічні рішення.
Що вважається невдалим релізом
У SharksCode невдалою вважають зміну в продакшні, яка погіршила роботу системи й вимагала втручання команди: від відкату чи вимкнення функції до відновлення даних. Головним критерієм залишається наслідок для системи та користувача, тому в облік має потрапляти навіть реліз без формального відкату, після якого довелося усувати інцидент. Показник рахують як частку таких розгортань від загальної кількості за період. Джерелом даних, за словами СТО, мають слугувати історія розгортань і пов’язані з нею інциденти. Для коректного обліку важливо однаково визначати одиницю зміни та правила обліку термінових виправлень. Окремо фіксують логіку, за якою інцидент пов’язують із конкретним релізом.
«Доступність важлива, але система може відповідати на запити й водночас неправильно виконувати операції. Тому критичними також є коректність даних, затримки та завершення бізнес-сценаріїв. У системах з асинхронною обробкою проблема може проявитися через накопичення черги або повторне виконання операцій», — пояснює СТО SharksCode.
Серед типових ризиків СТО називає несумісність версій сервісів і зміни контрактів API чи подій. Ще одна група ризиків пов’язана з міграціями даних, конфігурацією та поведінкою системи під реальним навантаженням. Окремою категорією він виділяє взаємодію кількох змін, кожна з яких окремо пройшла перевірку.
Ризик оцінюють ще до розгортання
Ризик кожної зміни оцінюють за її можливим впливом. Інженери аналізують, які частини системи вона зачіпає, скільки користувачів або операцій може торкнутися, чи змінює дані й наскільки легко її скасувати. Обсяг змін у коді залишається лише однією з ознак.
«Кілька рядків у критичній операції можуть вимагати більше перевірок, ніж велике ізольоване оновлення», — зазначає СТО.
Базовий набір перевірок охоплює рев’ю, автоматизовані тести та перевірку ключового сценарію. Далі контроль розширюється відповідно до типу зміни. Міграція вимагає уваги до блокувань і сумісності, інтеграція — до контрактів та обробки помилок, тоді як зміни на гарячому шляху потребують тестування продуктивності. Ще до релізу має бути зрозуміло, як виявити проблему та повернути систему до стабільної роботи.
Спосіб розгортання підбирають під архітектуру й ризик зміни. Поступовий запуск на частині трафіку чи перемикачі функцій допомагають обмежити вплив можливого збою там, де система підтримує такий режим. Перед цим інженери з’ясовують, чи можуть стара й нова версії працювати одночасно та чи сумісні вони з поточними даними.
Після релізу команда стежить за рівнем помилок і затримок, трафіком та використанням ресурсів, доповнюючи їх метриками конкретного сценарію: успішність операцій чи стан черг. Важливо бачити, як показники змінюються відносно звичайного рівня, тому на час релізу визначають відповідального за ці сигнали. Рішення зупинити розгортання ухвалюють з огляду на вплив на користувачів і коректність операцій. До уваги беруть також динаміку показників і швидкість поширення проблеми. Між відкатом і терміновим виправленням обирають шлях, що швидше й надійніше відновить роботу. Втім, для зміни, яка вже перетворила дані, повернення старої версії коду може виявитися недостатнім.
Тому до релізу готують відому стабільну версію, перевірену процедуру її розгортання та потрібні доступи. Для змін у даних передбачають окремий план відновлення чи виправлення. Після повернення до стабільного стану перевірки мають підтвердити, що бізнес-операції знову працюють коректно. Ролі також розподіляють заздалегідь. Ще до релізу зрозуміло, хто володіє зміною, хто проводить розгортання і хто координуватиме дії в разі інциденту. Розробники оцінюють поведінку зміни, DevOps-інженери відповідають за стан системи й варіанти відновлення, тестувальники перевіряють сценарії. Продуктову команду залучають за потреби, щоб оцінити вплив на користувачів.
Від інциденту до зміни процесу
Розбір кожного невдалого релізу починається з хронології подій. Команда з’ясовує, що змінилося, які сигнали з’явилися, чому перевірки не виявили проблему і що затримало відновлення. Результатом мають стати конкретні дії з відповідальними: від нового тесту чи сповіщення моніторингу до оновленої інструкції або меншого обсягу релізів.
СТО ілюструє це на прикладі інтеграції зовнішнього провайдера. ШІ допомагає розкласти вимоги на сценарії та підготувати чернетки тестів, зокрема для відмови, таймауту й повторного вебхука. Під час рев’ю інженер помічає, що реалізація перевіряє статус операції, проте не гарантує захисту від одночасної обробки двох однакових подій. Команда уточнює вимоги до ідемпотентності й додає тест на конкурентну доставку дублікатів.
«Цей приклад показує розподіл відповідальності. ШІ прискорює підготовку, а команда перевіряє припущення, коректність рішення та поведінку під навантаженням», — підсумовує СТО SharksCode.
Найочевидніший спосіб формально знизити CFR — рідше випускати релізи. Тому СТО радить оцінювати показник разом із частотою розгортань і швидкістю доставки змін, а також із часом відновлення та впливом інцидентів на користувачів. Умовний розрахунок добре це ілюструє: якщо за квартал команда виконала 120 продакшн-розгортань і шість із них потребували втручання, CFR становить 5%. Проте коли релізів стало менше, а зміни накопичуються й доставка сповільнюється, нижчий показник ще не доводить покращення процесу. Метрика має допомагати знаходити причини проблем.
Свій підхід SharksCode зводить до трьох принципів. Перший передбачає випуск змін керованого обсягу з урахуванням сумісності сервісів і даних. Другий вимагає ще до релізу знати, за якими сигналами оцінювати результат і як відновлювати роботу. Третій полягає в тому, щоб перетворювати досвід інцидентів на конкретні перевірки й технічні зміни, за виконання яких хтось відповідає. Разом вони роблять change failure rate робочим інструментом, що підказує команді, куди спрямувати зусилля в наступних релізах.
SharksCode
Подробиці можна знайти на сайті: highload.tech