Назад | Перейти на главную страницу

Как следует разрабатывать приложения для легкого развертывания?

Я работаю в компании, которая поставляет распределенные системы управления для различных отраслей. Мы обнаружили, что навыки ИТ-администратора в значительной степени различаются как по навыкам, так и по интересам. У нас есть все: от команды профессиональных ИТ-администраторов на нефтедобывающем предприятии до корабельного повара, работающего неполный рабочий день.

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

Мы изучаем виртуальные машины и централизованное управление сайтом для удаленной установки, изменение конфигурации (информация о сайте, параметры настройки и т. Д.), Версию управляющего программного обеспечения (двоичные файлы), наблюдение за системой (журналы ошибок, сигналы тревоги), администрирование тестовой лаборатории, администрирование пользователей и т. Д., Удаленное управление. диагностика / устранение неисправностей.

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

Какая должна быть основная логистическая инфраструктура и какие внешние интерфейсы будут хорошими?

Мой номер один - «Интеграция и тестирование со стандартными отраслевыми инструментами». Чем меньше пользовательских интерфейсов обновления / развертывания / мониторинга / обслуживания мне нужно использовать ежедневно, тем лучше.

Развертывание - использовать технологии Microsoft, такие как установочные базы данных установщика Windows (файлы MSI) для установки, исправления установщика Windows (MSP) и преобразования установщика Windows (MST) для предоставления настраиваемых параметров конфигурации. Только эти технологии позволят развертывать программное обеспечение только с помощью Active Directory / групповой политики и в более крупных сценариях. SCCM.

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

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

Конфигурация - мои личные предпочтения - это текстовая конфигурация и пользовательские файлы (кэш и т. д.) в% APPDATA%, текстовые файлы можно изменять или развертывать с помощью сценариев, и я могу выберите, чтобы не распространять изменения в файловой системе обратно на сервер. mh поднимает вопрос об использовании реестра для групповой политики, в большинстве случаев реестр является лучшим местом для настройки; не кладите туда слишком много, однако он предназначен для нескольких килобайт данных на приложение, а не мегабайт.

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

Для настройки придерживайтесь реестра. Шутки в сторону. Отличный аргумент реестра против файлов конфигурации хорош для автономных машин, где пользователь не возражает против изменения конфигурации самостоятельно, но для реальных конечных пользователей с удаленными системами аргумента нет. Использование реестра означает, что первоначальную конфигурацию и любые изменения можно легко развернуть с помощью групповой политики или - в случаях, когда групповая политика недоступна - просто дважды щелкнув файл .reg. Изменения можно постепенно объединять, и - с помощью HKCU - он работает правильно в многопользовательской среде.

Первоначальный конфиг очень важен. Избегайте диалогов, таких как «теперь введите имя вашего сервера jarglepoink» на этом этапе. Начальная конфигурация должна работать без какого-либо взаимодействия с пользователем или ввода данных. Посмотрите, как работает установка MS Office, управляемая GPO - при правильной настройке пользователю никогда не нужно вводить ни свое имя пользователя, ни имя сервера Exchange во время первого запуска Outlook. Скопируй это.

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

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

Все это - и приведенная выше рекомендация re: MSI - должно помочь создать настройку, в которой ПК пользователя никогда должен быть либо физически посещен, либо удален для выполнения работы, связанной с приложением.

Больше всего мне не хватает надлежащей документации.

Представление высокого уровня будет примерно таким:

  • все переключатели должным образом задокументированы
  • когда приложению нужен перезапуск
  • как настроено ведение журнала
  • и т. д., yadda yadda (на самом деле это зависит от потребностей клиента)

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

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