DevOps и система непрерывной доставки

Применять сцену

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

Проблема не в том, что команда не работает, а в том, что это так.Отсутствие автоматизированной системы и норм сотрудничества, связывающих разработку, тестирование, развертывание, транспорт и связьСцены, описанные здесь, предназначены для программных команд, которые рассчитывают создать стандартизированные методы DevOps и возможности непрерывной доставки, и отображаются на страницах.ZhiHua Tech (Shanghai e-Seok-shu Hsien-Shui Information Technology Ltd.)Доступные методы построения и доставки системы DevOps не представляют собой раскрытие данных для конкретных клиентов.

Типичные оперативные задачи

1. Длительный цикл выпуска, несколько ручных операций и высокая частота ошибок

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

2. Отсроченные отзывы от тестирования и ручного качества снизу вверх

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

3. Низко наблюдаемая онлайн-реакция и пассивная реакция на отказ

• Логи разбросаны и их трудно подключитьВ архитектуре микросервисов запрос пользователя может охватывать 5-10 примеров сервисов. Логи сервисов разбросаны по разным серверам, а проблемы проверяются пошагово, без единого последовательного идентификатора трека.
• Мы опаздываем на слежку.Правила тревоги являются широкими — часто только тогда, когда число пользователей значительно сократилось, а бизнес был поврежден — и вызывают тревогу. Не хватает анализа связей и раннего предупреждения для операционных показателей (более низкое количество, скорость успеха платежей) и показателей инфраструктуры.

Программное проектирование мышления

1. Создание стандартизированных линий потока CI/CD

• Спусковые механизмы представления кода: Разработка Push-кода для конкретной ветви автоматически запускает строительство потоковой линии - компиляцию, тестирование блока, сканирование кода (SonarQube), безопасное сканирование, зеркальное построение. Если какая-либо ссылка не удается, разработчик получает мгновенное уведомление в IDE или Enterprise IM.
• Экологическое самообслуживаниеТестовая среда и среда предварительной отправки определяются стандартным определением инфраструктуры или кода (terraform / Ansible), и любой член команды может создать полную среду одним ключом.
• Выпуск Grayscale и развертывание канарейкиПроизводственные выпуски сначала развернуты на 5-10%, а наблюдение за основными показателями (ошибки, задержки, бизнес-данные) является нормальным и масштабируется до полного объема.

2. Создание автоматизированных систем стратификации испытаний

• Испытания пирамидыБольшое количество единичных тестов (быстрых, заслуживающих доверия) Правильный интеграционный тест Небольшое количество сквозных тестов. Каждая потоковая линия запускается сначала единичными тестами (секундами), а затем только после прохождения проходит комплексное тестирование.
• Автоматизация регрессионного тестаБазовая линия производительности ключевого интерфейса автоматически тестируется в каждой сборке. Если представление приводит к задержке в интерфейсе P99, превышающей порог, сборка автоматически отмечает сбой.

3. Создание полной цепной детектируемости

• Единый журнал и отслеживание ссылок: На основе ELK/Loki + OpenTelemetry все журналы обслуживания собираются и вставляются в TraceID. Введите TraceID при поиске вопроса, чтобы увидеть время, необходимое для вызова полной ссылки и каждого узла.
• Ди-Ди, смотри и будильник.Мониторинг инфраструктуры (CPU/RAM/disk/network) + Мониторинг приложений (QPS/delayed/mistake) + Операционный мониторинг (lower/payment success) связан с тремя уровнями. Правила сигнализации поддерживают односимметричное/кольцевое обнаружение, чтобы избежать неправильной отчетности и занижения фиксированных пороговых значений.

Объем системных мощностей

Код и управление строительством

• GitFlow/Trunk-Based
• Интегрированное построение и управление мультимодульными проектами
• Качество кода дверной проем: статическая сканировка, обнаружение зазора безопасности, проверка покрытия испытания
• Комплексное управление складом продукции (Docker mirror/JAR/WAR/NPM)

• Текущая интеграция и развертывание

• Дженкинс / Gitlab CI / GitHub Actions Waterline
• Многоэкологическое автоматическое развертывание (разработка/тестирование/предварительная публикация/производство)
• Выпуск Greyscale, развертывание Blue Green, стратегия обновления
• Выдача потока одобрения и автоматизация записей об изменениях

Испытание на автоматизацию

• Модульное тестирование / Комплексное тестирование / Политика сквозного уровня тестирования
• Контрольные показатели эффективности и регрессионные тесты
• Тестирование по взаимному согласию (Pact) для обеспечения совместимости услуг
• Тест Chaos Mesh для проверки устойчивости

• Наблюдения за платформами

• ELK / Платформа Grafana Loki Central Log
• Prometheus + Grafana индикатор мониторинга и визуализации
• Открытая телеметрия, отслеживание по полным ссылкам.
• Многоканальное уведомление (круиз/микро/летающая книга/PagerDuty)

Инфраструктура — это код

• Облачная ресурсная организация Pulumi Cloud
• Управление конфигурацией SaltStack
• Kubernetes Cluster Management и Auto-Scalp
• Развертывание стандартных приложений Helm Chart

Доставляемые

Предполагаемая ориентация на ценность

• Как частота, так и надежность выпускаДо и даже чаще ежемесячные выпуски выпускаются по требованию, причем каждый выпуск значительно сокращается за счет небольшого набора изменений.
• 70% +• Устранение искусственных соединений и ожидающих звеньев через автоматизированные линии потока.
• Среднее время ремонта неисправностей (МТТР) сжато от родителя до минутыПолное отслеживание цепей + умная сигнализация, корень позиции больше не угадывается.
• Работа в команде прошла путь от «сериалов и так далее» до «сбора вместе».Экологическое самообслуживание, автоматизированная обратная связь, разработка и QA больше не ждут друг друга.