Комментарии 4
А что за дашик у вас такой?
На мантис похоже
Это karma, опенсорс-решение: https://github.com/prymitive/karma?tab=readme-ov-file
Мы в своей команде пришли к похожей модели, но начали с shadow-дежурств. Механика такая: QA-инженер не несёт формальной ответственности в он-колле, но целую неделю «сидит на плече» у дежурного разработчика. Смотрит в те же дашборды, слушает те же созвоны, задаёт вопросы. Это снимает 90% страха «а вдруг я что-то сломаю». Главный инсайт, который после таких циклов команда тестирования кардинально меняет фокус. Из «почему падает тест?» на «а что будет с очередью, если этот воркер умрёт?». Автоматически рождаются тесты на resilience (Chaos Mesh, кстати, отлично вписался).
Вопрос, который у нас до сих пор вызывает споры как вы балансируете нагрузку? Не возникает ли конфликта между «нужно писать тесты/автоматизацию» и «нужно быть в готовности к инциденту»? Ввели ли вы какую-то formal reduction в планах на время дежурства?И спасибо за список литературы — «Кабанчик» (Release It!) действительно must-read. Добавлю от себя «Building Evolutionary Architectures» — там отлично разобрана идея fitness functions, которые очень близки к мониторингу «здоровья» системы, о котором вы пишете.
QA в дежурствах: путь к настоящему качеству