Существуют ли известные анти-паттерны в области системного администрирования? [закрыто]

Я знаю несколько общих закономерностей, которые, похоже, сбивают с толку почти каждый проект в определенный момент его жизненного цикла:

1. Невозможность отключения
2. Сторонние компоненты блокируют обновления
3. Неоднородные среды
4. Отсутствие мониторинга и оповещения
5. Отсутствует избыточность
6. Недостаток вместимости
7. Плохое управление изменениями
8. Слишком либеральная или жесткая политика доступа
9. Организационные изменения негативно влияют на владение инфраструктурой

Я надеялся, что есть какая-то хорошо сформулированная библиотека этих анти-паттернов, обобщенная в книге или на веб-сайте. Я почти уверен, что многие организации учатся методом испытаний огнем. Если нет, давайте начнем.

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

И наоборот, преждевременная автоматизация. Совершенно не нужно тратить 3N часа на автоматизацию одноразового задания, которое занимает N часов вручную (даже если автоматизировать это гораздо интереснее, чем разбираться с вещами вручную).

A. не тестирует восстановление - резервная копия может быть проверена и хорошо, но как восстановить?

Сколько времени это займет, что нужно? Вы должны знать, чтобы сделать это в стрессовой ситуации ...

B. нет управления конфигурацией, нет единообразия - просто изменение здесь и там, и я думаю, что я настроил некоторые здесь ...

Кто знает, как реплицировать хорошо сделанный сервер, если все причуды не записаны и в магазине нет идентичных конфигураций? Что если вам удастся восстановить данные, но не конфигурацию, приложения?

C. нет мониторинга - понятия не имею, как и что делают ящики

Это двояко: а) вам необходимо отслеживать срабатывание сигналов тревоги во времени, прежде чем вы исчерпаете какой-либо ресурс или странное поведение, и б) вы должны отслеживать долгосрочные тенденции для управления емкостью (диск, процессор, оперативная память, сеть,. ..).

D. нет избыточности в вашем CFG - что происходит, когда XX умрет

Это значит заранее планировать, что вы хотите от своего системного администратора.

Для меня это самое главное.

Самый убивающий шаблон - когда системный администратор (или весь ИТ-отдел) становится пассивным участником компании. То есть они рассматриваются как самообслуживание, где каждый приходит с уже сформированными идеями о том, как следует действовать, принимая во внимание исключительно потребности пользователей, а не потребности всей ИТ-экосистемы в целом.

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

1) чрезмерно многообещающие и недооцениваемые (т.е. поддержание реалистичных ожиданий пользователя)

2) Не проверять резервные копии, пока они не понадобятся.

редактировать: я намеревался номер 2, чтобы включить восстановление файлов / данных

Не отслеживать шаблоны использования учетной записи AD, такие как время последнего входа в систему> 30 дней

(Мы должны сделать это по причинам аудита, но результаты довольно шокирующие)

• Хранение ключевой информации в папке head / inbox / documents одного человека. Если это важно, например, контактные данные поставщика, лицензионные ключи, инструкции по настройке, они должны быть доступны каждому в отделе, который имеет полномочия и может нуждаться в доступе к нему, и в стандартном месте.

• Просить человека, который знает о чем-то, чтобы задокументировать это. Это звучит хорошо, потому что это человек, который обладает знаниями, но на самом деле это плохо, потому что они не могут легко сказать, что такое важное знание. Лучше попросить кого-нибудь поработать над этим, спросив у знающего человека любую информацию, которая ему нужна, и попросив документировать, как они это делают.

• Непонятная документация. Любой может решить проблему со средним приоритетом в течение дня, когда весь ИТ-отдел будет доступен для общения. Другое дело - решить проблему с высоким приоритетом поздно вечером, когда вы почти одни и не знаете, почему система настроена так, как она есть, или почему она не соответствует тому, что говорится в документации.

• Не отслеживает пароли хорошо. Таким образом, вам быстро нужна учетная запись, создайте ее со случайным паролем, а через 18 месяцев она все еще используется, и никто не знает пароль или какие службы сломаются, если он будет изменен.

• Не покупать поддержку поставщиков для ключевых систем, потому что это «слишком дорого».

• Неуместные приоритеты. ИТ-специалисты должны руководствоваться руководством - должно быть согласовано, какие проекты являются приоритетными, или в чрезвычайной ситуации, какие системы требуются в первую очередь. Если ИТ-отдел пытается исправить бизнес-систему, руководство требует электронной почты, а пользователи требуют обработки заказов, что является причиной беспорядка.

• Неуместные решения - для ИТ-специалистов очень легко застрять в умонастроении: «чтобы исправить это, ИТ-система должна работать так, как это было раньше», когда может быть более уместно заключить соглашение об управлении и ИТ, чтобы «попробовать 2 часов, если это не исправлено, тогда остановитесь, даже если это выглядит многообещающе, и переходите к восстановлению из резервной копии. "

• Копии тестовых файлов везде. Вы не хотите открывать папку, в которой запущена бизнес-система или веб-сайт, и видеть "сайт-новый /, сайт-текущий /, сайт-копия /, сайт-тестирование /, сайт-тест-дэйв /, сайт-использование- this-one /, website-from-feb / и т. д.) Dev, производство и тестирование должны существовать и должны быть отделены от каждого вовлеченного отдела (IT, dev, управление проектами и т. д.), зная, что должно быть, и согласовать, как изменения одобрены. Также для конфигурационных файлов.

• Измените одобрение - даже если у вас сначала просто устная дискуссия, не меняйте способ работы важных вещей, пока никто не узнает. Вам решать, что «важно» покрывает вашу ситуацию.

• Обоснованные решения остаются на месте на длительный срок. Я знаю, что вы быстро подключили этот сервер к этой сети с помощью старого телефонного провода, чтобы вы могли решить насущную проблему. Я знаю, что у вас нет времени, чтобы переделать это правильно. Сделай время.

• Плохие отношения с остальной частью компании. ИТ - это услуга, которая помогает остальной части компании выполнять свою работу. Если им нужны огромные файлы быстро, сделайте это. Если вам нужно разрешение менеджера, чтобы купить оборудование, получите его. Если вы не можете его получить, четко сообщите, что огромные файлы не могут двигаться быстро, потому что руководство расставило приоритеты для некоторых других расходов. Если вам нужно архивировать по юридическим причинам, но у вас нет бюджета, вам нужно как можно лучше приспособить архивирование к вашей системе.