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

Эта система работает так, что он может пойти домой к детям.

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

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

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

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

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

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

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

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

Думаю, сочетание следующего:

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

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

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

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

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

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

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

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

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

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

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

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

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

Developer: I've never heard of anyone having that kind of trouble talking to the mail server. It has to be a firewall issue.

Me: I'm logged into the firewall, running a packet sniffer, and watching your app's traffic pass through without any problems. It's getting through the firewall just fine.

Developer: No, no - it has to be a firewall issue.

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