Проектирование услуг как управление рисками

В процессных моделях ITIL®, COBIT®, ISO 20000, MOF, CMMI for Services присутствуют одни и те же слова: доступность, мощность, непрерывность и, конечно, безопасность. Но почему-то в разных моделях ITSM соответствующие процессы управления то группируются в один, то разделяются, то вообще разносятся по различным этапам жизненного цикла ИТ-услуги. В этой статье мы попробуем проанализировать причины отсутствия единого мнения об этих процессах и о соответствующих параметрах качества ИТ-услуг. В заключительной части статьи мы представим простую модель, которая позволит читателям самостоятельно принимать решение о количестве и группировке процессов управления доступностью, мощностью, непрерывностью и безопасностью.

Что такое доступность, мощность, непрерывность и, безопасность? Если за основу рассуждений взять модель из ITIL третьей версии, то эти элементы суть четыре равноправных и обязательных составляющих качества ИТ-услуг:

Составляющие гарантии (а, следовательно, ценные свойства ИТ-услуги) по ITIL таковы:

• Доступность — готовность поставщика оказывать услугу тогда, когда это необходимо заказчику.
• Мощность — максимальная производительность оказываемой услуги.
• Непрерывность — готовность поставщика оказывать услугу в любых обстоятельствах, включая чрезвычайные.
• Безопасность — конфиденциальность, целостность и ограничение доступа к информации¹.

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

Согласившись с этой моделью и её определениями, далее следует понять, что именно поставщик услуг должен делать, чтобы его услуги действительно обладали важнейшими составляющими гарантии. Комплекс «дел» в ITIL называется «процессами», и мы в этой статье, прежде всего, имеем в виду процессы проектирования услуг. Составляющие гарантии услуг по ITIL — это выходы четырёх процессов: управления доступностью, мощностью, непрерывностью и безопасностью.

Знакомясь с ITSM более подробно, читатель быстро заметит, что ITIL отнюдь не единственный, хотя во многом и первичный свод знаний, описывающий управление ИТ-организацией. Прочие своды знаний часто лишены стройных философских моделей, подобных той, которая изложена выше. Но каждый из них содержит свою претендующую на целостность систему процессов. И это согласуется с важной идеей процессного подхода к предоставлению ИТ-услуг: услуги следует оказывать заказчикам раз за разом, пока работают потребляющие эти услуги бизнес-процессы. Следовательно, и поставщик услуг должен создавать собственные «бизнес-процессы»: повторяемые, структурированные, обезличенные и измеряемые, с тем, чтобы обеспечивать заказчикам функциональность не только здесь и сейчас, по мере готовности, но и всегда во время выполнения бизнес-процессов.

Составляющие гарантии в других сводах знаний

Так же, как и ITIL, эталонная модель процессов COBIT 5 использует слова, лежащие в фокусе нашего рассмотрения. Если соотнести доменную структуру процессной модели COBIT 5 с жизненным циклом услуги по ITIL, то окажется, что процесс управления информационной безопасностью действительно описан в COBIT на этапе проектирования услуги, в то время как о мощности и доступности авторы COBIT предлагают задумываться во время разработки системы. Ну а управление непрерывностью — это часть стадии эксплуатации.

Американский источник гораздо более почтенного возраста, интегрированная модель зрелости возможностей (CMMI for Services), вообще не уделяет внимания безопасности предоставления услуг, упоминая о ней вскользь лишь в процессе управления доступностью и мощностями. Этот процесс и процесс управления непрерывностью относятся в модели к третьему уровню зрелости.

Стандарт ISO\IEC 20000-1, регламентирующий систему «производства» ИТ-услуг, хотя и заявляет соответствие библиотеке ITIL третьей версии, тем не менее, совмещает процессы управления доступностью и непрерывностью, описывая отдельно процесс управления мощностью. Все три процесса входят в группу предоставления услуг (Service Delivery), однако требования к ним также сильно различаются.

