Что такое управление доступностью и как честно считать девятки

Зачем управление доступностью

Управление доступностью по ITIL — своду проверенных приёмов управления ИТ-услугамиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation — существует ради одного: чтобы услуги работали на согласованном уровне и чтобы этот уровень считали честно. Честный счёт — это согласованные критерии, один и тот же способ из месяца в месяц и знание цены каждой следующей девятки.

Пять слов, без которых дальше не обойтись

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

Критерии недоступности — записанная договорённость о том, что считать простоем: с какого момента медленная работа становится простоем, сколько пользователей должно пострадать, в какие часы услуга обязана работать. Хорошая практика — записать их в соглашение об уровне услуг 1.

Жизненно важная функция — часть услуги, без которой у потребителя не выходит главное дело 1. У почты это отправка, получение и архив писем, но не календарь.

Среднее время между сбоями (MTBF) — как часто услуга падает. Четыре недели между сбоями — это тринадцать падений в год 1.

Среднее время восстановления (MTRS) — как быстро услуга возвращается. Четыре часа — значит, после каждого сбоя пользователь ждёт в среднем четыре часа 1.

Как это выглядит в жизни. Пример — компания-разработчик на 60 человек. Она ведёт для сети фитнес-клубов мобильное приложение и личный кабинет: через них записываются на тренировки, оплачивают абонементы и получают уведомления. В соглашении с сетью записано: доступность личного кабинета — 99,5 %. Цифру когда-то назвал директор сети, а что за ней стоит, не считал никто.

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

Утром всё чисто: мониторинг зелёный — серверы, база и платёжный сервис работают, инцидентовИнцидентНезапланированное прерывание услуги или снижение её качества.ITIL 4, практическое руководство по управлению инцидентами о полном падении нет. В конце месяца Марина, менеджер по уровню услуг, приносит сети отчёт: 99,7 %, цель выполнена. Управляющий сетью кладёт рядом свою выписку: двенадцать вечеров за месяц посетители не могли записаться.

Обе стороны правы — и это самый неприятный поворот. Марина считала по падениям элементов и по инцидентам: элементы не падали, значит, простоя не было. Сеть считала вечера, когда посетители не могли записаться. Критериев недоступности в соглашении не было: ни порога, после которого медленная работа считается простоем, ни часов, ни доли посетителей. Проценты были — договора о том, что они меряют, не было.

Андрей разбирает журналы запросов за месяц: двенадцать вечеров, по сорок пять минут, страницы отдавались дольше тридцати секунд. Если эти вечера считать простоем, доступность месяца — 98,1 %, и цель провалена. Если не считать — 99,7 %, и цель выполнена. Разница не в работе кабинета, а в критериях: полпроцента повисло на договорённости, которой не было.

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

Марина с управляющим дописали к соглашению лист о критериях. Часы кабинета — с семи утра до одиннадцати вечера, вечер входит в них как пик. Простой — когда страница дольше пятнадцати секунд у каждого десятого посетителя. Ночные окна для релизов согласуются заранее, Света отправляет клубам уведомление, и в простой такие окна не идут. А минуты простоя считаются по журналам самой работы — по тому, что видит посетитель, а не по зелёным лампочкам элементов. Цифра осталась прежняя, 99,5 %, — но теперь у неё есть смысл.

Беда была не в медленной базе: то, что тормозит, лечится запасом мощности, и это соседняя практика CAPУправление мощностью и производительностью. Беда в том, что процент считался без договора о том, что он меряет, — и годился для отчёта, но не для разговора с заказчиком.

Цель практикиПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 ITIL формулирует коротко: услуги должны давать согласованный уровень доступности — такой, какой нужен заказчикам и пользователям 1. ГОСТ Р ИСО/МЭК 20000-1 — российский стандарт управления услугами — требует того же списком обязанностей: в назначенные сроки оценивать риски доступности, записывать требования и цели, наблюдать за услугой, сверять с целями и расследовать каждое нарушение 2.

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

