Просмотр исходного текста страницы LXF110:Решаем проблемы

: '''Решение проблем''' Эти советы помогут любому пользователю [[Категория:Учебники]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{{Врезка|Заголовок=Скорая помощь|Содержание= ''ps, top'' и ''df'' – вот инструменты первого эшелона. Удивительно, как много проблем сводятся к диску, памяти или процессору.|Ширина=200px}}

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

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