Забытый заинтересованный сторонник a.k.a Системный администратор

Question

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

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

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

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

Что бы системный администратор пожелал нам разработчиков при разработке систем, которые им нужно будет поддерживать?

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

Answer 1

различные вещи, в том числе (но вряд ли может быть ограничено) эти, которые не в порядке приоритета:

• Нет требование использовать привилегированный установить
• вариант использовать привилегированный установить
• вариант для распределенная установка (поэтому его можно установить на сервер и использовать на других машинах)
• Очистить удаление
• Разумные модели модернизации
• Возможность выбрать место установки
• Минимальные зависимости от другого программного обеспечения
• Минимальный разброс данных по всей системе (не сбрасывать вещи в/и т.д.,/USR/Lib,/вар/адм ...)
• нет постоянно не растут журналы
• Тихая установка
• Scripted установить
• онлайн документацию (на машине - а также в Интернете)
• Man страницы возможно
• Легко настроить
• легко сделать доступными для конечных пользователей
• Нет безопасности не рискует
• Нет особых пользователей или групп (или ограниченное количество - не более одного специального пользователя, одна специальная группа является целью, хотя и не всегда достижима)
не
• либо нет функциональности «домашнего телефона» или только если явно настроено (не должен быть по умолчанию)
• Хорошо ведения журнала диагностики, когда существует проблема
• Хорошей технической поддержки доступна, если есть проблема
• Отсутствует требование, чтобы получить код активации во время установки
• Нет требование перезагрузить компьютер после установки
• Возможность параллельных запускать старые и новые версии

Многое зависит от того, что программное обеспечение и как он используется , Требования к графической программе, работающей в Windows, Linux и MacOS X, радикально отличаются от требований к сетевому демона, но цель должна быть стабильной, надежной и легко управляемой программой.

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

Answer 2

Что система работает, так что он может вернуться домой к детям.

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

Я думаю, что комбинация из следующих действий:

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

2) Устранение неполадок в стиле поваренной книги -> Если что-то пойдет не так, как легко можно классифицировать его по коду, данным или сетевой ошибке.

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

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

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

Это были бы главные, которые приходят мне на ум.

Answer 7

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

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

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

Answer 8

Простота обслуживания!

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

Answer 9

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

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

Developer: Я никогда не слышал, чтобы кто , имеющего такой проблемы говорить с почтовый сервер. Должна быть проблема с брандмауэром .

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

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

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