<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://wiki.linuxformat.ru/wiki/skins/common/feed.css?303"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="ru">
		<id>http://wiki.linuxformat.ru/wiki/index.php?action=history&amp;feed=atom&amp;title=LXF110%3A%D0%A0%D0%B5%D1%88%D0%B0%D0%B5%D0%BC_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B</id>
		<title>LXF110:Решаем проблемы - История изменений</title>
		<link rel="self" type="application/atom+xml" href="http://wiki.linuxformat.ru/wiki/index.php?action=history&amp;feed=atom&amp;title=LXF110%3A%D0%A0%D0%B5%D1%88%D0%B0%D0%B5%D0%BC_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B"/>
		<link rel="alternate" type="text/html" href="http://wiki.linuxformat.ru/wiki/index.php?title=LXF110:%D0%A0%D0%B5%D1%88%D0%B0%D0%B5%D0%BC_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B&amp;action=history"/>
		<updated>2026-05-13T13:08:56Z</updated>
		<subtitle>История изменений этой страницы в вики</subtitle>
		<generator>MediaWiki 1.19.20+dfsg-0+deb7u3</generator>

	<entry>
		<id>http://wiki.linuxformat.ru/wiki/index.php?title=LXF110:%D0%A0%D0%B5%D1%88%D0%B0%D0%B5%D0%BC_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B&amp;diff=8735&amp;oldid=prev</id>
		<title>Crazy Rebel: Новая: : '''Решение проблем''' Эти советы помогут любому пользователю Категория:Учебники  ==Жизнь без проблем...</title>
		<link rel="alternate" type="text/html" href="http://wiki.linuxformat.ru/wiki/index.php?title=LXF110:%D0%A0%D0%B5%D1%88%D0%B0%D0%B5%D0%BC_%D0%BF%D1%80%D0%BE%D0%B1%D0%BB%D0%B5%D0%BC%D1%8B&amp;diff=8735&amp;oldid=prev"/>
				<updated>2009-09-24T04:28:53Z</updated>
		
		<summary type="html">&lt;p&gt;Новая: : &amp;#039;&amp;#039;&amp;#039;Решение проблем&amp;#039;&amp;#039;&amp;#039; Эти советы помогут любому пользователю &lt;a href=&quot;/wiki/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A3%D1%87%D0%B5%D0%B1%D0%BD%D0%B8%D0%BA%D0%B8&quot; title=&quot;Категория:Учебники&quot;&gt;Категория:Учебники&lt;/a&gt;  ==Жизнь без проблем...&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Новая страница&lt;/b&gt;&lt;/p&gt;&lt;div&gt;: '''Решение проблем''' Эти советы помогут любому пользователю [[Категория:Учебники]]&lt;br /&gt;
