Наблюдаемость и мониторинг - схемы
Узнайте больше о оперативном совершенстве → Наблюдательность и мониторинг
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Мониторинг событий | ✅ Мониторинг событий разработан в исходной архитектуре, собирающей коды корреляции, которые отслеживают запросы посредством цепочек асинхронной обработки и внешних интеграций |
| Платформа | Мониторинг событий | ✅ Инфраструктура наблюдения включается с первичного спринта, а не модернизируется после того, как производственные инциденты оказываются не поддающимися диагностике |
| Платформа | Интеграция | ✅ Контрольные точки интеграции размещены намеренно, чтобы включить отслеживание запросов через границы системы |
| Платформа | События платформы | ✅ Полезные данные события платформы структурированы для оперативной видимости с маркерами транзакций и контекстом |
| Платформа | Настраиваемая регистрация | ✅ Настраиваемая инфраструктура регистрации собирает отдельные события с полной контекстуальной информацией, включительно с удостоверением пользователя, отметкой времени, продолжительностью и результатом |
| Платформа | Показатели | ✅ Показатели агрегируют числовые измерения в динамике, раскрывающие тенденции, включительно с уровнем потребления API, распределениями процессорного времени Apex и уровнем успеха пакетных заданий |
| Платформа | Распределенное отслеживание | ✅ Трассировки подключают синхронные вызовы API к асинхронным цепочкам обработки, события платформы к выполнениям подписчика и запросы интеграции к ответам внешней системы |
| Платформа | Наблюдаемость | ✅ Наблюдаемость позволяет операторам отвечать на произвольные вопросы о поведении системы без развертывания новых приборов для каждого исследования |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Мониторинг событий | ⚠️ Запуск решения без настраиваемой регистрации, требующий серьезной реорганизации через полгода, когда производственные инциденты оказываются невозможными для диагностики только с помощью журналов платформы |
| Платформа | Мониторинг событий | ⚠️ Обозримость дооснащается существующим решением, требующим изменения контрольно-измерительных приборов, затрагивающим большинство компонентов и создающим опасность возникновения ошибок во время работ по оперативному улучшению |
| Платформа | Интеграция | ⚠️ Происходят сбои интеграции, но пути запроса невозможно отследить через границы системы без комплексной телеметрии |
| Платформа | События платформы | ⚠️ Полезные данные события платформы не имеют оперативного контекста, что делает расследование инцидентов зависимым от поиска нескольких систем |
| Платформа | Настраиваемая регистрация | ⚠️ Журналы собирают недостаточный контекст; расследования требуют воспроизведения проблем для сбора дополнительной информации |
| Платформа | Наблюдаемость | ⚠️ Предопределенные панели мониторинга не могут ответить на неожиданные вопросы о поведении системы, возникающие в производстве |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Мониторинг событий | ✅ Мониторинг событий включен для производственных сред, собирающих использование API, действия входа, выполнение Apex, запросы SOQL, страницы Visualforce, страницы Lightning и запуски отчетов |
| Платформа | Мониторинг событий | ✅ Экспорт файлов журнала событий ежечасно на централизованную платформу журнала, что позволяет архивировать данные за пределами сохранения собственной платформы |
| Платформа | Мониторинг событий | ✅ Агрегация внешних журналов обеспечивает корреляцию с телеметрией предприятия из других систем для комплексного отслеживания транзакций |
| Платформа | Мониторинг событий | ✅ Файлы журнала событий сохраняются совпадающие нормативные требования для отчетности по соответствию и анализа долгосрочных тенденций |
| Платформа | Proactive Monitoring | ✅ Пороги Proactive Monitoring настроены намеренно на основе характерного для организации нормального диапазона работы, а не принятия стандартных параметров |
| Платформа | Proactive Monitoring | ✅ Предупреждения Proactive Monitoring обнаруживают скачки ограничения API, параллельные сбои Apex, подходы к ограничению строк SOQL и споры о блокировке строк до инцидентов, доступных пользователю |
| Платформа | Proactive Monitoring | ✅ Настроенные пороги генерируют действенные сигналы, которым команды Trust и действуют в соответствии с созданием добродетельных циклов непрерывного улучшения |
| Платформа | Масштабный центр | ✅ Базовые показатели масштабного центра устанавливаются во время стабилизации решения и пересматриваются после каждого основного выпуска |
| Платформа | Масштабный центр | ✅ Масштабный центр определяет, какие операции потребляют больше ресурсов, какие транзакции приближаются к пороговым значениям времени ожидания и где инвестиции оптимизации приносят наибольший эффект |
| Платформа | Масштабный центр | ✅ Время транзакции увеличивается по сравнению с базовым оперативным расследованием, отображающим ненамеренные схемы запросов N+1, внедренные в последнем развертывании |
| Платформа | Контрольный журнал настройки | ✅ Контрольный журнал настройки отслеживает изменения конфигурации, включая изменения полномочий, развертывания метаданных и обновления параметров безопасности с сохранением до 180 дней |
| Платформа | Контрольный журнал настройки | ✅ Записи контрольного журнала настройки экспортируются для хранения свыше 180 дней, когда соответствие или требования контракта требуют более длительных архивных окон |
| Платформа | Щит | ✅ Контрольный журнал поля включен выборочно для полей, содержащих конфиденциальные данные, регламентированные данные, требующие журнала изменений или критические бизнес-данные |
| Платформа | Щит | ✅ Контрольный журнал поля обеспечивает хранение до 10 лет для полей, где понимание архивных значений помогает операциям и отчетности по соблюдению |
| Платформа | Проверка состояния | ✅ Проверка состояния запланирована на ежеквартальный период с исправлением выводов на основе приоритетов рисков для окружающей среды |
| Платформа | Проверка состояния | ✅ Результаты проверки состояния здоровья проверяются преднамеренно, а не пассивно; документально подтверждены меры компенсирующего контроля или разные допуски риска |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Мониторинг событий | ⚠️ Мониторинг событий включен, но журналы не экспортируются, ограничивая расследования собственным окном сохранности и предотвращая анализ архивных трендов |
| Платформа | Мониторинг событий | ⚠️ Файлы журнала событий остаются в хранилище платформы; внешняя агрегация не внедрена, предотвращая долгосрочное планирование нагрузки |
| Платформа | Proactive Monitoring | ⚠️ Proactive Monitoring использует слишком чувствительные или слишком мягкие пороговые значения по умолчанию, создавая шумные предупреждения, которые рабочие группы учатся игнорировать |
| Платформа | Proactive Monitoring | ⚠️ Шум предупреждения разрушает Trust в системе мониторинга; группы прекращают реагировать на действительные сигналы |
| Платформа | Масштабный центр | ⚠️ Центр масштабирования включен, но никогда не проверялся активно; производительность медленно ухудшается, пока пользователи не жалуются после нескольких месяцев инкрементной деградации |
| Платформа | Масштабный центр | ⚠️ Показатели эффективности не имеют базового контекста; неясно, является ли 3-секундное время транзакции типичным, улучшающим или ухудшающим |
| Платформа | Контрольный журнал настройки | ⚠️ Контрольный журнал настройки не экспортируется; ограничения хранения предотвращают расследования безопасности или проверку соответствия свыше 180 дней |
| Платформа | Щит | ⚠️ Контрольный журнал поля включен для всех полей, а не выборочно, что создает расходы на хранение без соответствующего значения соответствия |
| Платформа | Проверка состояния | ⚠️ Выводы проверки состояния никогда не проверяются; конфигурация безопасности отклоняется от базовых рекомендаций без преднамеренного принятия |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Потоки пользователя | ✅ Важнейшие потоки пользователей определяются на основе бизнес-влияния и отслеживаются от начала до конца для уровней успеха, времени завершения, точек отказа и уровня ошибок |
| Платформа | Потоки пользователя | ✅ Важнейшие потоки включают приносящие доход виды деятельности (отправка заказа, исполнение контракта, закрытие возможности), массовые виды деятельности (вход, поиск, создание записи) и действия, необходимые для соответствия (сбор согласия, выполнение прав субъекта данных) |
| Платформа | Потоки пользователя | ✅ Потоки оборудованы маркерами транзакций, обозначающими начало, завершение, оставление и сбой на каждом важном этапе |
| Платформа | Потоки пользователя | ✅ Поток отправки заказа, инструментированный событиями платформы на каждом этапе (проверка корзины, инвентаризация, обработка оплаты, триггер выполнения), отображающий уровень успеха по этапам |
| Платформа | Потоки пользователя | ✅ Мониторинг на уровне потока обнаруживает проблемы, невидимые в мониторинге на уровне компонента, поскольку сбои могут произойти в любой точке перехода |
| Платформа | Потоки пользователя | ✅ Предупреждения о пожаре, когда уровень успеха потока падает ниже допустимых порогов или продолжительность превышает целевые показатели задержки |
| Платформа | Интеграция | ✅ Мониторинг работоспособности интеграции обнаруживает сбои внешней системы, проблемы сети, проблемы проверки подлинности и подходы к ограничению частоты, прежде чем перейти к каскадным сбоям, ориентированным на пользователя |
| Платформа | Интеграция | ✅ Предупреждения о мониторинге уровня успеха при падении ниже 99% для критических синхронных интеграций |
| Платформа | Интеграция | ✅ Предупреждения о мониторинге распределения ошибок при отображении новых типов ошибок, не существовавших в базовом |
| Платформа | Интеграция | ✅ Предупреждения о контроле процентиля задержки (р95) при превышении 3 секунд для синхронных вызовов пользователя |
| Платформа | Интеграция | ✅ Предупреждения о мониторинге пропускной способности при превышении 80% от известного ограничения ставки или порога SLA |
| Платформа | Интеграция | ✅ Предупреждения о мониторинге состояния выключателя при размыкании любой цепи, свидетельствующие о деградации внешней системы |
| Платформа | Интеграция | ✅ Предупреждения о мониторинге частоты повторных попыток, когда устойчивый уровень повторных попыток превышает 5%, что указывает на проблемы надежности |
| Платформа | Интеграция | ✅ Маршруты телеметрии интеграции к платформам централизованного мониторинга, обеспечивающие трансграничную корреляцию системы |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Потоки пользователя | ⚠️ Компоненты отслеживаются независимо, показывая здоровую работу, в то время как 12% пользователей отказываются от критических потоков, не зная, почему |
| Платформа | Потоки пользователя | ⚠️ Панели мониторинга состояния компонентов отображаются зеленым цветом, в то время как пользователи не могут выполнить критические бизнес-процессы, отображающие сбой архитектуры мониторинга |
| Платформа | Потоки пользователя | ⚠️ Путешествие пользователя, касающееся нескольких классов Apex, потоков, событий платформы и внешних интеграций, не имеет сквозной видимости |
| Платформа | Потоки пользователя | ⚠️ Важнейшим бизнес-путешествиям не хватает контрольно-измерительной аппаратуры; показатели успеха и точки отказа неизвестны |
| Платформа | Интеграция | ⚠️ Сбои интеграции обнаруживаются только после каскадных сбоев, ориентированных на пользователя, а не упреждающе |
| Платформа | Интеграция | ⚠️ Интеграционная телеметрия остается изолированной в отдельных системах, предотвращая трансграничный корреляционный анализ и анализ первопричин |
| Платформа | Интеграция | ⚠️ Отслеживание предупреждений о симптомах в нисходящем направлении после нанесения ущерба, а не раннее выявление первопричин |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Platform | SLI | ✅ SLI доступности измеряют процент успешного выполнения критических потоков с точки зрения пользователя (получение ожидаемого результата, а не только кода 200 статуса) |
| Platform | SLI | ✅ SLI задержек измеряют время для выполнения операций при p50 (средний), p90 (90-й процентиль, исключая выпадающие значения), p95 (95-й процентиль, исключая худшие выпадающие значения) и p99 (99-й процентиль, отображающий худший прогноз) |
| Platform | SLI | ✅ Цели задержки различаются в зависимости от важности операции и ожидания пользователя (поиск 500мс кажется мгновенным, такая же задержка ввода кажется вялой) |
| Platform | SLI | ✅ Пропускная способность SLI измеряет объем успешных операций в единице времени, отображая тенденции использования и роста мощностей |
| Platform | SLI | ✅ Производительность в сочетании с задержкой определяет, поддерживает ли система производительность при возрастающей нагрузке или ухудшается по мере роста объема |
| Platform | SLI | ✅ Процент ошибок SLI различает типы ошибок (например, ошибки проверки и системные ошибки, например, исключения ограничения для управляющих) |
| Platform | SLO | ✅ Устанавливаются цели уровня обслуживания, определяющие допустимые пороги SLI на основе бизнес-требований перед выбором схем архитектуры |
| Platform | SLO | ✅ Бизнес-требование «Торговые представители должны видеть обновления возможности в течение 5 секунд» управляет ООД «Загрузки страницы сведений о возможности завершены в течение 3 секунд при p95», который управляет решениями архитектуры |
| Platform | SLO | ✅ ООД вытекают из бизнес-требований и определяют архитектурные решения, а не определяются исходя из того, чего достигает в настоящее время система |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Platform | SLI | ⚠️ Доступность оценивается с технической точки зрения (код статуса 200), а не с точки зрения пользователя (получение ожидаемого результата) |
| Platform | SLI | ⚠️ Задержка измеряется только при среднем значении без понимания наихудшего пользовательского взаимодействия при p95 или p99 процентилях |
| Platform | SLI | ⚠️ Многофакторные проверки подлинности ошибок не позволяют различать ошибки пользователей и системные ошибки, маскируя разные проблемы, требующие разных решений |
| Platform | SLO | ⚠️ Сначала создается архитектура, потом ООД определяется как “что бы мы в данный момент ни достигли”, что приводит к принятию 12-секундных загрузок страниц, поскольку при проектировании системы никогда не учитывались требования пользователей |
| Platform | SLO | ⚠️ ООД определяются архитектурой, а не бизнесом, устанавливая цели на основе того, чего достигает система, а не того, что нужно пользователям |
Шаблоны
| Где искать | Как хорошо выглядит |
|---|---|
| Платформа | Предупреждение | ✅ Классификация серьезности перенаправляет критические инциденты (производственная недоступность, риск повреждения данных, нарушение безопасности) на страницу инженеров по вызову немедленно |
| Платформа | Предупреждение | ✅ Серьезные инциденты (снижение производительности, частичные сбои) создают уведомления для оперативного расследования в течение рабочих часов |
| Платформа | Предупреждение | ✅ Предупреждения (приближение к пороговым значениям, отклонение конфигурации) создают ежедневные уведомления рассылки для активного исправления |
| Платформа | Предупреждение | ✅ Контекст предупреждений содержит количество задействованных пользователей, сообщения об ошибках, трассировки стека, недавние развертывания, связанные предупреждения и ссылки на соответствующие панели мониторинга |
| Платформа | Предупреждение | ✅ Обогащенный контекст сокращает среднее время для признания, предоставляя возможность немедленной оценки серьезности и расследования без сбора базовой информации |
| Платформа | Предупреждение | ✅ Группировка предупреждений предотвращает штормы предупреждений, когда сотни связанных предупреждений срабатывают для одной основной проблемы |
| Платформа | Предупреждение | ✅ Сбой интеграции запускает одно предупреждение, сгруппированное по конечной точке интеграции, отображающее 156 неудачных запросов за последние 5 минут с графиком задержки, распределением ошибок и ссылкой на панель мониторинга |
| Платформа | Предупреждение | ✅ Подавление предупреждения предотвращает создание предупреждений известными переходными условиями во время ожидаемых окон обслуживания или периодов автоматического восстановления |
| Платформа | Предупреждение | ✅ Предупреждения подавляются во время запланированного обслуживания, в течение первых нескольких минут после развертывания, когда кэши теплые, и во время коротких переходных сбоев, когда логика повтора успешна |
Антишаблоны
| Где искать | Как плохо выглядит |
|---|---|
| Платформа | Предупреждение | ⚠️ Все предупреждения перенаправляются в один канал без классификации серьезности; критические инциденты не отличаются от обычных предупреждений |
| Платформа | Предупреждение | ⚠️ Предупреждения лишены диагностического контекста; перед оценкой серьезности инженеры по вызову должны собрать основные сведения посредством отдельных запросов |
| Платформа | Предупреждение | ⚠️ Сбой интеграции создает 156 индивидуальных предупреждений за 5 минут, подавляющих телефон инженера по вызову, каждое предупреждение идентично, за исключением отметки времени |
| Платформа | Предупреждение | ⚠️ Предупреждение о штормах мешает исполнителям различать одну основную проблему и сотни связанных симптомов |
| Платформа | Предупреждение | ⚠️ Предупреждения о пожаре во время известных окон техобслуживания и переходных условий, генерирующих шум, который размывает Trust в мониторинге |
| Платформа | Предупреждение | ⚠️ Усталость предупреждения от шумных ложных положительных результатов приводит к тому, что рабочие группы игнорируют уведомления, снижающие эффективность ответа |