Архив метки: Планирование в ИТ

Критерии качественной настройки Active Directory

Наиболее заметное предназначение Active Directory – централизованная аутентификация пользователей. Именно благодаря Active Directory сотрудникам компании для доступа ко всем внутренним ресурсам корпоративной сети достаточно знать один логин и пароль, а не десяток.

Но централизованная аутентификация – это не самый ценный функционал Active Directory.  Куда более значимая, хоть и куда менее заметная роль Active Directory – это централизованное применение настроек к компьютерам, серверам и рабочему окружению пользователей. Данный функционал впервые появился еще в 1996 году в операционной систем Windows NT и назывался он тогда System Policy. В настоящее время этот функционал серьезно расширился и теперь называется Групповыми политиками (Group Policy). Через групповые политики можно настроить практически все параметры в операционных систем Windows, а разработчики приложений под Windows выпускают специальные Административные шаблоны, позволяющие через групповые политики настраивать в том числе и их приложения.

К сожалению, редко в какой компании возможности Active Directory применяются на полную катушку, а еще реже – применяются корректно. Часто можно встретить домен Active Directory в котором все учетные записи размещаются в контейнерах по умолчанию, а групповых политик одна-две штуки на всю компанию, не считая созданных по умолчанию (Рис. 1, 2): Читать далее

Как управлять приоритетами любого трафика в корпоративной сети на примере Skype

Это первая наша статья в цикле «как надо делать ИТ». Напомню, что мы в «Депарамент ИТ» строим и обслуживаем корпоративные ИТ-инфраструктуры так, что сотрудники у наших клиентов работают, а не звонят в техподдержку.

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

Для приоритизации доступа в сеть Интернет по типам трафика еще при царе горохе была придумана такая технология как Quality of service (QoS). Суть ее в том, что сетевое оборудование определяет тип проходящего через него трафика и на основании заданных на нем правил дает зеленый сигнал приоритетному трафику и притормаживает менее приоритетный, если ширины канала на всех не хватает.

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

Отличительные признаки «скороспелого» ИТ-директора

На которые стоит обратить внимание, подбирая себе руководителя ИТ-службы

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

В данной статье я собрал отличительные признаки «скороспелых» ИТ-директоров и постарался сформулировать их как можно доступнее. Надеюсь, что они помогут не разбирающимся в информационных технологиях специалистам по кадрам и генеральным директорам фильтровать кандидатов на должность руководителя ИТ-службы. Буду рад, если сообщество Хабрахабра дополнит меня или исправит ошибки в суждениях. Но на этом вступительную часть заканчиваю и перехожу к сути: Читать далее

Планирование аварийного восстановления. Часть третья — заключительная

Соотносим потребности бизнеса с его возможностями

Наша заключительная статья цикла: http://habrahabr.ru/post/228115/

В предыдущих статьях (1,2), посвященных вопросам планирования аварийного восстановления, были описаны процедуры сбора и обработки информации об ИТ-инфраструктуре организации, позволяющие получить точную информацию о:

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

И все бы ничего, если бы не ограниченные финансовые возможности организации, не позволяющие приобрести все необходимые резервы для оперативного восстановления. По этой причине заключительная задача планирования аварийного восстановления – поиск баланса между потребностями и финансовыми возможностями бизнеса, и закрепление его в виде соглашения об уровне обслуживания (Service Level Agreement – SLA) в части устранения возникающих инцидентов.

Данный этап полностью состоит из согласования с руководством компании следующих аспектов взаимодействия: Читать далее

Планирование аварийного восстановления. Вторая часть

Готовимся к любым падениям

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

Собственно, необходимые ресурсы будут в дальнейшем предметом торга с руководством компании, помогая найти баланс между инвестициями в информационные технологии, временем простоя и потерей данных в случае сбоя. Но это потом, а пока нам нужно определить какие сроки восстановления мы в принципе можем выжать из ИТ-инфраструктуры в случае сбоя. Поехали: Читать далее

Планирование аварийного восстановления. Часть первая

Определяем места, где стоит подстелить соломку


Еще одна наша статья на хабре: http://habrahabr.ru/post/225719/

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

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

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