Наконец, частный метод MOF 4, во-первых, оперирует понятием функции управления услугами, а не процесса, а во-вторых группирует все четыре свойства в одну функцию надёжности и относит её к этапу планирования.

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

Так какой же из источников прав? Какая из «лучших практик» лучше остальных? Похожи ли эти модели хоть чем-нибудь на реальное проектирование или эксплуатацию услуг? Почему ITIL разделяет процессы, а все остальные их группируют, причём совершенно произвольно?

Давайте разбираться.

Суть процессов проектирования гарантии услуг

Текстовые описания не помогают понять принципы группировки или разделения процессов, упомянутые выше: за скучными словами «планирование, управление, контроль, координация», увы, никаких принципиально отличающихся видов деятельности и их последовательностей не видно, а примеров в сводах знаний почти нет.

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

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

Особняком, пожалуй, стоит процесс управления информационной безопасностью, где основным артефактом становится политика информационной безопасности и её производные. Однако и здесь, в соответствии с циклом Деминга (на котором, кстати, основан и профильный стандарт ISO\IEC 27001), есть требования к регулярно повторяемым проверкам и совершенствованию механизмов, знаний сотрудников и аудитам ИБ.

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

И вот, глядя на это произвольное объединение и разделение, напрашивается очень простой вывод: если источники путаются, то, может быть, эти процессы действительно похожи до степени смешения?

Про управление рисками

ИТ-системе (иначе говоря, полезности ИТ-услуги) в ходе эксплуатации постоянно что-то угрожает. Возникшие из-за угроз неприятности приводят к тому, что заказчик оказывается не в состоянии в полном объёме воспользоваться функциональностью этой ИТ-системы.

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

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

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

Получается, что рассматриваемые процессы тем больше ценности добавят в ИТ-услугу, чем:

• Больше компонентов различных производителей в инфраструктуре,
• Ниже индивидуальные характеристики защищённости каждого компонента,
• Выше зависимость инфраструктуры от внешних сред, источников ресурсов и обстоятельств.

Такой системной подготовке к угрозам и применению контрмер для них посвящена широкая область знаний на стыке точных и гуманитарных наук — управление рисками. Из бесспорных источников можно упомянуть международный стандарт ISO 31000 и его существенное дополнение ISO 31010. Суммируя информацию из этого и множества других материалов, деятельность по управлению рисками можно изобразить так:

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

Пятый шаг этой процедуры — отслеживание угроз, рисков и инцидентов. ИТ-организация отслеживает все угрозы и значения их характеристик. В случае реализации угрозы быстро применяется правильная контрмера, и составляется и анализируется соответствующая отчётность. Кроме этого, все заинтересованные стороны должны быть постоянно осведомлены о рисках, а ответственные лица должны отслеживать реализацию предусмотренных рисков и снижать неопределённость, выявляя новые угрозы.

Этот процесс циклический: эксплуатация ИТ-услуги даст статистику, полезную и при отборе рисков, и при выявлении угроз и уязвимостей, и при количественной классификации рисков. Но если рассмотреть первый цикл процесса хронологически, то становится ясно, что шаги с первого по третий относятся к проектированию услуг (ITIL Service Design), четвёртый — к преобразованию услуг (ITIL Service Transition), а пятый к эксплуатации (ITIL Service Operation). Аналогичную трансляцию можно осуществить и в другие упомянутые модели управления.

Итак, вернёмся к основному вопросу этой статьи: как же поступать с четырьмя процессами, управляющими гарантией услуг при создании реальной системы управления ИТ?

Ответ прост: нужно выстраивать не отдельные процессы, но практику целостного и рационального управления рисками для ИТ-услуг.

Почему целостное управление рисками?

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

Получается, что четыре процесса, наряду с поставщиками компонентов, будут требовать инвестиций, буквально из одного и того же кармана! Разделение процессов, таким образом, становится инструментом создания искусственной конкуренции за ресурсы. А результаты разделения будут сводиться к двум существенным для системы управления ИТ-результатам.

