Вопросы Теги

Роли и обязанности для сети разместили производственную систему

Вы вставляете локальный диапазон адресов как этот 192.168.0.0/16?

2
задан 21 February 2015 в 21:03
3 ответа

Размер компании и промышленности в основном влияет на структуру отдела ИТ. В некоторых случаях, немного слишком много. Моим профессиональным фокусом является инфраструктура интернет-технологии.

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

Мне нравится юниор к подходу на высшем уровне, который документируется хорошо должностными инструкциями SAGE для системных администраторов. Это - разумное эмпирическое правило для следования в целом.

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

Ключевые области, которые часто извлекают выгоду из некоторого разделения обязанностей:

  • Стеки приложений
  • База данных
  • Сеть
  • Безопасность

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

  • Отслеживаемость SLA
    • Отчеты времени работы
    • Процессы контроля изменений

  • Резервные копии

    • Политика
    • Системы
    • База данных

  • Операционные системы

    • Windows
      • Маленькие патчи
      • Большие обновления
      • Настройка производительности
    • Linux
      • Маленькие патчи
      • Большие обновления
      • Настройка производительности
  • Контроль
    • Система предупреждений
    • Исторический контроль
    • Веб-аналитика
  • электронная почта
    • Поле Spam
    • Поле конечного пользователя
    • Реле производственного приложения

Этот список продолжается и на, который будет характерен для Вашей инфраструктуры и потребностей в Вашей компании.

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

4
ответ дан 3 December 2019 в 09:50

Вы достаточно близки для первого проекта без более подробной информации о Вашем приложении. Вот то, как получить остальную часть разрывов: Сделайте схему с каждым компонентом в, или это поддерживает/подает/зависит на, Ваше приложение. Удостоверьтесь, что у Вас есть имя или команда, это ответственно за каждую часть. Имейте по крайней мере кто-то еще, и предпочтительно не в Вашей команде делает то же самое с нуля - удостоверяется, что Вы получаете другие точки зрения. Это включает управление - у них, вероятно, будет совершенно другая точка зрения от людей IT, и это может быть очень допустимо. Это может также быть немного дерьма CYA, и это может все еще быть допустимо :-)

Вот некоторые другие идеи, которые могут или не могут относиться к Вам:

  1. Соответствие AV/Security/patching/regulatory. Часть этого может уже наложиться с Вашими людьми ОС/контроля/сети. Безопасность и/или соответствие установленным требованиям, возможно, должны быть своим собственным штатом.

  2. Документация - или каждая команда может потребоваться, чтобы делать свое собственное.

  3. Кто обрабатывает связь с клиентами? Существует ли система покупки билетов для проблем от клиента? Существует ли назначенная команда, которая обрабатывает объявления об обслуживании или незапланированное время простоя? Если клиенты являются внешними, там команда счетов по внутренним расчетам или продавцы, которым нравится быть уведомленными об этих вещах?

  4. Кто обрабатывает решения об обновлениях, запросах улучшения и отчетах об ошибках? Это могло быть "продуктом" или "управлением портфелем" и вероятно в большой степени наложится с бизнес-людьми.

1
ответ дан 3 December 2019 в 09:50

Возможно, не в рамках того, что Вы хотите, а что относительно самого приложения? Например: 1) Что относительно содержания (если таковые имеются)? Т.е. Который могут спроектировать роли, утвердите и выпустите содержание.

2) Какая роль решает, кого может удовлетворить draft/aprove/release? Какая роль затем реализует это т.е. настраивает пользователей с соответствующим доступом для спроектированного/утверждения/выпущения

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

0
ответ дан 3 December 2019 в 09:50

Теги

Похожие вопросы