Заброшенная заинтересованная сторона иначе системный администратор

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

Военная история: Назад приблизительно 6 лет назад, я был sysadminning для небольшой компании-производителя, и они решили купить некоторое программное обеспечение для обработки планирования профилактического сопровождения на их оборудовании. Одна из его функций импортировала запросы обслуживания из электронной почты, но у нас были случайные проблемы с ошибками, говорящими с почтовым сервером во время этого процесса, и я был в конечном счете призван для взгляда на него во время телефонного вызова с разработчиком. Разговор включил несколько повторений

Разработчик: я никогда не слышал ни о ком испытывающем такие затруднения, говорящие с почтовым сервером. Это должна быть проблема брандмауэра.

Я: я зарегистрирован в брандмауэр, выполнив анализатор пакетов, и наблюдая, что трафик Вашего приложения проходит без любых проблем. Это проходит через брандмауэр очень хорошо.

Разработчик: Нет, нет - это должна быть проблема брандмауэра.

(В конце оказалось, что проблема состояла в том, что приложение открыло соединение POP3, считайте всю почту, ожидал пользователя для планирования задач, затем отправил команду POP для удаления почты после того, как все запросы были запланированы. Если пользователь занял больше чем 15 минут, чтобы сделать, планирование, приведенное к таймауту соединение POP и приложение не смогли восстановиться, таким образом, оно умерло вместо этого. И затем пользователь должен был повторить планирование, подразумевая, что оно, вероятно, займет много времени достаточно для таймаута снова...),

Системные администраторы обычно хотят следующее:

• Прозрачность в операцию системы. Так своего рода GUI, который показывает параметры настройки системы и возможно историю системных проблем, а также списки того, что система обработала правильно.
• Ясная контекстно-зависимая эскалация соединяет каналом для проблем. Этим я подразумеваю, что каждый проблемный тип имеет некоторые примечания о фиксации, и человека или команду, с которой можно связаться, если проблема не может быть решена быстро, и эскалация требуется.
• Чтобы быть превентивным, т.е. быть в состоянии сообщить конечным пользователям о системной проблеме перед, конечный пользователь сообщает ему. Так своего рода непосредственное предупреждение для любой системной проблемы, где это выполнимо,
• Не лавинно рассылаться предупреждениями. Таким образом, после того как предупреждение прибыло, больше никаких предупреждений для той же проблемы; просто другое сообщение, когда система является операционной снова.
• Подробный вход с помощью чего-то как журнал событий (в Windows) для более глубокого расследования проблемы.

Я думаю комбинация о следующем:

1) Порог способности->, Какие машины делают это, берет для выполнения этого программного обеспечения и что метрики должны использоваться для определения, когда это число может измениться, например, идущий с 2 до 3 серверов баз данных или идущий с 10 до 15 веб-серверов. Насколько раскормленный аппаратные средства должны быть, и одна часть имеет значение больше, чем другой, например, ЦП имеет значение больше, чем RAM, что относительно конфигурации жесткого диска и пространства?

2) Поиск и устранение неисправностей стиля поваренной книги->, Если что-то идет не так, как надо, как легко может это быть категоризированным в код, данные или сетевую ошибку.

3) Схема сред->, Что делает dev, тест и производственные экземпляры этого программного обеспечения, похожа? Есть ли они и возможно другие среды, работающие прямо сейчас?

4) Обслуживание-> Является там файлами журнала для парсинга в отчеты, еженедельные журналы ошибок для отправки вокруг, или некоторое обслуживание, чтобы сделать с программным обеспечением, например, перезагрузить сервер еженедельно.

5) Безопасность-> Является там учетными записями, которые будут создаваться и управляться и политика безопасности для выделения, кто имеет что уровень полномочий в системе.

Это были бы основные, которые прибывают по моему мнению.

То, что система просто работает так, чтобы он мог пойти домой детям.

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

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

• Значимые параметры командной строки
• Своего рода поддержка сценариев (если соответствующий)
• Любой вид индикатора хода выполнения для длительных операций
• Регистрация ошибок
• Последовательный UI

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

Каждый проект имеет 'Планирование мощностей' наряду со своей архитектурой системы. Системные администраторы должны быть вовлечены в процесс Планирования мощностей, а также в окончательное рассмотрение Архитектуры системы. Это поможет ему, лучшее понимает систему и быть подготовленным к развертыванию и поддержке.

Легкое обслуживание пакета!

Должно быть до полусмерти просто установить и обновить программное обеспечение, и это идет для зависимостей также. Если существует много зависимостей и подзависимостей, и Вы не склонны освоить нюансы методологии управления пакетом каждой Операционной системы, было бы хорошо предложить версию пакета со всеми необходимыми зависимостями, связанными вместе в гиганта tarball. Запустите скрипт, зажмите все это в/usr/local/yourproject и скажите им, где сценарий запуска/завершения работы/перезапуска.