Пришло ли время переносить сервисы в облако? : Сеть

Да, переезд в Гермашку в плане закона выглядит крайне бредовым.
С другой стороны, слова про подставу всех клиентов не совсем верны, т.к. не все клиенты на битриксе сидят в облаке :)

Если хочешь что то сделать хорошо сделай это сам...
а так то да ... 1с вечно на чужих плечах в рай хотят вьехать...
ой а мы постоянно кривой код пишем? ничего - программеры на местах исправят... заодно и денег заработают... да еще и ИТС продадим в следующем релизе поправим и новых багов напихаем...
и по кругу...

Недавно у буржуйских разработчиков в группах шутку видел. Если клиент спрашивает про облака, напомните ему, что вслед за облаками приходят штормы...

По сообщению пользователя dobrovolskiy 15 мая 2019 года в результате человеческой ошибки Яндекс удалил часть виртуальных машин в своем облаке.

Пользователь получил письмо от техподдержки Яндекса с таким текстом:
Сегодня мы проводили технические работы в Яндекс.Облаке. К сожалению, из-за человеческого фактора были удалены виртуальные машины пользователей в зоне ru-central1-c, которые хоть раз находились в статусе SUSPENDED. Мы сразу заметили ошибку и остановили удаление. Увы, некоторые ВМ и их boot-диски были удалены.

В результате пользователем были полностью потеряны некоторые продакшн-сервера. Бекапы у пострадавшего были, но часть данных всё равно утрачена безвозвратно. Обычно Яндекс компенсирует даун-тайм своих сервисов, согласно своей политике, но кто компенсирует потерю данных?

Яндекс официально подтвердил инцидент и прокомментировал ситуацию.

Привет, это команда Облака. Пишем здесь только сейчас, потому что было важно разобраться в произошедшем.

Коротко о самом инциденте. На 16 мая были запланированы регулярные технические работы по остановке и удалению виртуальных машин заблокированных пользователей. Но при формировании списка был применен неверный принцип фильтрации, и в список попали активные машины. Удаление было остановлено, как только мы обнаружили ошибку.

Мы приносим извинения за этой сбой. Всем, кого он затронул, в качестве компенсации будут начислены гранты в Облаке. Кроме того, для пострадавших пользователей мы временно отключим тарификацию снимков дисков. И гранты, и нулевая тарификация вступят в силу в течение трёх рабочих дней.

Для предотвращения подобного в будущем мы, во-первых, в рамках процедуры блокировок облаков строго разделим остановку и удаление виртуальной машины и её дисков. Во-вторых, при удалении диска виртуальной машины будет автоматически создаваться его копия.

Вот наш пост с подробным разбором произошедшего:

Все чаще ИТ-отделы обнаруживают, что тщательно выстроенные ими облачные архитектуры на самом деле покоятся на довольно зыбком основании. С трудом собранные и упорядоченные данные и созданные с таким трудом приложения может потребоваться перенести, а иногда это нужно будет сделать в кратчайшие сроки, с минимальными простоями. Почему это происходит и как осуществить переход с наименьшим ущербом?

По уровню внедрения облачных сервисов Россия пока отстает от США и наиболее развитых стран Западной Европы. Что дает возможность воспользоваться их опытом, причем не только позитивным, изобильно представленном в разнообразных «историях успеха», но и негативным, связанным со сбоями в предоставлении услуг, разным трактовкам пользовательского соглашения, с реальной практикой обслуживания клиентов облачными гигантами.

Как утверждает Питер Уэйнер (Peter Wayner), автор статей и книг по ИТ-тематике, на тематических форумах фраза «заблокированная учетная запись» встречается весьма часто. А обращаются с вопросами «в интернет», как правило, тогда, когда все остальные способы решить проблему уже исчерпаны, поскольку облачный провайдер, технологический лидер, в плане коммуникаций оказался «черной дырой»: не отвечает на электронные письма или не указывает контактный номер телефона и даже физический адрес.

Во многих случаях мелкие разработчики и даже крупные компании попадают в подобные ситуации из-за какого-то пункта, скрытого в тексте «Условий обслуживания». Даже беглый просмотр «Условий» показывает, что они представляют собой смешанный набор правил, с одной стороны, четких и однозначных, с другой — весьма спорных и туманных. Вот, например, если пункт условий запрещает отправку «электронной почты низкого качества», то имеется ли в виду спам, и как это качество оценить?



Впрочем, считает Питер Уэйнер, вопрос не в том, как оспорить какие-либо пункты (ответ на этот вопрос практически очевиден — «никак»). Надо быть готовым в любой момент к прекращению обслуживания и переходу к другому провайдеру. Хотя бы морально. Вот несколько соображений от Питера Уэйнера, которые могут быть полезны и в российских условиях.

Не полагайтесь на «Условия использования»

У юристов облачных провайдеров был не один год, чтобы составить это многостраничное соглашение, и вряд ли они при этом захотят глубоко вникать в специфику вашей работы. Соглашения нередко предусматривают право закрыть учетную запись клиента в «любое время» по «любой причине», а некоторые юристы также оговаривают право заблокировать ее и вовсе «без причины». По данным поисковой системы Google, говорит Питер Уэйнер, существует более 1 млн. веб-страниц со словами «условия обслуживания» и «без причины». Так называемое «верховенство закона» не сильно повлияло на уровень доверия.

Не ждите, что с вашими доводами согласятся

