ru.unix

 
 - RU.UNIX ----------------------------------------------------------------------
 From : Eugene Grosbein                      2:5006/1       27 Jul 2005  09:22:07
 To : Eugene B. Berdnikov
 Subject : Re: Уцелеть перед Майкрософт. help.
 -------------------------------------------------------------------------------- 
 

 26 июл 2005, вторник, в 21:08 KRAST, Eugene B. Berdnikov написал(а):
 
  EG>> Системным инструментарием владеть надо, конечно, но вот систему,
  EG>> требующую при поддержке lsof/strace/gdb надо выкидывать сразу,
  EBB>  Дешевле (мне) набрать strace или включить в конфиге debug,
 
 debug включить это нормально, а бинари работающей системы трассировать imo нет.
 
  EBB>  чем заставлять
  EBB>  админа удалённого офиса протоколировать все свои шаги. Потому что
  EBB>  ситуации,
  EBB>  когда надо срочно что-то исправить, а "тот парень" уже свалил домой,
  EBB>  возникают не чаще раза в месяц. Hо писать протоколы-отчёты ему придётся
  EBB>  каждый день, естественно, он потребует какой-то компенсации.
 
 Закоммитить изменения с коротким описанием - невелик труд.
 
  EG>> ибо нефиг - диагностика должна быть, и быть хотя и локаничной,
  EG>> но точной, полной и внятной. И документированной тоже. Hикаких strace
  EG>> при эксплуатации, каждый код возврата внутри система обязана
  EG>> анализировать и обрабатывать.
 
  EBB>  Идеалист, блин. Беру _последний_ реальный случай подмены: Postfix, в
  EBB>  логе
  EBB>  написано "transport not available", очередь стоит, мобильник админа
  EBB>  "временно недоступен". Предлагается жаловаться Венеме на невнятную
  EBB>  диагностику? Или всё-таки лучше включить в конфиге debug?
 
 debug и есть диагностика. А если хочется диагностики не в режиме debug,
 то пинать Венему. 
 
  EG>> Место отладчикам в лучшем случае
  EG>> при отладке системы, когда обнаружатся данные извне утили, не
  EG>> возвращающие
  EG>> статус-кодов при проблемах.
  EBB>  Hатурально, идеалист. Другая абсолютно _реальная_ ситуация: без видимых
  EBB>  причин перестал печатать cups. В логах всё как обычно: задания
  EBB>  принимаются,
  EBB>  кладутся в спул, только на печать не идут. Демон жрёт 99.8% cpu.
  EBB>  Перезапуск не помогает. Ваши предложения? Переустановить cups? :)
 
 Пофиксить в нем багу/заменить другим софтом. И не считать систему
 работоспособной без этого.
 
  EG>> cvs commit в конце рабочего дня в обязательном порядке,
  EG>> за ненадлежащее заполнение лога - пороть. Отчет о коммите
  EG>> мылится, кому надо, включая самого комиттера. В результате
  EG>> ему не придется напрягать память в конце недели/месяца/квартала,
  EG>> чтобы обновить документацию.
  EBB>  Осталось ерунда - прикинуть, во сколько обойдётся обучение всех админов
  EBB>  cvs'у и поддержка этой хрени. 
 
 Любой админ обязан быть способным прочитать и усвоить описание CVS
 на русском языке в переводе Махоткина (если не переврал фамилию).
 Там ничего сложного нет, а все тонкости cvs и не нужны рядовому админу:
 commit/diff/log/annotate.
 
  EBB> Вряд ли оно будет рентабельно всегда и всегда.
 
 Это вложения в будущую нормальную работу при смене персонала.
 
  EBB>>>   2. если что-то сломается - всё равно придётся разбираться на месте,
  EBB>>>      ориентируясь по обстановке.
  EG>> 
  EG>> cvs diff принесет неоценимую помощь, поверь моему опыту.
  EBB>  Я скорее поверю в эффективность подхода В.Hечаева, который в cvs
  EBB>  закатывает
  EBB>  конфиги автоматом.
 
 Или так. Hо в этом случае теряется очень ценная информация - commit logs,
 написанные по горячим следам. Правда, в некоторых случаях они не особо
 и нужны.
 
  EBB> Мне же на практике даже diff|mail по крону достаточно.
 
 Что с чем сравнивать, когда админы не предпринимают ничего для хранения
 истории? Или ты собираешься подобие cvs вручную реализовывать? А занафига?
 
 Eugene
 -- 
 Смерть не разбирается, что сделано и что не сделано. (Артха)
 --- slrn/0.9.8.0 (FreeBSD)
  * Origin: Svyaz Service JSC (2:5006/1@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор