Создание платформы надежности для распределенных систем

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

Почему качество и надежность нуждаются в платформенном решении

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

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

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

Это делает определенные вещи сложными. Отладка чего-то, что охватывает сервисы, означает переключение между инструментами логирования с языками запросов разной формы. Надежность на уровне системы означает корреляцию вручную из сломанных панелей мониторинга.

Основы: базовые строительные блоки платформы

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

Наблюдаемость обеспечивает инструментарий распределенного приложения. Без сквозной видимости поведения системы победы в надежности - это выстрел в темноте. Платформа должна объединять три столпа наблюдаемости: структурированное логирование с использованием общих схем полей, инструментарий метрик с использованием общих библиотек и распределенную трассировку для отслеживания запросов через границы сервисов.

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

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

Второй фундаментальный навык - это автоматическое тестирование с валидацией через тестовые конвейеры. Все сервисы нуждаются в нескольких уровнях тестирования, которые должны быть выполнены перед развертыванием в производство: модульные тесты бизнес-логики, интеграционные тесты компонентов и тесты совместимости API. Платформа упрощает это, предоставляя тестовые фреймворки, хостинг тестовых сред и интерфейсы с системами CI/CD.

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

Контрактное тестирование особенно важно в распределенных системах. Когда сервисы общаются друг с другом через API, изменения в одном сервисе могут начать ломать потребителей. Контрактные тесты гарантируют, что поставщики продолжают соответствовать ожиданиям потребителей, обнаруживая критические изменения до выпуска. Платформа должна упрощать определение контрактов, автоматически проверять контракты в CI и давать явную обратную связь, когда контракты нарушаются.

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

Переход от 0→1: строительство с ограничениями

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

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

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

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

Тестирование инфраструктуры естественным образом следует как вторая ключевая возможность. Общая тестовая инфраструктура с обеспечением зависимостей, управлением фикстурами и очисткой снимает операционную нагрузку с каждой команды. Она также должна быть способна запускать локальную разработку и выполнение CI, чтобы все были на одной странице, где инженеры разрабатывают тесты и где выполняется автоматическая валидация.

Фокус в начале должен быть на общих тестовых случаях, которые применимы к большинству сервисов: настройка тестовых баз данных с тестовыми данными, заглушки для внешних API-зависимостей, проверка API-контрактов и выполнение интеграционных тестов в изоляции. Специальные требования к тестированию и крайние случаи могут быть рассмотрены в последующих итерациях. Достаточно хорошо сделанное раньше лучше, чем идеально сделанное позже.

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

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

\