Перевод статьи подготовлен специально для студентов курса «DevOps практики и инструменты», который стартует уже сегодня!

---

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

Большинство компаний в части практик промышленной эксплуатации в итоге приходят к подходам “Дикого Запада". Каждая команда с помощью проб и ошибок самостоятельно определяется с инструментами и лучшими практиками. Но это часто влияет не только на успех проектов, но и на инженеров.

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

Успешные организации:

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

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

Когда проверять сервис на готовность к продакшену?

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

Делайте проверку, когда:

• Выпускаете новый сервис в продакшн.
• Передаете эксплуатацию продакшн-сервиса другой команде, такой как SRE.
• Передаете эксплуатацию продакшн-сервиса новым сотрудникам.
• Организуете техподдержку.

Чеклист проверки готовности к продакшену

Некоторое время назад, в качестве примера, я опубликовала чеклист проверки готовности к продакшену. Несмотря на то, что этот список появился при работе с клиентами Google Cloud, он будет полезен и применим за пределами Google Cloud.

Проектирование и разработка

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

Управление конфигурацией

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

Управление релизами

• Подробно документируйте процесс релиза. Опишите как релизы влияют на SLO (например, временное увеличение задержек из-за промахов кэша).
• Документируйте канареечные релизы.
• Разработайте план анализа канареечных релизов и, при возможности, механизмы автоматического отката.
• Убедитесь, что откаты могут использовать те же процессы, что и развертывание.

Пригодность к мониторингу (Observability)

• Убедитесь, что собирается набор метрик, необходимых для SLO.
• Убедитесь, что можно отличить между собой клиентские и серверные данные. Это важно для поиска причин неисправностей.
• Настройте оповещения, чтобы уменьшить трудозатраты. Например, удалите оповещения, вызванные рутинными операциями.
• Если вы используете Stackdriver, то включите метрики платформы GCP в свои дашборды. Настройте оповещения для GCP-зависимостей.
• Всегда распространяйте входящую трассировку. Даже если вы не участвуете в трассировке, это позволит сервисам более низкого уровня отлаживать проблемы в продакшене.

Защита и безопасность

• Убедитесь, что все внешние подключения зашифрованы.
• Убедитесь, что ваши продакшн-проекты имеют правильную настройку IAM.
• Используйте сети для изоляции групп экземпляров виртуальных машин.
• Используйте VPN для безопасного подключения к удаленным сетям.
• Документируйте и мониторьте доступ пользователей к данным. Убедитесь, что весь доступ пользователей к данным проверяется и логируется.
• Убедитесь, что конечные точки для отладки ограничены ACL.
• Санитизируйте пользовательский ввод. Настройте ограничения размера полезной нагрузки для пользовательского ввода.
• Убедитесь, что ваш сервис может избирательно блокировать входящий трафик для отдельных пользователей. Это позволит блокировать нарушения, не влияя на других пользователей.
• Избегайте внешних конечных точек, которые инициируют большое количество внутренних операций.

Планирование мощностей

• Документируйте, как масштабируется ваш сервис. Например: количество пользователей, размер входящей полезной нагрузки, количество входящих сообщений.
• Документируйте требования к ресурсам для вашего сервиса. Например: количество выделенных экземпляров виртуальных машин, количество экземпляров Spanner, специализированное оборудование, такое как GPU или TPU.
• Документируйте ограничения ресурсов: тип ресурса, регион и т. д.
• Документируйте ограничения квот для создания новых ресурсов. Например, ограничение количества запросов GCE API, если вы используете API для создания новых инстансов.
• Рассмотрите возможность проведения нагрузочных тестов для анализа снижения производительности.

Вот и все. До встречи на занятиях!