Как часто вы игнорируете исключения?
Исключения в работе приложений — это технический долг.
Тот самый показатель качества спроектированного ПО, который вероятно вам никогда не покажут, если только вы о нём не знаёте и не спрашиваете сами.
Другими словами, покажут или нет - зависит от развития технологического и организационного.
В зависимости от технического развития компании, Заказчик/Продакт/Менеджер/Техдир (подставьте свое) может думать, что всё работает всегда идеально, а когда ломается - "это не у нас".
Если техническое развитие компании высокое, то понимают, что ошибки стреляют постоянно. При этом в зависимости от выстроенных процессов и коммуникации внутри команды/компании, а так же приоритетов, на эти ошибки закрывают глаза (если бизнес позволяет) или не закрывают (если цена ошибки слишком большая).
И там, и там продолжается это до тех пор пока ошибки не выстреливают заметно в проде так, что уже не проигнорируешь.
Тогда легче обосновать, почему надо "здесь и сейчас начать решать эту проблему".
Примерно так появился incident-management: "Мы приоритизируем проблемы в зависимости от того, как они портят наш SLA".
Основной фокус — на реактивном устранении причин сбоев, а не на превентивном анализе.
Как предотвращать проблемы? Почему игнорируются ошибки?
Коллеги с Alibaba собрались и ответили на неудобные вопросы.
Взяли несколько команд, провели опрос, проанализировали данные, и протестировали несколько моделей, которые могут вычислять root-cause автоматически (можно почитать в статье), чтобы снизить время разбора инцидентов.
Как это делается? Методов много и в этой сфере идёт активное развитие.
В этом посте я просто хотел поделиться графиками и статистикой для общего понимания темы среди читателей. У графиков в статье качество плохое, поэтому пришлось "нарисовать" с нуля.
Несколько наблюдений:
🔵Масштаб проблемы: ~69К исключений/день по 4k приложений. В среднем создают нагрузку от +12ч в день на разработчика — непосильную нагрузку.
🔵Более 80% разработчиков считают, что менее 10% всех исключений являются по-настоящему важными.
🔵Обработка исключений — рутинная, но ресурсоемкая задача, отнимающая время от разработки новых функций.
🔵Разработчики вынуждены фильтровать поток исключений, фокусируясь на малой доле (<10%) важных.
🔵Преобладает реактивная модель работы (устранение сбоев), а не превентивная.
🔵Усталость и замыленность — распространенное явление из-за объема и сложности исключений.
Даже, если вы не Alibaba, во многих командах причины те же.
Всё сводится к тому, что команда бежит писать бизнес-фичи, которые нужны были ещё вчера, срезает углы, накапливается технический долг. А потом технический долг отнимает время команды от того, чтобы писать бизнес-фичи.
#business@egorword
#pro@egorword
#likejava@egorword
