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

1. Четыре оси сравнения

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

• Суммарное потерянное время. Частота, умноженная на длительность. Главная ось: она отвечает на вопрос, где вообще лежат ваши часы простоя. Именно здесь обычно обнаруживается, что редкий вид сбоя даёт больше потерь, чем ежедневная мелочь.
• Заразность. Сколько услуг тянет за собой один отказ. Сбой, затрагивающий одну систему, и сбой, останавливающий площадку целиком, могут длиться одинаково и стоить несопоставимо.
• Управляемость. Можете ли вы уменьшить вероятность своими силами. Собственные изменения управляемы полностью, погода - никак, поставщик - частично и только договором.
• Кто владеет временем восстановления. Ось, о которой вспоминают в момент аварии. Если чинит подрядчик или провайдер, ваше умение чинить не имеет значения - значение имеет только то, как быстро вы к нему пробьётесь и что записано в договоре.

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

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

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

3. Верхняя часть: почему процесс выше техники

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

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

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

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

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

Три способа, которыми плановые работы портят качество

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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