Руководство Jumei: В этой статье приведены характеристики, связанные со стабильностью.Эти характеристики получены в результате обзора и сводки большого количества реальных онлайн-ошибок за пять лет с момента создания Shunfengche.Я надеюсь, что это поможет вам улучшить стабильность вашего Сервисы.

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

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

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

1. Глоссарий

В следующем описании будет использоваться много технических терминов.Для облегчения понимания эти термины кратко поясняются здесь:

Классификация услуг: в соответствии с потребностями бизнеса, как правило, нам нужно разделить самую маленькую систему на службы первого уровня, и как только возникает проблема, мы должны решить ее в первую очередь. Услуги, влияющие на основные бизнес-показатели (такие как количество заказов, количество заказов и т. д.), мы определяем как услуги первого уровня, а другие — как услуги второго уровня.
Предварительный кластер: набор сред, который точно такой же, как развертывание рабочей онлайн-среды, только беспроводной трафик, внутренний доступ и трафик с обратной связью в кластере.
Кластер с малым трафиком: Набор сред, которые полностью соответствуют развертыванию производственной онлайн-среды.Посредством управления трафиком в этот кластер будет попадать только трафик отдельных городов, а трафик в кластере закрыт.
Выпуск в оттенках серого: процесс выпуска разделен на кластер предварительного просмотра, городской кластер в градациях серого, механизм выпуска 10% трафика, 50% трафика и 100% трафика, чтобы обеспечить безопасный онлайн-процесс.
Полное стресс-тестирование: решение для стресс-тестирования производственной среды, не влияющее на онлайн-сервисы. Он используется для определения пропускной способности и узких мест производственной среды.
Несколько компьютерных залов: благодаря развертыванию нескольких компьютерных залов в случае сбоя компьютерного зала трафик можно быстро переключить на другие компьютерные залы, чтобы уменьшить потери. Полный набор решений, включающих маршрутизацию трафика, замкнутый цикл трафика, синхронизацию данных, согласованность данных, реагирование на стихийные бедствия и многие другие связи.

2. Характеристики стабильности

Стабильность конструкции

[Обязательно] Вызывающий должен установить период тайм-аута, а тайм-аут ссылки вызова уменьшается сверху вниз.Рекомендуется установить период тайм-аута следующим образом:

[Обязательно] Недавно добавленные зависимости основного процесса по умолчанию являются слабыми зависимостями.Если вам нужны новые расширенные зависимости, вам необходимо пройти проверку;
[Обязательно] Если нижестоящая служба обеспечивает обнаружение службы, все службы должны обращаться к службе через обнаружение службы, что удобно для обнаружения службы для управления нижестоящими узлами и тайм-аутом;
[Обязательно] Все внутренние службы должны иметь доступ к обнаружению служб, а внешние службы должны продвигать доступ к обнаружению служб;
[Рекомендация] Рекомендуется, чтобы фреймворк поддерживал ручной предохранитель в один клик для зависимых служб;
[Предложение] Дизайн службы отдает приоритет дизайну без сохранения состояния;
[Предложение] При написании интерфейса рекомендуется учитывать защиту от повторного входа;
[Предложение] Принцип проектирования системы прост и надежен, предпочтение отдается зрелой технологии;
[Рекомендация] Основная служба является обязательной, другие рекомендации и интерфейс рекомендуют установить разумную конфигурацию ограничения тока.

Развертывание и операции

[Обязательно] Категорически запрещается напрямую оперировать онлайн-данными без передачи интерфейса или метода инкапсуляции во временный скрипт, при необходимости он должен быть протестирован QA;
[Обязательно] Онлайн-сервис должен быть запущен через онлайн-платформу и подключен к платформе качества (функции включают в себя автоматический случай, график основной кривой и другие онлайн-контрольные списки), и обязательно оставаться и наблюдать».
[Обязательно] Услуги первого уровня должны включать предварительные кластеры, кластеры с небольшим трафиком (за исключением некоторых специальных служб) и развертывание в двух комнатах;
[Рекомендация] Рекомендуется, чтобы онлайн-сервисы не первого уровня включали предварительные кластеры;
[Рекомендация] Рекомендуется планировать пропускную способность нового сервиса онлайн, рекомендуется проверять пропускную способность модуля с помощью нагрузочного тестирования интерфейса или нагрузочного тестирования полного трафика.

Мониторинг сигналов тревоги

[Обязательно] Компьютеры онлайн-сервиса должны иметь базовый мониторинг и оповещения, включая ЦП, ввод-вывод, память, диск, дамп ядра и порты;
[Обязательно] Онлайн-сервисы должны иметь базовый мониторинг сервисов, включая интерфейс qps, фатальное число и трудоемкость;
[Предложение] Основные бизнес-показатели (количество выданных заказов, количество срочных заказов, сумма оплаты и т. д.) должны контролироваться и предупреждаться;
[Предложение] Необходимо иметь общий рынок услуг, который может охватывать мониторинг основных модулей в этом направлении, чтобы облегчить и быстро локализовать проблемы с обслуживанием.

