Bileti_po_AvIS / Avis_bilet_02
.docБилет №2.
1. Вопрос 1. Модели управления открытыми системами: TMN. ITIL. FCAPS.
Каждая из вышеупомянутых моделей описывает определённые функции, но ни одна из них не охватывает их все.
TMN Telecommunication Management Network.- описана в М.3010
Стандартизирующая организация ITU создала модель управления и администрирования TMN – Telecommunication Management Network. TMN создавалась для телекоммуникационных компаний (операторов связи).
Нужно создавать сеть, чтобы управлять всем остальным.
Концепция, созданная ITU, охватывала несколько задач телекоммуникационных сервисов.
Управление и объектами, и процессами.- это то, из-за чего не исп-ся
Объект- иерархическая структура.
- уровень элементов сети.- оборудование (сервера, коммутационное оборудование)
- уровень управления элементами (ОС).
- уровень управления сетью. (сетевая ОС)
- уровень управления услугами. (сопровождение услуг)
- уровень управления бизнесом.
Устарела и не удалась. Уровень управления бизнесом никого не устраивает, т.к. управление бизнесом сейчас разбито на отдельные процессы бизнеса.
Функции можно разбить на 4 класса:
-
конфигурация элементов;
-
проблема производительности и поиска ошибок;
-
администрация приложений (сервисов);
-
управление бизнесом.
Сейчас эта модель не применяется, так как все сочли, что она не годится для систем передачи данных и не учитывает необходимости создания протоколов на основе модели.
В конце 90-х годов ITU решили, что они будут использовать модель FCAPS, разработанную ISO.
ITIL
Модель управления инф системами ITIL (IT Infrastructure Library) была создана английским правительством для описания управления бизнес-процессами IT-компаний. т.к были большие потери бизнеса
В 80-х годах XX-го столетия Британское правительство создало агентство OGC (Office of Government Commerce), которое занялась разработкой модели эффективного управления IT-службами и ресурсами. Целью было создание рекомендаций для организаций, работающих в области IT. Результатом работы стала библиотека решений ITIL - IT Infrastructure Library-что надо делать для осущ-я IT-услуг. Основная модель управления IT-услугами. Процессы разделены на 3 группы:
- стратегические (организация IT-служб)
- тактические (планирование и контроль IT-услуг)
- оперативн управления (поддержка IT-услуг)
Существует 10 базовых процессов управления для поддержки и предоставления IT-сервисов.
-
процесс управления и инициализирования
-
- // - управления проблемами
-
- //- управления конфигурациями
-
-//- управления изменениями
-
- // - релизами
-
- // - уровнем услуг
-
- // - мощностью
-
- // - доступностью
-
- // - непрерывностью
-
- // - безопасностью
-
процесс финанс управления
-
служба HELP DESC
Пользователь системы- заказчик IT-услуг.
Согласно модели IT был создан стандарт ISO20000. Он описывает интегрированное множество всех процессов управления IT-услугами, дает спецификации, как организации организовать IT-сервис для получения сертификата.
Смысл рекомендация: чтобы внутренняя IT-служба могла конкурировать с внешней службой администрации сист. Нет технических подробностей, не затрагивает технические вопросы. Написано что делать, а как не написано.
В современных крупных компаниях применяется модель ITIL
eTOM: TMF (Tele Management Forum)- создали модель функционирования инф сист для оператора связи- eTOM. Более новое решение, чем ITIL. Говорит, какие процессы должны работать в компании оператора связи, какие долж быть прикладн и системн процессы. Полностью отражает все аспекты деятельности оператора связи. Представлена архитектура для классификации и систематизации бизнес-процессов компании связи.
4 основных процесса:
- бизнес-процессы, котор представляют потоки работ и требов к инф
- 2 гр. процессов отражает моделирование системн решения
- 3 гр процессов добавляет параметры внедрения и автоматизац
- 4 группа обеспеч аппарат-програм ср-ва для поддержки приложений.
На базе модели eTOM делаются сист сопровождения и поддержки у операторов связи- BSS(Business Service Support) /OSS (Operation Service Support). Прикладная часть создается согласно тем процессам, котрые для отрасли связи определил eTOM.
М.3050- рекомендации ITU. Здесь повторяются основные документы eTOM.
Центральный документ: eTOM TMF GB921
FCAPS
Это на сегодняшний день основная модель. ЩЫШ очнулась и решила сделать что-то современное.
ISO разработала свою модель FCAPS (Fault Configuration Account Performance Security), в которой все объекты – данные. Эта модель ограничивается перечисленными в аббревиатуре функциями, т.е. решает задачи:
– поиска неисправностей;
– конфигурации;
– учёта;
– производительности;
– защиты от несанкционированного доступа.
Эта модель администрирования наиболее распространена.
В ней не рассмотрены все функции администрирования, выделены следующие 5 функций:
-
Fault – диагностика и поиск неисправностей;
-
Configuration – конфигурация. В современных устройствах все управление осуществляется с помощью ПО. Пусть, например, в сети 250 пользователей, на них приходится примерно 9 серверов и 10 коммуникационных устройств, у каждого из которых около 300 параметров, которые нужно настроить. Поэтому конфигурация в этой средней система представляется весьма трудоемкой задачей.
До 50 портов – маленькая система;
До 800 портов – средняя система;
Более 800 портов – большая система;
-
Account – учет. Должны быть решены проблемы аудита: кто и когда работает, с какими ресурсами и имеет ли на это право (но задача не включает учета стоимости ресурсов);
-
Performance – производительность. Сбор статистики, мониторинг, оптимизация, метрики измерения производительности системы. Главное – понять, по каким именно параметрам (критериям) считать производительность системы. Эти критерии называются метриками;
-
Security – безопасность. Решение задач и функций защиты от НСД. По мнению OSI это наиболее простая из всех задач.
Эта модель не включает в себя никаких бизнес-функций.
Вопрос №2. Дайте методику обнаружения ошибок в системах передачи данных.
Разработчики ИС дают базовую модель поиска ошибок:
Есть базовые правила поиска ошибок:
-
Убедиться в том, что ошибки действительно есть (не смотрим никаких журналов и т.д.);
-
Провести инвентаризацию (при этом NMS может помочь, а может и не помочь, она дает план системы). У администратора должен быть worksheet - там карта сети и все параметры. Нужно убедиться, что все на месте и согласно плану;
-
Остановить все и сделать backup. Причем не пользуемся утилитой backup-ирования, а копируем «том в том» или «диск в диск»;
-
Делаем restart. Есть холодный restart (c отключением питания) и горячий (без отключения питания). При холодном старте заново загружаются все драйверы, все части ОС, заново делается инициализация. Нужно делать холодный старт, однако если проблема с оборудованием, то оно после этого может вообще не включиться. Перед restart нужно аккуратно завершить все процессы;
-
Если система загрузилась, нужно проверить права и привилегии, версии ПО (никогда не работаем на последней версии), нужно убедиться в том, что никто из пользователей не поставил себе никаких обновлений (хотя и непонятно, как у него это могло получиться);
-
Смотрим журналы (логии- syslog);
-
Записываем, что могло быть- строим гипотезы, т.е. по каким причинам может не работать (внешние шумы, возросли объемы информации);
Можно строить от прикладного уровня к физическому, и наоборот. А можно и по-другому:
Самые частые ошибки (1 место)- кабельные
2 место- ошибки прикладного софта
3 место- ошибки системного софта
4 место- ошибки hardware
-
Проверяем по очереди гипотезы (одну в единицу времени). Гипотезы проверяются в одной последовательности: или в восходящей (от станции к коммутационной аппаратуре), или в нисходящей (от коммутационной аппаратуры к станции). Проверяют сначала те гипотезы, которые быстрее проверить;
-
Задокументировать и коррелировать.
Есть две стратегии выявления ошибок: активная и пассивная.
Пассивная. После того, как что-нибудь уже случилось, посылаем сообщения по SNMP.
Активная. NMS посылает команды по сети и смотрим, что МОЖЕТ случиться. Протокол UDP или ICMP.
Предполагается, что мы используем обе стратегии. Но лучше всегда от пассивной стремиться к активной.
Нужно решить, сколько часов в сутки система должна работать. Это определяется SLA (Service Level Agreement).
Например, из 20 из 24 часов. Если это требование выполняется, считается, что ошибок нет.