Материал из Linuxformat.

Решение проблем Эти советы помогут любому пользователю

Содержание 1 Жизнь без проблем: базовые принципы 1.1 1 Делайте заметки 1.2 2 Сравните с другими машинами 1.3 3 Сужайте круг поиска 1.4 4 Изменяйте лишь одну вещь за раз 1.5 5 Загружайтесь в пошаговом режиме 1.6 6 Ясный отчет об ошибке 1.7 Проблем лучше избегать

Жизнь без проблем: базовые принципы

У компьютеров новые проблемы всегда наготове – Джульетта Кемп предлагает несколько простых способов держать все под контролем.

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

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

1 Делайте заметки

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

Делайте заметки о ситуации, с которой вы начали; делайте заметки при каждом изменении. Вам очень пригодится файл ~/.bash_history, если в спешке вы что-то забудете. Сохраняйте старые версии файлов, если вы меняете их, на случай, если забудете, что вы исправили на сей раз. (А еще лучше использовать систему управления версиями!)

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

Используйте физическую записную книжку, создайте wiki, нацарапайте заметки прямо на столе (последнее решение не очень-то гибкое). Все, что угодно. Главное – записать.

Должна признаться, что я все еще иногда не следую этому совету, особенно исправляя что-то жизненно важное к определенному сроку. (Хотя именно в такое время заметки обязательно следует делать). Но каждый раз, когда я не делала заметок, я всегда впоследствии жалела об этом.

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

2 Сравните с другими машинами

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

Полезная штука – diff, но если вы считаете его трудным для понимания (по мне, так он отнюдь не визуально интуитивный), то пригодятся vimdiff или gvimdiff. Если вы работаете в X, то gvimdiff имеет дополнительное преимущества изменения размера окна.

3 Сужайте круг поиска

Метод тыканья во все подряд – это определенно один из способов решения проблем, и я не могу сказать, что он не работает. Мне самой случалось им пользоваться. Но лучше все-таки попытаться локализовать проблему. Как и при поиске ошибок в коде, думайте: насколько малую часть вы можете протестировать и все еще уловить поведение? Эталонная (работоспособная) машина также может помочь. Все ли действует так, как должно? Что общего имеют машины? Можно ли что-то исключить из рассмотрения? Случается ли это в консоли? А если отключить iptables? Что происходит при закрытии других программ?

4 Изменяйте лишь одну вещь за раз

Именно так. Одно изменение, и вновь тестирование. Затем убедитесь, что изменения действительно сделаны и что вы тестируете именно ту машину (открыто много терминальных окон? Вы уверены, что сейчас именно в том, что требуется?), и вновь тестируйте. А вот потом можете менять что-то еще. Это тесно связано со сказанным выше о сужении поиска. (Я уже говорила вам, чтобы вы делали заметки, верно?)

5 Загружайтесь в пошаговом режиме

Если у вас проблемы с загрузкой или со службой, запускаемой автоматически при старте системы, можете загрузиться с /bin/sh в качестве init. Это может быть особенно полезно, если проблема – нечто приводящее к хаосу сразу после запуска: например, если вы так изгадили настройки вашего iptables, что заблокировались и каждый раз при перезагрузке вновь возвращаетесь в то же состояние. Ну, вы ж понимаете, я-то такого никогда не делала.

В Grub это достигается нажатием Е в загрузочном меню и редактированием команд. Выберите строку, начинающуюся с kernel, и нажмите Е вновь. Добавьте init=/bin/sh (или init=/bin/bash, если хотите), нажмите ENTER, а затем B для загрузки системы.

Это перенесет вас в оболочку sh или bash на ранней стадии загрузки. Отсюда вы можете или редактировать файлы (если вы уже знаете или предполагаете, в чем ошибка), или запустить систему пошагово для выполнения более глубокой отладки. Как всегда, ведите записи про любые изменения. Если они не приведут к исправлению, вы, вероятно, захотите их отменить.

6 Ясный отчет об ошибке

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

• Какая команда/ситуация вызывает ее?
• Каков ожидаемый результат?
• Каков реальный результат?
• Случается ли это, если вы используете разные машины? (особенно полезная информация в ситуациях, когда некоторые каталоги расположены в NFS, а пользователи централизованы)
• Проявляется ли это для разных пользователей?
• Что вы проделали для исправления ситуации?

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

Надеюсь, все эти советы и уловки дадут вам несколько полезных ориентиров (или замусорят память) для следующего раза, когда что-то случится. Один совет напоследок: если сомневаетесь, встаньте, пройдитесь и займитесь чем-то другим. Выпейте чашку чая, или, может быть, съешьте пирожное. Обойдите вокруг здания. Дайте мозгу отдохнуть. Иногда бывает достаточно прекратить ломать голову над проблемой на 30 минут, чтобы появился свет в конце тоннеля. И даже если нет, вы насладитесь прекрасной чашкой чая с пирожным, а это всегда приятно. LXF

Проблем лучше избегать

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

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

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