Общий опыт разработки бизнеса на лицевой связи - гарантия качества

Что такое качество?

Общие показатели для измерения качества

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

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

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

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

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

Что такое неисправность?

Технический сбой / Логический сбой

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

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

Внутренняя неисправность/Внешняя неисправность

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

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

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

«Три слоя и четыре стороны» обеспечения качества

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

стадия развития

тестовая служба

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

Стандартизированная техническая архитектура

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

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

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

качество цепочки поставок

От чего зависит страница? Обычно, после долгой работы в бизнесе, обслуживающий персонал сильно изменился, и это в принципе непросто понять. Как правило, распространенными зависимостями являются: CDN, сеть, контейнер, интерфейс, базовая структура/библиотека, SDK (скрытый, мониторинг и т. д.), инструменты для упаковки и т. д.

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

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

CDN

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

Интернет

Основная проблема с сетью — угон. Например, в этом сценарии: поскольку статические ресурсы js развертываются отдельно, необходимо решить междоменные проблемы, в тег script следует добавить crossorigin=anonymous, а в заголовке ответа указать Access-Control-Allow-Origin: * . После захвата ресурса ответ без этого заголовка приведет к тому, что ресурс будет отклонен браузером из-за междоменного выполнения, и страница обязательно зависнет. Один из способов отслеживания угона — это белый список IP-адресов, а другой — проверка хэша.Справочная целостность подресурса.

контейнер

С Webview могут быть разные проблемы.Например я столкнулся с примером: адаптивный дизайн страниц h5 опирается на rem, а при расчете rem нужно брать ширину страницы.Этот js обычно ставится в<header>Выполняется внутри тега. Затем, из-за проблемы с логикой предварительной загрузки контейнера, когда html анализируется в сценарии расчета rem, ширина полученной страницы равна 0, что означает, что страница контейнера не была инициализирована, но html уже начал выполнять. В результате все размеры в rem на самом деле равны 0px, а страница пуста. Так как же это контролируется? Основная идея состоит в том, чтобы рекурсивно пройти каждый элемент из элемента html и использовать getBoundingClientRect для вычисления размера.Если обнаруживается, что все элементы не имеют размера, это доказывает, что экран пуст (детали отображения, видимости, непрозрачности, и т. д. также учитываются), и обнаруживается пустой экран.Просто сообщите весь документ dom (document.documentElement.innerHTML). Очень жестоко, но вышеуказанная проблема обнаруживается таким образом (размер шрифта тега html равен 0).

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

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

интерфейс

Обычно существует три типа исключений интерфейса: сетевые исключения (5xx, тайм-аут); бизнес-исключения (обычно определяемые пользовательскими кодами состояния); проблемы со структурой данных (отсутствующие поля, недопустимые данные и т. д.).

Мониторинг сетевых исключений в основном осуществляется с помощью возможностей сетевой библиотеки, в то время как бизнес-исключения и различия в структуре данных необходимо отслеживать с помощью кода. Возьмем пример аномальных данных: однажды серверная часть обнаружила, что широта и долгота интерфейса были изменены на противоположные (очевидно, что интерфейсная часть также перевернута, поэтому с функцией нет проблем), поэтому после одностороннего изменения она подключился к сети незаметно, и он фактически не тестировался в приложении после того, как он вышел в сеть.Если вы думаете, что проблема устранена, значит, проблема должна быть. В этом случае внешний интерфейс может проверить диапазон широты и долготы и сообщить о любых проблемах — это пример активного мониторинга.

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

базовая структура/библиотека

Я никогда не сталкивался с ошибкой в ​​самом vue and react, вероятно, потому, что он использовался поздно и неглубоко. Как правило, качество фреймворков общего назначения в зрелом периоде все еще очень надежное, в конце концов, так много людей используют их (при тестировании). Фреймворк также предоставляет некоторые механизмы обработки исключений, которые необходимо использовать, такие как метод глобальной конфигурации vue errorHandler и компонент react ErrorBoundry.

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

