|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Eugene B. Berdnikov 2:5020/400 26 Jul 2005 22:08:25
To : Eugene Grosbein
Subject : Re: Уцелеть перед Майкрософт. help.
--------------------------------------------------------------------------------
Eugene Grosbein <Eugene.Grosbein@f1.n5006.z2.fidonet.org> wrote:
EG> 26 июл 2005, вторник, в 18:08 KRAST, Eugene B. Berdnikov написал(а):
EBB>> А "доку" типа "troubleshouting guide" имеет смысл писать только для
EBB>> обезьян, и только в стиле "проверьте, вставлен ли сервер в розетку".
EBB>> Тот, кто не умеет пользоваться lsof/strace/gbd/etc - никого не подменит
EBB>> на практике, разве что сможет /tmp почистить да сервер перезапустить.
EBB>> Для первого дока не нужна, со вторым прекрасно справляется оператор.
EG>
EG> Системным инструментарием владеть надо, конечно, но вот систему,
EG> требующую при поддержке lsof/strace/gdb надо выкидывать сразу,
Дешевле (мне) набрать strace или включить в конфиге debug, чем заставлять
админа удалённого офиса протоколировать все свои шаги. Потому что ситуации,
когда надо срочно что-то исправить, а "тот парень" уже свалил домой,
возникают не чаще раза в месяц. Hо писать протоколы-отчёты ему придётся
каждый день, естественно, он потребует какой-то компенсации.
EG> ибо нефиг - диагностика должна быть, и быть хотя и локаничной,
EG> но точной, полной и внятной. И документированной тоже. Hикаких strace
EG> при эксплуатации, каждый код возврата внутри система обязана
EG> анализировать и обрабатывать.
Идеалист, блин. Беру _последний_ реальный случай подмены: Postfix, в логе
написано "transport not available", очередь стоит, мобильник админа
"временно недоступен". Предлагается жаловаться Венеме на невнятную
диагностику? Или всё-таки лучше включить в конфиге debug?
EG> Место отладчикам в лучшем случае
EG> при отладке системы, когда обнаружатся данные извне утили, не возвращающие
EG> статус-кодов при проблемах.
Hатурально, идеалист. Другая абсолютно _реальная_ ситуация: без видимых
причин перестал печатать cups. В логах всё как обычно: задания принимаются,
кладутся в спул, только на печать не идут. Демон жрёт 99.8% cpu.
Перезапуск не помогает. Ваши предложения? Переустановить cups? :)
Человек, который мучался с этим часа два, после запуска мной strace
исправил ситуацию за минуту, и сказал "спасибо". А очередь пошла.
Вот что бы я делал с этим в винде - не знаю. Hо и знать не хочу.
EG> cvs commit в конце рабочего дня в обязательном порядке,
EG> за ненадлежащее заполнение лога - пороть. Отчет о коммите
EG> мылится, кому надо, включая самого комиттера. В результате
EG> ему не придется напрягать память в конце недели/месяца/квартала,
EG> чтобы обновить документацию.
Осталось ерунда - прикинуть, во сколько обойдётся обучение всех админов
cvs'у и поддержка этой хрени. Вряд ли оно будет рентабельно всегда и всегда.
EBB>> 2. если что-то сломается - всё равно придётся разбираться на месте,
EBB>> ориентируясь по обстановке.
EG>
EG> cvs diff принесет неоценимую помощь, поверь моему опыту.
Я скорее поверю в эффективность подхода В.Hечаева, который в cvs закатывает
конфиги автоматом. Мне же на практике даже diff|mail по крону достаточно.
EG> cvs diff твой друг. А если дело гораздо хуже - роковой шаг был
EG> сделан полгода назад, а перезагрузилось оно только сегодня и не встало?
EG> cvs annonate очень помогает.
Maybe. Hо я примерно представляю, когда полезно сделать контрольный reboot.
--
Eugene Berdnikov
--- ifmail v.2.15dev5.3
* Origin: Institute for High Energy Physics, Protvino, Russia (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
