![](/user_photo/2706_HbeT2.jpg)
- •Дипломный проект
- •Реферат
- •Перечень сокращений и терминов
- •Онтологическое соглашение проекта
- •Введение
- •Глава 1. Анализ предметной области
- •Услуга Colocation
- •Общие понятия услуги colocation
- •Услуги цод (colocation)
- •История развития цод и услуг colocation
- •Происхождение вида
- •Всеобщая цоДофикация
- •Аутсорсинг.
- •В регионы за электричеством.
- •Мировая мода.
- •Проблемы «озеленения».
- •Основные задачи, решаемые системой комплексного менеджмента colocation-проектов.
- •Пример методика ценообразования услуг
- •Обзор конфигураторов услуг и сервисных калькуляторов в сфере услуг colocation и аутсорсинга, представленных в Росии.
- •Что же такое сервисный калькулятор или конфигуратор услуг?
- •Компания europrojects.
- •Резюме:
- •Выводы.
- •Глава 2. Выбор и обоснование средств разработки и технологий реализации
- •Выбор программной платформы разработки системы.
- •Выбор технологии
- •Трехуровневая архитектура “клиент-сервер”
- •Выбор субд
- •Выбор языка программирования
- •Выбор web – сервера
- •Выбор программно-аппаратной платформы разработки информационной системы.
- •Обеспечение отказоустойчивости решения.
- •Использование failover кластера (отказоустойчивого кластера).
- •Принцип функционирования кластера.
- •Персональный компьютер пользователя (Клиент)
- •Глава 3. Разработка информационной системы
- •Проверка закона распределения данных по критериям к.Пирсона (критерии согласия)
- •Разработка и реализация пользовательского интерфейса
- •История развития веб-дизайна от технической графики до современных сайтов
- •Зарождение идей о юзабилити сайтов
- •Современный этап развития веба
- •Разработка пользовательского интерфейса
- •Архитектура и структурная схема информационной системы
- •Функциональная схема информационной системы
- •Глава 4. Модель оценки результативности работы системы. Расчет технических характеристик системы
- •Расчет математического ожидания ис.
- •Расчет производительности.
- •Расчет обобщенной энтропии информационной системы
- •Расчет интегральной информационной нагруженности информационной системы
- •Расчет надежности информационной системы
- •Надежность аппаратной части
- •Надежность программной части
- •Глава 5. Менеджмент проекта
- •Введение
- •Ступень дивергенции
- •Ступень трансформации
- •Ступень конвергенции
- •Ступень релаксации
- •Ступень ликвидации
- •Глва 6. Выбор и обоснование модели жизненного цикла информационной системы
- •Введение
- •Итеративный подход
- •Подход, основанный на фазах и вехах
- •Модель проектной группы msf
- •Фаза выработки концепции
- •Фаза планирования
- •Фаза разработки
- •Фаза стабилизации
- •Фаза внедрения
- •Глава 7. Экономическая часть проекта
- •Аннотация
- •Организация работ
- •Структура организации работ
- •Система управления производством работ
- •Бизнес-план
- •Конкуренция на рынке
- •Расчет сметной стоимости (себестоимости) проекта
- •Затраты на материалы и покупные изделия
- •Основная зарплата научного и производственного персонала
- •Дополнительная заработная плата
- •Оценка экономической эффективности проекта
- •Оценка рисков и поиск путей их минимизации
- •Заключение
- •Глава 8. Экологичность и безопасность проекта
- •Введение
- •Оптимальные условия труда на рабочем месте разработчика.
- •Расчет освещения.
- •Расчет системы вентиляции.
- •Расчет влаговыделения
- •Расчет тепловыделения.
- •Определение потребного воздухообмена
- •Проектирование системы вентиляции.
- •Глава 9. Проверка на соответствие стандарту гост р исо/мэк 15288:2005
- •Глава 10. Информационно-социальная компонента
- •Цод крупным планом: Креатив и Экзистенция
- •Увидеть лес среди деревьев
- •Не до идеалов
- •Принцип деления Цодов
- •Справка
- •Системы жизнеобеспечения
- •Как со всем этим справиться?
- •Приложение 1. Техническое задание
- •1.1 Полное наименование системы и ее условное обозначение
- •1.2 Шифр темы
- •1.3 Наименование предприятий разработчика и заказчика системы и их реквизиты
- •1.4 Перечень документов, на основании которых создается система, кем и когда утверждены эти документы
- •1.5 Плановые сроки начала и окончания работы по созданию системы
- •1.6 Сведения об источниках и порядке финансирования работ
- •1.7 Порядок оформления и предъявления заказчику результатов работ по созданию системы, по изготовлению и наладке отдельных средств и программно-технических комплексов системы
- •2.Назначение и цели создания системы
- •2.1 Назначение системы
- •Требования к системе
- •4.1.1.2 Требования к способам и средствам связи для информационного обмена между компонентами системы
- •4.1.1.4 Требования к режимам функционирования системы
- •4.1.1.5 Требования по диагностированию системы
- •4.1.1.6 Перспективы развития, модернизации системы
- •4.1.2 Требования к численности и квалификации персонала системы и режиму его работы
- •4.1.4.4 Требования к методам оценки и контроля показателей надежности на разных стадиях создания системы в соответствии с действующими нормативно-техническими документами
- •4.1.5 Требования безопасности
- •4.1.6 Требования к эргономике и технической эстетике
- •4.1.7 Требования к транспортабельности для подвижных ас
- •4.1.8 Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
- •4.1.8.2 Предварительные требования к допустимым площадям для размещения персонала и тс системы, к параметрам сетей энергоснабжения и т. П.
- •4.1.8.3 Требования по количеству, квалификации обслуживающего персонала и режимам его работы
- •4.1.8.4 Требования к составу, размещению и условиям хранения комплекта запасных изделий и приборов
- •4.1.8.5 Требования к регламенту обслуживания
- •4.1.9 Требования к защите информации от несанкционированного доступа
- •4.1.10 Требования по сохранности информации при авариях
- •4.3.3 Требования к программному обеспечению
- •Требования к техническому обеспечению
- •4.3.5 Требования к лингвистическому обеспечению
- •4.3.6 Требования к метрологическому обеспечению
- •5. Состав и содержание работ по созданию системы
- •6. Порядок контроля и приемки системы
- •8. Требования к документированию
- •9. Источники разработки
- •Приложение 2. Техническое предложение
- •3. Техническая характеристика
- •4. Описание и обоснование выбранной конструкции
- •5. Расчеты, подтверждающие работоспособность и надежность конструкции
- •6. Описание организации работ с применением разрабатываемого изделия
- •7. Ожидаемые технико-экономические показатели
- •8. Уровень стандартизации и унификации
- •Приложение 3. Технические условия
- •1.1 Наименование и назначение системы
- •1.2. Условия эксплуатации
- •2. Технические требования
- •2.1 Требования назначения
- •2.2 Требования к программной совместимости
- •2.3 Требования к производительности и точности
- •2.4 Требования к надежности
- •3. Требования безопасности
- •4. Требования охраны окружающей среды
- •5. Правила приемки
- •6. Методы контроля
- •7. Указания по эксплуатации
- •Приложение 4. Инструкция для всех групп пользователей
- •Приложение 5. Листы графики
- •Приложение 6. Описание демо-версии
- •Приложение 7. Текст доклада
- •Доклад окончен. Спасибо за внимание!
-
Проблемы «озеленения».
Мировая индустрия ЦОДостроения сейчас озабочена «озеленением» дата-центров. Недавно Uptime Institute и консалтинговая компания McKinsey & Co представили доклад, в котором утверждается, что к 2020 г. объемы парниковых газов, выбрасываемых дата-центрами в атмосферу, увеличатся в 4 раза и превзойдут объемы выхлопов всех самолетов мира. Там же говорится, что цены на энергоносители растут со скоростью 16% в год, а основной проблемой для дата-центров является резкий рост энергопотребления, который обгоняет рост вычислительной мощности. Компании, строящие и эксплуатирующие дата-центры, обеспокоены тем, что их затраты на электроэнергию сильно выросли за последние годы и продолжают расти. По данным IDC, в 1996 г. на электроэнергию приходилось примерно 15% затрат на эксплуатацию дата-центров, а к 2010 г. ее доля возрастет до 70%. Поэтому около половины опрошенных Uptime компаний собираются в течение ближайшего года модернизировать свои ЦОДы, чтобы снизить энергопотребление их инженерных систем и ИТ-оборудования. Причем заинтересованы в этом прежде всего ИТ-директора, так как электроэнергия для дата-центров на Западе уже давно оплачивается из ИТ-бюджета компании.
Наших владельцев ЦОДов до недавнего времени больше волновал вопрос, где вообще взять электричество, а не его цена. Но теперь мы стараниями наших энергетиков, и в первую очередь почившего в бозе РАО ЕЭС, по стоимости 1 кВт.ч догнали США, а счет энергопотребления нынешних дата-центров идет на мегаватты. К тому же западная практика внесения платы за электричество, потребляемое ЦОДом, в ИТ-бюджет пришла уже и в Россию. Судя по всему, скоро она станет обычной для всех корпоративных дата-центров. И тогда ИТ-директора наших компаний вслед за владельцами коммерческих ЦОДов и всем прогрессивным человечеством должны будут озаботиться проблемами экономии электроэнергии всеми доступными способами.
-
Основные задачи, решаемые системой комплексного менеджмента colocation-проектов.
Информационная система комплексного менеджмента colocation-проектов предназначена для обеспечения наиболее эффективной работы персонала компании, непосредственным направлением деятельности которой, является предоставление и реализации проектов по услугам colocation и аутсорсингу.
То есть, система представляет собой конфигуратор услуг (сервисный калькулятор), который позволяет сократить время формирования и повысить эффективность расчета специалистом спецификации для конкретного заказчика.
Спецификация представляет собой электронный документ, позволяющий оценить:
-
Трудозатраты, требующиеся на реализацию конкретного проекта.
-
Общую стоимость предоставляемого комплекса услуг.
-
Персонал и время, требуемое для реализации проекта.
-
Анализ рациональности реализации конкретного проекта.
-
Описание модели SLA проекта конкретного заказчика.
SLA – это основной документ, регламентирующий взаимоотношения ИТ и клиентов.
Цель документа – дать качественное и количественное описание сервисов, как с точки зрения провайдера, так и сточки зрения клиента.
Существенной частью SLA является каталог сервисов.
Соглашение об уровне сервиса (Service Level Agreement – SLA) определяет взаимные ответственности провайдера ИТ-сервиса и пользователей этого сервиса.
Типовая модель SLA должно включать следующие разделы:
-
Определение предоставляемого сервиса, стороны, вовлеченные в соглашение, и сроки действия соглашения.
-
Дни и часы, когда сервис будет предлагаться, включая тестирование, поддержку и модернизации.
-
Число и размещение пользователей и/или оборудования, использующих данный сервис.
-
Описание процедуры отчетов о проблемах, включая условия эскалации на следующий уровень. Должно быть включено время подготовки отчета.
-
Описание процедуры запросов на изменение. Может включаться ожидаемое время выполнения этой процедуры.
-
Спецификации целевых уровней качества сервиса, включая:
-
Средняя доступность, выраженная как среднее число сбоев на период предоставления сервиса
-
Минимальная доступность для каждого пользователя
-
Среднее время отклика сервиса
-
Максимальное время отклика для каждого пользователя
-
Средняя пропускная способность
-
Описания расчета приведенных выше метрик и частоты отчетов
-
Описание платежей, связанных с сервисом. Возможно как установление единой цены за весь сервис, так и с разбивкой по уровням сервиса.
-
Ответственности клиентов при использовании сервиса (подготовка, поддержка соответствующих конфигураций оборудования, программного обеспечения или изменения только в соответствии с процедурой изменения).
-
Процедура разрешения рассогласований, связанных с предоставлением сервиса.
-
Процесс улучшения SLA. В идеале, SLA определяется как особый сервис. Это позволяет сконфигурировать аппаратное и программное для максимизации способности удовлетворять SLA.