разработка программного обеспе-чения и изготовление веб-сайтов

  Основные разделы  
 :.  Веб сайты
 :.  Программы
 :.  Статьи
 :.  Контакты
Поиск на сайте  



Другие разделы  
 :.  Linux для программиста

 :.  Clarion для программиста

 :.  Assembler

 :.  Философия программиста


Скидки  

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


Улыбнись... :)  

  Методика перевода
:. Перевод ИТ инфраструктуры на Linux  

      Этапы миграционного проекта


Реклама  
Подключи котроллеры к KSduino, сделай сайт с использованием технологии KS-FRAME-PIE и никакой дезинсекции в Москве или других регионах и странах не понадобится:)

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



Состояние корзины  
      товаров:   0
      в количестве:  0
      на сумму:   0.00

      Оформить заказ
Информация  

Переход на свободно-распространяемое ПО Linux | Методика перевода | Успешные внедрения | Заявка | Статьи Linux

Методика переводаЭтапы миграционного проекта, которые мы обсуждаем и описываем вместе с нашими клиентами:

Оценка существующей инфраструктуры (обследование)

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

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

Повесть о двух предприятиях

В течение всех пяти лет одна компания страдала от разраставшейся и становящейся всё более насущной проблемы спама и вирусов, передаваемых по электронной почте. Ситуация стала настолько серьезной, что некоторые пользователи ежедневно тратили более двадцати минут на просмотр и удаление ненужной информации. В результате кое-кто из руководства среднего звена попросил ИТ-менеджера Василия оценить затраты на установку в систему передачи и получения электронной почты средств защиты от спама и вирусов.
Поскольку для передачи сообщений в компании использовался Exchange, Василий связался с поставщиками программных средств защиты от спама и вирусов продуктов, интегрированных с Exchange. Он выяснил, что установка указанных средств в Exchange обойдется в 800 $, поэтому было принято решение о подготовке предложения по установке открытых программ-антивирусов и антиспама  на Linux-сервер компании. Хотя программы защиты немного снижают скорость работы сервера, они устраняют проблемы появления вирусов и спама без оплаты дорогостоящих лицензий.
Просматривая приобретенные лицензии на программные продукты при подготовке отчета руководству, Василий обнаружил наличие лицензий на сервер Exchange и клиенты Outlook и отсутствие лицензий на клиентский доступ к Exchange (client access license. CAL). Проверка сервера Exchange показала лицензирование 999 пользователей - число в любом случае некорректное. Кто-то "подобрал" строку регистрации и избежал необходимости покупки лицензий клиентского доступа Exchange стоимостью 500- долларов.
Помимо проблемы спама и вирусов возникла очень щекотливая дилемма: заплатить 500- долларов или отказаться от использования Exchange. Теоретически открытые программные средства могли обеспечить необходимые компании функции, подобные функциям Exchange, причем не по ценам Exchange. Василий знал об этих возможностях открытых программ, но не предполагал, что они могут заменить всю инфраструктуру Exchange и службы каталогов Active Directory. Компания, где работал Василий могла бы избавиться от инфраструктуры Windows Server, перенести все сетевые приложения и даже полностью перейти на операционную систему Linux.


Определение требований к инфраструктуре Linux

После завершения оценки существующей инфраструктуры начинается следующий этап: определение требований к инфраструктуре Linux.

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

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

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

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

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

Создание проекта постмиграционной инфраструктуры

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

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

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

Составление плана испытаний

Для составления плана испытаний используется подготовленный ранее список функциональных требований. Каждый пункт документа становится записью в плане испытаний. Испытание сложных пунктов может быть достаточно продолжительным.
План проведения испытаний - это документ, содержащий испытываемые требования и описание процесса тестирования. Степень детализации плана испытаний зависит от сложности требований и среды, опыта и профессионализма сотрудников, выполняющих эту работу, а также от педантичности руководителя проекта.
В Acme Widgets процедура проверки функциональности электронной почты заключается в отправке тестового сообщения в Интернет и внутренним пользователям. В данном случае достаточно короткого описания: отправить сообщение на электронный адрес и убедиться в его получении.

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

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

Испытание инфраструктуры Linux

Испытания новой инфраструктуры необходимо проводить до ее развертывания в соответствии с  утверждённым планом проведения испытаний

Развертывание инфраструктуры Linux

После успешных лабораторных испытаний осуществляется развертывание инфраструктуры Linux в рабочей сети для дополнительного тестирования.
Предоставление выбранной группе пользователей (испытательской группе) возможности испытания инфраструктуры Linux на предмет ее работоспособности с точки зрения конечного пользователя.
Немаловажным является составление документации, регламентирующей корректный переход и его очерёдность.

Переход к инфраструктуре Linux

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

 - потребность в новых функциях, предлагаемых Linux (зависит от возможностей);
 - производственная единица или подразделение (зависит от производственной группы);
 - местоположение офиса (зависит от географических особенностей). Существует несколько
способов управления планом перехода. Важность (и сложность) управления планом перехода повышается с увеличением размеров и количества рабочих групп, переводимых на новую инфраструктуру. При реализации крупных миграционных проектов полезно назначить сотрудника, ответственного за взаимодействие между IT-персоналом и группой или филиалом. Он может помогать определять пользователей, готовых к переходу, а также даты и сроки перехода. Идеальным вариантом будет назначение контактных лиц рабочих групп ответственными за составление списков пользователей для перехода, чтобы группа IT-персонала могла сосредоточиться на фактическом процессе перехода и обслуживании новых пользователей. Процесс перехода будет успешным при оперативном взаимодействии рабочих групп с IT-персоналом, а также при чётком распределении обязанностей каждой группы.

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

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

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



 

:. Copyright © Kirsoft Inc., 1996-2012
:. Веб дизайн и П.О. © Kirsoft Inc., 2005