Комментарии 13
На файлшаре с важными документами, которых, собственно, почти 9 Тб насобиралось, лежит сериал «Доктор Хаус».
Я бы, для начала, вспомнил, что существует такая вещь, как стеганография. А потом, какая разница, что там лежит, хоть полное собрание сочинений Браззерс за 2000й год. Это не ваши данные, к ним должно относиться, как к raw — лежит на старой СХД что-то — переливайте.
Естественно, потом почистили, что в спешке заказчик не удалил.
Вот так запросто грохнули клиентские данные??? Красавцы.
>Один наш заказчик – агрегатор – почти целиком почти состоит
Так и хочется добавить «из почти разработчиков»
Так и хочется добавить «из почти разработчиков»
Кто разбирается, выносить АСУ ТП и IoT в облако — это православно? Я б такие инфраструктурные вещи с объекта бы не убирал, чтобы аккуратнее падало.
да, интересно было бы послушать аргументы ЗА… да и чем там в пекарне можно и тем более нужно управлять удаленно? врятли там именно асутп, скорее всякая статистика и отчетность…
Во-первых, инфраструктура облаков размещается в сертифицированных ЦОДах (у нас две площадки уровня Tier 3).
Во-вторых, есть возможность сделать свои системы катастрофоустойчивыми, настроить кластеры и т.д.
В таком случае вопрос о падении, даже «аккуратном», вообще стоять не будет.
Во-вторых, есть возможность сделать свои системы катастрофоустойчивыми, настроить кластеры и т.д.
В таком случае вопрос о падении, даже «аккуратном», вообще стоять не будет.
Просто я привык к АСУшной традиции, что если физически отвалился провод к датчику (на шахтах и прочих опасных производствах — или к датчику) или не прошла доставка пакета информации в назначенный срок — запускаем процедуру остановки производства, в зависимости от типа неполадки мягкую или срочную. Т.е. нормальная архитектура — пока получаем регулярные подтверждения, живём, но по дефальту умираем. Как это реализовать через Интернет — ума не приложу.
Неужели про взрыв на макаронной фабрике никогда не слышали? Везде где есть мука — возможен взрыв мелкодисперсной мучной смеси. И её предотвращает автоматика, то есть АСУТП. Могут засориться и упасть от перевеса фильтры — а это довольно тяжелые штуки. И тут опять автоматика. Ну и само собой — противопожарка. Ибо в пекарне печка.
А облако… Клиенты в пекарне как, тоже по Tier-3 сертифицированы? Что будет, если в пекарне инет за неуплату отключат? :-) А при пожаре как, будет у горящей пекарни связь с инетом?
Если (а вдруг?) пекарня сертифицирована по Tier-3 — так зачем ей облако. Если нет — общая надежность определяется надежностью связи пекарни с инетом, а не облака.
Ещё. Пинг меньше 1 мс вы гарантируете? А это обычные требования к скорости срабатывания защит.
Поэтому АСУТП делается на релейных схемах. Или на контроллерах, эмулирующих тупые релейные схемы. И только не критичные вещи — можно и на Дельфи/C/C++.
А в облаке у вас АСУ. Скорее всего технологические рецептуры, логистика и так далее. То есть то, отчего безопасность людей не зависит. Но это не АСУ ТП, это АСУ.
А падать оно должно. Если на 30 лет эксплуатации есть хоть один процент аварии — оно должно уметь упасть безопасно. Поэтому куча исполнительных устройств имеют «безопасное» состояние. По принципу мертвой руки. Оборвалась связь с контроллером — и клапана сами переходят в безопасное состояние (обычно закрываются). Это первый слой безопасности.
На втором слое — отказ контроллера. Если контроллер сломался (завис), то выходы туда же — в безопасное состояние.
На третьем слое — отказ датчиков. Любые датчики — ломаются. Хоть разок за 30 лет — но сломается. Контроллер, видя отказ датчика или несогласованность показаний делает что? Правильно, весь агрегат в безопасное состояние. То есть, как правило, выключает.
Четвертый слой — самопроверки работы программы контроллера и проверка команд оператора. Что не так — туда же, в безопасное.
Ну а когда люди надеются, что «вопрос о падении вообще стоять не будет», получается примерно так. Почитайте, история очень поучительная.
А облако… Клиенты в пекарне как, тоже по Tier-3 сертифицированы? Что будет, если в пекарне инет за неуплату отключат? :-) А при пожаре как, будет у горящей пекарни связь с инетом?
Если (а вдруг?) пекарня сертифицирована по Tier-3 — так зачем ей облако. Если нет — общая надежность определяется надежностью связи пекарни с инетом, а не облака.
Ещё. Пинг меньше 1 мс вы гарантируете? А это обычные требования к скорости срабатывания защит.
Поэтому АСУТП делается на релейных схемах. Или на контроллерах, эмулирующих тупые релейные схемы. И только не критичные вещи — можно и на Дельфи/C/C++.
А в облаке у вас АСУ. Скорее всего технологические рецептуры, логистика и так далее. То есть то, отчего безопасность людей не зависит. Но это не АСУ ТП, это АСУ.
А падать оно должно. Если на 30 лет эксплуатации есть хоть один процент аварии — оно должно уметь упасть безопасно. Поэтому куча исполнительных устройств имеют «безопасное» состояние. По принципу мертвой руки. Оборвалась связь с контроллером — и клапана сами переходят в безопасное состояние (обычно закрываются). Это первый слой безопасности.
На втором слое — отказ контроллера. Если контроллер сломался (завис), то выходы туда же — в безопасное состояние.
На третьем слое — отказ датчиков. Любые датчики — ломаются. Хоть разок за 30 лет — но сломается. Контроллер, видя отказ датчика или несогласованность показаний делает что? Правильно, весь агрегат в безопасное состояние. То есть, как правило, выключает.
Четвертый слой — самопроверки работы программы контроллера и проверка команд оператора. Что не так — туда же, в безопасное.
Ну а когда люди надеются, что «вопрос о падении вообще стоять не будет», получается примерно так. Почитайте, история очень поучительная.
вы както не на мой вопрос отвечаете. вопрос был о смысле управления пекарней из облака и чем именно там из облака можно управлять. а не про уровни tier выших цодов.
Пир после блокировки подсетей AWS, Google, Microsoft!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Байки облака