6 сентября автоконцерн Toyota наконец сообщил причину остановки на трое суток всех 14 заводов в Японии. СМИ предполагали, что за коллапсом стоят хакеры, запустившие в систему заказа деталей ошибочный код. Однако крупнейшая японская автомобилестроительная корпорация (по версии Википедии) провела расследование, и причиной оказалась… нехватка места на диске базы данных. Странно, да? Давайте разбираться, что произошло и как этого можно было избежать.
Официальная версия случившегося
«Сбой системы произошел из-за того, что некоторые из многочисленных серверов, обрабатывающих заказы на детали, стали недоступны. Что касается предыстории. 27 августа, за день до возникновения проблемы, проводились регулярные профилактические работы, в ходе которых мы удаляли и систематизировали данные, накопленные в базе данных. Однако из-за недостатка места на диске произошла ошибка, которая привела к остановке системы. Поскольку эти серверы работали в одной системе, аналогичный сбой также произошел в функции резервного копирования, переключение не удалось выполнить, что привело к остановке заводов. После этого 29 августа данные были перенесены на сервер с дисками большей емкости, система была восстановлена и работа заводов возобновилась».
Позволю себе критическую ремарку. Если честно, описание неисправности выглядит несколько сумбурно. И технически не до конца понятно, что же произошло. Но окей, главное зафиксировали — «недостаток места на диске».
Мониторинг всему голова
Удивительно, что остановка такого большого числа заводов крупнейшего автопроизводителя вызвана такой банальной проблемой, как переполнение дискового пространства. Ведь мы уже привыкли, что во всех инфраструктурах (я молчу про крупнейшие, где это должно быть по дефолту) внедрены системы комплексного мониторинга. Судя по всему, ИТ-департамент Toyota коллективно зевнул на этом моменте проектирования инфраструктуры. Ведь, как правило, именно системы инфраструктурного мониторинга решают такие задачи, как:
накопление, обработка и визуализация событий;
контроль состояния вычислительных ресурсов, сетевых устройств, операционных систем и приложений;
оповещение о выходе из строя компонентов, недоступности приложений, закончившемся месте на файловой системе и т.д.
И здесь — приземляемся на наш рынок — могут использоваться как Open Source решения (всем привычный стек Zabbix, ELK, Grafana и т.д.), так и отечественные продукты, например, Monq, Центральный пульт (Saymon) или INITI SOLO.
Но системы мониторинга — это не только выявление неисправностей оборудования или недоступности системы. Это может быть и проактивный мониторинг бизнес-приложений, и отслеживание бизнес-метрик. А также возможность подключить ML/AI для нахождения аномалий в метриках. Для этого, конечно же, важны доработки продукта и кастомизация под нужды и потребности. Необходимо подключить модули визуализации, чтобы получить понятные графики и дашборды, также можно настроить отправку уведомлений по E-mail или в Telegram и многое-многое другое.
Или, например, смежные решения класса DCIM помогают компаниям инвентаризировать оборудование, отслеживать наличие свободных портов в коммутаторах или юнитов в стойках.
А что с резервным копированием?
Скорее всего, сбой в БД у Toyota мог случиться из-за переполнения файловой системы транзакционными логами, которые должны были удалиться после очередного бэкапа. Но это по какой-то причине не произошло. Любопытно, но наблюдая за своими заказчиками, получая запросы и даже вот читая СМИ, мы в К2Тех замечаем такую тенденцию, что многие просто забывают об СРК. И вспоминают про эту систему только в критической ситуации, что в корне неверно.
И тут мы снова возвращаемся к тому, что даже СРК тоже точно нужно мониторить и отслеживать ее работу (самостоятельно или отдав на аутсорс, получая этот критичный сервис как услугу).
То есть проблема Toyota — это комплексная проблема отсутствия мониторинга состояния инфраструктуры. Которая стоила компании трое суток простоя и существенных финансовых потерь…
Новые вершины технологий ждут тебя в Telegram-канале К2Тех