управление изменениями

【Обязательно】Любое изменение услуги уровня 1 требует механизма выпуска оттенков серого;
[Обязательно] Любые изменения службы первого уровня, включая изменения службы и изменения конфигурации, должны иметь соответствующий план отката, чтобы гарантировать, что изменения могут быть быстро отменены в случае ненормальных изменений;
[Предложение] Старайтесь избегать использования кода в Интернете;
[Рекомендация] При откате сервиса рекомендуется одновременно откатить соответствующий код и конфигурацию, чтобы убедиться в правильности основного кода;
[Рекомендация] Для изменений конфигурации, особенно сложных изменений конфигурации, рекомендуется добавить соответствующий механизм проверки конфигурации.

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

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

Принципы устранения неполадок

[Обязательно] Если на линии есть неисправность, она должна быть обработана в первую очередь;
[Обязательно] При сбое на линии, если есть изменение, оно будет отменено как можно скорее;
[Обязательно] Если на линии есть неисправность, должна быть организована проверка;
[Обязательно] Требуются спецификации повторной экспертизы, и повторные экспертизы проводятся в соответствии со спецификациями.

3. Антипаттерн стабильности

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

3.1 Проектирование отказоустойчивости и отказоустойчивости

Антипаттерн 3.1.1 ** **Стратегия чрезмерного объединения узлов

【Пример】 Чтобы повысить процент успешных запросов, в случае отказа нижестоящих узлов принимаются меры по предохранению.Например, если ошибки доступа происходят 5 раз подряд в течение 1 минуты, узел будет отключен и не будет вызываться. снова (восстановление через некоторое время). Сеть дрожит один день. , 3 из 4 экземпляров нисходящей службы перешли в режим прерывателя цепи, в результате чего весь трафик, доступ к нисходящему потоку, упал на оставшийся экземпляр, и давление было слишком большой, дробящий экземпляр. Нисходящие сервисы лавинообразны, и вся система становится недоступной.

【решение】 В режиме термозакрепления также требуются меры защиты от плавления, чтобы избежать проблем со стабильностью, вызванных чрезмерным закреплением.

Антипаттерн 3.1.2 Фиксированная последовательность повторов

【Пример】 Каждая последовательность повторных попыток является «следующей».

【как результат】 Один из них — лавинный: если предположить, что последовательность повторных попыток определенного типа запроса — AB, то в случае неудачи A B выдержит двойную нагрузку. Потерянный трафик: Предполагая, что число повторных попыток равно 2, если A и B перезапускаются в одно и то же время при подключении к сети, запрос с последовательностью повторных попыток AB не должен иметь результата.

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

Антипаттерн 3.1.3 Необоснованная установка времени ожидания

【Пример】 Настройка тайм-аута вышестоящей службы является необоснованной, и при возникновении проблем с нижестоящей службой вышестоящая служба будет напрямую перетаскиваться вниз.

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

Антипаттерн 3.1.4 Не учитывает влияние нескольких обращений к нижестоящим в одном и том же запросе.

【Пример】 Нет проблем с установкой тайм-аута при вызове нижестоящей службы, но нижестоящая служба будет вызываться несколько раз подряд в одном и том же запросе.

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

Антипаттерн 3.1.5 Необоснованная логика повторных попыток

【Пример】 Повторные попытки выполняются в нескольких местах по всему каналу. При сбое нисходящей службы повторные попытки усиливаются, что приводит к лавине обслуживания.

【решение】 Оцените механизм повторных попыток, упорядочите всю цепочку обработки запросов и убедитесь, что повторные попытки сходятся в одном месте.

Антипаттерн 3.1.6 Не учитывает влияние сбоев в бизнесе

【Пример】 Для определенной бизнес-формы характерно наличие всплесков запросов в течение получаса и целого часа.Из-за праздника трафик, доступный к нисходящему каналу, внезапно резко увеличился, что привело к лавине нисходящих сервисов.

【решение】 Уравновешивание всплесков бизнеса для уменьшения влияния пикового трафика на нижестоящие сервисы.

Антипаттерн 3.1.7 Нет отказоустойчивости для аномального ввода

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

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

Антипаттерн 3.1.8 Интерфейс не поддерживает идемпотентный дизайн

【Пример】 Интерфейс не поддерживает идемпотентность, и при сбое сети возникает большое количество повторных попыток, что приводит к большому количеству ошибок основных данных.

【решение】 При проектировании интерфейса необходимо учитывать требование идемпотентности.

Антипаттерн 3.1.9 Отсутствие слабых зависимостей от непрофильных процессов

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

