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

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

Доступность — это способность услугиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation или отдельного элемента конфигурацииЭлемент конфигурацииЛюбой объект, которым надо управлять, чтобы предоставлять услугу: сервер, приложение, лицензия, документ.ITIL делать то, о чём договорились, тогда, когда это нужно 1. ПрактикаПрактикаНабор ресурсов организации для выполнения работы определённого типа.ITIL 4 существует ради того, чтобы обещанная доступность не осталась словами: её считают, подтверждают данными и знают, во сколько она обходится.

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

Разговор о доступности почти всегда начинается со спора о девятках. Её меряют в процентах, вот и спорят про 99,99%, 99,999% или ещё выше. А спорить нужно о другом: что считать недоступностью и сколько мы готовы платить за следующую девятку. Первый вопрос главный. Кажется, будто считать тут нечего: сколько раз упала и как быстро поднялась. На деле цифра зависит от того, как устроена услуга, какие её части важны, что стороны договорились считать недоступностью и в какие часы услуга обязана работать 1.

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

Отсюда главное правило практики: сначала договариваются о критериях, потом считают проценты.

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

Работает практика или нет, видно не по системе наблюдения, а по двум документам: соглашению об уровне услуг (SLAСоглашение об уровне услугЗаписанная договорённость поставщика и заказчика: что даёт услуга, когда доступна и как быстро её восстановят.ITIL 4: практическое руководство Service Level Management и книга ITIL Foundation, 5.2.15.1; ГОСТ Р ИСО/МЭК 20000-1-2021, пункты 3.2.16, 3.2.20, 3.2.21, 7.5.4, 8.3.2–8.3.4; FitSM-0, FitSM-1 (PR2), FitSM-2 (PR2), шаблон и образец SLA из FitSM-4; MOF 4.0, глоссарий; itSMF, «Введение в ИТ Сервис-менеджмент», 2003; Ami Nahari, «Secrets of Service Level Management», TSO, 2013; Молоткова, Сахаров, «Качество услуг ИТ-аутсорсинга», 2008; «Аутсорсинг в стратегии современного бизнеса», 2019; альманах itSMF России, 2015; «Свободный ITIL» Елхимова; Брукс, «Метрики для управления ИТ-услугами») и отчёту о доступности. Три признака.

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

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

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

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

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

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

Например, у почтовой службы жизненно важны отправка, получение и доступ к архиву писем, а вот доступ к календарю таковым может и не быть 1.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Доступность и непрерывность. Непрерывность — работа при катастрофе, у неё свои планы, критерии и цели восстановления 2. ГОСТ Р ИСО/МЭК 20000-1 держит их соседними пунктами, FitSM объединяет в один процесс 3.

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

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

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

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

Как измерять

Правило отбора: показатели должны отражать последствия для бизнеса, а не техническую доступность частей 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Управление непрерывностью услуг — что делать, когда простой перестаёт быть обычным.