Как уже было сказано в лекции №6 сервисные практики - практики, разработанные в области управления сервисами и индустрией ITSM. То есть это практики, пришедшие из ИТ-области.
Доступность - способность ИТ-сервиса или другой конфигурационной единицы предоставлять согласованную функцию тогда, когда это необходимо.
Целью практики управления доступностью является обеспечение согласованного уровня доступности для удовлетворения потребностей заказчиков и пользователей.
Деятельность в рамках практики:
Почему важна доступность и зачем ее измерять? Очень часто бизнес несет потери в результате простоя сервисов. Сбой приложения в период пиковой нагрузки может привести к многомиллионным потерям. Достаточно представить, что в «Черную пятницу» у Aliexpress не будет работать оплата по картам Visa.
Потери от простоя потребителя сервисов (и его бизнеса) могут зависеть от трех составляющих (см. рисунок 9.1):
Доступность(%)=(Согласованное время предоставления сервиса-Время простоя)/Согласованное время предоставления сервиса*100
Среднее время восстановления сервиса (Mean Time to Restore Service или MTRS) - среднее время, требуемое для восстановления конфигурационной единицы или сервиса после сбоя. MTRS измеряется от момента сбоя конфигурационной единицы или сервиса до момента полного восстановления и возврата к нормальной функциональности. Простыми словами это то, как быстро сервис восстанавливает нормальную работу после сбоя. При этом здесь следует обратить внимание на то, что это среднее время. Например, было 3 недоступности сервиса в течение двух, трех и четырех часов. MTRS будет равен 3 часам.
Среднее время между сбоями (Mean Time Between Failures или MTBF) - это среднее время, которое конфигурационная единица или сервис может выполнять свои функции без перерыва. Измеряется от начала работы до момента следующего сбоя. Например, сервис с MTBF 4 недели недоступен 13 раз в год (другими словами, каждые 4 недели он «падает»).
Интересно, что в ITIL4 Foundation даже не приводят упоминание классической формулы расчета доступности, упоминая только MTRS и MTBF. Тем не менее именно по ней многие поставщики сервисов стремятся к заветным цифрам в 99,999999(9) % в своих соглашениях с заказчиками.
Разберемся, почему эта формула не всегда отражает реальные потребности заказчиков в поддержке бизнеса со стороны ИТ.
Например, доступность определена как 99,9%. Выглядит очень красиво. Но 0,1% в год равен почти 9 часам. А в месяц - это почти 45 минут. А в неделю - чуть более 10 минут.
Более того, математически, чем выше период, за который рассчитывается доступность, тем выше получается процент доступности. Но даже это не столь важно, ведь в соглашении об уровне сервисов обычно указывается период расчета показателя. Важно то, что формула не учитывает влияния на бизнес. Что если эти 9 часов за год произошли за один сбой? Или сервис становился недоступен по две минуты 15 раз в день? Именно поэтому ITIL вводит показатели MTRS и MTBF. Однако на практике большинство организаций рассчитывают уровень доступности по классической формуле, так как формулирование требований в виде MTRS и MTBF требует определенной зрелости и понимания технических аспектов со стороны заказчика.
При этом ITIL говорит, что поставщику сервисов необходимо идти еще дальше в понимании доступности своих сервисов для потребителей и искать ответы на следующие вопросы:
Интересно упоминание плохой производительности («зависаний») в данном контексте. Допустим, в соглашении стоят заветные 99, (9)%, однако сервис работает крайне медленно. Формально это не сбой, но работать трудно и фактически сервис становится бесполезным (или малополезным). Возможно, этого заказчика устроила бы цифра 90% в соглашении об уровне сервиса и обязательство поставщика сервиса устранить медленную производительность.
Вот какие еще измерения, связанные с доступностью, предлагает ITIL Foundation[1]:
В организациях чаще всего нет отдельного подразделения, занимающегося доступностью. Мероприятия по управлению доступностью могут быть рассредоточены по различной деятельности: управление непрерывностью ИТ-сервисов, управление мощностями, управление рисками и т.д. Однако практика требует постоянного тестирования механизмов аварийного переключения и восстановления, а также регулярного мониторинга и отслеживания показателей.
На рисунке 9.2 показан вклад практики управления доступностью в цепочку создания ценности сервиса[1].
Наиболее темная область на рисунке говорит о значимости практики в контексте планирования. Действительно, аспекты управления доступностью должны учитываться при принятии решений в отношении портфеля сервисов, направления развития сервисов и практик.
При реализации любых инициатив необходимо контролировать отсутствие негативного влияния на показатели доступности.
Требования по доступности новых и изменяемых сервисов появляются и отслеживаются в рамках взаимодействия.
В рамках проектирования сервисов необходимо учитывать требования по доступности, а в рамках преобразования - проводить все необходимые тестирования.
Доступность должна учитываться при построении или получении компонентов у третьих сторон.
В рамках предоставления и поддержки происходит регулярный мониторинг показателей доступности и реагирование на события, которые могут помешать достигнуть согласованного уровня доступности (то есть устранение сбоев в работе сервисов).
Целью данной практики является анализ бизнеса или его составляющей, выявление потребностей и рекомендация решений по их удовлетворению и/или устранению какой-то проблемы, что в свою очередь приводит к созданию ценности для заинтересованных сторон. Бизнес-анализ позволяет организации выражать свои потребности на понятном языке, обосновывать необходимость изменения, разрабатывать и описывать решения, которые позволяют создавать ценность в соответствии с целями организации[1].
Рассмотрим для сравнения определение из «BABOK Guide 2.0» («International Institute of Business Analysis» (www.iiba.org)):
Бизнес-анализ - это набор задач и техник, используемых как связующее между участниками и заинтересованными лицами для понимания структуры, правил и операций в рамках организации, так и для рекомендации решений, позволяющих данной организации достичь ее целей[2].
Бизнес-анализом обычно занимаются бизнес-аналитики (BAs).
Если говорить об ИТ-области, то:
Бизнес-аналитик - это специалист, который анализирует потребности и проблемы бизнеса, консультируется с пользователями и заинтересованными лицами для нахождения возможностей улучшить отдачу от бизнеса с помощью ИТ, а также задает, управляет и отслеживает указанные требования в бизнес-процессах.
Основная задача бизнес-аналитика - понять, что действительно нужно бизнесу и предложить решение. Как говорили в IBM: «Мы продаем нашим заказчикам не то, что они хотят, а то, что им нужно».
Ключевая деятельность в рамках бизнес-анализа:
Бизнес-требования могут быть двух типов: ориентированные на полезность и ориентированные на гарантию.
Бизнес-требования, ориентированные на гарантию - требования, не связанные с функциональностью (например, требования по доступности или производительности), которые, как правило, поступают от ключевых заинтересованных сторон и из других практик. ITIL4 рекомендует организациям вести набор заранее определенных критериев приемки гарантии, который можно использовать в рамках проектной деятельности и деятельности по разработке.
Критерии приемки - лист минимальных требований, которым должен удовлетворять сервис или компонент, чтобы быть приемлемым для ключевых заинтересованных сторон.
Бизнес-требования, ориентированные на полезность - функциональные требования, определенные заказчиком и уникальные для конкретного продукта.
Бизнес-анализ требует не только критического мышления и способности к оценке инициатив, но также умения слышать, взаимодействовать, документировать сценарии использования, выполнять анализ данных и моделирование.
Сценарии использования (use case) - техника, использующая реалистичные практические сценарии для определения функциональных требований и разработки тестов.
Моделирование - деятельность по созданию, ведению и использованию моделей.
В бизнес-анализе крайне важен системный подход, который предполагает глубокое погружение, взаимодействие со всеми участниками и ознакомление с имеющейся документацией к сервису/системе/процессу/продукту или любому другому объекту исследования.
На рисунке 9.3 показан вклад практики бизнес-анализа в цепочку создания ценности сервиса[1].
Практика способствует принятию стратегических решений.
Улучшения на всех уровнях выигрывает от информации, предоставляемой бизнес-анализом.
В рамках этой деятельности бизнес-анализ собирает требования заинтересованных сторон.
Сбор, приоритизация, анализ точных требований, осуществляемые в рамках бизнес-анализа, помогут убедиться в качестве проектируемого решения.
Навыки бизнес-анализа являются неотъемлемой частью определения согласованного решения.
Бизнес-анализ может собирать данные по текущему предоставлению и поддержке сервисов и использовать их для разработки изменений и поиска возможностей по улучшению.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.