Без багов что это
Что такое баги, ворнинги и исключения в программировании
Разбираемся, какие бывают типы ошибок в программировании и как с ними справляться.
Многим известно слово баг (англ. bug — жук), которым называют ошибки в программах. Однако баг — это не совсем ошибка, а скорее неожиданный результат работы. Также есть и другие термины: ворнинг, исключение, утечка.
В этой статье мы на примере C++ разберём, что же значат все эти слова и как эти проблемы влияют на эффективность программы.
Пишет о программировании, в свободное время создает игры. Мечтает открыть свою студию и выпускать ламповые RPG.
Ошибки в программировании
Словом «ошибка» (англ. error) можно описать любую проблему, но чаще всего под ним подразумевают синтаксическую ошибку — некорректно написанный код, который даже не скомпилируется:
Компилятор тут же скажет, что в коде ошибка и скорее всего не хватает запятой или точки с запятой.
Также существуют ворнинги (англ. warning — предупреждение). Они не являются ошибками, поэтому программа всё равно будет собрана. Вот пример:
Предупреждения не являются чем-то критичным, но могут иметь негативные последствия. Например, ваша программа будет использовать больше памяти, чем должна. Так как C++ нужен в том числе и для разработки высоконагруженных систем, этого допускать нельзя.
После восклицательного знака в треугольнике — количество предупреждений
Третий вид ошибок — ошибки сегментации (англ. segmentation fault, сокр. segfault, жарг. сегфолт). Они возникают, если программа пытается записать что-то в ячейку, недоступную для записи. Например:
Вот результат работы такого кода:
Баги в программах
Мы выяснили, что баг — это не совсем ошибка, а скорее неожиданное поведение программы или результат такого поведения. Баги могут быть чем-то забавным или неприятным. Например, как в играх:
Но они могут привести и к более серьёзным последствиям. Если неправильно спроектировать работу многопоточного приложения, то потоки будут постоянно опережать друг друга. Например, сообщение об ошибке из одного потока может опоздать на миллисекунду, из-за чего второй поток подумает, что никакой ошибки не было, и продолжит работу.
Если ваш код приводит в действие какое-нибудь потенциально опасное устройство, то ценой такой ошибки может быть чья-нибудь жизнь. Такое случилось с кодом для аппарата лучевой терапии Therac-25 — как минимум два человека умерло и ещё больше пострадали из-за превышения дозы радиации.
Исключения в программах
Также во время работы программы могут возникать ситуации, которые мешают корректной работе программы. Например, если вы просите пользователя ввести число, а он вводит строку.
Конвертировать введённое значение не всегда возможно, поэтому функция, которая занимается преобразованием, «выбрасывает» исключение (англ. exception). Это специальное сообщение говорит о том, что что-то идёт не так.
Если разработчик не описывает логику работы программы при вы выбрасывании исключения, то программа аварийно закрывается. Подробнее мы рассказали об этом в статье про ввод и конвертацию в C++.
Одно из самых известных исключений — переполнение стека (англ. stack overflow). В честь него даже назвали сайт, на котором программисты ищут помощь в решении своих проблем.
Компилятор C++ при этом может выдать ошибку сегментации, а не сообщение о переполнении стека:
Вот аналогичный код на языке C#:
Однако сообщение в этот раз более конкретное:
В обоих случаях программа завершается, потому что не может дальше корректно работать.
Похожая ситуация — переполнение буфера (англ. buffer overflow). Она происходит, когда записываемое значение больше выделенной области в памяти.
Обратите внимание, что мы получили предупреждение об арифметическом переполнении (англ. integer overflow):
Тем не менее программа скомпилировалась. Если же такая ситуация возникнет во время вычислений, то мы можем не получить предупреждения.
Арифметическое переполнение стало причиной одной из самых дорогих аварий, произошедших из-за ошибки в коде. В 1996 году ракета-носитель «Ариан-5» взорвалась на 40-й секунде полёта — потери оценивают в 360–500 миллионов долларов.
Как избежать всех этих ошибок
К сожалению, вручную всё это заметить и исправить не получится. Однако существуют различные инструменты и технологии, которые могут помочь.
Один из таких инструментов — отладчик. Он помогает контролировать ход работы программы, чтобы отслеживать разные показатели.
Второй, более эффективный метод — unit-тесты. Они представляют из себя набор описанных ситуаций для каждого компонента программы с указанием ожидаемого поведения.
Например, у вас есть функция sum (int a, int b), которая возвращает сумму двух чисел. Вы можете написать unit-тесты, чтобы проверять следующие ситуации:
Если какой-то из этих тестов не пройден, вы узнаете об этом и сможете всё исправить. Это намного быстрее, чем проверять всё вручную.
Заключение
Ошибок существует слишком много. При этом самые опасные тяжелее обнаружить, что только усугубляет ситуацию.
Если вы хотите научиться писать качественный код и находить в нём ошибки, вы можете записаться на наш курс по разработке на C++.
Что такое баги в игре и как их находить при тестировании
Что такое баги в игре и как они классифицируются
Как классифицируют игровые баги:
Функциональный баг. Когда не работоспособны различные функции в игре. Например, когда при смене локации или каких-то настроек выбрасывает из игры.
Логический баг. Он же баг баланса. Когда выставленный баланс и игровая логика просто не дают возможность пройти игру полностью. Например, реальный наносимый урон не соответствует заявленному, или в игре сталкивают игроков разных уровней, где явно видно превосходящее преимущество одних над другими, что фактически обеспечивает им победу.
Баг совместимости. К примеру, игра не запускается на совместимых устройствах.
Н о эт о еще не все. Это была классификация по происхождению бага. Еще они классифицируются по приоритетности и скорости их устранения. В этом случае выделяют три категории:
Баги, мешающие пользователям игры. В целом влияют на количество игроков, на различные рейтинги и т. д.
Баги, мешающие бизнесу. В этой категории подобные баги могут не мешать пользователям, но мешать компании зарабатывать деньги на игре.
От чего зависит количество багов в играх
Игровой процесс. Чем сложнее процесс и больше функциональности в игре, тем больше шансов, что при их реализации возникнут ошибки в игре.
Сетевая игра. Если игровой процесс задумывается для сетевой игры, то возника ю т дополнительные трудности в налаживании взаимодействия между игроками, плюс накладываются возможные баги при балансировке. Поэтому в сетевых играх часто даже после удачного альфа-тестирования и устранения ошибок после запуска игры в сеть появляются н ео чевидные баги и проблемы с балансом.
Сетевой режим RPG-игр. Огромный игровой мир с просто невероятным количеством возможных сценариев при взаимодействии игроков между собой.
Графическая мощь игры. Трудно абсолютно без багов адаптировать мощные игры под разные устройства.
Как искать и находить баги в играх
Как искать и находить баги в играх, советы:
Фокусировка. Важно фокусироваться именно на процессе поиска, а не на процессе игры. Можно даже держать постоянно в голове мысль: «Здесь должен быть баг!»
Нельзя ничего пропускать. Даже если заметили небольшой баг, нельзя его игнорировать и искать что-то «крупнее». Один малый баг может породить несколько больших, нужно помнить об этом.
Тестировать разные жанры. Нужно тестировать разные жанры игр или даже разные проекты, чтобы глаз не «замылился» и вы всегда были способны вовремя заметить ошибку.
Заключение
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
Шестой подвиг Геракла: как мы расчистили прод от багов
В тексте я частенько буду срываться на «мы» в знак признательности всем тем людям, кто тащил, поддерживал и сопротивлялся лишь в полсилы. Особая благодарность Диме Кабанову, ведущему менеджеру продукта и автору сценария этой истории.
Проблема, которую мы заслужили
Мы участвуем в разработке продукта с долгой историей и сложной структурой. Продуктом пользуется 400 000 компаний по всему миру. В активную разработку вовлечены тысячи людей на 5 континентах. Разные языки, культуры и часовые пояса.
Баги на проде — неотъемлемая часть продукта. Не то чтобы это достойный повод для хвастовства. Просто данность. Подобную картину можно увидеть в известных продуктах с публично доступными трекерами.
Этот баг один из тех, кого не любит фикс И близко не госдолг США, но тоже много
Оставим за скобками критические и блокирующие дефекты — внимания им уделяется достаточно, чтобы не пропустить в релиз или максимально быстро поднять с пола патчом. Поговорим о багах (ни)когда-нибудь. В нашем контексте их приоритет помечают как P2 (Normal) и ниже: P3 (Low), P4 (Trivial). При этом большая часть P2 таки чинится в период стабилизации релиза. Процентов 20 — нет. Добавим несрочные инциденты с прода. И до кучи баги с корнями из прошлых версий, которые находят в процессе разработки.
Достаточная ли эта проблема, чтобы отвлекать разработчиков DINS и читателей Habr? Давайте прикинем. Фичи с объявленной ценностью успешно отправились в прод. Неприятные баги пофикшены. Кому какое дело до мелочей? Пусть пылятся на складе. Так-то оно так, но нет. Есть несколько явлений, которые не дают спокойно спать.
Во-первых, баг взвешенный вчера как P3, назавтра может проснуться как P1 у нового пользователя с крупной подпиской. Хуже всего ситуация сложилась с P2. В трекере это приоритет по умолчанию, читай — используется в любой непонятной ситуации. И он близок в P1, который считается недопустимым в релизе. Но иголки и сено всё ещё перемешаны.
Во-вторых, такие баги имеют тенденцию сбиваться в группы. По отдельности они доставляют лишь неудобство, а выстроившись в цепочку, способны сломать значимый для пользователя сценарий.
Хуже всего картина в динамике. Мониторинг таких багов показал устойчивый рост от релиза к релизу. Что вполне объяснимо — увеличивалась база пользователей, увеличивалось число разработчиков. Но ситуацию с каждым релизом всё сложнее стало называть контролируемой.
36-летний я прогнозировал накопление к 2021 году на проде 5100 известных багов
Было ещё одно нежелательное явление. Накопившиеся известные баги были разбросаны по разным проектам, а их актуальность не подтверждалась. Если до бага не дошли руки при принятии решения об откладывании фикса, то стоит ли пояснять, сколько времени выделяется на его проверку в дальнейшем?
Итого. Два года назад. На проде 4000 известных багов. Среди 1300 из них — потенциальные кандидаты на патч. С каждым релизом прибывает несколько сотен новых, а чинятся случайным образом пару десятков. Всё больше жалоб от пользователей и всё чаще мы обнаруживаем, что релевантная информация уже имеется в нашей базе. Просто она зафиксирована в (ни)когда-нибудь тикете.
Это уже было в Симпсонах
Проблема не уникальна. А раз так, то в интернетах должно быть полно готовых рецептов. Ниже я опишу известные мне подходы и причины, по которым мы ими не воспользовались. Буду признателен, если в комментариях дополните этот список хорошими решениями.
Всё на зеро
Zero bug policy (ZBP). Хотелось бы перевести название подхода как «пишем код без багов, а с багами не пишем». Но на любой продукт без багов найдется пользователь со специфичными вкусами.
Багоноль — это не четко определенный алгоритм действий, а совокупность методов, объединенных общей целью — ноль известных багов в беклоге. Методы можно разделить на 2 группы:
Способы первой группы топорны, зато бескомпромиссны. Как только становится известно о баге, его починка становится наиболее приоритетной задачей.
Вторая группа очень напоминает технику пустого инбокса Максима Дорофеева. Как только становится известно о баге, принимается решение: сейчас или никогда.
Просто и понятно. Почему бы не воспользоваться? Очевидно, из-за минусов, которые в нашем случае перевешивают выгоду.
Починить всё легко, когда «всё» — это «и это всё?». Единственная опечатка в системе и допустил ты её прямо сейчас. А когда «всё» — это «всё, с меня хватит» и количество известных багов перевалило за отметку «тлен», то совет всё починить воспринимается как шутка.
Второе ограничение связано с последствиями явного отказа исправления бага. Такое решение кто-то должен донести до заинтересованных лиц. И в глазах этого человека сохранение надежды, что баг когда-либо починят может казаться более привлекательным, чем прямой отказ.
Кроме того, такой подход хуже проявляется на больших масштабах и в запутанной среде. И всё же, прежде чем отклонить эту технику, примерьте её в своём контексте.
Фиксики
Допустим, вы пока не готовы перейти на ZBP. Накопление багов — неотъемлемая часть ваших процессов, как и починка. Часто баги обозначают в производственной системе как отдельный тип работ. И этот тип часто конфликтует с другим — фичи. Эффективный менеджер с трезубцем в руке как-будто нашептывает: «Раздели. Занимайся фичами, а баги починит кто-то другой.»
Одни фокусируются на фичах, другие — на устранении дефектов. И хотя в моей практике подобные конфигурации встречались редко и быстро разрушались, я считаю, что упоминания они заслуживают. Хотя бы для того, чтобы посоветовать так не делать.
Всё ради общего благого дела: «позволить лучшим из лучших сфокусироваться на самом важном». Это могло бы звучать как единственный плюс данного подхода, но, увы, при ближайшем рассмотрении ничего хорошего для общей цели метод не сулит.
А вот чем богат подход, так это минусами. И чем дольше вы практикуете его, тем проще вам будет расширить данный список нежелательных явлений:
отсутствие важной информации, хранящейся в багах, у тех, кто разрабатывает фичи;
отсутствие важной информации, хранящейся в фичах, у тех, кто чинит баги;
потеря целостности продукта.
Как вы заметили, наш список не такой уж большой. Мы пробовали, нам не понравилось.
Ху из он дьюти тудей?
Модификация предыдущего подхода, но более живучая. Мусорят все, прибирается один. График дежурства должен быть составлен таким образом, чтобы минимизировать негативные последствия и дать достаточную передышку от грязной работы.
Это первое, что стоит предложить, если перед вашим кабинетом столпились недовольные разработчики с вилами и факелами. Добавим справедливости и возвращаемся к работе.
Плюсы — склады багов не переполняются и с вами остались сотрудники с некоторым запасом терпения.
Минусы — баги чинятся, но чинятся неэффективно. Когда приходится отдуваться за всех, мотивация не поднимется выше потолка заданного Фиксиками. Баги имеют разные контексты, зачастую незнакомые дежурной команде. Время починки строго ограничено графиком и если для починки бага требовалось подождать, то это ожидание продлится дольше необходимого.
Субботник
Этот вариант можно рассматривать как альтернативу перехода от выделенной команды для починки багов к дежурству. Или же этот вариант может оказаться вынужденной необходимостью, когда падение качества стало заметно даже тем, кто способен дернуть стоп-кран.
Астрологи объявляют неделю наведения порядка. Всем грабли для разгребания граблей.
Ущерб для бизнеса очевиден — пока все чинят баги, никакие другие типы работ не выполняются. Хочется верить, что на такой шаг идут, только когда другого выхода нет, и ущерб от низкого качества еще сильнее. Совсем хорошо, если из таких прецедентов делают выводы и более не повторяются.
А что с эффективностью починки багов? Мне думается, что она выше, чем в случае дежурства. Во-первых, субботник прекратится не по графику, а когда у того кто ввел этот режим погаснет красная лампочка. Приблизить этот момент — посильное дело. Во-вторых, в активности участвуют одновременно все, а значит на руках полный набор необходимых знаний и компетенций, единая цель.
Итак, мы перебрали все известные подходы и не нашли решения. каким будет наш следующий шаг? Правильно! Изобретение велосипеда. А если серьезно, то выстраивание процессов в частном контексте на основе имеющихся знаний и опыта.
Наша история
Действительно интересные решения приходят только в условиях ограничений. Когда ты не можешь себе позволить закидать проблему безграничными ресурсами. Поэтому в качестве присказки небольшое вступление о них.
Ограничения
Прилаживание не было быстрым. Более того, процесс продолжается по сей день.
Давайте посмотрим какие общие ограничения обуславливают наши действия:
нет возможности привлечь дополнительных или выделенных людей;
нельзя нарушать баланс между разработкой фич и поддержкой кода, включая починку багов с прода.
Другими словами, допустимо изменять потоки работы. При этом состав вовлеченных людей и содержание их действий не должно меняться. В общем, никаких революций. Задача стояла сделать лучше, оставаясь в текущих рамках.
Пармезан
Прежде всего мы взялись за наведение порядка на складах. Как выглядела ситуация до упорядочивания:
4000 багов раскиданы по десяткам Jira-проектов;
актуальность большинства багов не подтверждена;
часть баг-репортов содержит минимум информации с расчётом на то, что баг починят моментально;
сомнительная достоверность выставленного приоритета.
Мы определили все входящие источники, пополняющие данный тип рабочих элементов. Наскребли по сусекам и перемотали через OR изолентой. Получился очень некрасивый JQL.
Некрасивый, но рабочий JQL запрос
Управлять такой амёбой было сложно и мы пересадили её в отдельный аквариум — предполагалось в дальнейшем хранить баги с прода только в едином новом проекте под названием BUG. Ограниченный доступ, набор обязательных полей и регулярный обзор — всё для обеспечения порядка на складе.
Прежде чем известный баг попадал из закромов в BUG, он валидировался менеджером продукта и упаковывался по-новому. Кроме стандартного описания репорт дополнялся следующей информацией:
тип используемой аккаунтом биллинг-системы;
конфигурация продукта и бренд;
локация, в которой воспроизводится баг, — в простейшем исполнении заполнялся как URL соответствующей web-страницы.
Новое ограничение. Предстояло перевести в BUG проект 4000 багов. В нашем распоряжении исходно было всего четыре руки, а голов и того меньше. Поэтому мы обратились за помощью к специалистам, тем, кто кушает такие сложности на завтрак.
После фича-фриза продукт, в разработке которого мы принимаем участие, проходит фазу стабилизации. Важной её частью является регрессионное тестирование системы. Такое тестирование выполняется силами отдельной команды QA-специалистов. Из чувства прекрасного по собственной инициативе они и ранее верифицировали часть багов с прода. В основном проверялись те баги, которые ими и были заведены. Но нам не хватало ресурсов проверить весь склад. Стандартный объем без ущерба для основной деятельности — 200-300 верифицированных баг-репортов за цикл.
Мы договорились, что после каждого крупного квартального релиза эта команда как и раньше будет обрабатывать около 200 багов, но те, которые наиболее желательно было перетащить в BUG проект. Если баг при проверке воспроизводился, то отчет дополнялся полезной информацией.
Где-то на полпути тёрка затупилась, но мы таки управились к апрелю
Отношение закрытых к воспроизведенным было 1:2. За полтора года на склад перевезли все баги уровня P2. А еще через полгода — верифицировали 80% всех известных багов. Без изменения схем работы команд, используя текущие правила игры.
Непосредственно в BUG тикеты переводились силами PM. Заодно валидировался приоритет, и проводилась кластеризация по бизнес-областям.
за два года все известные баги прода переведены в единый проект;
немного подправили процессы, чтобы предотвратить попадание продакшн багов в другие Jira-проекты;
каждый баг содержит расширенную информацию, что упрощает поиск;
каждый баг содержит видео воспроизведения, что улучшает восстановление контекста при починке.
Во время работы по этой активности мы общались со многими людьми, и пояснять каждую кастомизацию общими словами было бы долго и скучно. Поэтому для каждой значимой части придумывались короткие названия, якоря. Тут отсылка к принципу Пармезана — не есть целый кусок, а натереть небольшую его часть перед употреблением.
Кукушка
Недостаточно просто коллекционировать и аккуратно складывать известные баги. Это не шедевры из Эрмитажа. Полное удовлетворение приходит только после закрытия бага.
Мы не могли просто принести эти баги в команды с просьбой починить. Это нарушило бы один из принципов инициативы — не влиять негативно на текущую схему рабочей нагрузки.
Мы стали препарировать весь флоу починки типичного бага с прода на основе имеющегося опыта разработчиков по работе с этими багами. Примечательно, что многие из них с точки зрения кода чинились за полдня. При этом с момента взятия в работу до состояния готовности проходили дни, а иногда недели. И мы стали исследовать, куда утекает время.
Больше всего затрат было на восстановление контекста: мыслительного и технического. Для воспроизведения бага требовались особенные настройки окружения. Приходилось ждать подходящего момента, когда перенастройка не повредит основным задачам. Другой немаловажный аспект — разработчику приходилось выныривать из текущего проекта и погружаться в контекст бага. Очевидно, разница между этими контекстами могла быть большой и во времени (разные релизы) и в пространстве (система большая и сложная, с разными функциональными областями). Всё это в итоге складывалось и в психологический эффект — не было никакого желания браться за починку таких багов.
Мы сделали предположение: если разработчик будет уже находиться в контексте бага, то починка и не отвлечет разработчика надолго и не вызовет сопротивления.
Так возникла Кукушка. Имея упорядоченный склад, мы можем проводить эффективный быстрый поиск. Баги можно сгруппировать по локации, которая по сути представляет собой контекст. Во время очередного релиза команда занимается проектом в определенном контексте. Обеими областями знаний умело оперирует Product Manager (PM).
Когда PM готовит эпик для команды, через поиск релевантные по контексту баги со склада подтягиваются в этот же эпик. PM «подкладывает» баги в запланированную корзину. Отсюда и название — Кукушка.
С командой действует договоренность: запланированная работа в приоритете, но когда есть возможность, берутся подкидыши с прода. Часть из них закрывается как более неактуальные — например, из-за изменившегося дизайна страницы. Часть фиксится, с приемлемым расходом времени.
мы получили трёхкратный прирост закрытых багов с прода;
мы не изменили отношения между PM и командами разработки;
в обязанности PM входило расширение стандартного эпика багами с прода, имеющими общий с эпиком контекст. Но благодаря упорядоченному хранению, поиск информации не отнимал много времени.
Так сказался эффект Кукушки на числе закрытых известных багов. Разработчики, длительность цикла, приоритеты — без изменения.
Уборщик (Janitor)
Системный анализ захватил не только область хранения и устранения известных проблем, но и изучение источников пополнения.
Уборщика из Scrubs знают и в США, и в России, и в Китае. Хорошо подобранная ассоциация помогает быстрее понимать друг друга. Еще и напоминает о том, что не такие уж мы и разные.
Самым крупным поставщиком сырья на ПРОДовольственный склад невостребованных багов были остатки перед выпуском релиза. В момент, когда бизнес считает, что релиз пора выпускать, в работе еще есть баги. Ранее большинство из них возвращали в бездонные беклоги команд разработки. Теперь предстояло перевезти их на склад.
Основная наша цель тут была максимально прозрачно для бизнеса сообщить о том, что в релиз вместе с полезным контентом ушли баги. Забывать про них нельзя. Плюс необходимо было законсервировать контекст привносимых багов, чтобы эффективно его восстановить.
Структурированная информация о внесенных известных багах улучшила взаимодействие с бизнесом. Некоторые баги стали включаться планово в следующие релизы.
Сегодня я многое понял
Наша история — не быстрая прогулка, а долгое путешествие. Мы многому научились, идя по этому пути. Во-первых, улучшений можно добиться не выходя за рамки действующих правил. Для того чтобы получить значимый результат, не обязательно объявлять громкую кампанию, подключать большие ресурсы. Можно обойтись без резких изменений, а развиваться постепенно. Главное — понимать в какую сторону.
Во-вторых, в самом начале пути мы не рассчитывали на поддержку, скорее ожидали сопротивления изменениям. Людям это свойственно. Но мы были приятно удивлены желанию многих помочь в достижении общей цели. В этом ключ успеха.
В-третьих, следуя такому пути, надо набраться терпения. Это дело не быстрое. Хотя другого вряд ли стоило ожидать. Когда годами копившиеся привычки приводят к нежелательным явлениям, то компенсировать их за один присест не получится.
В-четвертых, в очередной раз убедились что нет серебряных пуль. Лучший вариант — это подбор хорошей практики полезной в своём контексте.
Ниже чуть больше деталей того, что на наш суд получилось, а что нет.. пока нет.
Что получилось
Тренд неконтролируемого роста багов общими усилиями удалось зафиксировать на определенном уровне. Этот уровень для P2 багов соответствует примерно половине от прогнозируемой в 2019 году отметке на данный момент. 952 известных P2 бага против ожидаемых 1840.
Получилось не нарушить текущие процессы разработки
Получилось выстроить систему менеджмента багов с прода
Что пока не получилось
Рассчитывали на убывающий тренд за счёт того, что скорость починки будет выше, чем скорость притока новых известных багов. Сейчас наблюдаем плато.
Не получилось полноценно вовлечь представителей бизнеса. Баги на проде воспринимаются как проблемы инжиниринга, как некий долг. Интерес бизнеса резко усиливается, только когда какой-то баг выстреливает, — ущерб от него соизмерим с запросом на создание фичи.
Не получилось в достаточной мере визуализировать поток багов. Возможностей Jira не хватает, а google sheets костыли не выглядят надежно. Много ручной работы по администрированию.
Всё ещё требуется администрирование системы, она не автономна. Периодически проседают отдельные узлы.
Общий интерес менеджмента к проблеме продакшн багов снижается с ростом успехов по их починке. Видимо, есть некоторая планка, ниже которой проблема перестает быть видимой и значимой.
Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее.
Мы продолжаем наш путь. В планах усилить компенсирующие обратные связи, снизить число багов до управляемого уровня, автоматизировать Кукушку, вернуться к идее ZBT.
Полезные ссылки по теме из моей коллекции:
Мне не попадалось много статей на эту тему, но если применение данной практики в вашей ситуации оправдано, то постарайтесь сделать жизнь людей комфортнее: 9 Ways to Incentivize Bug-Fix Teams by Bobby Tahir