sdk

Введенный нами пакет SDK также может быть проблематичным. SDK, такие как мониторинг, должны быть загружены первыми и должны быть загружены синхронно.Рассмотрите возможность встраивания, чтобы избежать сбоев при загрузке сети (коэффициент успеха сети не будет 100%, обычно около 99,9%), а затем вы должны контролировать версию.

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

упаковочный инструмент

Может ли универсальный инструмент, такой как webpack, также пойти не так? С ошибками самих общих инструментов не так просто столкнуться, а распространенными являются ошибки, вызванные использованием. Например, запакованный код содержит es6, что приводит к проблемам совместимости (да, в Android 5.x в 2020 году еще много пользователей), явно проблема в какой-то ссылке (типа импорта нескомпилированных js в node_module ) , и поскольку я использовал tapable.js для ввода кода es6 ранее, он не может скомпилироваться:

Поэтому при выборе внешней зависимости либо это общая зависимость, которая используется многими людьми и используется так же, как и вы (tapable — это общая зависимость, но мало кто использует ее напрямую), либо она очень понятная о реализации кода, стоящего за ним, а затем в противном случае вам придется полагаться на всестороннее тестирование. В противном случае будет рискованно вводить его опрометчиво.

Для процесса упаковки обычно требуются следующие методы мониторинга:

• Обнаружить код es6 (es-check)
• Обнаружение циклических ссылок (circular-dependency-plugin)
• Обнаружение дубликатов пакетов (inspectpack)

журнал

Какие сценарии требуют ведения журнала?

• считать показатель
• Устранение неполадок
• Для мониторинга исключений

Где нужно вести журнал?

• Активный мониторинг: интерфейсы, мостовые методы, бизнес-исключения
• Пассивный мониторинг: задержка сети/ресурса и вероятность успеха, производительность страницы, ошибка js

Неполное покрытие журналов означает наличие лазеек в мониторинге. Но это не чем больше, тем лучше, увеличивая потребление трафика и тратя ресурсы сервера.

Как вести журнал?

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

• Категория: Сеть / js / customize
• Рейтинг: ошибка/предупреждение/информация
  • Ошибки — это те, которые явно оказывают серьезное влияние на пользователя,не позволено существоватьИсключение, если оно разрешено, не может иметь уровень ошибки. Пока существует журнал Error-level, вы должны найти способ его очистить.В стратегии тревоги чувствительность должна быть максимальной, и тревога будет выдана, как только она произойдет.
  • Предупреждать означает, что это явно проблема, и ясно, что должно быть небольшое количество вхождений, но воздействие на пользователей несерьезно. Этот уровень в основном основан на масштабе стратегии тревоги, и допускается существование небольшого количества предупреждений.
  • Info — это, как правило, журнал, который содержит исключительно информацию об устранении неполадок, вообще не рассматривая мониторинг.

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

Где хранятся журналы?

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

Технические решения

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

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

