Почему критические изменения API — это проблема инфраструктуры, а не проблема мониторинга

Выставление счетов прекращается в 2 часа ночи. Не из-за ошибки, которую вы написали. Не из-за того, что вы сделали развертывание. Потому что Stripe незаметно удалил поле из ответа API; поле, которое ваш код оплаты читает в течение 18 месяцев. Вы тратите три часа на поиск 12 файлов, внесение исправлений, повторное развертывание и объяснение соучредителю, почему сегодня утром снизился доход. Это случается с каждой инженерной командой. И это продолжает происходить, потому что все относятся к этому как к проблеме мониторинга. Ловушка мониторинга: Инстинкт после этого инцидента: «Нам нужен лучший мониторинг». Итак, вы добавляете Datadog. Вы настраиваете оповещения о частоте ошибок. Вы подписываетесь на журналы изменений API вручную. Вы поручаете кому-то читать их каждую неделю. Ничто из этого не предотвращает проблему. Это просто заставляет вас немного быстрее реагировать на него. Мониторинг носит реактивный характер. Он говорит вам, что что-то сломалось после того, как сломалось. Критические изменения API однозначно плохи для мониторинга, потому что: Они не всегда вызывают немедленные ошибки. Иногда они вызывают молчаливое неправильное поведение. Журнал изменений публикуется за несколько дней или недель до даты выхода из строя; у тебя есть время, если ты поймаешь его Исправление требует понимания вашей конкретной кодовой базы, а не только API. Мониторинг