Я знаю несколько общих закономерностей, которые, кажется, сбивают с толку почти каждый проект на определенном этапе его жизненного цикла:
Я надеялся, что существует некоторая хорошо сформулированная библиотека этих антипаттернов, обобщенная в книге или на веб-сайте. Я почти уверен, что многие организации учатся методом испытаний огнем. Если нет, давайте начнем.
Оставление автоматизируемых задач для автоматизации до тех пор, пока их выполнение вручную не займет достаточно времени, чтобы их нельзя было автоматизировать, потому что выполнение задач вручную все время съедает.
Наоборот, преждевременная автоматизация. Абсолютно нет необходимости тратить 3N часов на автоматизацию однократной задачи, выполнение которой вручную занимает N часов (даже если автоматизировать это увлекательнее, чем копаться вручную).
A. восстановление не тестируемое - резервную копию можно проверить и нормально, а как восстановить?
Как долго, что нужно? Вы должны знать, что делать это в стрессовой ситуации ...
Б. Никакого управления конфигурацией, никакого единообразия - просто изменения здесь и там, и я думаю, что настроил кое-что здесь ...
Кто знает, как реплицировать хорошо сделанный сервер, если не прописаны все причуды и в магазине нет одинаковых конфигураций? Что, если вам удастся восстановить данные, но не конфигурацию, приложения?
C. без мониторинга - понятия не имею, как и что делают коробки
Это двоякое: а) вы должны следить за тем, чтобы сигналы тревоги реагировали вовремя, прежде чем у вас закончатся какие-либо ресурсы или странное поведение, и б) вы должны отслеживать долгосрочную тенденцию для управления емкостью (диск, ЦП, ОЗУ, сеть,. ..).
D. Отсутствие избыточности в вашем cfg - что происходит, когда XX умирает
Это означает заранее планировать то, что вы хотите от своего системного администратора.
Для меня это самое главное.
Наиболее опасный паттерн - это когда отдел системного администрирования (или вся ИТ) становится пассивным участником компании. То есть они рассматриваются как самообслуживание, когда каждый приходит с уже сформированными представлениями о том, как все должно быть сделано, что учитывает исключительно потребности пользователей, а не потребности всей ИТ-экосистемы в целом.
Второй наиболее опасный паттерн - это когда отдел системного администрирования превращается в кучу кнопок, то есть все программное обеспечение / инструменты покупаются или разрабатываются и устанавливаются третьими сторонами, а системный администратор получает официальное обучение и руководство, а затем следует только руководствам по эксплуатации и передать поставщику все, что явно не указано в руководстве. Эта ситуация может быть очень удобной для (некоторых, если не для большинства) системных администраторов, но это катастрофа, ожидающая своего часа, когда тот факт, что никто не знает, как на самом деле работает вся система, приведет ее к полному завершению (подумайте о тонком взаимодействии между компонентами и игра виноватых между продавцами).
1) чрезмерно многообещающие и недостаточные (т.е. реалистичные ожидания пользователей)
2) Не проверять резервные копии, пока они не понадобятся.
изменить: я намеревался номер 2 включать восстановление файлов / данных
Отсутствие мониторинга шаблонов использования учетной записи AD, например, время последнего входа в систему> 30 дней
(Мы должны сделать это по причинам аудита, но результаты довольно шокирующие)
Хранение ключевой информации в папке головы / входящих / документов одного человека. Если это важно, например, контактные данные поставщика, лицензионные ключи, инструкции по установке, оно должно быть доступно всем сотрудникам отдела, имеющим полномочия и, возможно, нуждающимся в доступе, и в стандартном месте.
Просить человека, который что-то знает, задокументировать. Это звучит хорошо, потому что у них есть знания, но на самом деле это плохо, потому что они не могут легко определить, что это за знания. Лучше попросить кого-то нового заняться этим, спросив у знающего человека любую информацию, которая ему нужна, и попросить его документировать, как они это делают.
Непонятная документация. Любой может решить проблему средней важности в течение дня, при этом весь ИТ-отдел будет готов поговорить с ним. Другое дело - решить высокоприоритетную проблему поздно ночью, когда вы почти один и не знаете, почему система настроена так, как она есть, или почему она не соответствует тому, что написано в документации.
Плохое отслеживание паролей. Таким образом, вам быстро понадобится учетная запись, создайте ее со случайным паролем, а затем 18 месяцев спустя она все еще используется, и никто не знает пароль или какие службы сломаются, если он будет изменен.
Не покупать поддержку поставщиков для ключевых систем, потому что это «слишком дорого».
Неуместные приоритеты. ИТ-специалисты должны руководствоваться руководством - необходимо согласовать, какие проекты являются приоритетными, или в чрезвычайной ситуации, какие системы потребуются в первую очередь. Если ИТ-специалисты пытаются исправить бизнес-систему, руководство требует электронной почты, а пользователи требуют обработки заказов, это рецепт беспорядка.
Неподходящие решения - ИТ-специалистам очень легко застрять в мышлении «чтобы исправить это, ИТ-система должна работать так, как это было раньше», тогда как может быть более подходящим заключить соглашение между руководством и ИТ-специалистами, чтобы «попытаться за два». часов, если проблема не устранена, остановитесь, даже если она выглядит многообещающей, и перейдите к восстановлению из резервной копии ».
Везде копии тестовых файлов. Вы же не хотите открывать папку, в которой работает бизнес-система или веб-сайт, и видеть «новый веб-сайт /, текущий веб-сайт /, копия веб-сайта /, веб-тестирование /, веб-сайт-тест-дэйв /, веб-сайт-использование- this-one /, website-from-feb / и т. д.). Разработка, продакшн и тестирование должны существовать и должны быть разделены, при этом каждый вовлеченный отдел (ИТ, разработка, управление проектами и т. д.) знает, что и где должно быть, и согласовывает, как изменения одобрены. Также для файлов конфигурации.
Измените одобрение - даже если вы сначала просто поговорите, не меняйте способ работы важных вещей без ведома других. Вам решать, что «важное» покрывает вашу ситуацию.
Бодрые решения остаются в силе на долгий срок. Я знаю, что вы быстро подключили этот сервер к этой сети со старым телефонным проводом, чтобы вы могли решить неотложную проблему. Я знаю, что у тебя нет времени переделывать это как следует. Найдите время.
Плохие отношения с остальной частью компании. ИТ - это услуга, которая помогает остальной части компании выполнять свою работу. Если им нужны большие файлы быстро, сделайте это. Если вам требуется одобрение руководства для покупки оборудования, получите его. Если вы не можете этого понять, четко сообщите, что огромные файлы не могут перемещаться быстро, потому что руководство поставило в приоритет некоторые другие расходы. Если вам нужно архивирование по юридическим причинам, но у вас нет бюджета, вам нужно как можно лучше вписать архивирование в свою систему.