Да, всё так. Рассказ про доступность "на пальцах", плюс пул аргументов для разговоров с топами и бизнесом.
Насчёт методички для младшего командного состава не соглашусь - на митапах мои расчёты (очень упрощённые) были часто откровением для devops-инженеров, sre-инженеров, разработчиков и их лидов. И пришлось рассказывать подробно, как в статье, с обоснованием "почему нельзя вопрос обеспечения доступности полностью переложить на инфру".
Запихнуть в одну, даже очень длинную, статью весь учебник по теории надёжности - задача такой же достижимости, как и задача получения виртуалки с доступностью 100%, я не ставил себе такой цели :)
Цель - дать всем общее представление, коллегам-инфраструктурщикам - аргументы в переговорах, а коллегам-менеджерам - понимание, где искать заветные "девятки" доступности.
[1] И часть не переезжает вовсе. Вы не представляете, сколько систем в крупных организациях, которые когда-то кем-то были запущены, потом команда внедрения разошлась и осталось полтора инженера на поддержку. И что в итоге мы делаем, когда текущее облако не устраивает? Добавляем ещё одно, если я правильно понимаю? И даём выбор командам, в какое облако заезжать? И как всем этим хозяйством потом в компании управлять?
[2] Ещё хуже. Валидировать придётся каждый элемент информационной системы на всех этапах жизненного цикла. Как вы себе это представляете? Контролировать кто и что поставил на новую созданную виртуалку и как это что-то новое настроил, по стандартам, или нет? Это просто остановит любые изменения.
[3] Что делаем, если провайдер делает 90% нужного и не делает 10% нужного? А если соотношение 80 на 20? Спокойно смотрим, как 20% от 4000 человек говорят и вам, и руководству, что выбор данного конкретного облака был ошибочным? Наш подход очень простой - если есть востребованный, но отсутствующий сервис, то он реализуется. Точка.
[4] У вас пострадал сервис из-за того, что конкретный инфраструктурный элемент не работал 3 дня. Все средства обеспечения отказоустойчивости от Облака ограничены одним регионом, а иногда регионы ломаются целиком. Вы теряете примерно по миллиону в час и ничего не можете с этим сделать, эскалировать некому, поддержка говорит "мы чиним, ваш звонок очень важен для нас". По итогам месяца строго по договору получаете компенсацию в 10-50% от месячной стоимости этого инфраструктурного элемента.
[5] Спасибо, я умею пользоваться поиском и не зря написал, что утрирую. Я и так отлично знаю, что редис в облаках есть. Вопрос мой звучит очень просто - как добавить в публичное облако сервис, который востребован у нас но его нет у провайдера? Как этот вопрос решается? Сколько времени займёт? И ответ я знаю из собственного опыта, если что: "Можно открыть кошелёк и слёзно попросить провайдера. Времени займёт столько, сколько пожелает провайдер, если вообще возьмётся". Потому что каждый конкретный клиент, даже крупный - для провайдера это всего лишь один клиент.
Хороший подход. Жаль, что в реальной крупной организации не работает :)
Вы не можете начать работу с виртуалкой, т.к. кто-то должен настроить на ней доменную авторизацию по вашей заявке. И даже неважно, как это происходит - руками, плейбуком, или пайплайном.
Либо альтернатива - всё отдать на откуп 200 командам. Команды будут очень рады, когда узнают, что им самим нужно не бизнес-приложение пилить, а реализовывать инфраструктурные сервисы самостоятельно: мониторинг, логирование, доменная авторизация и другие требования ИБ. Бизнес также будет доволен тем, что вместо компактного подразделения, которое занимается массовыми операциями, в каждой команде появится отдельный человек, занимающийся инфраструктурой. Архитекторы порадуется тому, что мониторинг у 100 команд построен на Prometheus, у 70 на Zabbix, а оставшиеся вообще Splunk притащили вопреки арх.стандартам компании :)
А ещё из этих 200 команд примерно половина забудет обновить сертификат CA, или цепочку сертификатов и раз в год половина систем будет складываться как карточный домик )
Как снимать метрики здоровья и организовать мониторинг инфры в таком подходе?
Как поступать при сбоях в сервисах и оперативно их чинить?
Как реализовать bulk-операции на всех элементах инфры (принудительное обновление, добавление новых внутренних доверенных сертификатов)?
Как снимать сводную статистику по использованию "в попугаях" (CPU/RAM) и в деньгах для всех проектов?
Я могу таких "как" накидать ещё штук 50 :)
Если ручками/плейбуками допиливать всё, то вся прелесть облака теряется - возвращаемся к системе заявок в инфровое подразделение и ожидание исполнения, измеряемое в днях, а не минутах. В этом подходе никакого бенефита от облака не прослеживается, можно и собственные сервера + vSphere/Xen использовать.
Нет, это не я лукавлю, скорее вам надо чуть глубже погрузиться в вопрос, так как дьявол всегда кроется в деталях :)
Для начала я предлагаю вообще перестать говорить про AWS, сразу по нескольким причинам: санкционные риски для крупной компании в этом случае запредельны, требования российского законодательства нарушаются на каждом шагу (ФЗ 152 и т.п.)
Если вы разрабатываете один продукт без персональных данных, то публичное облако + cloud agnostic подход может быть для вас применим. Но при этом, боюсь, что только на старте и для небольших систем.
Почему я так думаю?
Представьте, что вам нужно перенести в другое облако не 1, не 10 приложений, а, к примеру, 100, или 200. Сколько времени займёт у вас такая миграция? Год для такого процесса - очень оптимистичный срок. Скорее 2-5 лет.
Как вы будете контролировать Cloud Agnostic? Запускается ещё один проект, в силу сложностей в коммуникациях до конечного инженера не донесли этот подход, или инженер на него забил, потому что "надо использовать новое, а не жить как староверы". И всё, в какой-то системе уже используется, скажем, Tarantool, который как сервис есть только в VK Cloud. А так как инженеры друг с другом часто общаются, то ещё через полгода тарантул появляется ещё в 10 проектах. И этот эффект сразу вы даже не заметите, узнаете как раз во время миграции. И даже с сотрудником ничего не сделать, так как он год как уволился.
Как быть с требованиями ИБ, которые не статичны? Как быть, если новое требование ИБ нереализуемо на конкретном облаке? Вам ИБ просто не согласует использование сторонних инфраструктурных площадок, т.к. данные компании физически "живут" в месте, которое компания никак не контролирует физически. Как пример: требование ИБ - авторизация только с помощью корпоративной учётки AD. Как это реализовать by default на всех виртуальных машинах, которые будут создаваться сотрудниками компании в публичном облаке? Административно заставить всех настраивать доменную авторизацию? Заставить всех использовать кастомные образы? А как это сделать для чего-то посложнее виртуальной машины, в том PostgreSQL/K8S as a service от публичного облака?
Тут в соседних комментариях уже упоминали немного про SLA, я расширю этот момент. Как управлять доступностью в публичном облаке? Как компании-потребитель предъявить требования к доступности сервисов? Что делать, если предлагаемая, либо обеспечиваемая доступность вас не устраивает?
Как добавить свой сервис в платформу? Я сейчас немного утрирую, чтобы было понятно. У сферического публичного провайдера нет redis as a service. При этом redis используется всё активнее, см пример с Tarantool. Даже в копии публичного облака, которое мы физически установили в нашем ДЦ для себя, это сделать было невозможно. Как и кастомизировать образ PostgreSQL as a Service под себя. В итоге у вас просто нет нужного сервиса и 4 тысячи сотрудников смотрят на вас как на идиота, потому что "именно вы приняли решение выбрать такого плохого провайдера услуг, ищите способ решения".
А для крупной компании, про которую и написана статья, всё описанное - не праздные вопросы, количество стейкхолдеров зашкаливает и вы просто не найдёте публичного провайдера, который предложит всё, что требуется. Либо предложит, но это уже будет не паблик, а форк паблика с огромным количеством минусов.
Cloud Agnostic - это выход, если вы ищете облако для одной-единственной команды.
На 5 командах у вас уже будут трудности с управлением такой инфраструктурой.
На 10 трудности станут явными.
На 200 такая модель просто работать не будет. Когда провайдер сломается, внезапно выяснится, что 20 команд не могут мигрировать, потому что никто не знает, как ПО устроено, ещё 40 завязли по уши в vendor specific сервисах, из оставшихся примерно половина не думает про ИБ и мы все вместе прочитаем на Хабре про новую утечку данных. И всё потому, что в публичном облаке вы отдаёте в руки командам полный контроль и никак не можете ограничить, что делать можно, а что нельзя.
Дьявол, как всегда, кроется в деталях поэтому взять любой готовый продукт и использовать его - это всегда компромисс между потребностями большой организации и возможностями вендорского продукта. Причём этот компромисс решается всегда в пользу вендора, а не компании-потребителя, которая, между прочим, платит совсем немаленькие деньги за продукт. Абсолютно типовая ситуация, когда запрос реализация потребности приводит сразу к нескольким негативным эффектам:
1) Появление форка продукта, который вендор в какой-то момент решит перестать поддерживать. Изменилась стратегия, команду форка переключили на развитие другого направления и т.д. - всем этим вы не управляете.
2) Выставление заградительных ценников на доработки. Вендору может быть просто неинтересно тратить ресурсы на создание того, что вам требуется.
3) Неуправляемые со стороны потребителя сроки реализации функционала. На сроки можно просто согласиться, почеледжить не выйдет.
Это только малая часть того, что скрывается за словом Opinionated.
Простой пример. Компании нужно, чтобы управление группами безопасности (по сути, просто правила фаервола) происходило под контролем ИБ, а не только пользователя. Это вообще стандарт в энтерпрайзе. Какое готовое облако позволяет так организовать ролевую модель, чтобы это было возможно реализовать?
Второй пример - санкционные ограничения. Если вы используете готовый Openstack, то заменить его вполне реально. Да, это отдельный технологически сложный проект, но реально. А вот если вы используете готовое облако, то выход у вас только один - миграция на другой продукт, что в крупной организации гораздо сложнее и дольше.
Готовые продукты как раз используются - тот же Openstack, например. Но, во-первых, это продукты не конкретной компании, а opensource-сообщества, а во-вторых, только как отдельные компоненты конечного продукта, вся логика предоставления сервисов конечному пользователю сделана иначе, под потребности большой организации.
Да, всё так. Рассказ про доступность "на пальцах", плюс пул аргументов для разговоров с топами и бизнесом.
Насчёт методички для младшего командного состава не соглашусь - на митапах мои расчёты (очень упрощённые) были часто откровением для devops-инженеров, sre-инженеров, разработчиков и их лидов. И пришлось рассказывать подробно, как в статье, с обоснованием "почему нельзя вопрос обеспечения доступности полностью переложить на инфру".
Запихнуть в одну, даже очень длинную, статью весь учебник по теории надёжности - задача такой же достижимости, как и задача получения виртуалки с доступностью 100%, я не ставил себе такой цели :)
Цель - дать всем общее представление, коллегам-инфраструктурщикам - аргументы в переговорах, а коллегам-менеджерам - понимание, где искать заветные "девятки" доступности.
[1] И часть не переезжает вовсе. Вы не представляете, сколько систем в крупных организациях, которые когда-то кем-то были запущены, потом команда внедрения разошлась и осталось полтора инженера на поддержку. И что в итоге мы делаем, когда текущее облако не устраивает? Добавляем ещё одно, если я правильно понимаю? И даём выбор командам, в какое облако заезжать? И как всем этим хозяйством потом в компании управлять?
[2] Ещё хуже. Валидировать придётся каждый элемент информационной системы на всех этапах жизненного цикла. Как вы себе это представляете? Контролировать кто и что поставил на новую созданную виртуалку и как это что-то новое настроил, по стандартам, или нет? Это просто остановит любые изменения.
[3] Что делаем, если провайдер делает 90% нужного и не делает 10% нужного? А если соотношение 80 на 20? Спокойно смотрим, как 20% от 4000 человек говорят и вам, и руководству, что выбор данного конкретного облака был ошибочным? Наш подход очень простой - если есть востребованный, но отсутствующий сервис, то он реализуется. Точка.
[4] У вас пострадал сервис из-за того, что конкретный инфраструктурный элемент не работал 3 дня. Все средства обеспечения отказоустойчивости от Облака ограничены одним регионом, а иногда регионы ломаются целиком. Вы теряете примерно по миллиону в час и ничего не можете с этим сделать, эскалировать некому, поддержка говорит "мы чиним, ваш звонок очень важен для нас". По итогам месяца строго по договору получаете компенсацию в 10-50% от месячной стоимости этого инфраструктурного элемента.
[5] Спасибо, я умею пользоваться поиском и не зря написал, что утрирую. Я и так отлично знаю, что редис в облаках есть. Вопрос мой звучит очень просто - как добавить в публичное облако сервис, который востребован у нас но его нет у провайдера? Как этот вопрос решается? Сколько времени займёт? И ответ я знаю из собственного опыта, если что: "Можно открыть кошелёк и слёзно попросить провайдера. Времени займёт столько, сколько пожелает провайдер, если вообще возьмётся". Потому что каждый конкретный клиент, даже крупный - для провайдера это всего лишь один клиент.
Хороший подход. Жаль, что в реальной крупной организации не работает :)
Вы не можете начать работу с виртуалкой, т.к. кто-то должен настроить на ней доменную авторизацию по вашей заявке. И даже неважно, как это происходит - руками, плейбуком, или пайплайном.
Либо альтернатива - всё отдать на откуп 200 командам. Команды будут очень рады, когда узнают, что им самим нужно не бизнес-приложение пилить, а реализовывать инфраструктурные сервисы самостоятельно: мониторинг, логирование, доменная авторизация и другие требования ИБ. Бизнес также будет доволен тем, что вместо компактного подразделения, которое занимается массовыми операциями, в каждой команде появится отдельный человек, занимающийся инфраструктурой. Архитекторы порадуется тому, что мониторинг у 100 команд построен на Prometheus, у 70 на Zabbix, а оставшиеся вообще Splunk притащили вопреки арх.стандартам компании :)
А ещё из этих 200 команд примерно половина забудет обновить сертификат CA, или цепочку сертификатов и раз в год половина систем будет складываться как карточный домик )
Как снимать метрики здоровья и организовать мониторинг инфры в таком подходе?
Как поступать при сбоях в сервисах и оперативно их чинить?
Как реализовать bulk-операции на всех элементах инфры (принудительное обновление, добавление новых внутренних доверенных сертификатов)?
Как снимать сводную статистику по использованию "в попугаях" (CPU/RAM) и в деньгах для всех проектов?
Я могу таких "как" накидать ещё штук 50 :)
Если ручками/плейбуками допиливать всё, то вся прелесть облака теряется - возвращаемся к системе заявок в инфровое подразделение и ожидание исполнения, измеряемое в днях, а не минутах. В этом подходе никакого бенефита от облака не прослеживается, можно и собственные сервера + vSphere/Xen использовать.
Нет, это не я лукавлю, скорее вам надо чуть глубже погрузиться в вопрос, так как дьявол всегда кроется в деталях :)
Для начала я предлагаю вообще перестать говорить про AWS, сразу по нескольким причинам: санкционные риски для крупной компании в этом случае запредельны, требования российского законодательства нарушаются на каждом шагу (ФЗ 152 и т.п.)
Если вы разрабатываете один продукт без персональных данных, то публичное облако + cloud agnostic подход может быть для вас применим. Но при этом, боюсь, что только на старте и для небольших систем.
Почему я так думаю?
Представьте, что вам нужно перенести в другое облако не 1, не 10 приложений, а, к примеру, 100, или 200. Сколько времени займёт у вас такая миграция? Год для такого процесса - очень оптимистичный срок. Скорее 2-5 лет.
Как вы будете контролировать Cloud Agnostic? Запускается ещё один проект, в силу сложностей в коммуникациях до конечного инженера не донесли этот подход, или инженер на него забил, потому что "надо использовать новое, а не жить как староверы". И всё, в какой-то системе уже используется, скажем, Tarantool, который как сервис есть только в VK Cloud. А так как инженеры друг с другом часто общаются, то ещё через полгода тарантул появляется ещё в 10 проектах. И этот эффект сразу вы даже не заметите, узнаете как раз во время миграции. И даже с сотрудником ничего не сделать, так как он год как уволился.
Как быть с требованиями ИБ, которые не статичны? Как быть, если новое требование ИБ нереализуемо на конкретном облаке? Вам ИБ просто не согласует использование сторонних инфраструктурных площадок, т.к. данные компании физически "живут" в месте, которое компания никак не контролирует физически. Как пример: требование ИБ - авторизация только с помощью корпоративной учётки AD. Как это реализовать by default на всех виртуальных машинах, которые будут создаваться сотрудниками компании в публичном облаке? Административно заставить всех настраивать доменную авторизацию? Заставить всех использовать кастомные образы? А как это сделать для чего-то посложнее виртуальной машины, в том PostgreSQL/K8S as a service от публичного облака?
Тут в соседних комментариях уже упоминали немного про SLA, я расширю этот момент. Как управлять доступностью в публичном облаке? Как компании-потребитель предъявить требования к доступности сервисов? Что делать, если предлагаемая, либо обеспечиваемая доступность вас не устраивает?
Как добавить свой сервис в платформу? Я сейчас немного утрирую, чтобы было понятно. У сферического публичного провайдера нет redis as a service. При этом redis используется всё активнее, см пример с Tarantool. Даже в копии публичного облака, которое мы физически установили в нашем ДЦ для себя, это сделать было невозможно. Как и кастомизировать образ PostgreSQL as a Service под себя. В итоге у вас просто нет нужного сервиса и 4 тысячи сотрудников смотрят на вас как на идиота, потому что "именно вы приняли решение выбрать такого плохого провайдера услуг, ищите способ решения".
А для крупной компании, про которую и написана статья, всё описанное - не праздные вопросы, количество стейкхолдеров зашкаливает и вы просто не найдёте публичного провайдера, который предложит всё, что требуется. Либо предложит, но это уже будет не паблик, а форк паблика с огромным количеством минусов.
У вас просто лицензионный ключ работать перестанет и продукт превратится в тыкву, только и всего :)
Cloud Agnostic - это выход, если вы ищете облако для одной-единственной команды.
На 5 командах у вас уже будут трудности с управлением такой инфраструктурой.
На 10 трудности станут явными.
На 200 такая модель просто работать не будет. Когда провайдер сломается, внезапно выяснится, что 20 команд не могут мигрировать, потому что никто не знает, как ПО устроено, ещё 40 завязли по уши в vendor specific сервисах, из оставшихся примерно половина не думает про ИБ и мы все вместе прочитаем на Хабре про новую утечку данных. И всё потому, что в публичном облаке вы отдаёте в руки командам полный контроль и никак не можете ограничить, что делать можно, а что нельзя.
Что-то готовое == негибкое.
Дьявол, как всегда, кроется в деталях поэтому взять любой готовый продукт и использовать его - это всегда компромисс между потребностями большой организации и возможностями вендорского продукта. Причём этот компромисс решается всегда в пользу вендора, а не компании-потребителя, которая, между прочим, платит совсем немаленькие деньги за продукт. Абсолютно типовая ситуация, когда запрос реализация потребности приводит сразу к нескольким негативным эффектам:
1) Появление форка продукта, который вендор в какой-то момент решит перестать поддерживать. Изменилась стратегия, команду форка переключили на развитие другого направления и т.д. - всем этим вы не управляете.
2) Выставление заградительных ценников на доработки. Вендору может быть просто неинтересно тратить ресурсы на создание того, что вам требуется.
3) Неуправляемые со стороны потребителя сроки реализации функционала. На сроки можно просто согласиться, почеледжить не выйдет.
Это только малая часть того, что скрывается за словом Opinionated.
Простой пример. Компании нужно, чтобы управление группами безопасности (по сути, просто правила фаервола) происходило под контролем ИБ, а не только пользователя. Это вообще стандарт в энтерпрайзе. Какое готовое облако позволяет так организовать ролевую модель, чтобы это было возможно реализовать?
Второй пример - санкционные ограничения. Если вы используете готовый Openstack, то заменить его вполне реально. Да, это отдельный технологически сложный проект, но реально. А вот если вы используете готовое облако, то выход у вас только один - миграция на другой продукт, что в крупной организации гораздо сложнее и дольше.
Готовые продукты как раз используются - тот же Openstack, например. Но, во-первых, это продукты не конкретной компании, а opensource-сообщества, а во-вторых, только как отдельные компоненты конечного продукта, вся логика предоставления сервисов конечному пользователю сделана иначе, под потребности большой организации.