Основные причины багов в проде

Это мой личный рейтинг причин на основе работы в 5 компаниях в 4 странах в течении почти двух десятков лет:

1) Качество разработчиков. В начале карьеры я думал, что основная причина - отсутствие процессов. Но потом на практике убедился, что это не так. Какие бы не были процессы (код ревью, тестирование, мониторинг и т.д.) вы не сможете всего предугадать и сделать защиту от дурака от всех возможных случаев. Процессы помогают, но при низком качестве разработчиков это не спасет от всех возможных случаев. В Мета процессов почти нет, тестирование минимально, при этом количество багов не такое большое. Если вы будете нанимать верхние персентили разработчиков по качеству (что бы это не значило), то они будут сразу писать правильно и без багов.
2) Конфигурации. Это вообще топ причина для фангов. Что в Амазоне, что в Facebook/Meta sev0, Large Scale Event аутеджи чаще всего случаются из-за деплоя конфигураций в прод. Конфигурации практически никак не тестируются, быстро деплоятся в прод (минуты). И никто не знает как они повлияют на систему. В них нет/мало проверок, как автоматических так и ручных. Нет особых процессов. Нет интуиции и опыта, как с кодом. Поэтому качество программистов не всегда спасает.
3) Проблемы версионирования/API. Это актуально, если у вас не монолит. Если вы дергаете какую-то зависимость, но ее поведение изменилось и стало не таким каким вы его ожидаете или изменился протокол взаимодействия, то это приводит очень часто к багам. Это типичная проблема микросервисных архитектур, особенно, когда зависимостей очень много.
4) Miscommunication, неправильное понимание задачи/бизнес логики. Тут часто не спасают ни тесты, ни качество программистов. Тесты не спасают, т.к. если вы не правильно поняли как это должно работать, то и в тесте вы будете проверять, что оно работает как ожидаете вы, а не как правильно. Качество программиста тут только гарантирует, что оно будет работать как вы ожидаете, но не как правильно.
5) Проблемы зависимостей. Это то, что сложно контролировать. Если ваша зависимость перестала работать, то тут только нужно убедиться, что ваша компонента fault tolerant и реализованы все нужные механизмы для сокращения blast radius. Например, retry, rate limiting/throttling, circuit breaker, bulk head и т.д.
6) Отсутствие достаточного тестирования. Это только на 6 месте у меня, т.к. при хорошем качестве программистов, это не обязательное условие. При низком качестве, если вы хотите минимизировать число багов - это must have. Если человек не глубоко понимает как работает, написанный им, код. Не видит все edge-cases. Не имеет опыта, не предвидит потенциальные проблемы. Если человек не внимателен к деталям, если он не умеет делать прогрессивный ролаут, мониторить, находить проблемы и их исправлять, пока они не станут влиять на систему, то все возможные тесты обязательны.
7) Отсутствие прогрессивного ролаута и мониторинга в проде. Тестировать и воспроизводить условия прода в тестах часто очень сложно. Поэтому иногда проще задеплоить это в прод, но добавить feature flag и ограничить, кто может пользоваться этим функционалом. Например, можно начать с одного пользователя или маленького процента пользователей. Посмотреть как это будет работать в условиях прода, собрать и проанализировать все метрики и потом уже разворачивать на больший процент пользователей.
8) Сложное сочетание редких событий/медленная деградация системы. Обычно, это сложно покрыть тестами заранее. Часть проблем можно отловить нагрузочным/перфоманс тестированием, но не всегда. Т.к. длительность теста ограниченна по времени и баг может воспроизводится в каких-то особенных условиях. Например, у вас какая-то проблема в коде с многопоточностью, или у вас есть подтекание памяти, которое не происходит на масштабах времени работы нагрузочного теста. Тогда проблема может возникнуть в проде через большой промежуток времени при определенных условиях, которые сложно предусмотреть во время тестирования. Также частично это покрывается качеством программистов, у кого есть опыт и интуиция возможных проблем, но далеко не всегда. Обычно, такие проблемы находят в проде, долго инвестигируются и потом уже под них добавляют какой-то особенный тест.
9) Отсутствие или плохой code review. Одна из задач code-review это найти баги. Это хоть и не основная, но важная часть. Когда пару других разрабов посмотрят на ваш код, они могут заметить баги, которые не заметили вы. Из всех компаний, где я работал, это реально работало только в Amazon. Во многих других компаниях code review или отсутствовал, или был формальным. Но чаще это просто был тул для создания холиваров и конфликтов между программистами и ничему не помогал.

Каков ваш опыт? Почему у вас в компании чаще всего возникают баги?