• Заранее продумайте ключевые вопросы,Например:
  • Сфера влияния: Объем изменений, затронутых этим требованием, если он будет пропущен, график определенно будет неточным.QA также особенно обеспокоен объемом изменений, потому что это определяет объем тестирования QA
  • зависимые ресурсы: Чтобы выполнить это требование, необходимые функции должны быть предоставлены извне. Необходимо уточнить, являются ли эти функции надежными (может потребоваться предварительное исследование), и что делать, если они не доступны своевременно, и если они не могут быть предоставлены своевременно
  • Источники данных: Откуда берутся все данные, необходимые для уровня представления, где они размещаются или кто их предоставляет.
  • основная логика: Обеспечение правильного понимания посредством «переформулирования»
  • схема интерфейса: Иногда передняя часть интерфейса лучше, ведь как требователь, ты лучше знаешь, что тебе нужно
  • Нижняя линия: Если предположить, что с этой функцией возникла проблема, есть ли резервный план, такой как переключение, понижение версии и т. д.
  • Решение для мониторинга: Как я могу узнать, есть проблема или нет после запуска этой функции? Это фактически тест уровня, и в какой-то мере определяет и варианты использования автоматизированного тестирования.
  • Тестовая программа: Какие условия должны быть подготовлены и какие ожидания достигнуты с помощью какого процесса, чтобы доказать, что моя функция не является проблемой. Если вы можете смоделировать в уме логический процесс реализации всей функции до того, как начнется спрос, обнаружить ключевые точки и точки риска и даже сделать вывод о неразумности дизайна спроса, это может на самом деле отразить уровень работы. Иногда неопытные разработчики могут обнаружить, что некоторые функции трудно измерить или даже невозможно измерить после их разработки. Если это можно предвидеть заранее, техническое решение можно скорректировать, либо увеличить смету времени. Чтоб не торопиться после теста
  • Онлайн план: Основная проблема в том, кто придет первым, и каков порядок отката, если что-то пойдет не так. Кроме того, будьте осторожны, чтобы избежать периода бана.Я видел ситуацию, когда оттенки серого выпускали половину результатов и только что прибыли во время бана, что приводило к ситуации, когда оставшаяся половина не могла быть выпущена (хотя это следует рассматривать как проблема издательской системы)
• основа для планирования: Крупномасштабные требования могут быть выполнены только после точного планирования после демонтажа
• коллегиальная проверка: С точки зрения управления командой, как правило, в каждом подразделении есть по крайней мере два (или более) активных и резервных человека. В ходе проверки в зависимости от ситуации будет привлечено соответствующее ответственное лицо для оказания помощи в разминировании.

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

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

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

SOP

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

Управление требованиями

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

Обычно люди, которые занимаются разработкой, привыкли к исполнению, не умеют задавать вопросы. Это может быть потому, что компания не установила соответствующую систему или консенсус, но [суждение о спросе] действительно является относительно высоким требованием. Лично я считаю что в качестве НИОКР надо как минимум активно стремиться к выражению своего мнения.Если не высказывать свое мнение,то нельзя иметь право говорить.Иначе если работать три часа сверхурочно за продукт, вы можете это вынести? Некоторые крупные производители очень четкие, им непонятны преимущества своих потребностей, и если проверка требований не удалась, R&D имеет право отказать в их реализации. Это заставляет продукт ясно мыслить и ясно объяснять. Теоретически без требований не бывает багов, верно? Делая хорошо продуманные требования, не делайте случайных изменений в середине, по сравнению с частыми изменениями требований вероятность ошибок меньше, верно?

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

Если спрос слишком велик, это принесет ряд проблем, которые увеличат вероятность проблем:

• Скорость поглощения. Объем информации слишком велик, один отзыв невозможно переварить, одного отзыва недостаточно, а несколько обзоров — пустая трата времени. Разумная детализация является основной предпосылкой для обеспечения эффективности и действенности обзора.Если встреча превышает один час, эффективность очень подозрительна (для обычных работающих людей)
• Объем информации слишком велик, в результате слишком много деталей и проблем, которые легко пропустить и трудно найти заранее
• Степень детализации слишком велика, что приводит к длительному периоду строительства, могут возникать перекрестные требования и параллельные требования, а выполнение других задач может быть заблокировано из-за долгосрочной неспособности рабочей силы высвободить
• Детализация выходит из-под контроля, и вводится слишком много информации, что увеличивает стоимость синхронизации информации. Если продолжительность проекта велика из-за проблем с памятью, в середине требуется непрерывная связь и согласование, что еще больше снижает эффективность.
• Изменения имеют тенденцию происходить. Требования меняются, неопытные разработчики могут легко изменить старый и ввести новый, а также изменить старый код, чтобы ввести новые ошибки.

Для НИОКР управление требованиями может выполнять следующие функции:

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

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

Если есть дублирование или даже конфликт между требованиями, это авария внутреннего управления продуктом, и между TL необходимо дружеское общение.

