Заброшенная заинтересованная сторона a.k.a Системный администратор - PullRequest
8 голосов
/ 21 ноября 2008

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

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

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

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

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

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

Ответы [ 9 ]

9 голосов
/ 21 ноября 2008

Различные вещи, включая (но вряд ли ограниченные), которые не находятся в приоритетном порядке:

  • Нет необходимости использовать привилегированную установку
  • Возможность использовать привилегированную установку
  • Опция для распределенной установки (чтобы ее можно было установить на сервере и использовать на других машинах)
  • Чистая удаление
  • Разумные шаблоны обновления
  • Возможность выбора места установки
  • Минимальные зависимости от другого программного обеспечения
  • Минимальное рассеяние данных по системе (не выводите данные в / etc, / usr / lib, / var / adm, ...)
  • Нет постоянно растущих бревен
  • Тихая установка
  • Установка по сценарию
  • Электронная документация (как на компьютере, так и в Интернете)
  • Страницы справочника возможно
  • Простота настройки
  • Легко сделать доступным для конечных пользователей
  • Без угроз безопасности
  • Нет специальных пользователей или групп (или ограниченное количество - не более одного специального пользователя, одна специальная группа является целевой, хотя и не всегда достижимой)
  • Либо нет функции «телефон дома», либо только если явно настроено (не должно быть по умолчанию)
  • Хорошая регистрация диагностики, когда есть проблема
  • Хорошая техническая поддержка доступна, если есть проблема
  • Нет необходимости получать код активации во время установки
  • Нет необходимости перезагрузить компьютер после установки
  • Возможность параллельного запуска старых и новых версий

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

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

4 голосов
/ 24 ноября 2008

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

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

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

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

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

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

2 голосов
/ 21 ноября 2008

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

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

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

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

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

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

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

2 голосов
/ 21 ноября 2008

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

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

Простое обслуживание упаковки!

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

1 голос
/ 22 ноября 2008

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

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

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

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

1 голос
/ 21 ноября 2008

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

1 голос
/ 21 ноября 2008

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

...