Совершенствуйте свои навыки разработки и эксплуатации с помощью теории устранения неполадок

За несколько лет до прихода в DNSimple я около 3,5 лет проработал в магазине Apple Retail в Genius Bar, помогая диагностировать и ремонтировать все, от iPod до систем XServe. Самым большим выводом, который я сделал за время работы, была Теория устранения неполадок, которая помогла мне решить множество сложных проблем как разработчику, так и системному администратору здесь, в DNSimple. Я объясню процесс устранения неполадок шаг за шагом с некоторыми реальными примерами того, как вы можете применить это к разработке, администрированию серверов и ремонту оборудования, ближе к концу моей статьи.

Действия по устранению неполадок обычно следующие:

  1. Собирать информацию
  2. Изолируйте проблему
  3. Планирование решения
  4. Реализация решения
  5. Тестирование решения

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

Когда вы сталкиваетесь с проблемой, постарайтесь получить как можно больше информации о проблеме. Такие как:

  • Симптомы (что происходит, что кажется ненормальным?)
  • Этапы воспроизведения (можете ли вы воссоздать проблему? Как?)
  • Все, что могло привести к возникновению проблемы («Мы перезагружали сервер, когда…»)
  • Области, которые затронуты или, скорее всего, будут затронуты (это файл кода, может быть, набор методов в вашем коде? Сетевая карта на сервере?)

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

Второй шаг: выявить проблему

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

  1. Линейный
  2. Half-Split (также называемый Split-Half)

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

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

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

Линейный: сверху вниз

Подход, противоположный восходящему принципу, проще, и, как правило, вы можете попробовать его в первую очередь. Обычно это начинается на уровне приложения или операционной системы, когда вы спускаетесь вниз по стеку к платформе или оборудованию. Для разработчиков попробуйте закомментировать одну или две строки кода. Системные администраторы могут попробовать получить доступ к другому веб-сайту, настроить другой виртуальный хост или перезапустить процесс и продолжить его. Нисходящий подход может следовать модели OSI, когда вы начинаете с уровня 7 и постепенно спускаетесь до уровня 1 в изоляции проблемы, особенно если она связана с сетью. Это может привести вас к тестированию таких основ, как настройки DNS-преобразователя, конфигурации брандмауэра и настройки сети, чтобы выявить проблему.

Half-Split (или Split-Half)

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

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

Третий шаг: планирование решения

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

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

Четвертый шаг: реализация решения

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

Последний шаг: тестирование вашего решения

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

Практические примеры

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

Пример отладки программного обеспечения

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

Линейный подход

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

Подход с разделением половин

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

Планирование, применение и тестирование решения

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

Пример аппаратной отладки

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

Линейный подход: сверху вниз

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

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

Подход с разделением на половину

Как удобный геймер, у вас был live-диск linux на флэш-накопителе, который вы использовали раньше и знаете, что он работает. Таким образом, вы можете использовать его для очень быстрой загрузки и проверить, работает ли это, возможно, приблизив вас к тому, является ли это проблемой аппаратного или программного обеспечения. Предполагая, что ваша установка загружается, вы затем обращаетесь к встроенной памяти и математическим тестам на живом диске Linux, чтобы выполнить некоторые быстрые проверки ОЗУ и ЦП, чтобы устранить еще один основной источник ошибок. Это значительно сужает список возможных источников вашей проблемы за считанные минуты.

Планирование, применение и тестирование решения

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

Вывод

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

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

Не торопитесь, задавайте вопросы и, если возможно, поделитесь своим процессом со своей командой, чтобы помочь им расти.

Автор Аарон Калин. Первоначально опубликовано на blog.dnsimple.com.