Во-первых, разделение процессов позволит избежать конфликта интересов одного владельца «совмещённого» процесса. Четыре составляющие гарантии независимы друг от друга, а, следовательно, их совмещение в одном процессе приведёт к тому, что целей процесса будет две или более, и владелец процесса будет вынужден постоянно балансировать между ними.

К примеру, управление доступностью и мощностями объединены в COBIT 5, где говорится, что для ИТ-систем одновременно нужно обеспечить и минимальное количество прерываний, и достаточное быстродействие. То есть в случае, когда требуемый уровень доступности достигается резервными компонентами, для процесса управления мощностями это существенный недостаток: резервный компонент ведь будет простаивать в нормальном режиме эксплуатации, а мог бы повысить производительность! И наоборот: повышенная производительность системы означает, что в ней задействовано большее число компонентов, сами компоненты сложнее и более ресурсоёмки, стоимость их выше — все это угрозы для конечного значения доступности, особенно последняя. Аналогичны конфликты и в прочих сочетаниях процессов. Поиск равновесного значения будет более объективным, если каждая составляющая гарантии будет отслеживаться отдельным владельцем процесса.

Во-вторых, все четыре составляющих гарантии услуги вряд ли будут равноценны в глазах заказчика. На прямой вопрос, какой из четырёх классов угроз представляется ему наиболее важным, заказчик, скорее всего, ответит «Все важны!», но быстро изменит точку зрения после попытки подсчитать расходы на контрмеры. Ему придётся выбрать приоритетные направления инвестиций. Здесь работает известная цепочка: чем более важным для заказчика является составляющая гарантии, тем более контролируемым должен быть обеспечивающий её процесс. Для многих коммерческих предприятий важнее всего безопасность (для большинства²). Для других — доступность. Для динамично развивающихся компаний — гибкая мощность. Для предприятий, связанных с жизнедеятельностью общества (например, больницы) — непрерывность. Получается, что важность процесса в глазах заказчика должна определять его уровень зрелости относительно других процессов проектирования услуг.

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

Какую же методику можно применить для создания такой системы?

Управление рисками как основа системы управления ИТ

Итак, суммируем тезисы, к которым мы пришли выше. Предпосылки, на которых строится система управления ИТ на предприятии:

• ИТ-услуги предоставляют заказчику ценность: функциональность ИТ-систем (полезность) и гарантированное предоставление этой функциональности (гарантия).
• ИТ-услуги оказываются с использованием гетерогенной инфраструктуры: аппаратное и программное обеспечение, сети передачи данных, ИТ-персонал и так далее.
• Чем сложнее ИТ-инфраструктура, создающая полезность, тем более дорогостоящими будет обеспечение гарантии ценности ИТ-услуг.
• Гарантия складывается из защиты ИТ-услуги от четырёх различных классов угроз в эксплуатации. Зачастую механизмы защиты таковы, что внедрять и применять их следует заблаговременно, до наступления негативных событий.
• Заказчик требует от поставщика ИТ-услуг максимально рационального расходования средств на создание защищённой инфраструктуры.
• Рациональность защиты возможна только в случае взвешенного и целостного анализа всех угроз.
• Рациональность защиты для различных услуг и заказчиков будет достигаться на разных уровнях, в зависимости от приоритетов угроз для заказчика.

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

Таблица 1. Матрица управления рисками

Итак, для конкретного проекта разработки, или для ИТ-системы, или для ИТ-услуги (в зависимости от сущностей, которыми управляет ИТ-организация) можно представить подобную матрицу. По столбцам — этапы жизненного цикла такой сущности, в соответствии с хронологическим порядком управления рисками. По строкам — четыре составляющих гарантии. Что же разместим на пересечении?

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

