Comments 12
Еще один пунктик: облачный провайдер может сам стереть всю вашу инфраструктуру и данные совершенно случайно
Терли, трут и будут тереть. Все через это проходили и никто от провайдеров не уклонился. Из последнего крупняка в памяти - Яндекс со своим "rm -rf /" и отсутствием защиты от таких действий админа в 2019)
Или специально, причем без особых предупреждений. В нынешних реалиях бывает и такое.
Да и ответственность сервис-провайдера обычно ограничивается скидкой ну услуги, причем весьма скромной.
Был бы этот материал без ярко выраженной политической позиции автора - поставил бы плюс. За "вату" в материале - заслуженный минус.
Почему здравый смысл в одном случае есть, а в другом наглухо отсутствует - вопрос риторический.
Надо просто помнить, что все это имеет свою цену. И пока ты весь из себя такой независимый и троекратно зарезвированный, другие давно снизили себестоимось и выдавили тебя с рынка
Поэтому все условно сводится к тому, либо ты ведешь бизнес, либо нет.
Не требуется делать все описанное в статье до последней запятой. Надо для начала регулярно делать бэкапы. Потом постепенно подготавливаться к смене провайдера. Да и свой ЦОД не мешает начинать проектировать, при достижении компанией определенного уровня зрелости.
И эта статья, вообще-то, именно про бизнес. Потому что те же переговоры с провайдером при попытке задирания им цены имеют разную окраску при наличии альтернативы и при ее отсутствии. И зависимость бизнеса компании от того, сгорит или не сгорит (условно) ЦОД чужого провайдера - это бизнес-риски в чистом виде.
И еще: гугл, фейсбук и амазон имеют собственные ЦОДы. Когда Вы создадите свою компанию такого уровня, возможно, Вы сможете поделиться собственным опытом здесь на эту тему. Но пока, извините, Ваш коммент - абстрактные рассуждения от человека, который - судя по всему - еще не налетал на крупные проблемы, связанные с сохранностью и доступностью своих данных в чужом облаке. Потому что у налетевшего обычно отношение к надежности облаков совсем другое
Надо для начала регулярно делать бэкапы.
Тут никто не спорит, но для этого достаточно где-то найти диски и платить за трафик. Но надо понимать, что бэкап условно документов, которые могут быть использованы просто так - это одно. Скопировали к примеру договора и все.
Бэкап баз данных без возможности поднять софт, который с ними будет работать - ну такое. Чемодан без ручки в лучшем случае
Поэтому голый бэкап - почти никому не интересен.
А в статье куча рассуждений на эту тему
Потом постепенно подготавливаться к смене провайдера.
В больших организациях это все обычно покрывается чем-то вроде Disaster Recovery Plan, где на уровне Правления определяются риски, которые стоит принимать во внимание, а какие - не стоит. Никто не запрещает иметь "холодное" решение у другого провайдера, при условии, что ваше решение не использует cloud-native решения первого.
Тогда такое решение и стоит недорого, да и миграция кроме внешнего домена скорее всего много времени не займет.
Т.е. условно актив + стендбай - у первого, холодное - у второго. Если исключить риск того, что вы реально преступник, либо сотрудничаете с ними - вряд ли сразу два провайдера решат разорвать в вами отношения.
Да и свой ЦОД не мешает начинать проектировать, при достижении компанией определенного уровня зрелости.
Можно, каждый выбирает сам, растить свои компетенции или нет. Но вы должны понимать, что свой ЦОД - это в реале минимум три, один из которых находится достаточно далеко, чтобы исключить риски катастроф. Два можно ближе друг у другу. Эо уже уровень крупных организаций, которые условно входят в ТОП-10 своей отрасли, ну может в ТОП 20.
И зависимость бизнеса компании от того, сгорит или не сгорит (условно) ЦОД чужого провайдера - это бизнес-риски в чистом виде.
Тут мировые лидеры клауда предлагают 100500 решений (шутка, коненчо решений меньше, но они закрывают любые потребности). Поэтому каких-от сложностей тут нет от слова совсем. Для своего ЦОДа это все надо решать и строить самому
Ваш коммент - абстрактные рассуждения от человека, который - судя по всему - еще не налетал на крупные проблемы, связанные с сохранностью и доступностью своих данных в чужом облаке. Потому что у налетевшего обычно отношение к надежности облаков совсем другое
Степень сохранности данных больше зависит от способностей того, кто это проектирует и реализует, а не от технологий.
Гордиться тем, что нарвался на неприяности - ну такое :( А если проблему налетевший ищет не в зеркале, а в ком-то другом - это уже диагноз
Жаль, что Хабр читают технари, а не руководители топ уровня, а ведь именно сверху спускается распоряжение: в этом году (/квартале/месяце) мы едем в облака! Решение принято и обсуждению не подлежит! При этом видит на экране начальника красочную презентацию очередных модных облаков и сколько они "экономят" денег для бизнеса. Тогда СТО (/начальник IT/Сисадмин) вздыхает и думает фразу: "Ой, дурааааак...."
Как правильно входить в облака