Спор о девятках, с которого обычно начинается разговор о доступности, — спор не о том. 99,99 % или 99,999 % — вопрос цены; главным всегда был другой вопрос: что считать недоступностью. Кажется, считать тут нечего: сколько раз упала и как быстро поднялась. На деле цифра зависит от того, как устроена услуга, какие её части важны, что стороны договорились считать простоем и в какие часы услуга обязана работать 1. Отсюда главное правило практики: сначала критерии, потом проценты.

Главная трудность. Доступность нельзя докупить постфактум: правильный уровень закладывают при проектировании, добавлять его потом дороже, а услугу с репутацией ненадёжной потом почти невозможно реабилитировать 1. Вторая — у практики почти нет своих данных: минуты простоя приносят наблюдение и инциденты, требования — работа с заказчиком, деньги — финансовая практика. И третье, что стоит знать заранее: сбои будут у всех, включая самых дисциплинированных; восприятие заказчика определяет не сам сбой, а то, как поставщик на него отреагировал 1.

Когда практика работает

Три признака; видны они по соглашению и отчёту, а не по системе наблюдения.

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

Цифра собирается одним и тем же способом, и способ известен обеим сторонам. Как проверить: в отчёте названо, откуда взяты минуты простоя, и февральский отчёт считается тем же способом, что и январский.

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

Что входит и что рядом

Жизненно важные функции: почему одни части услуги важнее других

Не все части услуги одинаково важны. Жизненно важная функция — та, без которой у организации не выходит главное; остальные части могут такими и не быть 1. У почтовой службы жизненно важны отправка, получение и доступ к архиву писем, а доступ к календарю может и не быть жизненно важным 1.

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

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

Что на входе и что на выходе

Особенность практики — она работает раньше всех остальных. Решения на этапе замысла и проектирования определяют и уровни доступности, и саму возможность их измерить 1. После запуска остаётся наблюдать за тем, что спроектировали.

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

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

Что считать недоступностью

До подписания соглашения нужно решить пять вопросов 1:

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

В истории выше не решён ни один из пяти — поэтому один и тот же месяц даёт и 99,7, и 98,1 процента.

Есть тонкость посложнее: разным услугам доступность меряется по-разному 1.

• Услуга обслуживает бизнес-операцию, скажем одобрение кредита или отчётность, — смотрят, проходит ли сама операция.
• Услуга даёт доступ к ресурсу, например сети, печати или почте, — смотрят, доступен ли ресурс.
• Услуга состоит из выполнения обращений, как поддержка пользователей, — доступность к ней не подходит вовсе; меряют своевременность исполнения.

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

Как считают доступность

Общепринятая формула проста 1:

Доступность = (согласованное время работы − время простоя) ÷ согласованное время работы

За ней стоят два показателя, которые объясняют, из чего складывается результат 1:

«Свободный ITIL» раскладывает доступность на пять свойств: надёжность, сопровождаемость, обслуживаемость, производительность и безопасность. Формулу объясняют первые три, и два из них легко перепутать 6:

• надёжность — как долго услуга работает без сбоя;
• сопровождаемость — как быстро чиним мы сами;
• обслуживаемость — как быстро чинит внешний поставщик.

Одну и ту же доступность можно получить двумя способами: редкими сбоями или быстрым восстановлением; услуги высокой доступности проектируют как баланс того и другого 1.

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

• чем дольше суммарный простой за период, тем больше потери;
• чем длиннее отдельный сбой, тем выше потери — и пока он тянется, они прибавляются всё быстрее;
• чем чаще сбои, тем дороже каждый возврат людей к работе.

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

Откуда берут минуты простоя

Способов три, и у каждого своя слабость 1.

Записи об инцидентах. Дают отметки времени обнаружения и решения — между ними, казалось бы, и лежит простой. Слабости: инцидент заводят не в момент падения и закрывают не в момент восстановления; не всякий инцидент — про доступность; пересекающиеся инциденты надо связывать, иначе простой посчитается дважды. Небольшому провайдеру способ подходит, крупному — уже нет: услуг и инцидентов слишком много 1.

