17.04.2012 07:26:44

Эраст Костюк

По следам одного из проектов......

Многие из нас помнят время, когда для объединения удаленных офисов было необходимо коммутировать выделенные линии, или прокладывать оптику между площадками, и такие проекты были под силу только нефтяникам и банкам.

Сейчас - с развитием интернета и появлением технологии VPN (Виртуальные частные сети)  - объединить офисы может позволить себе практически любая компания.

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

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

Не вдаваясь в технические детали, я нарисую несколько сценариев такого объединения. От того, какой выбран сценарий, нужно будет выбрать ту или иную технологическую платформу (или так называемые технологические компоненты). Собственно сами эти технологические компоненты останутся за рамками данной статьи.  А вот выбор заказчиком  того или иного сценария позволит более внятно сформулировать задачу и подобрать необходимое оборудование.

Сценарий 1.

У нас есть головной офис, а так же несколько площадок, на которых работает от одного до трех сотрудников. Эти сотрудники работают с некой информационной системой (например 1С торговля), читают электронную почту, а так же работают с документами Word,  Excel.

Другими словами - все ресурсы, необходимые удаленным пользователям, находятся в центральном офисе.  Удаленные площадки являются лишь потребителями этих ресурсов.

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

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

С позиции руководителя мне бы хотелось централизовать всю информацию в головном офисе и не выпускать ее за пределы периметра. Поэтому первые три минуса для меня существенные.

При таком сценарии я бы рекомендовал заказчику установить у себя в головном офисе так называемый терминальный сервер. Некий сервер, на котором одновременно будут работать все удаленно подключаемые сотрудники. Именно на этом сервере будет происходить обработка всех данных. Удаленные сотрудники будут подключаться, работать на терминальном сервере каждый в своем сеансе. А после отключения вся информация останется в центральном офисе.

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

Сценарий 2.

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

Другими словами - удаленная площадка использует ресурсы головного офиса, а головной офис регулярно использует ресурсы удаленной площадки.

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

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

Сценарий 3.

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

Другими словами - удаленной площадки нет как таковой. Есть удаленные сотрудники, которые используют ресурсы головного офиса, и при этом могут это делать из совершенно произвольных мест.

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

Но прежде чем это делать необходимо ответить на два вопроса

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

2. Если перечень закрытый, есть ли возможность предоставить доступ к этим ресурсам через WEB интерфейс?

Например, если сотруднику нужна почта - можно применить сервер, позволяющий подключение к нему через WEB интерфейс.  Если это 1С торговля - можно использовать последние версии 1С, имеющие WEB интерфейс. Если это файлы Word и Excel, можно использовать SharePoint.  В этом случае вообще снимается вопрос с применением каких то специальных средств для подключения к головному офису удаленных сотрудников. А так же достигается определенная универсальность, так как работать с WEB интерфейсом можно даже со смартфона.

Если все же перечень ресурсов произволен, тогда возвращаемся к вопросу организации терминального сервера. Смотри сценарий 1. И в этом случае возможно использование VPN канала, аппаратного или программного, как дополнительного средства защиты, увеличивающего стоимость проекта но в ряде случаев необходимого.

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

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

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

Э.В.Костюк.  Руководитель компании.

каналы связи | удаленные площадки | Объединение офисов | VPN

10.04.2012 10:40:11

Максим

Модели облачных сервисов

Существует три модели облачных сервисов. У каждой из моделей есть свои преимущества и недостатки.

SaaS (Software as a Service)

SaaS – Софт как сервис. Типичным примером подобного решения является Google Apps или Office 365 от Microsoft. В качестве сервиса мы получаем готовое программное решение, которое используем, не заботясь об администрировании.

Преимущества:

• Мы получаем готовое к эксплуатации решение.
• Нет необходимости что-то администрировать и тратиться на оборудование.

Недостатки:

• Решение универсальное для всех пользователей. Нет возможности что-то изменить

PaaS (Platform as a Service)

PaaS – Платформа как сервис. Примером такого облака служит Azure от Microsoft. Мы получаем готовую платформу, в которой разворачиваем свое приложение.

Преимущества:

• Не нужно администрировать операционную систему и службы и тратиться на оборудование.
• Приложение разрабатывается под наши задачи, а значит будет их решать оптимальным образом

Недостатки:

• Наше приложение привязано к платформе и ограничено ее возможностями

IaaS (Infrastructure as a Service)

Iaas – инфраструктура как сервис. Пример такого решения – облако Amazone или виртуальная машина в датацентре. В качестве сервиса мы получаем виртуальную машину, на которую можем установить необходимую нам платформу и программное обеспечение

Преимущества:

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

Недостатки:

• Такое решение требует профессиональных знаний системного администратора для настройки и администрирования. Мы сами отвечаем за работоспособность сервисов на нашей виртуальной машине.

Облако сервисы

05.04.2012 10:53:51

Эраст Костюк

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

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

Если следовать рекомендациям ITIL, то поступающие от клиентов проблемы следует разделить на три категории

- заявки на восстановление

- заявки на обслуживание

- заявки на изменение

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

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

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

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

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

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

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

- Заявка на обслуживание  - это консультация на техподдержке. Или плановые задачи для линейного сотрудника.

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

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

1. Функциональное разделение сотрудников, с выделением службы техподдержки, линейных специалистов, администраторов. Но этого не достаточно. Само по себе такое разделение вызывает неразбериху в работе и перекладывание ответственности.

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

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

Над этим сейчас работает менеджмент компании.

Э.В.Костюк  Руководитель компании.

Обслуживание компьютеров | ITIL | заявка на обслуживание