Вопрос: Что вы делаете, чтобы предотвратить глупые ошибки?


Я видел этот комментарий:

«Были там, сделали это. Мы смирились с   killall-команда на солнечных батареях   после этого: alias killall = 'echo   ORLLY? =) - Командир Кин 28 мая в   12:03"

В ответ на ответ,

Это заставило меня задуматься, что делают системные администраторы, чтобы предотвратить глупые ошибки, как для себя, так и для других?

В предыдущей организации, где каждый изменение должно было пройти через управление изменениями (даже добавив хост к / etc / hosts), мы скопировали / вставили инструкции для всех записей изменений. Если для этого потребовались дополнительные команды / процедуры, которые не были записаны, был открыт новый билет.


4
2018-06-05 19:54


Источник


Возможно, это должно быть сообщество wiki ... - tomjedrz
действительно, и так оно и есть. - jtimberman


Ответы:


Удивленный никто не добавил ... Иди домой, когда ты устал! Мозг не делает свою лучшую работу, когда вам нужно 10 или 12 часов в день, идите домой, возьмите пиво, заткнитесь и ударитесь по земле, работая утром!

Я также считаю, что «экспертная оценка» полезна ... «Эй, боб, я просто собираюсь схватить францию ​​- вы видите что-нибудь с этим?» просто сказать это вслух может укрепить то, что вы делаете в своем уме.

Теперь мы возвращаем вас к «техническим решениям для одиночного, уставшего мозга»;)


9
2018-06-05 19:18



Я согласен с тем, что не делаю что-то критическое, когда ты устал ... лучше сделай это на следующий день. - Hapkido
У нас есть политика в нашем офисе, что после 3 вечера никаких серьезных изменений не произойдет, потому что мы все начинаем смотреть в будущее и начинаем делать ошибки. - Mark Henderson♦
Мне это нравится - официальная политика «3 вечера» - мы можем добавить, что «никогда не делать большие изменения в пятницу» (поскольку это стоит больше, чтобы исправить ошибки в субботу!) - Tom Newton


Я не делаю ничего, чтобы предотвратить их, а скорее планирую вокруг ожидания, что я обязательно сделаю ужасные.


8
2018-06-05 19:03





Просто не делайте ошибку, которая была явно отмечена или объяснена в документации ... что является хорошим советом: ПРОЧИТАЙТЕ ДОКУМЕНТАЦИЮ ПЕРВЫЙ


5
2018-06-05 19:31



Аминь! Прочтите и убедитесь, что нет слов или фраз, которые вы не понимаете. Это всегда может вас отбросить. - Hondalex
И прочитайте все сообщения журнала, до конца, когда вы видите ошибку. - jtimberman


Я беру максимум от моего плотника freinds ...

Мера дважды вырезать один раз.

Прежде чем делать то, что может привести к тому, что я буду стоять в очереди на безработицу ...

Подумайте, дважды запускайте один раз.


5
2018-06-05 21:13



Обзор коллегией хорош для этого! Добавление комментария, поэтому я помню +1, когда возвращаю голоса. - jtimberman
Независимо от того, сколько раз я вырезал эту доску, она все еще слишком короткая. Кажется, что независимо от того, сколько раз я перезагружаю этот компьютер, он не запустится. - SpaceManSpiff


Я категорически против защитных псевдонимов, таких как rm = "rm -i".

Как только вы переучиваете свой мозг, чтобы ожидать, что rm будет в безопасности, вы становитесь очень опасным на любой машине без этих защит. Я бы скорее тренировал пальцы, чтобы набрать «rm -i» или просто использовать mv вместо rm, так как это вряд ли вызовет у меня проблемы в новой среде.


5
2018-06-05 19:25



Итак, что вы делаете для предотвращения глупых ошибок или других админов? - jtimberman
Получайте привычку не нажимать быстро, когда делаете деструктивные команды. - Matt Simmons


Среди прочего, это может оказаться ценным:

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 для таблиц.


4
2018-06-05 19:56



комментируя, поэтому я помню +1, когда завтра получаю голоса. - jtimberman


У многих команд есть опция, которая только показывает вывод, как если бы команда выполнялась, но на самом деле это не делает. (Например, rsync -dry-run) Ищите их и используйте их.


4
2018-06-05 20:05





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

Используйте различные методы для писать надежные сценарии оболочки,

При подготовке пакетного задания (для цикла, ClusterSSH работа и т. д.), добавьте команды, которые echo чтобы они выглядели здоровыми.


4
2018-06-05 20:48





Контрольные списки и сценарии

Для каждой сложной задачи есть контрольный список или скрипт, который сохранит ваш прикладом.

Если это достаточно хорошо для хирургов и пилотов авиакомпаний, это достаточно хорошо для нас.


4
2018-06-08 21:27





Когда это действительно имеет значение, я сажусь за неделю до этого и пишу все это на странице Wiki. Цель состоит в том, чтобы вырезать и вставить все действие без одного живого редактирования. В принципе, напишите сценарий, но с человеком, способным прервать и перезапустить любое действие.

На следующий день я прочитал его и исправлю.

На следующий день я снова прочитал его и исправлю.

На следующий день я снова прочитал его и исправлю.

За 2-3 дня до реального исполнения я запускаю его один раз на машине, которую я могу испортить. Поцарапайте, что машина, которую я будем испортить. Затем я исправлю это wiki-страницу.

На следующий день я снова прочитал его и исправлю.

В фактическую дату исполнения я запускаю ее на первой производственной системе. Затем я фиксирую страницу wiki.

Вторая производственная система обычно работает без проблем.

Пример использования: переход из старой SAN в новую SAN без простоя. Включая «горячие» кабельные миграции Fibre Channel.

Он сосал. Но какой спешка, когда я его снял!


3
2018-06-05 19:05





Если вы не знаете, что делаете, нанять кого-то другого, чтобы сделать это вместо того, чтобы пытаться понять это самостоятельно.


2
2018-06-05 19:22



Пожалуйста! Если бы я это сделал, я бы просто сидел за своим столом, читая ServerFault весь день! - Matt Simmons