Наблюдение за инфраструктурой. Даёт доступность элементов, а не услуги. Сбой части не всегда роняет услугу, а недоступность услуги случается и без падения элементов — например, от медленной работы 1. Это способ Марины из истории: лампочки зелёные, а заказчик месяц не может записать посетителя.

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

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

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

Как это работает

Процессов два 1.

Установить контроль доступности — работа до запуска: собрать требования, согласовать их, определить, как измерять, спроектировать показатели и отчёты 1. Главная сложность здесь: требования у заказчика обычно есть, но сказаны словами, которые нельзя посчитать. Перевести их в проверяемые критерии — и есть работа этого шага.

Анализировать и улучшать доступность — работа после: считать, сверять с целями, разбирать нарушения, предлагать изменения 1.

Шесть шагов ниже — наша раскладка этих двух процессов по порядку.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение работа с людьми и сторонами

У анализа два уровня. На уровне компонентов и инфраструктуры доступность разбирают менеджер по доступности, администраторы и инженеры; на уровне услуги — он же вместе с владельцем услуги и менеджером по уровню услуг 1. Истории выше нужен был именно уровень услуги: цифры не сходились не из-за железа.

Отдельно стоит трендовый анализ: накопленные данные смотрят наискось, чтобы поймать изъяны, которые ещё не дали ни одного инцидента 1. Вечерние тормоза месяц не были инцидентами — и поймать их можно было только трендом.

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

Риски доступности и контрмеры

Проектирование и измерение — половина практики. Вторая половина — обрабатывать риски: находить и устранять единые точки отказа там, где это оправдано ценой 1.

Контрмеры у ITIL разложены по четырём измерениям 1:

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

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

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

Что с чем путают

Четыре пары, которые смешивают чаще всего. Разница в каждой не филологическая: от неё зависит, что считать простоем и кто за него отвечает.

Доступность и непрерывность. Граница тонкая: обе практики работают над устойчивостью к отказам, и некоторые организации их не разделяют 1. Руководство разводит их так 1:

По строке про риски и читается граница: вечерние тормоза — доступность, пожар в дата-центре — непрерывность. ГОСТ Р ИСО/МЭК 20000-1 держит эти практики соседними пунктами, FitSM объединяет в один процесс 2 3.

Доступность и надёжность. Надёжность — про частоту сбоев, доступность — про итог с учётом скорости восстановления 6. Услуга, падающая раз в неделю на пять минут, надёжнее той, что падает раз в год на четыре часа, — а доступность у них почти одинаковая.

Доступность и производительность. Медленная услуга формально доступна. Именно поэтому заранее договариваются о пороге, после которого замедление считается простоем 1. Вечер кабинета — ровно этот случай: не упал, но не работает.

Доступность услуги и доступность оборудования. Сервер работает, услуга не работает — обычная ситуация, если между ними стоят очередь, сеть или интеграция.

Кто участвует

Отдельной организационной структуры под практику обычно нет — доступностью занимаются другие практики и функции 1. MOF относит эту работу к ответственности архитектуры и собирает под одной крышей пять планов: конфиденциальности, целостности, доступности, непрерывности и мощности 4. Логика та же: все пять решаются на этапе замысла, а не в эксплуатации.

Как измерять

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

Для компании из примера первая строка отрезвляющая: из всех услуг компании критерии записаны у одной — и то после осеннего спора.

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

Почему одного процента мало, показывает Брукс 7. За теми же четырьмя девятками может стоять один часовой простой — а может 365 обрывов по девять секунд каждый. Для пользователя это две разные жизни: в первом случае он потерял час один раз, во втором его выбивало из работы каждый рабочий день в году.

Минуты простоя не однородны — это второе, что стоит мерить. Брукс раскладывает простой на пять отрезков 7.

