Методы решения проблем: снайпер против генерала

Какой подход лучше в борьбе с критическими инцидентами в production?

10:00 утра, команда сталкивается с инцидентом: «Селектор товаров на главной странице нашего интернет-магазина показывает только 50% товаров», начинается решение проблемы.

Команда, владеющая сайтом, начинает расследование. Один из членов команды утверждает, что проблема, скорее всего, в ETL, который отвечает за кеш товаров, использующийся в этом селекторе, и который запускается в 9:00, так что он собирается пересобрать этот кеш вручную. На это уйдет 30–40 минут, и тогда результаты снова появятся на главной.

В 11:00 после пересборки кеша проблема сохраняется. Тому же члену команды приходит другая идея: «вероятно, дело в шардинге кеша. Возможно, один или несколько узлов ведут себя неправильно. Давайте отключим шардинг; это временно увеличит нагрузку, но проблема будет решена»

Шардинг отключен, кэш перестроен, и к 12:30 дня команда понимает, что все еще выводится только 50% товаров. Другая идея: "На прошлой неделе мы обновили компонент товара на фронте. Возможно, поэтому некоторые из них не отображаются". Команда откатывает релиз компонента, но все с тем же результатом. День подходит к концу, а проблема остается нерешенной.

Я был свидетелем такого подхода тысячи раз. Возникает проблема в очень сложной системе с большим количеством движущихся частей, и кто-то сразу же предполагает наиболее вероятную причину и начинает исправлять ее, чтобы затем обнаружить, что причина была не в этом. Этот цикл может повторяться несколько раз, затягивая решение проблемы на несколько часов или даже дней или недель.

Это стратегия угадывания и снайпинга. Инженер выступает в роли снайпера, выбирает цель (угадывает) и устраняет ее (снайпит). Если интуиция его не подведет, эта техника даст решение в рекордно короткие сроки. Но в противном случае она может закончиться водоворотом попыток, потерей времени и разочарованием.

Существует и другой подход к исправлению сложной ошибки - стратегия "разделяй и властвуй". Она заключается в том, чтобы оглядеть систему и все ее составные компоненты и придумать проверку, которая поможет нам убрать из поля возможных причин большую часть компонентов (разделить). Мы продолжаем делить так систему до тех пор, пока оставшаяся область не станет настолько мала, что мы сможем точно определить, откуда возникла проблема (властвовать).

К примеру, в истории с селектором товаров мы могли бы вызвать API товаров, который используется веб-страницей, и проверить, есть ли там товары, которые не выводятся. Если API возвращает только 50% товаров, мы можем отбросить весь фронт-энд, JavaScript или все возможные обновления браузеров. В этом случае мы бы разделили проблему пополам, отбросили половину и упростили себе задачу вдвое.

Основное различие между снайпингом и разделением заключается в цели расследования. При снайпинге мы ищем то, что работает неправильно. При разделении мы ищем то, что позволит определить, пострадала ли одна часть системы или другая.

Итак, у нас есть два подхода к решению одной и той же проблемы: снайперский, который устраняет возможные первопричины одну за другой, и "генеральский" (или "всеохватывающий", general), который предпочитает видеть общую картину и придерживаться стратегии разделения и покорения противника. Давайте сравним оба подхода и рассмотрим их плюсы и минусы.

Снайперский метод может быть очень быстрым, если предположения сделаны верно. Насколько вероятна правильность догадок:

• Чем более опытны в работе с системами наши сотрудники, тем больше вероятность того, что их предположения окажутся верными.
• Чем сложнее система, тем меньше вероятность верности догадок.
• Чем больше попыток они предприняли, чтобы найти решение, тем меньше вероятность того, что следующие догадки окажутся верны. То есть вероятность того, что первая догадка окажется верной, гораздо выше, чем последующие. Если то, что мы уже предприняли, не помогло, вряд ли то, что мы предпримем следующим, окажется первопричиной проблемы.

Первые два пункта очевидны, но третий заслуживает более подробного объяснения. Когда команда берется за проблему и рассматривает несколько возможных ее причин, она бессознательно выберет наиболее вероятную из них. По мере того, как они будут терпеть неудачи и пытаться снова, их догадки будут статистически менее вероятными первопричинами.

Всеобъемлющий подход, с другой стороны, более безопасен. Может потребоваться некоторое время, чтобы взять ситуацию под контроль, но чем больше времени будет потрачено, тем ближе мы окажемся к решению. В противоположность снайперскому подходу, где чем больше времени мы тратим, тем дальше мы уходим от решения.

Снайперский метод может быть быстрым, всеобъемлющий - более безопасным. Что выбрать? И то, и другое.

Наилучшая практика - прежде всего оценить, есть ли очевидный кандидат для снайпинга. Первые варианты с высокой вероятностью могут оказаться правильными. Особенно если речь идет о системе, которой владеет наша команда. Но как только первые варианты оказываются неверными, нужно сесть, проанализировать общую картину и изменить подход на противоположный.

Если вы менеджер, возможно, моя история будет вам интересна. Однажды я столкнулся с такой же ситуацией. Команда занимается снайпингом проблем, время идет, и я решил вмешаться и попросить команду изменить подход. Первой реакцией команды было: "Мы здесь технические эксперты; дайте нам спокойно поработать!". И они были правы. Но в то же время я понимал, что их подход был неправильным. Что делать в такой ситуации?

Урок, который я извлек из этих инцидентов и которым хочу поделиться с вами, заключается в том, что репетиторство в разгар пожара - не самое лучшее занятие. Когда люди находятся в состоянии стресса, это не то время, в которое следует читать лекции своей команде.

Если команда не уверена в себе и ей не хватает лидерства или координации во время работы над проблемой, они будут рады, если вы вмешаетесь в ситуацию. Вы - их руководитель, и, скорее всего, они ждут этого от вас. Это и есть поддержка, в которой они нуждаются. В таких случаях у вас больше возможностей для взаимодействия с ними. Не читайте нотаций в это время, а согласовывайте с ними решения, которые двигают их в правильном направлении.

С другой стороны, если команда уверена в своих силах и имеет четкое представление о том, что им делать, вам не следует вмешиваться. Дайте им поработать. Ваша роль в это время должна сводиться к заинтересованной стороне, спрашивающей, как помочь, каков статус, что ожидать.

Ваша роль должна больше сводиться к их защите, устранению блокирующих элементов, ведению записей и поддержанию связи с остальной организацией. В какой-то момент они могут проявить признаки неуверенности, отчаяния и попросить о помощи. Это дверь, которая открывается для вас, чтобы вы могли войти и помочь им.

Время для анализа того, как мы справились с проблемой, обсуждения предпринятого подхода и поиска того, что можно улучшить, наступит позже, на этапе пост-мортем и извлечения уроков. Чтение таких лекций должно происходить вне кризиса.

Материал подготовлен с ❤️ редакцией Кухни IT.