Я видел этот комментарий:
«Был там, сделал это. После этого мы назвали команду killall на Solaris-box псевдонимом killall = 'echo ORLLY?' =) - Командир Кин 28 мая в 12:03 "
В ответ на Ответ.
Это заставило меня задуматься, что делают системные администраторы, чтобы предотвратить глупые ошибки, будь то для себя или других?
В предыдущей организации, где каждый изменение должно было пройти через управление изменениями (даже добавление хоста в / etc / hosts), мы сделали инструкции копирования / вставки для всех записей изменений. Если требовались дополнительные команды / процедуры, которых не было в записи, открывался новый тикет.
Удивлен, что никто не добавил ... иди домой, когда устанешь! Мозг не работает наилучшим образом, когда вы 10 или 12 часов в день идете домой, берете пиво, отдыхаете и с утра рветесь!
Я также считаю, что "экспертная оценка" полезна ... "эй, Боб, я просто собираюсь потихоньку трястись - ты видишь что-нибудь с этим?" просто произнеся это вслух, можно закрепить в уме то, что вы делаете.
А теперь вернемся к «техническим решениям для одинокого уставшего мозга»;)
Я ничего не делаю, чтобы предотвратить их, а скорее планирую, исходя из ожиданий, что обязательно сделаю ужасные.
Я категорически против защитных псевдонимов вроде rm = "rm -i".
Как только вы переучите свой мозг, чтобы ожидать, что rm будет безопасным, вы станете очень опасным на любой машине без этой защиты. Я бы предпочел научить свои пальцы набирать «rm -i» или просто использовать mv вместо rm, так как это вряд ли доставит мне неприятности в новой среде.
Я беру изречение своих друзей-плотников ...
Отмерьте дважды, отрежьте один раз.
Прежде чем делать то, что может привести к тому, что я окажусь в очереди по безработице ...
Подумай дважды, беги один раз.
Просто не делайте ошибки, которая явно была отмечена или объяснена в документации ... это хороший совет: ПРОЧИТАЙТЕ ДОКУМЕНТАЦИЮ В первую очередь
Контрольные списки и сценарии
Для каждой сложной задачи есть чек-лист или сценарий, который спасет вашу задницу.
Если этого достаточно для хирургов и пилотов авиакомпаний, то и для нас.
Автоматизируйте все, что можете. Всякий раз, когда вы полагаетесь на то, что делаете что-то вручную, вы допускаете возможность ошибок.
Используйте различные техники, чтобы писать надежные сценарии оболочки.
При подготовке пакетного задания (для цикла, кластерыш job и т. д.), добавьте команды, которые работают с echo чтобы убедиться, что они выглядят вменяемыми.
Многие команды имеют параметр, который просто показывает вывод, как если бы команда была запущена, но на самом деле этого не делает. (Например, rsync --dry-run) Найдите их и используйте их.
Среди прочего, они могут оказаться ценными:
alias rm='rm -i'
alias cp='cp -i'
alias mv='mv -i'
alias mysql='mysql --safe-updates' (or add to your .my.cnf)
set -o noclobber
Кроме того, если вы часто просматриваете свою базу данных, но не часто вносите много изменений, создайте отдельного пользователя, который только имеет привилегии SELECT для таблиц.
Когда это действительно важно, я сажусь за неделю до этого и записываю все на странице Wiki. Цель состоит в том, чтобы вырезать и вставить все действие без единого редактирования в реальном времени. По сути, напишите сценарий, но с человеком, который может прервать и перезапустить любое действие.
На следующий день читаю и исправляю.
На следующий день перечитал и исправил.
На следующий день перечитал и исправил.
За 2-3 дня до реального исполнения я один раз запускаю его на машине, которую могу испортить. Поцарапайте это, машина, которую я воля испортить. Потом исправляю на вики-странице.
На следующий день перечитал и исправил.
В дату фактического исполнения я запускаю его в первой производственной системе. Потом исправляю вики-страницу.
Вторая производственная система обычно работает без проблем.
Пример использования: переход со старой SAN на новую без простоев. Включая «горячие» миграции кабелей Fibre Channel.
Это отстой. Но какая спешка, когда я это сделал!
Мы по-разному раскрасили подсказки bash в системах dev / stage / production. "Вот дерьмо, я был на производстве?!?!?!"
Я думаю, что сложно защитить себя от самого себя ... если бы я знал, что делаю это неправильно, я бы этого не сделал. Тем не менее, я пытаюсь запомнить пару мыслей:
Я внимательно отношусь к тому, что делаю, прежде чем что-либо делать. Написание сценария, который удаляет все файлы в текущем рабочем каталоге, например, может работать в моем тесте, но позже сделает что-то плохое.
Если вы не знаете, что делаете, нанять кого-нибудь для этого вместо того, чтобы пытаться понять это самостоятельно.
У нас есть политика, позволяющая редактировать конфигурацию системы только с помощью сценария, который сначала создает резервную копию файла конфигурации, а затем позволяет вам редактировать его. По сути, это оболочка для vi, но она выполняет свою работу довольно хорошо: очень легко откатить даже самые сложные изменения.
Не работайте над деликатными вещами, когда чувствуете усталость!
Поскольку я слишком новичок, чтобы комментировать [Что вы делаете, чтобы не допустить глупых ошибок?, Я должен опубликовать другой ответ.
Вот как я раскрасил различные командные строки: $ cat ~ / .bashrc
export FGGRAY=37
export BGRED=41
export BGYELLOW=43
export BGGREEN=42
export HIGHLIGHT=01
export NORMAL=00
export PS1="[\u@\[\e[${FGGRAY};${BGRED};${HIGHLIGHT}m\]\h\[\e[${NORMAL}m\] \W]\\$ "
$ cat ~ / .cshrc
setenv FGGRAY 37
setenv BGRED 41
setenv BGYELLOW 43
setenv BGGREEN 42
setenv HIGHLIGHT 01
setenv NORMAL 00
setenv ESC "^["
set prompt = "[%n@%{${ESC}[${FGGRAY};${BGRED};${HIGHLIGHT}m%}%m%{${ESC}[${NORMAL}m%} %~]%# "
Мне потребовалось на удивление много времени, чтобы заставить эти подсказки работать и в некоторой степени читаться. Присвоение цветов упростило переход системы от производственной к промежуточной и обратно (поскольку наша промежуточная машина стала «производственной» во время циклов бета-тестирования, что было частью проблемы).
Проницательный читатель заметит, что я использую escape-последовательности ANSI, которые работают не везде. Они нормально работали с RedHat, но я не тестировал другие ОС.
[1]: Ответ Трея о цветных подсказках выше
Документируйте все, что вы делаете, вы можете использовать это позже как сценарий, когда вам нужно будет повторить задачу. Рецензирование. Дважды проверьте и используйте сценический компьютер, чтобы проверить то, что вы хотите сделать / изменить. Автоматизируйте и сохраняйте все связанные настройки в какой-либо системе контроля версий.
Самое главное «не бойтесь ошибаться - вы их сделаете». Чаще всего это облегчит вам работу. Ошибки будут происходить, просто будьте готовы к тому, чтобы правильно исправить ошибки.
Я не встаю с постели.
В противном случае я прочитал дважды и щелкнул один раз.
Несколько советов для Linux-машин:
alias rm="rm -i"
alias mv="mv -i"
Полагаю, это действительно зависит от вашего бизнеса. В моем предыдущем посте в качестве младшего системного администратора Linux все, что шло не так, было ОЧЕНЬ плохо. У нас были клиенты, которые зависели от вещей, программисты, которые плохо справлялись с защитой / сохранением своего кода, и люди из других отделов, которые возились с вещами, к которым они не имели права прикасаться.
В моем нынешнем положении ошибки не так уж и плохи. На днях мой босс случайно rm -rf * создал неправильный каталог. было больно переписывать скрипты? вы делаете ставку. мы потеряли много денег? Нет.
Все, что я могу сказать, это следовать предыдущей мантре: подумай дважды, сделай один раз. И, поскольку все мы знаем, что это не всегда срабатывает, разработайте план восстановления. Лично я фанат каталога Rsync'd, который сохраняет все важные файлы каждую ночь, но это потому, что мне это подходит. другим людям могут потребоваться решения для резервного копирования, которые используются гораздо чаще.
автоматическое управление версиями наиболее важных файлов конфигурации и сценариев входа в систему, поэтому все остается отслеживаемым.
Безусловно, наиболее распространенной практикой в этом направлении является установка alias rm="rm -i" и alias mv="mv -i".
Помимо всего перечисленного, я использую Zsh как моя оболочка.
/var/lib/mysql% rm ib_ * zsh: sure you want to delete all the files in /var/lib/mysql [yn]? n
Некоторые разумные и опасные задания выполняются в парах, а не в одиночку. Экран GNU используется, когда это возможно, поэтому один и тот же терминал используется двумя администраторами, работающими вместе.
Например, однажды у меня вышел из строя RAID-диск, когда я находился на расстоянии 300+ км от сервера, и местный администратор не был слишком защищен от процедуры. Он правильно определил и заменил неисправный диск, но боялся иметь дело с чудовищем, которым является интерфейс управления командной строки RAID (называемый afacli). Для него это была сложная ситуация: массив был поврежден, а это означало, что в случае отказа другого диска последовала бы серьезная потеря данных.
Итак, мы присоединились к сеансу с общим экраном, и я наблюдал, как он вводил команды для установки нового диска в качестве запасного, а затем смотрел, как RAID восстанавливается на новом диске.