【решение】 Регулярно разбирайте системный процесс, минимизируйте систематизацию и минимизируйте второстепенные процессы как слабо зависимые.

Антипаттерн 3.1.10 Не учитывает влияние переполнения идентификатора

【Пример】 Идентификатор использует int32.После переполнения идентификатора служба экспорта работает неправильно.

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

3.2 Развертывание и эксплуатация

Антипаттерн 3.2.1 Сегмент сети не учитывается при развертывании

【Пример】 Фактор сетевого сегмента не учитывается при развертывании сервиса и нескольких экземплярах сервиса на одном коммутаторе.При сбое коммутатора несколько экземпляров сервиса недоступны, а кластер, в котором находится сервис, лавинный.

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

Антипаттерн 3.2.2 Изоляция ресурсов не выполняется, когда службы находятся в одном месте.

【Пример】 Несколько служб совмещены, и одна из них использует слишком высокую загрузку ЦП, что приводит к ненормальной работе других служб.

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

Антипаттерн 3.2.3 Не заниматься основным бизнесом и изоляцией и защитой

【Пример】 Неосновной процесс записывает большое количество сообщений в mq из-за ошибки, что приводит к недоступности всего кластера mq и сбою всего бизнеса.

【решение】 Изоляция MQ основных и неосновных ссылок, раздельное развертывание, изменения в неосновных процессах не повлияют на основной процесс, обеспечивая стабильность основных процессов и сервисов.

3.3. Управление мощностями

Антипаттерн 3.3.1 Неспособность учитывать планирование мощностей

【Пример】 Qps у онлайн-сервиса невелик, а развернуто всего 2 инстанса, при возникновении проблемы в одном инстансе в пиковый период трафик падает на другой инстанс, что перегружает сервис.

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

Антипаттерн 3.3.2 Запуск новых функций без надлежащего планирования мощностей

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

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

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

Антипаттерн 3.4.1 Код Автостоп онлайн

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

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

Антипаттерн 3.4.2 Отсутствует код отката при откате службы

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

【решение】 Когда служба откатывается, код откатывается в первый раз

Антипаттерн 3.4.3 Слишком высокие параметры параллельного развертывания

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

【решение】 Одновременное количество конфигураций развертывания службы, чтобы гарантировать, что оставшиеся машины могут нести весь бизнес-трафик.

Антипаттерн 3.4.4 Запуск или откат службы занимает слишком много времени

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

【решение】 Регулярно проверяйте время запуска и отката службы, чтобы гарантировать, что операция отката может быть завершена как можно скорее в случае сбоя.

Антипаттерн 3.4.5 В файле конфигурации отсутствует действительный механизм проверки

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

【решение】 Установите механизм строгой проверки и проверки файлов конфигурации, особенно тех, которые создаются моделями.

Антипаттерн 3.4.6 Изменения конфигурации не отображаются серым цветом

【Пример】 Изменения, связанные с конфигурацией, недостаточное внимание к осведомленности о стабильности, недостаточное наблюдение и оттенки серого, что приводит к сбою

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

Антипаттерн 3.4.7 Изменения не проходят тщательную проверку

【Пример】 Небольшие изменения, которые казалось ненужными для тестирования, приводящие к низкоуровневым ошибкам, приводящим к сбоям.

【решение】 Любые изменения должны быть протестированы, перепроверены и модифицированы одной строкой кода, что также может привести к сбоям стабильности в сети.

Антипаттерн 3.4.8 Изменения не реализуются строго в соответствии со спецификациями изменений

【Пример】 При выходе в интернет малый трафик и машинный зал А были проверены в строгом соответствии со спецификациями, проблем с сервисами и различных кривых не было, при запуске компьютерного зала Б проверка не проводилась. В результате компьютерный зал Б неисправен. После расследования это произошло из-за отсутствия конфигурации компьютерного зала B.

【решение】 Любое изменение должно строго проверяться по спецификации изменения, а различные кривые и показатели сервиса должны проверяться на каждом этапе запуска.

Антипаттерн 3.4.9 Обновлять данные БД в автономном режиме напрямую через sql

【Пример】 База данных обновляется в автономном режиме напрямую через sql, а текущая ограничивающая защита плохо защищена, что приводит к высокой нагрузке на базу данных и большому количеству тайм-аутов при доступе к онлайн-сервисам.

【решение】 Если нет особых обстоятельств, категорически запрещается напрямую работать с данными БД через sql.Модификация должна быть изменена через интерфейс, который удобен для наблюдения через кривую, а также может снизить риск прямого изменения базы данных;

Чтобы изменить данные БД в пакетном режиме, вам необходимо уведомить БД.После проверки вы можете работать только в том случае, если нет проблем;

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

3.5. Мониторинг тревоги

