Почему устранение неполадок так сложно?

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

Если вы склонны отвечать ДА на последний вопрос, то вы теряете много времени, пытаясь найти ответ. Еще хуже, поскольку этот процесс совершенно непредсказуем, он создает напряженность в команде, и, скорее всего, начнёт указывать пальцем:

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

Устранение неполадок в производстве

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

Прежде всего, вы боретесь с давлением « давайте просто перезапустим экземпляр, чтобы вернуться в нормальное состояние ». Желание использовать самый быстрый способ избавиться от воздействия на конечных пользователей естественно. К сожалению, перезапуск также может уничтожить любые свидетельства относительно фактической первопричины. Если экземпляр перезапускается, вы больше не можете собрать доказательства того, что на самом деле происходило. Даже когда перезапуск решает проблему, сама первопричина все еще существует и просто ожидает повторения.

Далее на очереди другие аспекты, связанные с безопасностью, которые имеют тенденцию изолировать разработку от производственных сред . Если у вас нет доступа к среде самостоятельно, вы вынуждены устранять неполадки удаленно, со всеми проблемами, связанными с этим: каждая операция, которая должна быть выполнена, теперь включает в себя несколько человек, что увеличивает как время, необходимое для выполнения каждого действия, так и потенциально теряя информацию по пути.

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

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

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

Таким образом, вполне вероятно, что вы окажетесь в ситуации, когда дни или даже недели тратятся на прохождение еще одного сценария сбора телеметрии или еще одного патча «будем надеяться, что это сработает»:

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

Устранение неполадок в тестировании / разработке

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

• Тестовая среда не использует тот же источник (и) данных, что и производственный. Это означает, что проблемы, вызванные объемом данных, могут не воспроизводиться в тестовой среде.
• Шаблоны использования, раскрывающие определенные проблемы, нелегко воссоздать. Представьте себе проблему, которая возникает только 29 февраля и требует от двух пользователей Windows ME одновременного доступа к определенной функции, вызывающей конкретную проблему параллелизма.
• Само приложение не то же самое. Производственное развертывание может иметь существенно различную конфигурацию. Различия могут включать в себя разные ОС, функции кластеризации, параметры запуска или даже разные сборки.

Эти трудности приводят к печально известной цитате «работы на моей машине»:

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

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

Оснащение и опытные люди на помощь?

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

Если вы нашли вышесказанное слишком знакомым, не бойтесь, вы не одиноки. Далеко не все инженеры испытывают недостаток в глубоком опыте в этой области, который делает невозможным прогресс на основе известных шаблонов. В этом нет ничего постыдного — если вы не Брендан Грегг или Питер Лоури , у вас просто нет 10 000 часов на поиск неисправностей, чтобы сделать вас экспертом в этом вопросе.

Этот недостаток опыта приводит к тому, что разные инструменты для сбора фактов бросаются навстречу рассматриваемой проблеме, в том числе:

• Сбор различных метрик (процессор, память, ввод-вывод, сеть и т. Д.).
• Анализ журналов приложений
• Анализ журналов ГХ
• Захват и анализ дампа потоков
• Сбор и анализ дампов кучи

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

Решение проблем кошмара

Помимо накопления минут на 10 000 часов, которые сделают вас экспертом в этой области, существуют более быстрые решения для облегчения боли, вызванной поиском неисправностей.

Профилирование в разработке

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

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

Тестирование в QA

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

Однако зачастую трудно оправдать инвестиции в обеспечение качества. Все, что называется «тестирование производительности» или «приемочное тестирование», в конечном итоге будет конкурировать с новыми функциями, основанными на четких и измеримых бизнес-целях. Теперь, когда единственное, что разработчик настаивает на задаче «производительность чего-либо», это какие-то сокращения, такие задачи никогда не выйдут из отставания:

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

Мониторинг в производстве

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

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

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

• Журнал мониторинга. Журналы из разных узлов вашего производственного стека должны быть агрегированы, чтобы инженерная группа могла быстро искать информацию, визуализировать журналы и регистрировать предупреждения об аномалиях. Одним из наиболее часто используемых решений является стек ELK, где журналы хранятся в Elasticsearch , анализируются в Logstash и визуализируются с помощью Kibana .
• Системный мониторинг. Агрегирование и визуализация показателей системного уровня в вашей инфраструктуре выгодны и просты в настройке. Отслеживание использования процессора, памяти, сети и дисков позволяет выявлять проблемы на уровне системы и регистрировать предупреждения об аномалиях.
• Мониторинг производительности приложений / Пользовательский опыт. Отслеживание взаимодействия отдельных пользователей покажет проблемы с производительностью и доступностью, влияющие на конечных пользователей. Как минимум, вы будете знать, когда определенные службы, предлагаемые вашим приложением, работают со сбоями. В лучшем случае, когда используется Plumbr , вы также приближаетесь к фактической основной причине в исходном коде.

Вынос

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

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