1. Диверсифицировать ит-системы - не значит создать вместо одной системы (ну пусть даже по бронированию) еще одной подобной. И, мол, пусть работает и та, и та; 2. Диверсифицировать - это может значить, например, разработку или приобретение дополнительного ПО, которое будет поддерживать существующую систему и/или исключать возможность сбоев. Согласитесь, это и есть то самое разнообразие; 2. Далее выдержка из Ведомостей: "...Но, несмотря на большие подвижки в части создания и внедрения отечественного ПО для авиаотрасли, огромное количество компаний по-прежнему используют базовые программы зарубежного производства, отмечает исполнительный директор «Авиапорта» Олег Пантелеев. Поэтому нельзя считать, что отрасль полностью независима от глобальных сбоев или целенаправленных отключений сервисов, поясняет он. При этом в России степень защищенности от внешних проблем выше, чем в других странах, признает эксперт. «В частности, малое распространение решений Crowdstrike в стране привело к тому, что нашу авиацию глобальный сбой пока не затронул», – объясняет собеседник." О чем нам это говорит? Решения crowdstrike у нас все еще присутствуют и тем не менее сбоя из-за них не произошло. Значит что? Значит были внедрены некие it решения, которые не дали их продуктам стать причиной негативных последствий. Это не есть диверсификация?
Я бы сказал, что после определённого уровня бизнес должен себя обезопасить не просто какой-то подушкой, а в целом... Обезопасить. Ведь это может проявляться по разному.
Мне кажется, вы немного казуистикой занимаетесь. Слово диверсификация с английского значит разнообразие, и, подозреваю, Вам это известно. Чьего производства будет это разнообразие, своего или зимбабвийского..уже другой вопрос. В нашей стране решили импортозаместить. А если бы таких возможностей не было бы, полагаю, искали бы аналоги чьего угодно производства.
Почему же, сбоит. Но и я не утверждал авторитарно, что ПО должно быть именно российским. Я говорил об альтернативе. А чьё производство...вопрос иного порядка.
Совершенно верно. Вы правы. Но вы все-таки сейчас уводите все в сторону немного иной темы - риск-аппетит. Об этом я уже упомянул выше: "Безусловно, тут надо все просчитывать, т.к. меры по управлению риском (затраты которые необходимо понести) не должны превышать величину самого риска. Но это уже отдельная тема и история."
Хотите сказать, их клиенты априори согласны нести убытки за Х дней простоя, лишь бы не делать дорогостоящих изменений? Рано или поздно, такие периодические простои и убытки от них превысят стоимость изменений.
Совершенно не против вашего суждения про "не давать доступ бай дефолт" и игнор этого принципа. Это и есть прямой путь к реализации риска.
Немного не соглашусь с "Далее можно долго рассуждать как компенсировать, как восстанавливать и как это все автоматизировать". Статьей я как раз таки хотел дать понять, что для управления рисками надо действовать не постфактум и думать как исправить, а превентивно, дабы не допустить.
Насчет дороговизны альтернатив. Безусловно, тут надо все просчитывать, т.к. меры по управлению риском (затраты которые необходимо понести) не должны превышать величину самого риска. Но это уже отдельная тема и история.
Диверсификация IT-систем. Именно об этом в статье и написано.
И, в частности, РЖД этим занимается уже давно. А во избежание дополнительных вопросов, выдержка из их отчета аж за 2020 год: "Продолжение работы по переходу ОАО «РЖД» на преимущественное использование отечественного программного обеспечения...".
Ухх...не задумывался об этом. Со временем перестаешь смотреть на них с позиции "необычности". Риск и риск. Но я подумаю, постараюсь выложить что-нибудь.
Наступление. Если исходить из того, что как правило риск имеет денежное выражение, тогда это ситуация, когда вы понесли какой-то убыток: недополучили запланированный доход, заработали штрафы со стороны контролирующих органов и т.д.
Тогда мой комментарий снимается.)
Вопрос Анны сводится к тому, что нужно было сделать самим пострадавшим.
Возможно, более IT-подкованные читатели ответят почему это не было сделано и возможно ли это вообще.
В целом, если это возможно, то да, это могло быть какой-никакой мерой по управлению риском сбоя.
Думаю, эту ветвь дискуссии можно завершить.
Собственно, Вы и говорите о необходимости управления риском, что и было основной мыслью статьи.
Боюсь, не могу ответить Вам за всех.
Надеюсь, теперь мы поняли друг друга)
1. Диверсифицировать ит-системы - не значит создать вместо одной системы (ну пусть даже по бронированию) еще одной подобной. И, мол, пусть работает и та, и та;
2. Диверсифицировать - это может значить, например, разработку или приобретение дополнительного ПО, которое будет поддерживать существующую систему и/или исключать возможность сбоев. Согласитесь, это и есть то самое разнообразие;
2. Далее выдержка из Ведомостей:
"...Но, несмотря на большие подвижки в части создания и внедрения отечественного ПО для авиаотрасли, огромное количество компаний по-прежнему используют базовые программы зарубежного производства, отмечает исполнительный директор «Авиапорта» Олег Пантелеев. Поэтому нельзя считать, что отрасль полностью независима от глобальных сбоев или целенаправленных отключений сервисов, поясняет он. При этом в России степень защищенности от внешних проблем выше, чем в других странах, признает эксперт. «В частности, малое распространение решений Crowdstrike в стране привело к тому, что нашу авиацию глобальный сбой пока не затронул», – объясняет собеседник."
О чем нам это говорит?
Решения crowdstrike у нас все еще присутствуют и тем не менее сбоя из-за них не произошло. Значит что? Значит были внедрены некие it решения, которые не дали их продуктам стать причиной негативных последствий.
Это не есть диверсификация?
1. У вас личная неприязнь к РЖД? Наши авиакомпании вы не упоминаете.
2. Не совсем понял, представляю что?
Вам спасибо за отзыв.
Я бы сказал, что после определённого уровня бизнес должен себя обезопасить не просто какой-то подушкой, а в целом... Обезопасить. Ведь это может проявляться по разному.
Мне кажется, вы немного казуистикой занимаетесь.
Слово диверсификация с английского значит разнообразие, и, подозреваю, Вам это известно.
Чьего производства будет это разнообразие, своего или зимбабвийского..уже другой вопрос.
В нашей стране решили импортозаместить. А если бы таких возможностей не было бы, полагаю, искали бы аналоги чьего угодно производства.
Почему же, сбоит.
Но и я не утверждал авторитарно, что ПО должно быть именно российским. Я говорил об альтернативе. А чьё производство...вопрос иного порядка.
Совершенно верно. Вы правы. Но вы все-таки сейчас уводите все в сторону немного иной темы - риск-аппетит.
Об этом я уже упомянул выше:
"Безусловно, тут надо все просчитывать, т.к. меры по управлению риском (затраты которые необходимо понести) не должны превышать величину самого риска. Но это уже отдельная тема и история."
Так никто и не утверждал, что панацея может быть только российского производства. Но как вариант, почему бы и нет?))
Хотите сказать, их клиенты априори согласны нести убытки за Х дней простоя, лишь бы не делать дорогостоящих изменений?
Рано или поздно, такие периодические простои и убытки от них превысят стоимость изменений.
Совершенно не против вашего суждения про "не давать доступ бай дефолт" и игнор этого принципа. Это и есть прямой путь к реализации риска.
Немного не соглашусь с "Далее можно долго рассуждать как компенсировать, как восстанавливать и как это все автоматизировать".
Статьей я как раз таки хотел дать понять, что для управления рисками надо действовать не постфактум и думать как исправить, а превентивно, дабы не допустить.
Насчет дороговизны альтернатив. Безусловно, тут надо все просчитывать, т.к. меры по управлению риском (затраты которые необходимо понести) не должны превышать величину самого риска. Но это уже отдельная тема и история.
Диверсификация IT-систем.
Именно об этом в статье и написано.
И, в частности, РЖД этим занимается уже давно.
А во избежание дополнительных вопросов, выдержка из их отчета аж за 2020 год:
"Продолжение работы по переходу ОАО «РЖД» на преимущественное использование отечественного программного обеспечения...".
Тогда тем более тому, в чью операционку вшито сторонее ПО с максимумом привилегий, стоит задумываться как "соломки подстелить"...пост как раз об этом.
Разве "максимальные" привилегии означают означают "монопольные"?
Ухх...не задумывался об этом. Со временем перестаешь смотреть на них с позиции "необычности". Риск и риск.
Но я подумаю, постараюсь выложить что-нибудь.
А надо ли?)
А вдруг все еще впереди?
Терпеливо наблюдаем за дальнейшими событиями.
Подозреваю, если бы были основания "включать на полную", уже бы это сделали.
Так как речь идет о сбое облачных сервисов, вот и был использован термин облако.
Если это не совсем корректно, что ж...shame on me. Буду иметь в виду.
Наступление. Если исходить из того, что как правило риск имеет денежное выражение, тогда это ситуация, когда вы понесли какой-то убыток: недополучили запланированный доход, заработали штрафы со стороны контролирующих органов и т.д.
Учиться никогда не поздно.
И потом...эта учеба не принудительна. Каждый решает сам.
А верные выводы были сделаны?
Риск - такая штука, которая может произойти, а может и не произойти. То есть носит вероятностный характер.
А значит настигнуть может кого угодно)
А почему бы и нет? Как показывают последние годы под давлением, мы можем...
Не думаю, что существует некое шаблонное и единственно верное решение. Многое зависит от...
Ряд возможных шагов был рассмотрен в статье.