Время устранения неполадки — сумма четырёх последних. Обнаружение в неё не входит и меряется отдельно 7.

У каждого отрезка своя пара чисел. Брукс задаёт не цель, а две границы: целевое значение и опасное — то, при котором пора вмешиваться. Для обнаружения это 1 минута против 4, для реагирования — 5 против 10, для ремонта — 10 против 20, для восстановления и возобновления — по 2 против 5 7. Пороги сходятся между собой: 10 + 20 + 5 + 5 дают ровно те 40 минут, которые стоят опасным значением у всего устранения неполадки.

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

Сами числа к вам не переносятся: Брукс приводит их образцом для настройки под свою модель работы. Переносится привычка держать у показателя обе границы: цель говорит, куда идти; порог — когда переставать наблюдать и начинать действовать.

Раскладка нужна не ради отчёта, а чтобы понимать, куда вкладываться: долгое обнаружение лечится наблюдением, долгий ремонт — запасом компонентов, долгое возобновление — избыточностью. У Брукса есть и три показателя, которых нет в таблице выше. Простой по вине поставщика считают отдельно от своего. Простой в критический период — не так, как обычный: для финансовых систем это могут быть 27–29 числа месяца, для почты — часы с восьми до десяти утра. Третий показывает, сколько элементов ломается повторно 7.

Один показатель идёт против всех остальных. У среднего времени между системными неполадками (MTBSI) опасное значение 150 минут, а целевое — 200 7. Это не описка: у времени восстановления «меньше» значит «лучше», у промежутка между сбоями — наоборот. Панель, где все показатели покрашены по одному правилу «растёт — плохо», на этом показателе врёт, и врёт незаметно.

Зрелость управления доступностью

✕

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

Где ломается чаще всего

Шесть мест.

Критериев нет, а проценты есть. Никто не договорился, что считать простоем, и каждая сторона считает по-своему. Разговор об отчёте превращается в спор о методике — как в истории выше.

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

Меряют железо, а не услугу. Как проверить: есть отчёт, где все элементы зелёные, а заказчик за тот же период заявлял простой.

Обещали девятки, не спросив цену. Чем выше обещание, тем дороже устойчивость, которая его держит 1. Каждая следующая девятка дороже предыдущей, и решают о ней вместе с деньгами, а не отдельно.

Нарушения не разбирают. Стандарт требует расследовать нарушения доступности и принимать действия 2, но отчёт закрывается фразой «цель не достигнута».

Забыли про часы обслуживания. Плановые работы попадают в простой или, наоборот, исчезают из него — в зависимости от того, кто считает. Ночное окно без согласования — тоже простой, только никем не посчитанный.

Что говорят своды

Своды знаний и стандарты, которые описывают эту практику:

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL описывает практику подробнее всех: определение доступности, жизненно важные функции, критерии, формула, три источника данных, два процесса, контрмеры по четырём измерениям 1.

ГОСТ Р ИСО/МЭК 20000-1 формулирует минимум обязанностей: оценка рисков через интервалы, документированные требования и цели, мониторинг, сравнение с целями, расследование нарушений 2.

FitSM объединяет доступность и непрерывность в один процесс из четырёх требований: выявлять требования, оценивать риски, принимать меры, наблюдать за доступностью услуг и их частей 3.

MOF ставит доступность в ряд с конфиденциальностью, целостностью, непрерывностью и мощностью — как один из пяти планов надёжности, создаваемых при планировании 4.

COBIT держит доступность и мощность одной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives 5.

Расхождение одно, и оно про соседство: доступность объединяют то с непрерывностью, то с мощностью. Смысл от этого не меняется — меняется то, с кем практика делит людей и бюджет.

Где описано

Что почитать дальше

Три соседние практики, без которых доступность не считается: SLMУправление уровнем услуг — где записываются критерии и цели, EVNМониторинг и управление событиями — откуда берутся минуты простоя, CONУправление непрерывностью услуг — что делать, когда простой перестаёт быть обычным.