Matthew Liste, исполнительный вице-президент и глобальный руководитель инфраструктуры в American Express, считает, что успешность технической платформы определяется не количеством ее компонентов, а способностью скрывать сложность и предоставлять разработчикам стабильный и понятный опыт. В своем выступлении на QCon San Francisco Liste опирался на более чем 20 лет, проведенных за созданием платформ и инфраструктуры для критически важных систем в Goldman Sachs, JPMorgan Chase и American Express.
Платформами, о которых говорил Liste, пользуются многочисленные внутренние разработчики: около 20 тысяч пользователей в American Express и около 60 тысяч в JPMorgan Chase. Несмотря на отличие масштабов от поставщиков облачных услуг, он считает, что те же основные принципы применимы к любой команде, создающей слой, от которого зависят другие.
Хорошая платформа скрывает сложность, но не скрывает происходящее
Liste начинает с определения платформы как набора интегрированных технологий, образующих основу для построения приложений. Он сравнивает ее с системами водоснабжения и канализации: пока все работает, пользователь не думает об инфраструктуре, стоящей за ними, но сразу замечает ее при сбое.
Поэтому работа с платформой должна быть интуитивно понятной, а сама она — использовать общие и взаимозаменяемые компоненты, такие как унифицированные основы для мониторинга, идентификации и пространств имен. Такая компонуемость делает платформу похожей на кубики Lego, а не на набор разрозненных сервисов, которые начинают работать вместе лишь после дополнительных усилий.
Стабильность, безопасность и масштабируемость — не опциональные преимущества
Liste выделяет то, что называет «тремя опорами»: стабильность, безопасность и масштабируемость. Требуемый уровень доступности зависит от ценности системы; по его словам, системы авторизации кредитных карт в American Express работают на уровнях, достигающих шести девяток, тогда как другие системы могут выдерживать более длительные простои.
Он также подчеркивает, что первоначальный успех может скрывать проблемы масштабирования. Платформа, хорошо работающая на раннем этапе, может столкнуться с узкими местами при росте использования, что непосредственно скажется на стабильности. Поэтому цели уровня обслуживания (SLO) необходимо определять вместе с потребителями и соблюдать с течением времени, а не только в день запуска.
Непрерывное обновление и сокращение работы, не создающей отличительной ценности
Liste считает поддержание платформы в актуальном состоянии одной из самых сложных и наиболее часто откладываемых задач. Накопление отложенных обновлений может сделать переход на более новую версию дорогостоящим и повлиять на клиентов. Он предлагает внутренний стандарт, который называет 0114: ноль сотрудников для регулярного обслуживания благодаря автоматизации, возможность обновить все компоненты парка, завершить обновление менее чем за день и проводить цикл обновлений каждые 14 дней или чаще.
Он также призывает не создавать заново то, что уже доступно с достаточным качеством. Вместо написания нового движка PostgreSQL он приводит пример создания управляющего слоя, выполняющего ежедневное резервное копирование в объектное хранилище, — именно той части, которая необходима для соблюдения нормативных требований. Идея заключается в том, чтобы сосредоточиться на ценности, необходимой организации, а не на задаче, наиболее интересной с инженерной точки зрения.
Четкие решения и договорные отношения с потребителями
Владельцы платформ должны прислушиваться к клиентам, но не выполнять каждую просьбу. Ресурсы ограничены, а сохранение устаревших функций без вывода из эксплуатации накапливает технический долг и мешает развивать более важные направления. Поэтому у платформы должна быть четкая «позиция»: она должна определять, что будет поддерживать, от чего откажется и что служит большинству пользователей.
Это также предполагает официальное определение границ ответственности через API, соглашения об уровне обслуживания и процессы. Недостаточно, чтобы команда знала, что она предоставляет; потребитель также должен понимать, что входит в его ответственность и какие границы платформа не пересекает. Liste сравнивает платформы с компонентами фиксированной формы: ограниченная команда не может создавать отдельный продукт для каждого клиента.
Практический опыт: пробуйте раньше и используйте абстракцию, не скрывая деталей
Liste советует быстро и многократно терпеть неудачи после принятия решения о создании, защищая клиентов во время перехода. Он ссылается на ранние эксперименты с контейнерами Linux и различными инструментами оркестрации, которые в итоге привели к переходу на Kubernetes; ранние эксперименты позволили команде учиться, не дожидаясь созревания одного решения.
В то же время слои абстракции не должны скрывать происходящее под ними. Можно предоставить пользовательский интерфейс, API и Infrastructure as Code, например Terraform, но необходимо обеспечить достаточную видимость и детализацию для понимания сбоев и изменения поведения при необходимости. В заключение Liste подчеркивает важность построения поверх открытого исходного кода и открытых стандартов, чтобы команда платформы могла сосредоточиться на интеграции и добавленной ценности, а не воссоздавать каждый слой с нуля.
Почему эти принципы важны?
Главная ценность подхода Liste заключается в том, что он превращает создание платформ в долгосрочное операционное обязательство, а не в проект по запуску набора инструментов. После внедрения платформа влияет на множество команд, поэтому возможность обновления, ясность ответственности и управление выводом из эксплуатации становятся важнее быстрого добавления новой функции. Эти принципы остаются рекомендациями, основанными на практическом опыте, а не единым стандартом, гарантирующим успех; уровень доступности, масштаб автоматизации и выбор абстракций по-прежнему зависят от природы системы и потребностей ее пользователей.