Вопрос с черным ящиком — одна из самых старых традиций клуба «Что? Где? Когда?». На неделе приключилась рабочая история, которая напомнила мне эту самую традицию.
Очередной релиз — всё протестировано, QA и PO дали своё добро на внедрение — релиз покатился в заранее запланированное время, поды с новой версией сервиса прекрасно раскатываются на кластере, ошибок в логах не наблюдается. Все, казалось бы, рады…
Но фактически сервис не работает, как ожидается.
Вопрос знатокам — «Что же в чёрном ящике?»
Не буду углубляться в технические детали, скажу лишь, что найденная на следующий день проблема достойна размещения в музее пыток багов.
Проблема заключалась в том, что разработчики ошибочно поместили часть критически важной логики работы микросервиса внутри условия, которое выполнялось только при наличии уровня логгирования «DEBUG» (для примера накидал на Python):
logger = logging.getLogger(__name__)
logging.basicConfig(level=logging.INFO) # Сейчас стоит INFO, DEBUG-код не выполнится
def process_data(some_id):
print(f"Обработка каких-то данных {some_id}")
if logger.isEnabledFor(logging.DEBUG):
// Здесь какая-то критически важная логика
// Остальной кодКонечно же, на всех тестовых стендах логика приложения работала ровно так, как ожидается, поскольку на них выставлен был уровень логгирования «DEBUG», а на продакшне был «INFO».
Ба-дум-тсс!…
К слову, данную ошибку обнаружил Claude Opus буквально в первый проход по коду проекта. Если бы у коллеги было этой подписки, сидели бы как знатоки над чёрным ящиком.
Добавить комментарий