Как мы построили прототип модели прогнозирования выхода жестких дисков из строя
Неожиданный выход HDD из строя — неприятная для сервера ситуация. Выяснение причин и замена жесткого диска (не всегда это можно сделать «горячим» способом) почти всегда означают даунтайм работы системы. При этом подсказок о своем состоянии HDD не дает, специалисты могут ориентироваться только на время эксплуатации диска и свой опыт.
Инженеры по разработке ПО искусственного интеллекта в YADRO Владислав Маркин и Андрей Соколов решили применить возможности ИИ в прогнозировании проблем с HDD. Задача не тривиальная: модели нужны данные для обучения и тренировки, а где их найти — отдельный вопрос.
Что удалось сделать инженерам, что стало основой прототипа прогнозной модели и какие результаты она показала в применении для дисков в серверах YADRO, Владислав рассказал в статье.
- на каких данных можно натренировать прогнозную модель для HDD
- что стало прототипом модели инженеров YADRO
- какие недостатки существующей модели исправили
- каковы результаты тестов новой модели для прогнозирования сбоев жестких дисков
На основе каких данных можно прогнозировать неисправность HDD
Для жестких дисков существует довольно известный способ диагностики его состояния — S.M.A.R.T.-тестирование (от англ. self-monitoring, analysis and reporting technology — технология самоконтроля, анализа и отчетности). В результате теста мы получаем диагностическую информацию в виде набора числовых атрибутов. К ним относятся счетчики ошибок, показания датчиков температуры и другие.
Если в каком-то значении есть отклонение от нормы, оно будет подсвечено красным. Возможно, именно здесь кроется проблема нештатной работы HDD.
Всего существует порядка 255 идентификаторов, среди которых наработка часов, частота возникновения ошибок при позиционировании блока магнитных головок, количество повторных запусков шпинделя при неудачной первой попытке, количество неисправных секторов и многие другие. У разных моделей дисков может быть разное количество и список атрибутов — по сути, его определяет производитель: какую именно информацию о диске он считает нужным представить. В среднем диск сообщает до 20 атрибутов.
Где взять набор SMART-данных
Американская компания по облачному хранению и резервному копированию данных Backblaze c 2013 года публикует SMART-данные, которые собирает в собственных дата-центрах. По сути, на данный момент это самый известный публичный датасет с такими данными. За 2020 и 2023 годы есть SMART-данные, собранные с 85 моделей дисков, подключаемых по интерфейсу SATA. По 14 из этих моделей собирались данные по более 10 000 штучных их представителей. То есть данных на самом деле немало.
И самое главное — этот датасет размечен. Есть столбец Failure, и единица в этом столбце означает последний день жизни диска.
Кроме этого датасета, мы нашли результаты соревнований PAKDD2020 Alibaba AI Ops Competition от компании Alibaba Cloud. Перед участниками стояла, по сути, аналогичная задача. Им нужно было построить ML-модель, которая формировала бы прогнозы вида «выйдет ли диск из строя в течение 30 дней или нет». Прогноз нужно было формировать раз в сутки для каждого диска.
Используемый участниками датасет похож на данные от BackBlaze — те же записи со SMART-атрибутами. Снимки SMART-данных делались с каждого диска раз в сутки, а данные представлены по двум моделям дисков. По условиям конкурса, к сожалению, информация о производителе и моделях дисков была закрыта.
Датасет, используемый в конкурсе, также был размечен, но информацию об отказах представляли в отдельном файле в виде failure tickets. Там был идентификатор диска и время его отказа. Мы нашли код решения участников, которые заняли третье место, — вот их Jupyter Notebook. Его мы взяли за основу нашего прототипа. Также организаторы соревнования предложили метрики для оценки качества ML-моделей, мы переняли эти критерии, уточнив их.
Метрики качества ML-модели для прогнозирования выхода из строя HDD
Метрики мы назвали k-window в честь одного из параметров, о котором я расскажу ниже. В целом, это «классические» Precision (точность), Recall (полнота) и F1, но с некоторыми оговорками.
Precision — это точность, доля истинно позитивных прогнозов среди всех положительных прогнозов модели. В нашем случае прогнозом считается ответ на вопрос, выйдет ли конкретный диск из строя в ближайшее время или нет. Так, Precision в 0,7 будет означать следующее: если модель спрогнозировала выход из строя 100 дисков, то на самом деле только 70 из них действительно выйдут из строя в ближайшее время.
Precision=\frac{TP}{(TP+FP)}
Recall — это полнота, доля реальных отказов, которые модель смогла спрогнозировать. Допустим, на тестовых данных известно, что откажут 100 дисков. Recall в 0,4 будет означать, что на самом деле модель смогла спрогнозировать только 40 из сотни отказов. Остальные либо спрогнозировала несвоевременно, либо вообще пропустила, не подав никакой индикации.
Recall=\frac{TP}{(All\quad Ground\quad Truth\quad Positive)}
F1 — это гармоническое среднее между Precision и Recall.
F1=2\ast \frac{Precision\ast Recall}{Precision+Recall}
Параметр k (количество дней или часов) определяет ширину временного окна с момента вызова модели, в который должно попасть событие реального отказа. Чтобы лучше понять значение этого параметра, посмотрим на картинку ниже. На ней изображено, как при подсчете метрик интерпретируются прогнозы модели для одного диска.
Какие у нас могут быть сценарии прогнозов
Рассмотрим, опираясь на таймлайн, — начнем снизу.
Своевременно спрогнозировали выход диска из строя. В некий момент времени (значение Т) модель делает позитивный прогноз. До этого позитивных прогнозов она не делала, это First positive prediction. В реальности, а не на картинке это было бы некой красной лампочкой на дашборде мониторинга у сисадмина или алертом в системе. То, что подразумевает: нужно среагировать на потенциальный выход из строя жесткого диска и предпринять какие-то действия.
От этого момента времени T в будущее мы откладываем некий отрезок длины k (T + k) и смотрим, попало ли в него событие реального отказа. На изображении это зеленая область. True Positive прогноз в нее попал, а значит, мы своевременно спрогнозировали выход из строя.
Слишком поздно прогнозировали выход из строя. У этих метрик есть еще один параметр, который называется Best Before. Я не говорил про него ранее, потому что в моей задаче этот параметр пока не используется и равен нулю. Но в общем случае Best Before определяет зазор, который определяет некое минимальное время, когда прогноз еще будет актуальным.
Например, для пользователя модели прогноз, сделанный за сутки до отказа, — это слишком поздно — не успеет среагировать. В таком случае параметр Best Before должен быть больше — допустим, 48 часов.
Слишком рано спрогнозировали выход из строя. Опять-таки, модель делает первый позитивный прогноз с момента времени T, а событие реального отказа вывалилось за правую границу Т+k. Это тоже False Positive прогноз.
Ложно положительный прогноз, или False Positive. Модель сделала позитивный прогноз, но на тестовых данных реального отказа не было. То есть диск здоров, а мы фактически поставили на нем крест.
Ложно отрицательный прогноз, или False Negative. Тут примерно то же самое, что в предыдущем варианте, только в обратную сторону. Модель не сделала ни одного позитивного прогноза, но нам достоверно известно, что диск выйдет из строя и когда это произойдет.
Unknown Positive. Этот сценарий подразумевает случаи, когда модель сделала позитивный прогноз, но тестовые данные заканчиваются раньше, чем наступает правая граница окна T+k. То есть мы не можем однозначно сказать, что, например, прогноз был сделан слишком рано, так как у нас нет информации о времени реального отказа. Следовательно, нам не отнести это позитивное срабатывание ни к False Positive (неизвестно, что этот диск еще проживет, допустим, минимум k дней), ни к True Positive (нет информации о реальном времени отказа диска).
Про метрики поговорили. Теперь о том, какие их значения достижимы.
Наш прототип на основе существующей модели
В таблице ниже подсвечены результаты команды участников полуфинала PAKDD2020, занявшей третье место.
Ранее мы уже писали, что разработанная ими модель легла в основу нашего прототипа. Поэтому мы ожидали, что получим максимально близкие к этим цифрам результаты. Спойлер: в реальности вышло иначе. Тем не менее, это некий baseline, от которого мы отталкивались. В терминах ранее описанных k-window метрик k равно 30 дням, а значение Best Before равно нулю.
Чем наш прототип отличается от модели китайской команды
Мы заметили, что модель, разработанная бронзовыми призерами PAKDD2020, обладает рядом недостатков:
- Она тренировалась и тестировалась на дисках с одними и теми же серийными номерами. Иными словами, модель тестировалась на тех же дисках, на которых обучалась.
- Модель не универсальна с точки зрения интервала времени, на котором она будет применяться. Модель тренировалась на данных за текущий месяц и использовалась на данных в пределах следующего месяца.
А значит, потенциальному пользователю модели китайских разработчиков — например, какой-нибудь компании — пришлось бы создавать систему регулярного сбора SMART-данных и данных о событиях отказов. Это существенно снижает возможность широкого использования модели.
Мы задались целью понять, можно ли для фиксированной модели жесткого диска построить универсальную модель, прогнозирующую выход HDD из строя. И которую можно было бы применять к ранее не виданным дискам в произвольные моменты времени. При этом не потерять в качестве прогнозирования.
Как выглядит наш прототип
В нашем прототипе модели прогнозирования проблем HDD мы использовали алгоритм LightGBM classifier, так как это задача бинарной классификации. Это алгоритм из семейства GBDT (Gradient-Boosted Decision Trees), которое является золотым стандартом алгоритмов ML для обработки табличных данных (наряду с аналогичными XGBoost, CatBoost и другими).
На вход мы подавали два вида признаков:
- сырые значения SMART-атрибутов,
- «производные» признаки — абсолютные разницы в значениях SMART-атрибута на текущий момент и сутки назад, сглаженные экспоненциально взвешенным скользящим средним на окне в 7 дней.
Целевая метка (target label) при обучении классификатора называлась failure_in_{backtrace_days}d. Backtrace составлял 7 дней. Буквально эта метка означала, что ожидается отказ диска в ближайшие семь дней, но в датафрейме это выглядело как единица на последней неделе жизни HDD.
Один из важных моментов, который мы позаимствовали у прототипа модели, — это функция потерь focal loss, которая используется при обучении. В основном она применяется в задаче обнаружения объектов на изображениях, но неплохо себя показывает и в задаче классификации, когда есть сильный дисбаланс классов. А в нашей задаче он присутствует: процент отказавших дисков, как правило, составляет 1% или меньше.
Алгоритм LightGBM на выходе выдает вероятность принадлежности к классу. В нашем случае это означает вероятность выхода из строя в ближайшем будущем. Логика формирования предсказанной метки у нас простая: если вероятность отказа выше определенного порога, то диску присваивается метка 1 (он выйдет из строя в ближайшее время). В противном случае присваивается метка 0 — диск здоров.
Полученная LightGBM-модель заворачивается в адаптер, формирующий «производные» признаки, которые мы упоминали ранее, перед вызовом predict_proba (). Благодаря этому адаптеру также не нужно самостоятельно считать эти признаки.
Все это соответствует нашей задаче, что по короткой истории SMART-данных получится сформировать прогноз. Так, в текущей имплементации адаптера нужно передать семь последовательных снимков состояния, которые были сделаны с интервалом в 24 часа, — модель сделает прогноз вида «выйдет диск из строя или нет в ближайшем будущем».
Результаты проверки модели, которые мы получили
Для экспериментов мы отобрали ряд моделей дисков, которые близки к тем, что используются в серверах YADRO. Точных совпадений в датасете BackBlaze найти не удалось, поэтому мы ориентировались на схожие характеристики — например, на скорость вращения шпинделя. Также нам было важно, чтобы для выбранных дисков было достаточно данных для обучения. Достаточно — это хотя бы несколько сотен событий отказов.
В итоге в нашем эксперименте участвовали пять моделей дисков от Seagate: ST8000NM0055, ST12000NM0008, ST14000NM001G, ST16000NM001G, ST4000DM000.
В таблице перечислены SMART-атрибуты, которые мы использовали для формирования прогноза. Половина из них — счетчики ошибок или релоцированных секторов.
Результаты прогнозов получились довольно близкими к установленному нами baseline — цифрам команды, занявшей третье место в конкурсе от Alibaba. Напомним, что это F1 — 40.47, Precision — 52.76, Recall — 32.82.
Для еще большей иллюстративности в последней строчке мы указали показатели команды-победителя PAKDD2020.
Видно, что нам удалось достигнуть достаточно высокой точности с моделью ST14000. Но тот же Recall не превышает 50%, то есть как минимум половину отказов отлавливать не удается.
Также по каждой модели HDD мы получили Test Report в виде графиков. Давайте посмотрим, какие данные мы получили для жесткого диска Seagate Exos X16 (модель ST14000NM001G).
Эти два графика показывают, какие бы значения метрик Precision, Recall и F1 были при другом значении k. Например, мне — потенциальному пользователю модели — нужно понять, какие метрики ожидать, если я хочу видеть позитивный прогноз не раньше чем за 10 дней. На графике справа — абсолютные значения из Confusion Matrix, то есть сколько всего True Positive, False Positive, False Negatives и Unknown Positives было.
На этих графиках, опять же, выбранные нами метрики, но при зафиксированном значении k. Здесь меняется порог вероятности, по которому мы принимаем решение, делать ли прогноз, что диск выйдет из строя в ближайшем будущем, или нет. Это позволяет понять, в какую сторону этот порог можно скорректировать. Например, в данном случае можно увеличить Precision за счет более высокого значения порога вероятности.
Эта гистограмма — так называемая гистограмма времени доживания. Здесь показано распределение времени между первым позитивным прогнозом модели и реальным выходом диска из строя. Опять-таки, конкретно для выбранной модели жесткого диска.
Для ST14000 можно сказать, что после первого позитивного прогноза для половины дисков выход из строя произойдет в течение 8 дней. Для других моделей дисков случались единичные выбросы в районе 100−200 дней. Это говорит о том, что некоторые признаки выхода из строя проявляются в SMART-данных достаточно рано, но, тем не менее, не означают скорый выход из строя.
На этом графике изображено медианное время доживания диска в зависимости от порога принятия решения. Ранее мы приводили пример, когда можно увеличить значение порога и тем самым выиграть Precision, пожертвовав метрикой Recall. На медианном времени доживания это отобразится линейным уменьшением.
При текущем пороге можно рассчитывать, что до отказа будет оставаться примерно одна неделя. А при уменьшении порога вероятности до 0.6 получим примерно 20 дней на то, чтобы среагировать, но пожертвуем точностью прогноза.
Выводы
Нам удалось построить прототип модели, которая не зависит от момента времени исполнения и конкретного экземпляра дисков. В нашей тестовой выборке были экземпляры дисков с серийными номерами, которых не было в тренировке, но это практически не повлияло на качество прогнозирования. Поэтому мы считаем, что у нас получилась довольно универсальная модель — критической зависимости от данных SMART-дисков, используемых в конкретной компании, нет. А значит, наша модель не требует сложной системы регулярного сбора SMART-данных и событий отказа дисков. В этом ее основная ценность.
Модели, которые мы разработали на данный момент, могут обеспечивать достаточно высокую точность. В некоторых случаях Precision достигает 70%, но при этом значительное количество отказов эти модели спрогнозировать не могут. Метрика Recall ни разу не превысила 50%, то есть половина дисков выходит из строя по причинам, которые модель не понимает. Эти выходы из строя (отказы) можно назвать «внезапными смертями», или sudden death. Вероятно, столь большое количество «внезапных смертей» говорит о том, что SMART-данных просто недостаточно. И то, что у победителей конкурса от Alibaba, Recall составляет лишь 40%, подтверждает эту гипотезу.
Поэтому для развития этого проекта мы планируем искать новые данные.