Всем привет! Я Андрей Халиуллин — руководитель направления IAM & Security Services в MWS Cloud Platform, и мы продолжаем делать облако. В этот раз хочется поговорить о стабильности, отказоустойчивости и прочих SLO. Естественно, начать нужно с подводки о том, что стабильность облачного провайдера — это очень важно, нужно и актуально в наше нелёгкое время.
Но на самом деле логика довольно простая: клиенты используют облако для разворачивания своих сервисов, систем или продуктов, и если функциональные возможности этих самых сервисов и систем полностью определяются тем, что клиент облака накодит и надеплоит в инфраструктуру, то отказоустойчивость клиентского решения мажорируется отказоустойчивостью провайдера. А значит, как пользователь облака я могу сделать отказоустойчивость своего сервиса хуже, чем у облачного провайдера, но довольно затруднительно получить больше девяток, чем у инфраструктуры, на которой я живу. Если, конечно, вы ещё не оседлали мультиклауд-подход — тогда моё почтение.
Как бы то ни было, облачный провайдер наследует от совокупности своих клиентов все аргументы о том, почему отказы продукта недопустимы. И вот об этом поговорим в статье — как мы, как провайдер, обеспечиваем свою отказоустойчивость, как мы её тестировали и что нового для себя узнали.
Модель отказоустойчивости MWS Cloud Platform
Отказоустойчивость — вопрос, естественно, комплексный. Можно ткнуть пальцем в любую строчку документации, API, элемент интерфейса облака и собрать часовой доклад о том, как обеспечивается надёжность этой функциональности. Ключевая мысль относительно обеспечения надёжности облака — нельзя рассчитывать «сделать надёжность» инкрементально.
Работа над стабильностью облака начинается вместе с самой работой над облаком: проработка требований к ЦОДам, планирование инфраструктуры, проектирование архитектуры сервисов и подготовка процессов. Нефункциональные требования, связанные с отказоустойчивостью (и, кстати, безопасностью), лежат в сфере управления рисками и требуют соответствующих инструментов для управления.
Swiss Cheese Model
Модель швейцарского сыра — наглядная ментальная конструкция, которая даёт хороший способ думать о том, как управлять рисками в системах с большими ставками. Получила распространение в здравоохранении, авиации и многих других высокорисковых индустриях современности.
Идея простая: идеальной сферической защиты от риска в вакууме не существует. Для того чтобы добивать последние девятки и устремлять как можно ближе к нулю вероятность реализации риска, защита должна быть построена в несколько слоёв. Это позволяет каждому слою иметь свои изъяны, которые прикрываются другими слоями защиты.
Для иллюстрации подхода автор модели предлагает брать случайные слайсики «дырявого» сыра и накладывать их друг на друга, чтобы изобразить слоёную защиту. Не страшно, если в одном слайсе дырка, потому что в каком-то из других слайсов это место будет защищено. «Пробитие» такой защиты — это событие, которое умудрилось найти сквозной путь через выровненные в линию дырки на всех слоях. Как нетрудно догадаться, для минимизации рисков модель предлагает уменьшать площадь дыр (качество каждой конкретной защитной меры) и увеличивать количество слайсов (количество защитных мер).
N. B. Если вы практик-визуал, рекомендую в домашних упражнениях использовать конкретно «Эмменталь». С условным «Грюйером» вы рискуете переоценить качество ваших защитных механизмов.
Что за абстрактные слои защиты? Ну, зависит от масштаба, на котором вы смотрите на систему. Рекомендуется на любой «величине зума», с которой умеете рассматривать свой сервис, иметь для себя ответ на вопрос «как устроены мои слои защиты от рисков на этом уровне абстракции».
Применительно к облаку как инженерному продукту, на helicopter view естественным образом в голову приходит примерно вот такое разделение:
Hardware Infrastructure
На этом слое MWS Cloud Platform находится два с половиной (об этом ниже) независимых Tier III ЦОДа с резервированными линками между ними. Tier III — это короткий способ описать отдельный мир общепризнанных мировых стандартов инженерных решений и процессов для управления рисками железной инфраструктуры, который, как принято считать, уже даёт три девятки доступности.
В чём смысл Swiss Cheese Model? В том, чтобы в этом месте сказать: «Окей, у нас классный высокодоступный ЦОД, и он, скорее всего, будет работать 24/7. Но допустим, он отказал, что дальше?»
Software Infrastructure
А дальше мы переходим на следующий уровень абстракции — софтварную инфраструктуру. Здесь у нас находятся baremetal-кубы, managed-сервисы для систем хранения и прочие инфраструктурные запчасти, которые наши разработчики используют для развёртывания компонентов сервисов облака.
Уже на инфраструктурном слое мы предполагаем, что дата-центры склонны отмирать; отдельные диски, планки памяти и сетевые карты отваливаются только в путь. А ещё над двумя линиями нашей оптики в 10 километрах друг от друга находятся две независимые стройки, на которых у двух операторов экскаваторов рабочий день начинается в одно и то же время.
Для описания того, что происходит на слое софтварной инфраструктуры с точки зрения отказоустойчивости, нет хорошего термина типа «у нас Tier-N». В нашем случае инфраструктура предоставляет продуктовым командам k8s-кластера базы данных и балансировщики в двух вариантах: зональном и региональном (мультизональном).
Региональные инфраструктурные сервисы в нашей модели отказов должны уметь переживать отказ одной зоны. Например, если по какой-то из миллиона крайне маловероятных причин у нас отвалится дата-центр — региональные кубы должны продолжать работать как ни в чём не бывало, и это же касается региональных баз данных — postgres должен продолжать работать на чтение и на запись, другими словами: мастер должен быть выбран и доступен.
Сейчас наше облако предоставляет ресурсы в двух зонах доступности, и здесь те из читателей, кто знаком с термином «кворум», должны напрячься, потому что собрать этот самый кворум на двух ногах не представляется возможным. Другими словами, если нам нужен механизм выбора мастера postgres, переживающий отказ одной AZ, нам нужно хотя бы три AZ.
Решение этой проблемы: добавить 0,5 AZ в систему. Да, у нас есть только две геораспределённые крупные площадки в районе Москвы, на которых в нашем облаке есть мощности на обслуживание клиентских нагрузок. Но в целом у организации предостаточно разноразмерных высокодоступных дата-центров, в которые можно впихнуть какую-то инфраструктуру. Поэтому на инфраструктурном слое у нас есть третья AZ, в которую нельзя задеплоить поды продуктовых сервисов или даже реплики сервисных БД. На третью AZ доразвёрнут etcd, на базе которого собирается кворум для обеспечения leader election в кубе и во всех инсталляциях региональных баз данных — так мы обеспечиваем отказоустойчивость региональной инфраструктуры на 2,5 AZ.
Cloud Services
Самый близкий клиентам слой облака — слой сервисов, где наши продуктовые команды имплементируют IAM, Compute, VPC и прочее и разворачивают это всё в нашу инфраструктуру.
В соответствии с общей философией, при разработке сервисов мы не позволяем себе просто принять: «Ну ок, если инфра развалилась — то я уже даже не знаю, что делать». При проектировании сервисов команды должны достаточно глубоко понимать все примитивы и инструменты, которые предоставляет инфраструктура, чтобы правильно их использовать для минимизации вероятности и/или размера импакта при отказах на слоях ниже.
Глобальные запчасти сервисов, например весь CPL IAM, должны сидеть в мультизональных кластерах, должны быть готовы переваривать нагрузку в случае отказа одного ДЦ, должны уметь переживать переезд мастера.
Зональные запчасти, напротив, должны быть в любой момент готовы к потере связности с глобальным слоем, чтобы в режиме подводной лодки AZ могла продолжать функционировать в том объёме, в котором вообще возможно функционирование сервиса без линка до центра принятия решений.
Естественно, для «невозможных» сценариев сервисы должны прорабатывать пути graceful degradation, чтобы минимизировать импакт отказов инфраструктуры на сценарии конечных пользователей. Условно, отсохший мастер — не повод ломать клиентам сценарии, не требующие транзакционной записи.
Тестирование моделей отказа
Перефразируя народную мудрость: «Самурай с мечом, которым он ни разу не пользовался, подобен самураю с мечом, только без меча». Судить о надёжности системы, которую разрабатывают несколько сотен человек, только по тому, что написано в ADR, — неправильно, отказоустойчивость системы должна тестироваться.
Заметную часть сценариев отказа каждая команда облака может тестировать в изоляции. Более того, каждый релиз любого компонента можно рассматривать как «микроинцидент» — когда экземпляры сервиса гасятся, поднимаются, трафик перебалансируется и так далее.
Если обычный релиз сервиса приводит к просадке SLI, или вы релизите сервис только в нерабочее время, чтобы минимизировать влияние на пользователей, или релиз требует от релиз-инженера исполнения фигур высшего пилотажа в инструментах деплоя и балансировки — можете себе представить, как сервис себя почувствует, если «подик моргнёт» по своей инициативе. Так что любой сервис в стадии живой разработки в некотором смысле тестирует себя на отказ самим своим релизным циклом.
Но тем не менее облако устроено гораздо сложнее, чем каждый из его сервисов в отдельности. И сильное утверждение «наша платформа переживает отказ одной AZ» требует явного тестирования.
Учения
Чуть больше года назад мы решили, что, прежде чем объявлять в рынок о том, что «хей, у нас теперь тоже облако!», стоит проверить, чего стоят наши заявления о надёжности собранной конструкции. Момент выглядел идеальным для того, чтобы провести честные учения по отказу AZ в продакшне. На тот момент в нашем портфеле были:
Группа сервисов IAM & Resource Management.
Высокодоступный S3-compatible Object Storage.
VMware по кнопке как отдельный сервис, интегрированный с платформенным IAM.
«Консоль» — веб-интерфейс облака.
Наш целевой IaaS и сервисы на его основе — только готовились к выходу в preview.
Подготовка
Подготовка учений заняла около недели — за это время в чате подготовки собралось около 40 инженеров разных сервисов облака. Мы начали с проработки способа эмуляции отказа — отключения внешних линков на border leaf коммутаторах одной из зон, а также проработали механизм восстановления связности.
Параллельно все сервисы, участвующие в учениях, проанализировали свою готовность к отказу зоны (принимался ответ «кажется, мы не должны сломаться»), а также заранее сформулировали свои специфичные критерии досрочной остановки учений с учётом обязательств перед текущими клиентами. С интересом обнаружили в скоупе сервисов сайт mws.ru, который никто, конечно, изначально тестировать не собирался, но команда сайта как раз закончила переезд на новую инфраструктуру и HA-конфигурацию — с корабля на бал, так сказать. Сгенерили в AI логотип для чата координации учений, выбрали дату и ...
День X
После отключения AZ — по ощущениям «легло все». Более пристальный анализ показал, что недоступна вся консоль облака и Object Storage. DPL VMware жив, сайт немного почихал, но выжил.
Зафиксированные критерии досрочной остановки учений позволили нам несколько минут потратить на живой траблшутинг проблем по всем направлениям, но в какой-то момент пришлось восстанавливать связность и уходить на ретроспективную диагностику по логам. Предварительные находки на выходе из созвона:
IAM Token Service лежал.
Консоль сломалась на авторизации — вероятно, из-за лежащего Token Service.
До нод Object Storage не доходили запросы.
Сбоил DNS в инфраструктуре.
Результаты разбора
Чуть больше двух недель заняло исследование проблем, формулирование action item’ов и прочая подготовка к LSR по результатам учений. В итоге получили порядка 30 тикетов на улучшения по всем командам облака.
IAM
Мы наблюдали проблемы (полную недоступность) в компоненте Token Service. На момент проведения учений Token Service был единственным компонентом облака, который выписывал все облачные Access Token’ы.
Token Service — относительно нагруженный и ответственный компонент. Им пользуются явно или неявно абсолютно все клиенты облака, включая сами сервисы облака, которые получают токены для авторизации service-to-service взаимодействия. Бутерброд проблем Token Service наиболее наглядно демонстрируется в модели Swiss Cheese с нашими слоями защиты от инфраструктурных рисков.
БД Token Service доступна на запись при отказе зоны
Но не этой зоны, другой зоны. БД сервиса была развёрнута на 3 реплики в 2 AZ. Нам повезло погасить AZ, в которой жили 2 из 3 реплик сервиса. Оставшаяся в живых реплика была успешно выбрана мастером, на основании кворума над живыми 1.5 AZ, но отказывалась принимать записи из-за включённого synchronous_mode_strict. Это правильное поведение в нашей модели: если мастер не видит ни одной живой реплики, то он не может принимать записи, поскольку иначе потеря дисков под этим мастером будет означать безвозвратную потерю пользовательских данных.
Целевая топология БД — 4 реплики (по 2 в AZ) — была принята в облаке за несколько месяцев до учений, но мы не проконтролировали внедрение в существующих сервисах.
Ключевым AI, помимо допинывания компонентов IAM и других сервисов на целевой лейаут БД, стал пересмотр процессов внедрения новых практик в инфраструктуре: задача считается выполненной не тогда, когда новая технология доступна для использования, а когда она внедрена в существующие сервисы.
Высокодоступный метод критического сервиса не пытается что-то синхронно писать в БД
И это правда: Token Service осознанно был собран так, чтобы на critical path не было никаких синхронных записей.
Проблема в том, что работа с базой в состоянии RO не была поддержана на уровне нашего облачного фреймворка — рантайм сервиса просто отказывался стартовать. Задача лежала в плане, и в некотором роде это был контролируемый риск, но так получилось, что множество людей, которые знали, что наши сервисы не живут над RO-базой, не пересеклось со множеством людей, которые предполагали RO-состояние как вероятное последствие учений.
В результате учений поприоритизировали задачу о поддержке RO-режима повыше.
Ответы Token Service кешируются в клиентах на десятки минут
На самом деле «софтварная инфраструктура» Token Service не заканчивается на границе его API — на всех используемых в облаке языках мы предоставляем командам SDK, который не только правильно кеширует выписываемые токены, но и проактивно подновляет их для длинных сессий по мере приближения к expires at.
Но это всё в design doc’ах.
На деле на тот момент времени у нас творился дикий запад — как с точки зрения полноты поддержки stability-фичей в клиентах IAM, так и adoption официальных клиентов в командах сервисов облака.
Итого
При отключении AZ две из трёх реплик сервиса отключились вместе с зоной, третья стала мастером, но ушла в RO из-за synchronous_mode_strict. Token Service не мог совершать запросы в БД из-за отсутствия поддержки RO-режима в фреймворке, после чего с песнями и плясками ушёл в ребут-цикл до окончания учений. Подавляющее большинство сервисов-клиентов Token Service, включая web-консоль облака, бегали в него примерно на каждый чих — и остались без возможности авторизовываться при запросах друг к другу. Такой вот бутерброд.
Немного про infra DNS
В процессе учений мы довольно долго грешили на проблемы DNS как причину отказа сервисов, потому что в логах разных компонентов всплывали варнинги и ошибки name resolution. Исследование показало, что из-за выключенного topology aware routing в нашем Cilium DNS-запросы компонентов облака разъезжались round robin’ом по всей группировке DNS-серверов в обеих AZ. Что само по себе звучит сомнительно, но в случае отказа зоны означает, что 50% DNS-запросов проливается на пол, пока мёртвые эндпоинты не выключатся из балансировки.
И хотя в результате расследования инцидента мы пришли к выводу, что проблемы DNS никак не законтрибьютили в причины отказа облака — проблемный DNS как минимум смазал диагностическую картину и фактически пустил наше расследование не туда с самого начала проблем. Что ещё более важно — этот дырявый ломтик, скорее всего, сидел и ждал других просчётов в конструкции облака, с которыми можно было бы заколлабиться для какого-нибудь другого нескучного инцидента.
В общем, исправление странной модели роутинга DNS-трафика добавили к списку других action item’ов инцидента.
Object Storage
Одной из рабочих гипотез относительно причины отказа Object Storage, разумеется, был отказ Token Service. И какая-то доля правды в этом есть: мы не проводили глубокий ретроспективный анализ, «а что было бы, если», но весьма вероятно, что одного только отказа Token Service было бы достаточно для отказа или существенной деградации Object Storage. Однако расследование инцидента показало, что наше объектное хранилище схлопнулось самостоятельно, без дополнительной помощи со стороны упавшего компонента IAM.
Устройство Object Storage
У нас есть прекрасная статья о деталях технического устройства нашего Object Storage. Но для понимания причин отказа достаточно понимать общую конструкцию: контент объектов хранится в кластерах Ceph, каждый объект задублирован в двух AZ, и это не говоря об избыточности в схеме хранения в пределах одной AZ — серьёзно, почитайте статью. Между пользователем и его данными стоит машинерия, представленная хранилищем метаданных на шардированном Postgresql и флотом stateless-рантаймов, который можно безопасно сдувать/раздувать и мигрировать под производственные нужды.
Таким образом, наш сторадж запроектирован так, чтобы переживать отказ одного ДЦ и одновременно, например, произвольной стойки в живом ДЦ в придачу. Так что же случилось?
Отказ API-бэкендов
Расследование инцидента показало, что весь флот API-бэкендов устроил забастовку и отстрелился по liveness-пробам. Liveness-пробы призваны автоматизировать древнейший Ops-приём IT-индустрии: если что-то не работает — надо попробовать выключить и включить.
В случае нашего Object Storage liveness-пробы API-бэкендов, помимо прочего, бегали по эндпоинтам Ceph, чтобы собрать полную картинку о карте доступности блобов и на ее основании сделать выводы о том, способен ли инстанс API-бэкенда обслуживать пользовательские запросы к данным.
Бизнес-логика liveness-пробы была реализована прекрасно и не содержала каких-то глупых багов, которые привели к отказу. Проблема в том, что мы забыли согласовать тайм-аут ожидания кубом ответа liveness-пробы с тайм-аутами ожидания бэкендом ответов от Ceph. Пока бэкенд скрупулёзно бегал по эндпоинтам Ceph, чтобы собрать для себя картинку о доступности стораджей, k8s дотерпел до тайм-аута на ответ liveness-пробы и посчитал пробу проваленной. И так для всех бэкендов.
Выводы
Очевидный вывод, он же фикс root cause: тайм-аут на liveness-пробу поднять, тайм-ауты на пробы от бэкенда к Ceph — опустить.
В целом вокруг обсуждения механики liveness-пробы на разборе инцидента завелась довольно жаркая инженерная дискуссия о том, что пробы надо делать то ли не так, то ли так, но не ту (помимо liveness, в k8s также существуют readiness и startup), то ли вообще настоящие самураи пробами не пользуются. Поэтому следующий важный вывод для нашей организации: нам нужен единый централизованный гайд от команды Development Platform о том, как правильно варить пробы для рантаймов сервисов облака, а также каноничная имплементация в common framework, которая этому гайду бы соответствовала.
Ещё одно интересное наблюдение касается способа проведения учений: нам повезло выбрать один из самых жестоких методов эмуляции отказа AZ. Понятно, что было бы странно гасить компоненты в отключаемой AZ graceful-механикой — так бы мы протестировали не готовность к отказу, а готовность к плановому выводу зоны. Но спонтанный сетевой разрыв тоже можно эмулировать по-разному. Какой-нибудь rule с TCP Reset кажется недурственным выбором, но в такой механике мы бы не смогли поймать проблему liveness-проб в Object Storage.
Как в человеческих отношениях игнорирование хуже прямого отказа, так и в сетевом взаимодействии звенящая тишина в ответ на TCP SYN способна вскрыть неожиданные проблемы в динамике вашего рантайма. Сегодня про connection timeout помнят не только лишь все.
Остальное облако
Понятно, что 30 action item’ов, которые были прилинкованы к тикету учений, покрывают не только три проблемы, которые я описал в тексте. По результатам учений каждая команда посмотрела на себя, свой сервис и свои процессы: что моргало, что икало, кто куда смотрел и чего писал.
Помимо проблем с кодовой базой и инфраструктурой, крупные инциденты прекрасно вскрывают процессные дыры и шероховатости, которые тоже можно и нужно чинить в организации. В конце концов код, закоммиченный в репозитории, отвечает за то, как ваш сервис себя поведёт прямо сейчас. А процессы и майндсет людей в организации влияют на то, что с сервисом будет происходить через месяц или год.
Любой инцидент в сервисе — это урок, за который компания платит в лучшем случае деньгами и нервами своих сотрудников, в худшем — своей репутацией. Поскольку урок уже оплачен, нам остаётся только сделать из него максимально возможное количество выводов для предотвращения подобных проблем в будущем.
Что дальше
Учения для нас были своего рода экспериментом, и, глядя на находки, эксперимент мы признали успешным. Но теперь мы окончательно и безоговорочно в проде. Учения на внутренней инфраструктуре — довольно нормальная практика для высокотехнологичных компаний, разрабатывающих массовые сервисы. Учения в публичном облаке — нууу, это интересное упражнение. Мы успели их провести, пока мы были маленькие и без IaaS. Но для взрослой фазы существования облака по большому счёту видятся три потенциальные стратегии для проведения учений:
Полное отключение AZ
Давайте честно, большинство клиентов облака не инвестируют в отказоустойчивую инфраструктуру. Как я говорил в начале статьи, чтобы добивать последние девяточки надёжности, ты должен не просто «взять отказоустойчивую инфраструктуру», а изучить кирпичики, контракты и принципы, которые эта инфраструктура предоставляет, и интегрировать их в свой процесс проектирования, разработки, развёртывания и эксплуатации сервиса. Не говоря о том, что для отказоустойчивости придётся несколько перезаложить чек на размер рантайма. Это классическая тройная крутилка между отказоустойчивостью, стоимостью ресурсов и сложностью системы (стоимостью технического штата клиента).
Облачные провайдеры стремятся «стягивать» этот треугольник к центральной точке ради счастья пользователя, но в конечном итоге выбор всё равно остаётся за клиентом. И полный отказ зоны доступности публичного облака — гарантирует полный отказ некоторых сервисов части клиентов.
Мне интересно, существует ли бизнес-модель публичного облачного провайдера, который рассчитан на осознанных клиентов, которые заинтегрированы в процесс учений по отказу инфраструктуры. Но сейчас мы живём в реальности, где провайдер, который на регулярной основе вырубает зоны доступности, — плохой провайдер.
Учения на внутренний контур, без влияния на клиентские рантаймы
На первый взгляд решение выглядит очевидным и неплохим компромиссом. И это правда, что в такой модели, например, можно полноценно тестировать SaaS-сервисы. Но для IaaS и PaaS всё осложняется. Где нам стоит прочертить границу?
Понятно, что в этой опции мы договариваемся не трогать гипервизоры, на которых крутятся пользовательские виртуалки и инстансы БД. Можем ли мы вырубить зональный control plane compute? Кажется, что нет, хотя бы потому, что тогда мы сломаем связь между global CPL и конечными виртуалками, со всеми вытекающими: клиенты не смогут создавать, удалять, рестартовать и ещё каким-либо образом управлять своими VM, а также получать с них статус.
Тогда из всей машинерии Compute, а также всех остальных IaaS- и PaaS-сервисов предметом для тестирования в таких учениях остаётся только global CPL. И это, конечно, здорово, но не предоставляет всего разнообразия данных о процессах, которые происходят в системе при полноценном отказе зоны. Не говоря о том, что дизайн процесса таких учений — довольно увлекательная работа, которая требует аккуратного выпиливания лобзиком вокруг систем, которые должны оказаться в контуре учений, причём, вероятно, независимо в Underlay- и Overlay-сетях провайдера.
Ну и вишенка на торте — такие учения на продакшне всё ещё несут ненулевую вероятность отказа сервисов облака для конечных клиентов платформы в случае, скажем так, ультимативного успеха этих учений. Для нас такая модель учений выглядит компромиссом, который позволяет собрать худшее из обоих миров.
Учения на preprod
Последняя опция выглядит довольно прямолинейным ответом на наш вопрос: если не хочешь сломать прод — ломай не прод. У нашего облака есть отдельная инсталляция, которая называется preprod и с которой внешние клиенты не взаимодействуют никогда. Фактически это релизный stage, через который деплоятся все сервисы облака. Но важно, что preprod облака — это не просто среда для экспериментов, в которую команды деплоят свой непротестированный код.
В препроде все сервисы облака интегрированы между собой точно так же, как это сделано на проде, и в целом препрод — это полноценная отдельная инсталляция всего облака от железа до веб-консоли, с теми отличиями, что там сильно меньше мощностей, чуть пониже SLA и нет «диких» пользователей.
Естественно, что, тестируя препрод, мы можем делать только косвенные выводы о том, как прод будет чувствовать себя в похожей обстановке. Здесь хочется провести аналогию с продуктами материального мира: когда я прочитал мегабайты статей, просмотрел гигабайты видеообзоров и выбрал безопасный автомобиль своей мечты — та железка на колёсах, которую я покупаю в салоне, и та железка, которая прошла краш-тест по модели фронтального удара с 25%-м перекрытием, — это две разные железки. По крайней мере мне бы хотелось в это верить.
Вопрос в воспроизводимости производства инсталляций облака. Мы заинтересованы в том, чтобы держать препрод максимально похожим на прод. Речь не только о том, чтобы катать в обе инсталляции одинаковые бинари сервисов, но также о том, чтобы для двух инсталляций идентично выглядела инфраструктура: топология кубов, механизмы подачи трафика, те же железки в стойках.
И то же самое касается процессов — да, требования к доступности препрода в каждый момент времени ниже, чем к проду, они никогда не выровняются, но эти требования непрерывно повышаются и стремятся к проду по асимптоте. И это позволяет нам в рамках тех же учений на препроде тестировать не просто код, а всю систему в сборе: включая «человеческие» процедуры и процессы по реакции на отказ.
Для себя в качестве оптимального решения на будущее мы выбрали учения на препроде как целевую механику. За этот год мы уже успели подойти к снаряду и провести точечные учения по отказу Token Service без влияния на внешних клиентов. По мере накопления ценного опыта, я полагаю, мы будем делиться новыми находками и весёлыми историями. Но на сегодня у меня на этом всё — до встречи в следующих сериях!
Приходите в сообщество MWS Cloud Platform, чтобы обсудить решения или архитектуру. В чате отвечает инженерная команда платформы.
