Чтобы использовать наблюдаемость, нам нужен значительный сдвиг в нашей корпоративной культуре, который охватывает всю компанию и выходит за рамки инструментов.
Я виновен в том, что применяю слово «отладка» практически ко всему. Лего моих детей не подходит, давайте это исправим. Наблюдаемость — одна из немногих дисциплин, которые действительно оправдывают это прозвище; это отладка. Но традиционная отладка на самом деле не согласуется с методами наблюдения. Обычно я называю это «упреждающей отладкой». Нам нужно заранее иметь приблизительное представление о том, как будет выглядеть наш процесс отладки для эффективного устранения неполадок с наблюдаемостью.
Обратите внимание, что это не относится к наблюдаемости разработчика, которая является особым случаем. Это более динамичный процесс, больше напоминающий типичный сеанс отладки. Речь идет о более традиционном мониторинге и наблюдаемости. Где нам нужно сначала настроить систему и добавить журналы, метрики и т. Д., Чтобы охватить информацию, которая нам понадобится, поскольку мы позже исследуем проблему.
Я уже писал о вреде перепрошивки. То же самое относится и к показателям наблюдаемости: поскольку мы собираем все больше и больше данных, затраты на хранение и обработку быстро перевешивают преимущества наблюдаемости. В итоге мы получаем большую проблему. Нам нужно выбирать наши сражения, регистрировать «правильное количество» и отслеживать «нужное количество». Не больше и не меньше, чем нам нужно. Для этого нам нужно понимать риски, с которыми мы имеем дело, и стараться максимизировать дублирование в нашем расследовании.
Хаос-инжиниринг как источник вдохновения
В традициях Chaos Engineering мы организовали «игру», организованную «мастером бедствий», чтобы отработать готовность к бедствиям. Это прекрасное упражнение и отличный способ нарастить эту «мышцу». Это не подходит для архитектуры наблюдаемости, поскольку наблюдаемость имеет дело с нюансами, а не с «огнем».
Наблюдаемость требует аналогичной игры, но преднамеренной, в которой наша команда соревнуется в поиске способов, при которых наша система может дать сбой. Думайте об этом как о бинго. Когда у нас есть электронная таблица, полная потенциальных сбоев, нам нужно сопоставить сбои с наблюдаемостью, которую мы хотели бы иметь для каждого потенциального сбоя. Например, в случае взлома мы хотели бы, чтобы идентификатор пользователя регистрировался при доступе к любому ресурсу с ограниченным доступом.
После того, как мы наметим все эти желания, мы можем просмотреть их и попытаться унифицировать некоторые показатели и журналы. Затем внедрите их, чтобы наша наблюдаемость могла ответить на все, что нам нужно, чтобы отследить проблему.
Мы пропустим некоторые вещи?
Да. Это часть процесса. Нам нужно будет повторить и настроить это. Вероятно, потребуется уменьшить объем некоторых дорогостоящих точек данных, чтобы сохранить разумные затраты. Мы, несомненно, столкнемся с проблемами, которые не покрываются наблюдаемостью (или чье покрытие наблюдаемости неочевидно). В обоих случаях нам понадобится помощь.
Нужны ли нам специалисты?
Некоторые поклонники наблюдаемости предполагают, что нам больше не нужен опыт предметной области для отладки проблемы. Учитывая правильно наблюдаемую систему, мы должны быть в состоянии понять проблему, ничего не зная о системе.
Хотя соглашусь, что специалист по отладке наверное быстрее решит проблему. Возможно, быстрее, чем эксперт домена. У меня все еще есть сомнения. В течение десяти лет я был консультантом и обращался в компании, где использовал профилировщики, отладчики и т. д. В рамках этой работы я обнаружил проблемы, которые ускользнули от людей, которые были большими экспертами в предметной области, чем я. Так что в этом утверждении есть резон.
Но отладка требует некоторого знакомства с системой, которую мы пытаемся понять. Это как диагностика через гугл. Иногда мы можем найти причину лучше, чем наш врач общей практики, но, вероятно, не лучше, чем эксперт. Есть исключения из правил, но по моему опыту опыт имеет значение для любого типа отладки.
Наша собственная панель инструментов
Одна вещь, которую я часто вижу, — это универсальная информационная панель «один размер подходит всем» в компании. Grafana — это фантастический инструмент с замечательной гибкостью, но некоторые визуализируют его как единую панель инструментов компании. Для этих приложений должно быть как минимум три дашборда:
- Высокий уровень — уровень CTO/VP R&D. Основное внимание уделяется бизнес-показателям, пользователям, надежности, затратам.
- DevOps — Низкоуровневая информация о среде
- Разработчики — метрики для конкретных приложений и информация о платформе.
Там много совпадений. Но нам нужны кастомные дашборды. Вся идея приборной панели состоит в том, чтобы видеть все, что имеет значение, в одном месте. Использование ЦП в контейнере может быть мне интересно в целом, но, скорее всего, это будет просто отвлечение. Я хочу знать, есть ли проблема с системой авторизации, потому что пользователи сталкиваются с повышенным количеством ошибок при входе в систему. Эти показатели должны быть в центре внимания.
Когда я открываю новую вкладку в своем браузере, я вижу Grafana. Это должна быть домашняя страница для каждого члена команды. «Здоровый» взгляд на нашу систему должен быть запечатлен в нашем сознании, чтобы мы могли мгновенно замечать небольшие отклонения в окружающей среде и действовать соответственно.
Рост с наблюдаемостью
По мере роста нашей системы нам нужно включать наблюдаемость и метрики в запрос на вытягивание, который вводит функцию. Ничто не может быть запущено без наблюдения в первый же день. Это должно быть включено в процесс проверки кода и должно соответствовать требованиям к тестовому покрытию.
В отличие от тестового покрытия, у нас нет метрики, на которую мы могли бы положиться, чтобы убедиться, что наблюдаемость достаточна для быстро меняющихся потребностей, поэтому в настоящее время это ложится тяжелым бременем на плечи рецензентов. Но есть еще большая нагрузка: стоимость. По мере нашего роста эти изменения могут повлиять на затраты, которые могут внезапно подскочить до высот, ведущих к банкротству. Затраты не всегда легко контролировать, но это показатель, на который мы должны смотреть ежедневно. Отслеживая этот показатель и выявляя скачки затрат на раннем этапе, мы можем поддерживать стабильность и управляемость наших систем, не отказываясь от экономической эффективности.
Последние мысли
Некоторые инженеры слишком увлечены метриками. Я не один из них. Некоторые вещи невозможно измерить. Ценность личных отношений. Ценность команды. Сообщество. Из-за этой одержимости наблюдаемость набирает популярность. Это хорошо и плохо. С этой навязчивой идеей мы иногда заходим в журнал и наблюдаем, что приводит к снижению производительности и перерасходу средств.
Мы должны применять наблюдаемость скальпелем, а не лопатой. Это не должно быть чем-то, что мы делегируем команде DevOps в последнюю очередь. Это должно быть групповое усилие, которое мы постоянно совершенствуем по мере продвижения вперед. Мы должны держать руку на пульсе наших показателей и иметь инструментальные панели для конкретных предметных областей, чтобы постоянно держать важные вещи в нашем периферийном зрении. Наблюдаемость не имеет значения, если мы не утруждаем себя поиском.