** Антипаттерн 3.5.1 Отсутствие базового мониторинга**

【Пример】 Отсутствие базового мониторинга приводит к сбоям и неспособности заметить их с первого раза.

【решение】 Разберите контрольный список для базового мониторинга, а также регулярно просматривайте и детализируйте базовый мониторинг службы.

Антипаттерн 3.5.2 Отсутствие мониторинга бизнеса.

【Пример】 Отсутствие мониторинга бизнеса приводит к сбоям и неспособности почувствовать их с первого раза.

【решение】 Для основных процессов и основных бизнес-показателей необходимо добавить бизнес-мониторинг.

Антипаттерн 3.5.3 Возникла проблема с настройкой порога срабатывания сигнализации.

【Пример】 Большое количество срабатываний сигнализации в сети было вызвано бизнес-багами.Во-первых, порог срабатывания сигнализации был временно изменен с 20 до 200. После того, как проблема была устранена и в сети, я забыл изменить его обратно, поэтому оставил эту настройку порога.В результате , когда возникла проблема с последующим бизнесом, я не мог сообщить об этом как можно скорее.

【решение】 Попробуйте использовать кратковременные приглушающие сигналы тревоги вместо повышения порога.

Антипаттерн 3.5.4 Тревога мониторинга в настоящее время недействительна

【Пример】 Бизнес-итерация слишком быстрая, так что информация о сигналах тревоги мониторинга и бизнесе больше не совпадают.

【решение】 Регулярно репетируйте сигналы тревоги, чтобы убедиться в их эффективности.

Для крупных бизнес-итераций в контрольный список необходимо включить сигналы тревоги мониторинга.

3.6 Управление планом

Антипаттерн 3.6.1 Нет соответствующего плана предотвращения лавин, когда движение вверх по течению ненормально.

【Пример】 Внезапное увеличение восходящего трафика службы приводит к тому, что служба мгновенно перегружается, а система лавинообразно

【решение】 Сервис должен заранее подготовить противолавинный план, иначе он легко приведет к выходу из строя всего системного уровня

Антипаттерн 3.6.2 У сервиса нет планов защиты от кистей и атак

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

【решение】 Онлайн-сервисы, особенно те, которые много взаимодействуют с терминалом, должны учитывать стратегии защиты от кистей и атак при разработке и заранее планировать

Антипаттерн 3.6.3 Отсутствует соответствующий план обработки в случае сбоя ниже по потоку

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

【решение】 Сбои в нисходящем направлении, особенно слабо зависимые сбои в нисходящем направлении, требуют соответствующих планов обработки.

Антипаттерн 3.6.4 Срок действия плана отказа истек

【Пример】 Из-за быстрой бизнес-итерации текущая зависимость от определенного нисходящего потока изменилась со слабой зависимости на сильную зависимость.При сбое нисходящего потока выполняется план перехода на более раннюю версию, но бизнес-сбой не восстанавливается.

【решение】 Проводить регулярные учения по плану для обеспечения эффективности плана

3.7. Принципы стабильности и осведомленность

** Антипаттерн 3.7.1 Неуважение к стабильности**

【Пример】 Я думаю, что это нормально, что сервис выходит из строя, но меня не волнует стабильность.

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

Антипаттерн 3.7.2 Отсутствует первый стоп-лосс в случае неудачи

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

【решение】 Если есть сбой, он должен быть устранен в первую очередь, и потеря будет остановлена в первый раз.

Антипаттерн 3.7.3 Использование недостаточно проверенных технологий и решений

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

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

Антипаттерн 3.7.4 Неконтролируемый ритм доступа при использовании новой технологии

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

【решение】 Обязательно контролировать ритм доступа при внедрении новых технологий Только после достаточной проверки на некритических сервисах они могут быть применены к основным ссылкам.

Антипаттерн 3.7.5 План повышения стабильности не реализован вовремя

【Пример】 Произошел сбой сервиса, и в ходе проверки были сформулированы соответствующие меры по улучшению, но они не были реализованы своевременно и эффективно, затем проблема вспыхнула снова, и произошел очередной сбой сервиса.

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

Профиль команды

Сервисная команда Shunfengche состоит из группы небольших партнеров, которые сплочены, оптимистичны и честны и преследуют конечную цель.Они привержены созданию первоклассной системы безопасности, транзакций и маркетинговых услуг, чтобы помочь Didi Shunfeng реализовать прекрасную миссию «Обмен путешествиями делает жизнь лучше».

Если вы хотите узнать о высококачественном обмене технологиями Didi Shunfeng, обратите внимание на общедоступную учетную запись «Didi Shunfeng Technology», прочитайте исходный текст и другие технические галантерейные товары.

Добро пожаловать на официальный аккаунт Didi Technology!

Эта статья публикуется блогерами и другими операционными платформами.OpenWriteвыпуск