этап интеграции

управление филиалом

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

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

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

Период запрета / оттенки серого / прогрессивный

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

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

Инкрементальность — это фундаментальная философия не только в процессе выпуска, но и в повседневной работе. Например, после более чем года работы в отрасли я, наконец, вошел в крупную фабрику, и я сделал очень ошеломленную вещь, когда впервые вошел: я обновил веб-пакет 1 до 3, чтобы решить такие проблемы, как скорость компиляции. Поскольку проект имеет определенный масштаб, за неделю работы один pr изменил сотни файлов, даже превысив верхний предел diff платформы управления кодом. Для такого большого изменения нет теста QA.После тестирования несколько раз, оно было запущено напрямую. В результате возникает случайная проблема (возникающая при определенных условиях), которая сбивает с толку Сотни различий файлов, какое изменение вызвало ее? Если его разделить на несколько пакетов пошагового преобразования, это не только снижает риск, но и помогает обнаружить проблему постфактум.

Code Review

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

Чтобы улучшить осуществимость и эффективность проверки кода, Хэ Шицзюньэта статьяЗдесь упоминается один момент: ограничьте детализацию одного pr. В этом есть доля правды, но эксплуатационные расходы немного выше, в зависимости от ситуации в команде.

Контент, который обычно требует проверки:

• Качество кода (предварительная проверка, граничные условия, повторное использование, техническая реализация, ведение журнала...)
• Читабельность кода (укажите, что вы не понимаете, переименуйте, добавьте комментарии...)
• Найдите проблемы (проблемы технической реализации, проблемы бизнес-логики...)

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

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

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

Code Review обычно сталкивается с некоторыми проблемами в работе:

• Ответственность: "Он вообще более надежен в своей работе. Не надо внимательно смотреть на пиар, это должно быть без проблем"; "Зачем возиться друг с другом?
• Неблагоприятный отбор: "Ну, два человека уже видели пр, так что мне не нужно внимательно проверять, это точно нормально, идите в интернет"

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

Ссылаться на:Google Code Review Developer Guide

Этап эксплуатации и технического обслуживания

монитор

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

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

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

Ссылаться на:Говоря о внешнем мониторинге

резервное копирование, понижение версии, переключение

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

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

Фактически, внешний интерфейс также столкнется с проблемами версии.Ссылаться на

управление неисправностями

основная идея

Демонтаж аварии, а не для ответственности, увидеть первопричину, и постепенно улучшаться.

Поиск проблемы

Как остановить убыток, найти причину и восстановить верхний предел в кратчайшие сроки — это проверка мастерства и опыта. Подводя итог, можно привести ряд стандартных действий для справки:

Шаг 0 Определите проблему

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

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

Шаг 1 Стоп-лосс вовремя

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

Шаг 2 Причины позиционирования

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

Процесс позиционирования должен следовать определенному научному методу, а не просто догадкам:

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

Шаг 3 Восстановление и подключение к сети, регрессионная проверка

После устранения неисправности необходимо сообщить об этом.

Шаг 4. Просмотрите сводку

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

Поиск проблемы

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

Обзорный документ в основном состоит из четырех частей:

1. Хронология

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

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

Если времени слишком много, тем более необходимо провести углубленный анализ.

2. Сфера влияния, рейтинг

Сфера влияния является основой для оценки, а оценка является мерой управления. Например:

• Цель качества команды: ни одной ошибки выше xx уровня в течение года
• Недостижение уровня xx требует участия босса уровня xx в проверке.

3. Основная причина

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

Чтобы судить об уважительной причине, в основном зависит от того, может ли она быть выдвинута за причинуисполняемыйрешение. По этому стандарту недействительны следующие причины (обычно субъективные):

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

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

4. Последующие меры

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

три красные линии

заранее:Запрещено выходить в сеть без тестирования

В процессе:Невозможно откатиться онлайн

после:Невозможно вернуться к запретной линии