Вот еще одна модель с минимальной прикладной ценностью, зато для меня обеспечивающая полное понимание вопроса.
В процессных моделях ITIL, COBIT 5, ISO 20000, MOF 4, CMMI for Services присутствуют одни и те же слова: доступность, мощность, непрерывность и, конечно, безопасность. Если брать за основу идеологию ITIL, то это – четыре равноправных и обязательных составляющих качества ИТ-услуг (есть еще функциональность, но я не о ней пока).
И вот, в ITIL всё понятно: есть четыре процесса, которые оперируют ими: проектируют и контролируют. А вот в других источниках всё по-другому, по-разному. Во всех перечисленных моделях эти слова комбинируются в произвольном порядке. Стандарт – объединяет, и управляет вместе доступностью и непрерывностью, MOF – все объединяет в «надежность» и т.д.
Почему же эти процессы объединяют в разных процессных моделях, и как поступать на практике?
Описания процессов не помогают понять принцип группировки процессов, потому что за скучными словами «планирование, управление, контроль, координация», увы, ничего не видно, а примеров нет.
И, тем не менее, следуя не букве, но духу ITIL, я рискну представить, что все четыре (два, три) процесса – это один и тот же процесс: управление рисками. Попробую объяснить.
Функциональности ИТ-системы, которую проектируют, разрабатывают, тестируют и внедряют другие ребята, а ITSM считает «полезностью услуги», в эксплуатации постоянно что-то угрожает. Каждый из четырех процессов отвечает за один класс подобных угроз: доступность – за сбои, мощность – за дефицит ресурсов против спроса, непрерывность – за "пожары", безопасность… ну вы поняли. Действуют они примерно одинаково, в соответствии с методикой управления рисками (последовательно и упрощенно):
-
Выявление
- Классификация
- Отбор важнейших угроз
- Разработка контрмер
- Мониторинг угроз и контрмер
– почти как на картинке.
В ходе управления рисками эксперты оценивают свой класс угроз для ИТ-услуг, выбирают значимые по сочетанию ущерба и вероятности наступления и придумывают, как эти угрозы предупредить или ликвидировать. После четвертого шага спроектированная и внедренная услуга как бы защищена ото всех угроз, которые сочтены значимыми. А значит, качество этой услуги не снизится, несмотря ни на что.
Пятый шаг этой процедуры – это мониторинг. ИТ-организация отслеживает все угрозы и значения их характеристик. В случае реализации угрозы быстро применяется правильная контрмера, и составляется и анализируется отчетность об этой угрозе. Деятельность операционная.
Третий шаг – это отражение очевидного факта: везде соломки не подстелишь. Не хватит ресурсов, да и большая часть «соломы» сгниет из-за неупотребления. Строго говоря, предотвращать все возможные угрозы (от метеорита в серверную до ошибки пользователя) – нерационально, то есть дорого и не приведет ни к какому результату. Насчет «дорого» – разговор отдельный. Заказчик при проектировании услуги будет стремиться потратить как можно меньше средств, а, значит, на разработку контрмер будет оставаться очень немного. При этом, надо обеспечить:
- Резервирование систем
- Запасные ресурсы на случай всплеска потребления
- Средства защиты
- Планы поведения при наступлении угрозы
- и т.п.
И вот, получается, что все четыре процесса, в своих интересах, будут лезть за контрмерами в один общий кошелек! Ничего удивительного, что их объединяют! Так проще драться за ресурсы! 😉
Итак, мне кажется, объединять процессы проектирования можно, потому что у них:
- А. похожая структура.
- Б. общие ресурсы.
Но ведь ITIL всё-таки разделяет. Почему же?
Пост получился длинный, поэтому я мысль продолжу формулировать модель в следующем. Ну а пока буду рад корректировкам и этих тезисов.