Комментарии 22
Во времена фидо ходила устойчивая байка, как энергетикам было лень ездить в другой район перезагружать часто виснущий сервер, и они делали это обесточиванием половины города.
в 14:02 линии 345 КВт Stuart-Atlanta
наверно 345 кВ?
Думаю, главной причиной аварии было то, что в ответ на звонки о проблемах диспетчер предпочел "клятвенно уверять, что у них всё в порядке" вместо того, чтобы проверить всю доступную ему в SCADA информацию.
вот скажите - когда вам grep пишет, что в файле логов ничего не нашел - вы ему доверяете, или после него идете и глазами еще раз просматриваете весь лог?
Вы себе представляете - где сидит диспетчер, а где реальные провода на сотни км ? Или вы думаете, что он программист а не электрик и может легко посмотреть "всю доступную ему в SCADA информацию" (и для начала - найти ее и перевести в человекочитаемый формат...) ?
вот скажите — когда вам grep пишет, что в файле логов ничего не нашел — вы ему доверяете,
да, до момента, когда мне позвонят несколько юзеров и скажут, что что-то упало. Тогда я всё-таки перепроверю :)
Диспетчер не может легко посмотреть всю доступную ему информацию, но он в общем-то в состоянии позвонить на подстанцию и спросить, что у них там происходит.
Когда меня первый раз спрашивают — я доверяю grep.
Когда второй — я проверяю не ошибся ли я с grep (бывает), и на всякий случай проверю изменялся ли лог вообще в последнее время, т.е. есть ли там хоть что-нибудь.
Когда третий (за последние полчаса) — я уже разбираю всю цепочку по винтику и вручную проверяю все компоненты, работают ли они вообще. Да, бесит, но зато надёжно.
Такой подход не раз спасал ситуацию когда казалось бы всё совершенно нормально и проблема явно где-то ещё. Да, иногда действительно проблема оказывается где-то ещё — но лучше перебдеть, это займёт всего несколько минут но они могут спасти от многочасового аврала.
Если бы диспетчер руководствовался похожим принципом, то на третий вопрос он бы уже позвонил в техотдел и спросил всё ли работает как должно, а судя по рассказу он получил кучу вопросов, сам факт их возникновения за короткий временной интервал уже должен был его насторожить.
PS: В далекой молодости (ещё при союзе) я проходил практику в чём-то типа центра управления энергосистемой крупного города, и там было похожее правило — на третий звонок, неважно что показывают лампочки на пульте и даже если они все зелёные — давай проверяй ручками или ножками, звони на участки и вообще поднимай кипеш до выяснения ситуации.
Кстати, это открывает вектор атаки на систему через социальную инженерию. Пранкеры звонят сразу с сотен номеров на кучу подстанций и жалуются, что пропал свет. И на более крупные узлы мониторинга тоже. И начинается неслабый кипиш, техники начинают перезагружать сервера, звонить друг другу ещё больше усиловая хаос, и в итоге кто-то что-то реально ломает. А так, если система отлажена нормально, оператор посмотрит, что всё ОК, поймёт, что его разыгрывают, и пошлёт звонящих лесом.
Диспетчеру было достаточно посмотреть состояние линии, статья утверждает, что это было легко доступно, но обычно делается при появлении аварийного сообщения. Что мешало посмотреть при многочисленных звонках, на которые отвечали клятвенными заверениями?
Один из основных принципов расследования инцидентов состоит в том, что у него всегда больше одной причины. Даже если там был человеческий фактор, то он был не единственный.
Диспетчерская это не один человек (и в статье пару раз упоминают во множественном числе). То есть, были причины из-за которых продолбали все, кто был на дежурстве.
Это ж не ответ. Просто перекладывание ответственности на всю смену. Диспетчеры отвечая не знали состояние сети, они могли уверенно сказать, что не было аварийных сообщений, а не то, что всё в норме. Почему никто из целой смены не посмотрел?
Я просто хотел сказать, что причин было больше. Свалить все на одного диспетчера (или смену) это просто, но по факту не практично, так как даёт лишь временный эффект, как латание дыр. Заменят одних другими и потом снова все повторится.
Цель таких расследований не в том, чтобы указать на виноватого, а чтобы найти и потом усилить все узкие места в системе. Инструкции по расследованиям предлагают сразу отбрасывать причину, которая кажется всем очевидной, и начинать копать дальше.
В статье это хорошо показано - они обнаружили там кучу интересных и по-отдельности не очевидных проблем в разных местах. Начиная с банально за годы разросшейся флоры, больших организационных проблем и заканчивая гонками где-то в софте на микросекунды.
Я что, предлагаю свалить только на диспетчеров? Вина остальных в статье раскрывается. Тут даже копать не надо, техподдержка скады, не проверившая работоспособность, диспетчер MISO забывший запустить скрипт, кто-то, ответственный за неполноту данных в MISO (когда там целая линия исчезла из модели). Если б они не лажали, то все другие недостатки были бы не критичны.
Тут свою роль сыграло доверие диспетчера к оповещениям в его системе. Оповещений нет - значит, все нормально.
Вот если бы такого абсолютного доверия не было, то был бы и шанс на обнаружение проблемы. Конечно, диспетчер бы не сорвался и не поехал смотреть линию (хотя у него вроде должен быть вариант по телефону послать разбираться на месте дежурную бригаду). Он просто поглядел бы на конкретное место на карте, увеличив масштаб.
Тут свою роль сыграло доверие диспетчера к оповещениям в его системе. Оповещений нет - значит, все нормально.
чтож, вот поэтому в систему аварийного оповещения здорового человека ставят две лампочки:
первая - красная, для оповещений, а вторая - зеленая, чтобы видеть что первая лампочка таки сработает, когда надо (а не "замерла в состоянии не горит").
Эм, обычно же кнопка "квитирование" проверяет что сигнал ходит туды-сюды.
Вот у них весь экран и был в зелёных лампочках, а что толку? Информации просто слишком много, волей-неволей приходится на систему оповещений смотреть.
В SRE для мониторинга есть 4 золотых сигнала: latency, traffic, errors и saturation. Здесь контроль трафика и насыщенния по нижнему пределу должны по идее выявлять ситуации, когда от системы перестают приходить метрики вообще. Проще говоря, кроме grep, нужен ещё wc -l
Начало аварии положило незначительное на первый взгляд происшествие: в 13:30 остановился блок №5 ТЭЦ Eastlake мощностью 680 МВт.ИМХО, в подобный ситуациях в протоколе действий электростанции должно быть дополнительное информирование центрального диспечерского центра энергосистемы по телефону. Тогда диспечер был бы в состоянии повышенного внимания и увидел бы, что в логе у него нет этого события и начал бы предпринимать какие-то действия.
В идеальном мире для этого использовалась бы real-time система, как SCADA, но MISO развивало свой собственный продукт, в основном методом добавления костылей. Система в распоряжении MISO была не real-time, да она получала данные с низовых устройств, но расчёт надёжности проводился по таймеру раз в 5 минут, таким образом оператор имел срез состояния энергосистемы, который мог за следующий промежуток времени сильно устареть. Автоматический расчёт надёжности проводился по скрипту, который днём в 13:07 был отключён для проведения работ с системой. Причиной стала необходимость привязать сигналы включенного/отключенного состояния линии 230 кВ Bloomington-Denois Creek к её отображению в расчётной модели. После окончания процесса диспетчер попросту забыл активировать скрипт и ушёл на ланч, из-за чего до 14:40 автоматический расчёт надёжности не производился.
Паразительно читать такое!
То, есть можно для критически важной отрасли разрабатывать свой собственный продукт (его кто-нибудь сертифицировал?), не real-time, и где можно что-то отключить и "забыть включить" обратно! И никаких протоколов на случай технических работ!
А во-вторых, пользовательский интерфейс был таков, что диспетчеру после получения оповещения требовалось найти на схеме нужный выключатель и уже, кликнув по нему, проверить его состояние. Система не подсвечивала выключатели, изменившие состояние, и не имела функции перехода к объекту по щелчку на уведомление.
С этого же нужно начинать разработку, с вопроса: а как должен выглядеть пользовательский интерфейс? Сделанные ошибки выглядят просто детскими. Но они оказались фатальными!
Более крупных блэкаутов в США не было, но как и в любой сложной системе, сколько бы дыр в ней не закрывали, всегда может найтись новая.
А как быть имитационным моделированием? С поиском оптимальных систем управления? И что было, если бы было бы несколько независимых энергетических сетей?
Расследование инцидентов это не поиск виноватых. Это крутая инженерная практика. Тот факт, что происшествие в сложной географически распределенной технической системе удалось описать языком, понятным для широкой публики, говорит о высоком уровне проведенной работы.
В АйТи часто бывает так, что ни система ни персонал не способны решать проблемы, когда от инцидента до катастрофы в распоряжении всего час.
Блэкаут в США 2003: как два сервера обвалили энергосистему