• Ответственный (эту роль выполняют эксперты: ответственный за классификацию угроз — аналитик, ответственный за разработку контрмер — инженер и т.д.).
• Шаги и методика выполнения (ясно, что они будут очень различаться для безопасности и доступности). Множество различных методик управления рисками приведены в стандарте ISO 31010.
• Ресурсы (инструменты моделирования, расчётов, мониторинга и т.д.).
• Эскалация (то есть механизмы передачи решения «наверх» в случае конфликта ресурсов или отклонения от плановых значений).
• Итог: ощутимый результат выполнения данного шага управления рисками.

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

Таблица 2. Пример модели для шага матрицы управления рисками «Выявление угроз доступности»

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

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

Первым потребителем такой модели управления станут так называемые Владельцы продуктов\систем\услуг. Владельцы сущностей, в общем случае, представляют конкретный результат работы ИТ-организации, и наделены соответствующими полномочиями по использованию ресурсов ИТ для того, чтобы результат устраивал заказчика. Каждый владелец, сформировав подобную матрицу для своей услуги (продукта или системы), сможет быстро представить объём ресурсов и сроки, которые ему потребуются для стабильного предоставления результата своему заказчику.

Обычно владельцев услуг, как и самих услуг, может быть несколько. Поэтому на матрицу управления рисками накладывается и третье измерение, глубина: измерение конкретных результатов ИТ-организации, которые интересны заказчику.

За каждый из «слоёв» глубины будет отвечать владелец соответствующей услуги. В его же обязанности и будет входить координация усилий четырёх процессов управления гарантией услуг, он же и будет следить за управлением рисками в своей услуге. А между собой они будут делить соответствующие ресурсы. Конкуренция за ресурсы ИТ-организации и инвестиции в ИТ, таким образом, выносится на уровень владения результатами ИТ. Легко представить, что эта картина может помочь и приоритизации проектов в портфеле ИТ-организации.

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

Итог

Прикладная ценность этой табличной модели адресована, прежде всего, тем, кто изучает системы управления ИТ, но не представляет себе за «лесом» слов про процессную модель того, как процессы взаимодействуют между собой. В этом смысле, предложенная модель — это очередной «шкаф с полками», в котором можно аккуратно разместить всё те же вещи: ресурсы и способности ИТ-организации и её сотрудников.

Более того: матрица позволяет делать срезы в различных направлениях. Анализируя матрицу по строкам, можно увидеть, чем наполняется соответствующий процесс проектирования и за что отвечает владелец этого процесса (например, управления доступностью). Анализ по столбцам покажет, как именно выполняется практика управления рисками (и во сколько она, в конечном итоге, обходится заказчику). На разных уровнях глубины матрицы можно увидеть схему проектирования конкретной услуги, включая сопровождение механизмов защиты от угроз в эксплуатации.

В реальности, в практике ИТ-управленца, наполнение подобной матрицы может помочь:

• Визуально представить систему управления всем заинтересованным лицам.
• Наладить в ИТ-команде культуру управления рисками, которую пропагандирует стандарт ISO 31000, существенно не меняя суть работы сотрудников, и обеспечивая целостность подхода.
• Спланировать ИТ-проект внедрения ИТ-услуги (опираясь на заявленные временные нормативы и требуемые ресурсы)
• Совершенствовать ИТ-организацию, выявив на матрице пустые ячейки, то есть практики, которые в организации сейчас не реализуются (например, часто отсутствуют средства обеспечения непрерывности ИТ-персонала в чрезвычайной ситуации).
• Применять лучшие практические рекомендации и техники из сводов знаний системно, повышая качество ИТ-услуг для заказчика.

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

Сноски

1. К сожалению, авторы ITIL новейшей версии не сочли нужным давать определения понятий непрерывности (continuity) и безопасности (security) как таковых. Мы формулируем эти определения с помощью описаний соответствующих процессов.
2. В ITIL второй версии управление безопасностью было вообще вынесено в отдельную публикацию, за рамками основной сервисной модели. И сегодня тоже можно сказать, что сравнительный приоритет угроз информационной безопасности не окажется самым низким в этой модели хотя бы потому, что обеспечение ИБ требуется регулирующими органами.

Автор: Константин Нарыжный.