Кто вы и какую работу выполняет ваша компания, в 99% случаев не имеет никакого значения. Истории об аннулированных учетных записях и заблокированных серверах рассказывают вовсе не наркодилеры, которые возмущены решением закрыть их сайт. Нет, они написаны людьми, которые думали, что их не отключат, потому что не за что. Так что разумнее не полагаться на то, что ваши данные и приложения в облаке находятся в безопасности.

Не рассчитывайте на решение проблемы по телефону

Раньше компании нанимали специалистов отделов продаж и службы поддержки, которые действительно были полезны для клиентов. В последнее время все больше и больше решений принимает ИИ, используются боты и автоматизированные скрипты. Если в этом процессе и участвуют люди, они, скорее всего, выполняют свою работу анонимно, «за сценой». В любом случае, сегодня показатели эффективности службы поддержки измеряются пропускной способностью, поэтому у них считанные минуты или даже секунды на принятие решения. А если вы подаете апелляцию на решение «первой инстанции», она попадает в очередь к немногим более опытному человеку, которого все равно оценивают по скорости ответа. Никто ни за что не отвечает.

Заводите друзей

Одна из примечательных особенностей современных облачных вычислений — это то, как много историй начинаются со слов: «Мы бы ничего не добились, если бы я не знал кого-то, кто там работает». Когда кругом боты и ИИ, любой контакт с реальным человеком может быть просто бесценным. Так что чаще бывайте в барах. Рассылайте больше подарков на день рождения всем знакомым сотрудникам в штате провайдера.

Идентифицируйте ключевые данные

Как заявил некогда один из основателей брокерской фирмы: «Мы должны особенно внимательно относиться к списку с именами каждого клиента и суммой денег, которые он вложил. Если бы мы потеряли этот список, то были бы разорены».

Некоторые данные важнее других. Составьте таблицы своей основной базы данных и сконцентрируйтесь на них. Реплицируйте эти таблицы на сервер, который находится под вашим физическим контролем. Затем скопируйте их на другой. Когда вы обнаружите ошибку, то сможете восстановить хотя бы эти таблицы.

Гибкое переключение при отказе

Будет ли ваш веб-сайт все еще работать, если половина микросервисов не отвечает? Тем, кто использует микросервисные архитектуры, следует убедиться, что система функционирует даже в том случае, если некоторые из сервисов выходят из строя. Это добавит гибкости любой быстрой миграции. Пользователям может быть безразличен изящный механизм рекомендаций на основе ИИ или API, импортирующий красиво оформленные локализованные прогнозы погоды. Они могут хотеть просто разместить заказ.

Представьте, что вы работаете на половине оборудования

При переезде в другое облако вы не сможете запустить сразу все базы данных и службы. Хорошая архитектура должна включать план частичной поддержки оборудования. Начните работать над таким планом прямо сейчас. Можете ли вы выключить половину оборудования, чтобы все работало на оставшихся ресурсах? А как насчет одной десятой?

Используйте контейнеры

Команды разработчиков DevOps преследуют одну главную цель: упростить и ускорить развертывание ПО. Практически все, что они делают, поможет вам перейти к новому провайдеру. Контейнеры — это хороший формат для быстрого развертывания вашего приложения, но есть и другие похожие варианты. Канули в Лету те времена, когда требовалась неделя, чтобы настроить новый сервер.

Тестируйте процесс миграции

Почему бы не запустить фиктивную миграцию? Попробуйте развернуть копии всего, что у вас есть, в другом облаке, или на нескольких серверах на своей площадке. Посмотрите, сколько времени это займет. Есть ли какие-либо файлы конфигурации или пакеты программного обеспечения, которые можно настроить, чтобы ускорить работу? Может ли какая-либо из баз данных реплицироваться автоматически? Все ли ваши контейнеры запускаются, как ожидалось?

Проводите эксперименты с новыми проектами

Традиционные проекты начинаются с одинаковой конфигурации оборудования в одном облаке. Если вы собираетесь экспериментировать с новым сервисом или расширенной базой данных, почему бы не попробовать одновременно развернуть все это в другом облаке?

Диверсифицируйте риски

Хотя заманчиво упростить задачу, используя одно и то же облако для всего и вся, есть опасность, что такое облако станет большой единичной точкой отказа. Microsoft, например, купила GitHub, и это должно дать пользователям Azure повод задуматься о хранении своего программного кода в других репозиториях. Или, по крайней мере, убедитесь, что он регулярно сохраняется в виде резервных копий. То же самое относится к другим облачным решениям. Диверсифицируйте риски. По данным опроса компании Flexera, в 2020 г. средний клиент облачных провайдеров использует ресурсы 2,2 частных и 2,2 публичных облаков, всего же мультиоблачной стратегии придерживались 93% ее респондентов. Из них 87% использовали гибридные облачные решения.

Создавайте самовосстанавливающиеся наборы данных

Многие приложения используют последовательность событий или сводят набор данных в таблицы. Что произойдет, если поток событий прекратится? Что делать, если какие-то события повторяются? Разработайте архитектуру с учетом сбоев, чтобы базы данных оставались согласованными даже при прерывании потоков данных.

Используйте открытый исходный код

Проприетарный код имеет много замечательных особенностей. Но только программное обеспечение с открытым исходным кодом дает вам свободу легко и быстро перемещать ПО, не спрашивая, можно ли это сделать. Это свобода не на словах, а на деле.

Избегайте проприетарных инструментов

Облачные провайдеры обычно предлагают два типа продуктов: клоны ПО с открытым исходным кодом и проприетарные инструменты. В то время как продукты с закрытым исходным кодом могут предлагать множество заманчивых вариантов и привлекательных инноваций, угроза потери обслуживания слишком велика.