Рейтинг видов сбоев: что сильнее всего портит качество работы инфраструктуры

1. По каким признакам сравнивать сбои

Для отдельного инцидента в ITIL есть общепринятая пара признаков: влияние (сколько пользователей и услуг задето) и срочность (как быстро нужно восстановить). Из них складывается приоритет: за какой сбой браться первым. Чтобы сравнить целые виды сбоев за год, этого мало. Мы используем четыре вопроса. Это не отраслевой стандарт, а практичная схема, собранная из общепринятых показателей.

• Сколько часов простоя набралось. Частота, умноженная на среднюю длительность. Главный вопрос: он показывает, куда на самом деле уходят часы. Часто оказывается, что редкий вид сбоя отнимает больше времени, чем ежедневная мелочь.
• Насколько широко поражение. Масштаб влияния: сколько услуг и пользователей задевает один отказ. В практике SRE (надёжность сервисов, подход Google) это называют «радиусом поражения». Отказ одного сервера и отключение всей площадки могут длиться одинаково, но стоить несопоставимо.
• Можно ли предотвратить своими силами. Собственные изменения - полностью в ваших руках. Поставщик - частично и только через договор. Погода и стройка за забором - никак.
• Кто чинит. Если восстанавливает провайдер, ваше мастерство на длительность почти не влияет. Влияют две вещи: как быстро вы поняли, что причина у него, и что записано в договоре. В ITIL это зона управления поставщиками и соглашений об уровне услуг.

2. Рейтинг: двенадцать источников

Две оговорки.
Строки 11 и 12 стоят внизу по обычному вкладу в потерянное время, а не по опасности. Если ранжировать по худшему сценарию, безопасность и электропитание поднимутся в первую тройку. Это другой рейтинг и другая задача - план восстановления после катастрофы.
Строка 1 - не совсем вид сбоя. Она действует на все остальные строки: от неё зависит, сколько длится любой сбой. Поэтому она первая.

3. Почему организация важнее техники

Простой любого сбоя складывается из четырёх отрезков. Обнаружение: сколько сбой шёл незамеченным. Реакция: сколько искали, кто будет чинить, и когда он взялся. Диагностика: сколько искали причину. Восстановление: сколько чинили. В SRE и DevOps для этого есть общепринятые показатели - среднее время обнаружения (MTTD) и среднее время восстановления (MTTR). Техника влияет только на последний отрезок. Первые три - это мониторинг, дежурство, порядок передачи сбоя нужному специалисту и база известных ошибок, то есть организация.

Ситуация: в двух компаниях отказывает одинаковый узел одинакового оборудования. В первой простой длится 20 минут: оповещение пришло сразу, дежурный нашёл описание в базе известных ошибок и выполнил обходное решение по инструкции. Во второй - 4 часа: о сбое узнали от пользователей, дежурный полтора часа искал, кто отвечает за систему, а нужный инженер был в отпуске, и его телефон знал только начальник. Вывод: техника одна, разница в 12 раз - целиком организация.

Вторая и третья строки - собственные изменения и плановые работы - стоят высоко по другой причине. Это полностью управляемые источники: вы сами решаете, что менять, когда и с каким планом отката. Поэтому вложения сюда окупаются быстрее всего: не нужны ни закупки, ни переговоры с поставщиками. Чтобы измерить результат, в DevOps используют долю неудачных изменений: сколько изменений из ста привели к сбою или откату.

4. Плановые работы: самый недооценённый источник

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

Три способа, которыми плановые работы создают простой

• Окно не закрылось вовремя. Работы затянулись, отката не подготовили, и услуга вернулась не через два часа, а через шесть. Формально - «плановые работы», по сути - авария, которую никто не считает аварией.
• Последствие проявилось позже. Работы прошли успешно, а через два дня выяснилось, что перестало работать резервное копирование или отвалился второй канал. Связь с работами никто не установил, и сбой ушёл в статистику как самостоятельный.
• Короткие окна складываются. Каждое обслуживание короткое и согласованное, но их много, и за год набираются часы, сравнимые с авариями. Эту сумму никто не считает, потому что каждое окно рассматривают отдельно.

Лечится это не отказом от работ: отложенное обслуживание само порождает отказы. Лечится четырьмя правилами, и выполнение каждого можно проверить.

1. Считать плановые окна в общем балансе недоступности. Отдельной строкой, но в том же отчёте. Иначе накопленные окна не увидит никто.
2. Проверять резерв до начала работ, а не в процессе. Классическая авария: работы на основном узле, когда резервный уже неисправен, а об этом никто не знал.
3. Заранее записать, когда откатываться. В ITIL это план отката. Не «если что-то пойдёт не так», а «если к 04:00 услуга не поднялась - возвращаем как было». Решение, принятое ночью на месте, почти всегда звучит как «ещё немного попробуем».
4. Держать период повышенного внимания после работ. Сутки-двое любой сбой по умолчанию считается связанным с работами, пока не доказано обратное. В ITIL похожая практика называется ранней поддержкой после изменения. Только так ловятся последствия, проявившиеся позже.

5. Внешние поставщики: чужое время восстановления

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

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

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

6. Электропитание: редко, но целиком

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

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

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

7. Почему оборудование внизу списка

Это самая спорная строка: она противоречит и интуиции, и разговорам в курилке. Железо ломается, и регулярно. Но с тех пор как резервирование стало нормой - диски в массивах, сдвоенные блоки питания, серверы в кластерах, запасные каналы, - отказ одной детали обычно не останавливает услугу. Отказ происходит, простоя нет.

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

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

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

8. Как построить свой рейтинг

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

1. Взять журнал за год целиком. Не за квартал: на коротком отрезке сезонные пики и редкие тяжёлые сбои искажают картину.
2. Каждому сбою присвоить один источник из списка. Один, даже если причин было несколько: тот, без которого сбоя бы не было. Спорные случаи - в отдельную группу. Если она большая, это уже находка: причины записывают плохо.
3. Сложить не количество, а длительность. И отдельной строкой добавить плановые окна, иначе накопленные окна из раздела 4 останутся невидимыми.
4. Оценить масштаб влияния. Сколько услуг или пользователей в среднем задевает один сбой каждого источника. Эта колонка часто переставляет местами верхние строки.
5. Отделить то, на что вы влияете, от остального, и посмотреть на верх первой части. Это и есть план работ на следующий квартал: в нём только то, что вы можете изменить.

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