- •Дипломный проект
- •Реферат
- •Перечень сокращений и терминов
- •Онтологическое соглашение проекта
- •Введение
- •Глава 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.