&lt;br /&gt;
==Жизнь без проблем: базовые принципы==&lt;br /&gt;
&lt;br /&gt;
: У компьютеров новые проблемы всегда наготове – '''Джульетта Кемп''' предлагает несколько простых способов держать все под контролем.&lt;br /&gt;
&lt;br /&gt;
Я уже несколько лет как сисадмин, и мне стало более чем очевидно: сколько бы проблем вы ни решили, вас всегда подстерегает еще одна, с которой вы сроду не встречались. Иногда на помощь приходят накопленные знания, но нередко вам кажется, что вы&lt;br /&gt;
полный нуль и не имеете ни малейшего понятия, с чего начать.&lt;br /&gt;
&lt;br /&gt;
К счастью, даже если вы абсолютно не представляете, к какой&lt;br /&gt;
области знаний кинуться, существуют базовые принципы для выяснения того, что же пошло не так на этот раз. Я вывела многие из них из  собственного горького опыта; несколько раз – еще до того, как данные погибли. Так что, я надеюсь, они вам пригодятся!&lt;br /&gt;
&lt;br /&gt;
===1 Делайте заметки===&lt;br /&gt;
&lt;br /&gt;
Если изо всех способов упростить и ускорить решение проблем надо  выбрать один, то это именно он.&lt;br /&gt;
&lt;br /&gt;
Делайте заметки о ситуации, с которой вы начали; делайте заметки  при каждом изменении. Вам очень пригодится файл '''~/.bash_history''',  если в спешке вы что-то забудете. Сохраняйте старые версии файлов, если вы меняете их, на случай, если забудете, что вы исправили на сей раз. (А еще лучше использовать систему управления версиями!)&lt;br /&gt;
&lt;br /&gt;
Вы воображаете, что не забудете? Я в восторге от вашей памяти, но не верю вам. Вы действительно полагаете, что после десяти минут мыканья по множеству файлов и терзания сомнениями – а вдруг на этот раз все погибло? – сможете точно восстановить, что именно вы сделали, какой из предпринятых шагов и был роковым, а какой лишь испортил что-то по ходу?&lt;br /&gt;
&lt;br /&gt;
Используйте физическую записную книжку, создайте wiki, нацарапайте заметки прямо на столе (последнее решение не очень-то гибкое).&lt;br /&gt;
Все, что угодно. Главное – записать.&lt;br /&gt;
&lt;br /&gt;
Должна признаться, что я все еще иногда не следую этому совету, особенно исправляя что-то жизненно важное к определенному сроку.&lt;br /&gt;
(Хотя именно в такое время заметки обязательно следует делать). Но каждый раз, когда я не делала заметок, я всегда впоследствии жалела об этом.&lt;br /&gt;
&lt;br /&gt;
Завершив исправления, сохраните заметки где-нибудь в надежном месте. Шансы, что вы вновь встретитесь с этой проблемой или чем-то&lt;br /&gt;
подобным, чрезвычайно велики. Для долгосрочных записей я использую wiki, поскольку там имеется больше возможностей поиска, чем в&lt;br /&gt;
записной книжке.&lt;br /&gt;
&lt;br /&gt;
===2 Сравните с другими машинами===&lt;br /&gt;
&lt;br /&gt;
Если вы имеете несколько машин, а проблемы только на одной из них, то у вас под рукой есть полезный сравнительный тест. Чем больше&lt;br /&gt;
похожи файлы настроек обеих машин, тем полезнее сравнение. Но даже абсолютно разные машины содержат одинаковые настройки. Это&lt;br /&gt;
особенно выгодно при проблемах с сетью или с какой-то другой базовой частью системы.&lt;br /&gt;
&lt;br /&gt;
Полезная штука – ''diff'', но если вы считаете его трудным для понимания (по мне, так он отнюдь не визуально интуитивный), то пригодятся ''vimdiff'' или ''gvimdiff''. Если вы работаете в ''X'', то ''gvimdiff'' имеет дополнительное преимущества изменения размера окна.&lt;br /&gt;
&lt;br /&gt;
===3 Сужайте круг поиска===&lt;br /&gt;
&lt;br /&gt;
{{Врезка|Заголовок=Скорая помощь|Содержание= ''ps, top'' и ''df'' – вот инструменты первого эшелона. Удивительно, как много проблем сводятся к диску, памяти или процессору.|Ширина=200px}}&lt;br /&gt;
&lt;br /&gt;
Метод тыканья во все подряд – это определенно один из способов решения проблем, и я не могу сказать, что он не работает. Мне самой&lt;br /&gt;
случалось им пользоваться. Но лучше все-таки попытаться локализовать проблему. Как и при поиске ошибок в коде, думайте: насколько&lt;br /&gt;
малую часть вы можете протестировать и все еще уловить поведение? Эталонная (работоспособная) машина также может помочь. Все ли&lt;br /&gt;
действует так, как должно? Что общего имеют машины? Можно ли что-то исключить из рассмотрения? Случается ли это в консоли? А если&lt;br /&gt;
отключить ''iptables''? Что происходит при закрытии других программ?&lt;br /&gt;
&lt;br /&gt;
===4 Изменяйте лишь одну вещь за раз===&lt;br /&gt;
&lt;br /&gt;
Именно так. Одно изменение, и вновь тестирование. Затем убедитесь,&lt;br /&gt;
что изменения действительно сделаны и что вы тестируете именно ту&lt;br /&gt;
машину (открыто много терминальных окон? Вы уверены, что сейчас&lt;br /&gt;
именно в том, что требуется?), и вновь тестируйте. А вот потом можете&lt;br /&gt;
менять что-то еще. Это тесно связано со сказанным выше о сужении&lt;br /&gt;
поиска. (Я уже говорила вам, чтобы вы делали заметки, верно?)&lt;br /&gt;
&lt;br /&gt;
===5 Загружайтесь в пошаговом режиме===&lt;br /&gt;
&lt;br /&gt;
Если у вас проблемы с загрузкой или со службой, запускаемой автоматически при старте системы, можете загрузиться с ''/bin/sh'' в качестве '''init'''. Это может быть особенно полезно, если проблема – нечто приводящее к хаосу сразу после запуска: например, если вы так изгадили настройки вашего ''iptables'', что заблокировались и каждый раз при&lt;br /&gt;
перезагрузке вновь возвращаетесь в то же состояние. Ну, вы ж понимаете, я-то такого никогда не делала.&lt;br /&gt;
&lt;br /&gt;
В ''Grub'' это достигается нажатием '''Е''' в загрузочном меню и редактированием команд. Выберите строку, начинающуюся с '''kernel''', и нажмите '''Е''' вновь. Добавьте '''init=/bin/sh''' (или '''init=/bin/bash''', если хотите), нажмите''' ENTER''', а затем '''B''' для загрузки системы.&lt;br /&gt;
&lt;br /&gt;
Это перенесет вас в оболочку '''sh''' или '''bash''' на ранней стадии загрузки. Отсюда вы можете или редактировать файлы (если вы уже знаете или предполагаете, в чем ошибка), или запустить систему пошагово для выполнения более глубокой отладки. Как всегда, ведите записи про любые изменения. Если они не приведут к исправлению, вы, вероятно, захотите их отменить.&lt;br /&gt;
&lt;br /&gt;
===6 Ясный отчет об ошибке===&lt;br /&gt;
&lt;br /&gt;
Это более применимо к ситуации, когда вы получаете отчеты от других, но также хорошо дисциплинирует вас самих, и может быть удивительно полезным. Убедитесь, что у вас есть ясный отчет, в чем состоит проблема:&lt;br /&gt;
&lt;br /&gt;
* Какая команда/ситуация вызывает ее?&lt;br /&gt;
* Каков ожидаемый результат?&lt;br /&gt;
* Каков реальный результат?&lt;br /&gt;
* Случается ли это, если вы используете разные машины? (особенно полезная информация в ситуациях, когда некоторые каталоги расположены в ''NFS'', а пользователи централизованы)&lt;br /&gt;
* Проявляется ли это для разных пользователей?&lt;br /&gt;
* Что вы проделали для исправления ситуации?&lt;br /&gt;
&lt;br /&gt;
Это похоже на «протокол плюшевого мишки». Суть его в том, что вы должны попытаться объяснить вашу проблему плюшевому мишке.&lt;br /&gt;
Вам следует использовать короткие слова и быть точным, потому что плюшевый мишка – не технарь. Если вы когда-либо проделаете это, то поймете, что данный шаг поможет вам найти половину решения. Я не занимаюсь плюшевыми мишками, но часто обнаруживала, что описание проблемы во всех деталях, ради задания вопроса в списке рассылки, подсказало мне новые идеи.&lt;br /&gt;
&lt;br /&gt;
Надеюсь, все эти советы и уловки дадут вам несколько полезных ориентиров (или замусорят память) для следующего раза, когда что-то&lt;br /&gt;
случится. Один совет напоследок: если сомневаетесь, встаньте, пройдитесь и займитесь чем-то другим. Выпейте чашку чая, или, может&lt;br /&gt;
быть, съешьте пирожное. Обойдите вокруг здания. Дайте мозгу отдохнуть. Иногда бывает достаточно прекратить ломать голову над проблемой на 30 минут, чтобы появился свет в конце тоннеля. И даже если нет, вы насладитесь прекрасной чашкой чая с пирожным, а это всегда приятно. '''LXF'''&lt;br /&gt;
&lt;br /&gt;
===Проблем лучше избегать===&lt;br /&gt;
&lt;br /&gt;
Хорошее начало – это хороший распорядок&lt;br /&gt;
тестирования. Тестируйте в начале, в конце и&lt;br /&gt;
в середине, перед тем, как что-то делать, а не&lt;br /&gt;
после. Храните заметки – они полезны при&lt;br /&gt;
любых изменениях, не только при устранении проблем. Как комментарии в коде, вам&lt;br /&gt;
постоянно следует создавать заметки так,&lt;br /&gt;
словно вы пишете для кого-то другого – потому что спустя шесть месяцев вы будете&lt;br /&gt;
уже другим!&lt;br /&gt;
&lt;br /&gt;
Еще лучше хранить ваши файлы настроек в чем-то вроде системы контроля версий.&lt;br /&gt;
''Subversion'' подойдет. Если у вас более одной&lt;br /&gt;
машины со схожими настройками, избегайте&lt;br /&gt;
повторения проблем, используя ''Puppet'' или&lt;br /&gt;
схожую централизованную систему управления настройками – а затем также сохраните&lt;br /&gt;
их в ''Subversion'', и не забывайте каждый раз&lt;br /&gt;
использовать ее. Да, это нудно, но не так, как&lt;br /&gt;
проводить часы, выискивая неуловимое&lt;br /&gt;
изменение в одной строке, сделанное вами&lt;br /&gt;
недели назад и вызвавшее теперь ошибку&lt;br /&gt;
из-за обновления чего-то другого...&lt;br /&gt;
&lt;br /&gt;
А если у вас много машин и все они идентичны, и вы действительно не можете понять,&lt;br /&gt;
что же произошло с одной из них – то у вас&lt;br /&gt;
есть возможность полной переустановки.&lt;br /&gt;
Погоня за ошибками может вылиться в большую потерю времени, так что иногда кардинальные меры – это лучший выбор.&lt;/div&gt;</summary>
		<author><name>Crazy Rebel</name></author>	</entry>

	</feed>