Site Reliability Engineering

Также, пожалуйста, сделайте мне одолжение и мысленно дополните каждый из следующих пунктов словом “обычно”. Каждая ситуация уникальна, и то, что я не сталкивался с тем, что (например) использование Git является плохой идеей, не означает, что такого случая не существует. “Только Ситхи всё возводят в абсолют”, и т.д.

Итак! Пройдя через всё это — вот как я бы начал все сначала, если бы мог.

Coding (параметры? да я их еле знаю!)

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

Чрезвычайно строгие настройки RPC. Я говорю о нуле (или МОЖЕТ БЫТЬ одной) повторных попыток и таймауте, в 3 раза превышающем p⁹⁹. Здесь мы стремимся к предсказуемости, и многократные повторные попытки или длительные таймауты в качестве быстрого решения проблемы в работе сервиса превратятся в недельное расследование и головную боль через год. Исправьте неисправный сервис!

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

Избегайте использования состояния как чумы. Управление сервисом с сохранением состояния (stateful) значительно сложнее, чем без сохранения состояния. Существует много хороших управляемых баз данных и кэшей, просто используйте один из них!

Merging (там, куда мы идем — тесты не нужны)

Используйте Git. Используйте его для всего — инфраструктуры, конфигов, кода, дашбордов, графиков дежурств. Ваш репозиторий Git — это источник истины, который можно восстановить на определенный момент времени.

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

Уделяйте приоритетное внимание тестам в реальных условиях. Самый ценный тест, который занимает меньше всего времени, — это просто применение вашего изменения на стейджинге (или, еще лучше, на проде!) и демонстрация того, что оно делает то, что вы хотели, и не ломает всё. На втором месте по эффективности находятся интеграционные тесты, а юнит-тесты идут последними — то есть, “только если у вас есть на них время”.

При изменениях в инфраструктуре делайте планы максимально ясными и очевидными. Это может означать “положить Terraform Plan как коммент к пуллреквесту”, так же сделайте с diff helm. Существуют отличные инструменты, позволяющие убедиться, что изменения, которые, по вашему мнению, вы вносите, являются теми изменениями, которые вы вносите на самом деле, поэтому убедитесь, что они находятся в центре внимания.

При внесении изменений в код делайте регрессии максимально очевидными. Журналы ошибок, использование ЦП и частота ошибочных запросов являются отличными сигналами, позволяющими выявить около 90% плохих версий и работают для практически любого сервиса (полностью универсальны). Так что не отбрасывайте их!

Deploying (no sleep til prod)

Используйте Docker. Это отраслевой стандарт не просто так — разбор зависимостей в средах с такими инструментами, как Chef или Ansible, всегда проигрывает этой приятной автономности.

Развертывайте всё и всегда. Каждый день, который проходит без вашего деплоя, увеличивает вероятность того, что он на самом деле был незаметно сломан (в результате чьего-то изменения, обновления зависимостей, удаления стороннего API), и через две недели будет очень трудно выяснить, что и где пошло не так.

Проверяйте развертывания по мере их выполнения. Можете ли вы создать полностью поврежденный образ и успешно разлить его на все машины? Почему? Это можно исправить несколькими способами, включая canary/shadow развертывания или даже просто хорошими readiness проверками.

Включите ограничение на “мгновенное” развертывание конфигов. Это может показаться нелогичным (“мгновенное” часто означает “сломать все сразу и быстро”), но возможность отключить проблемную функцию или заблокировать IP менее чем за 5 минут с лихвой компенсирует повышенный риск. Это позволяет всё делать быстро, но управлять этим нужно осторожно!

Operating (my god, it’s full of pods)

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

Используйте Helm. Или какой-то другой инструмент для управления манифестами Kubernetes, я не привередлив — главное, чтобы вы никогда не использовали прямые команды kubectl apply, edit или delete. Жизненный цикл ресурсов должен быть доступен в системе контроля версий.

Избегайте операторов и CRD (Custom Resource Definition). Как уже упоминалось выше, я люблю Kubernetes, но для очень многих разработчиков он очень сложен, и пользовательские операторы резко уходят в область “Что это за херня?”, что создает ему сложную репутацию. Пусть все будет просто.

Запускайте по 3 экземпляра всего. Как и с резервными копиями, два экземпляра — это один, а один — не существует :) Кроме того, убедитесь (действительно проверьте на проде), что 2 из 3 “штук” могут справиться с полной нагрузкой самостоятельно — в противном случае у вас на самом деле нет такой устойчивости к сбоям, как вы думаете.

Структурированные логи — это неотъемлемая часть. Вместе с идентификаторами трассировки они позволяют вам пройти 90% пути к APM (application performance monitoring), но при гораздо меньших затратах и усилиях со стороны разработчиков.

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

Photo by Jeremy Thomas on Unsplash

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

В чём разница между надежностью и доступностью?

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

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

График, показывающий процент доступности двух сервисов

На первый взгляд кажется, что сервис А более надежен, но при более внимательном рассмотрении оказывается, что это не так. Пользователи не обращаются к каждой странице сайта равномерно. Каждый пользователь обязательно заходит на страницу входа в систему, около 90% из них посещают каталог, а страницу с настройками посещает только 30% пользователей. Учитывая это, сервис B будет восприниматься как более надежный, потому что надежность определяется на основе пользовательского опыта.

Что такое “доступность”?

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

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

Как измерить доступность?

Вот как вы можете рассчитать процент доступности вашего сервиса:‍

1. Определите общее время работы

2. Вычтите время, в течение которого сервис был недоступен

3. Разделите получившееся время на общее время‍

Процент доступности = (Общее время — Сумма простоев)/Общее время

“Девятки” доступности

Допустимое время простоя для различных “девяток” доступности

Как улучшить доступность услуги?

• Развертывайте свой сервис в различных географических точках по всему миру, сокращая количество единичных точек отказа.

• Используйте chaos engineering для экспериментов и поиска уязвимостей системы.

• Эффективно используйте балансировщики нагрузки для перенаправления запросов.

• Улучшите процесс управления инцидентами, чтобы сократить время простоя, вызванное инцидентами.

Что такое надежность?

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

Как измерить надежность?

Поскольку надежность — это продолжительность безотказной работы системы, мы можем измерить ее, используя метрику “Среднее время наработки на отказ” (MTBF).

1. Посчитайте количество отказов

2. Найдите общее время работы

3. Разделите общее время на количество сбоев‍

Среднее время наработки на отказ (MTBF) = Общее время работы (в часах)/Количество отказов‍

Надежность также может быть измерена с помощью частоты отказов сервиса:

1. Посчитайте количество отказов

2. Найдите общее время работы

3. Разделите количество отказов на общее время работы‍

Частота отказов = Количество отказов/Общее время работы‍

Имейте в виду, что, хотя эти формулы и выглядят простыми, самое сложное — определить, что же такое “сбой” для вашей системы. Поскольку надежность основана на пользовательском опыте, вам необходимо использовать такие процессы, как SLI, чтобы понять, каков приемлемый уровень обслуживания.

Как повысить надежность сервиса?

• Тестируйте систему и разверните runbook automation.

• Тщательно тестируйте новые функции перед деплоем.

• Внедрите надлежащий процесс управления инцидентами.

Взаимосвязь между надежностью и доступностью

Надежность системы зависит от того, будет ли она выдавать правильный результат, когда это нужно. Это не то же самое, что доступность, которая означает доступность в любое время. Тем не менее, доступность и надежность взаимосвязаны. Можно сказать, что доступность — это самый простой и основной элемент надежности. Надежность и доступность идут рука об руку, поскольку одно невозможно без другого. Только если что-то доступно, мы можем определить, насколько оно надежно. Таким образом, высокий уровень надежности приводит к высокому уровню доступности.

Что такое ремонтопригодность и как она связана с доступностью и надежностью?

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

• Проактивная ремонтопригодность предполагает создание сервиса с понятным и легко изменяемым кодом. Проактивное техническое обслуживание также включает практики, такие как тестирование и контроль качества (QA).

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

Надежность против инноваций

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

‍Всегда будут изменения, нестабильность и неопределенность, и именно поэтому бессмысленно стремиться к совершенству. Вы всегда должны стремиться к реалистичному и практичному времени безотказной работы (которое никогда не будет 100%). После определенного момента улучшение надежности или доступности станет незаметным для пользователей. Усилия, которые вы тратите на повышение надежности после этого момента, лучше было бы направить в другое место. Лучшие в своем классе корпоративные организации часто обеспечивают доступность на уровне 99,999%, также известную как доступность “пять девяток”, с годовым временем простоя всего 5,256 минут.‍

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

Источник

0. Ваше психическое состояние

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

Если все это происходит, вы, вероятно, находитесь в состоянии стресса, а стресс заставит вас решать проблему медленнее, а не быстрее. Поэтому, прежде чем перейти к очевидному шагу 1, нам нужно сначала позаботиться о шаге 0. Убедитесь, что вы находитесь в хорошем расположении духа. Постарайтесь расслабиться, будьте спокойны. Ваш продакшен может не работать в течение часа, но это лучше, чем если бы он простоял много часов из-за того, что вы поспешно предприняли неправильные действия.

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

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

1. Воспроизведите проблему

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

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

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

2. Воспроизведите ее снова

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

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

3. Не воспроизводите ее

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

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

4. Поймите код

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

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

Иногда код поступает из непрозрачных сторонних источников. Если у вас нет доступа к этим источникам, у вас все равно есть пути для расследования. Прочитайте справку по API или другую документацию, поищите в базе данных ошибок, если таковая имеется. Есть ли соответствующие вопросы на Stackoverflow или в других местах?

В начале 2000-х годов я работал над прикладным фреймворком, который был бинарником для Internet Explorer 6. Это означало использование ряда API IE и Windows, которые имели скудную документацию. Всякий раз, когда реальность не совпадала с нашими ожиданиям от этих API, мы прибегали к поиску ответа в Usenet или на других онлайн-форумах. Чаще всего, когда мы в конце концов находили правильный ответ, его размещал таинственный гений с именем “Игорь Тандетник”. Прошло немного времени, прежде чем мы начали по умолчанию добавлять ко всем нашим поисковым запросам “Игорь Тандетник”. В качестве ускорителя отладки это полностью оправдало себя.

5. Наблюдайте за состоянием

После рассуждений о коде в его статической форме, посмотрите на динамическое состояние памяти в момент возникновения проблемы (до, во время и после).

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

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

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

6. Запишите то, что вы (как вам кажется) знаете

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

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

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

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

7. Исключите некоторые вещи

Иногда полезно удалить куски кода, чтобы доказать, что они не связаны (или нет). Это можно сделать по двум направлениям: по времени и по функциям.

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

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

8. Погуляйте с собакой

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

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

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

9. Перепишите компонент

Хотя переписывание целых систем редко бывает хорошей идеей, переписывание небольших фрагментов функциональности может быть эффективным способом выявить факторы, которые часто могут быть скрыты от глаз. Иногда вы можете смотреть на код целую вечность, и он выглядит прекрасно, но как только вы попытаетесь переделать его на свой лад, вы столкнетесь с костылями, на которые пришлось пойти автору. Эти костыли — отличный источник моментов “ага!” для отладки.

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

10. Напишите неудачный тест

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

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

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

11. Исправь это

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

Для нашего приложения электронной коммерции мы сосредоточимся на следующих SLI:

• Время отклика: время, необходимое приложению для ответа на запрос пользователя.

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

• Уровень ошибок: процент запросов, которые приводят к ошибкам.

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

Шаг 3: Определите цели уровня обслуживания (SLO)

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

Для нашего приложения электронной коммерции мы установим следующие SLO:

• Время отклика: 95% запросов должны быть выполнены в течение 500 мс

• Пропускная способность: приложение должно обрабатывать не менее 100 запросов в секунду

• Частота ошибок: Менее 1% запросов должны приводить к ошибкам

• Доступность: Приложение должно быть доступно в 99,9% случаев

Шаг 4: Рассчитайте соглашения об уровне обслуживания (SLA)

SLA — это соглашения между поставщиком услуг и клиентом, которые определяют уровень обслуживания, который будет предоставляться. Соглашения об уровне обслуживания обычно основаны на SLO, которые были определены для сервиса.

Чтобы рассчитать SLA, вам нужно сравнить фактическую производительность вашего сервиса с определенными вами SLO. Если ваш сервис соответствует SLO, значит, вы соответствуете своим SLA. Если ваш сервис не соответствует SLO, значит, вы не соответствуете своим SLA.

Допустим, для нашего приложения электронной коммерции мы собрали следующие данные за последний месяц:

• Время отклика: 94% запросов были выполнены в течение 500 мс

• Пропускная способность: приложение обрабатывало в среднем 90 запросов в секунду

• Частота ошибок: 1,5% запросов приводили к ошибкам

• Доступность: приложение было доступно в течение 99,5% времени

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

Шаг 5: Определите области для улучшения

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

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

• Время отклика: нам нужно определить, выполнение каких запросов занимает больше 500 мс, и оптимизировать эти запросы. Возможно, нам потребуется оптимизировать производительность конкретных микросервисов или выявить узкие места в нашей системе.

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

Определив, что мы можем улучшить, мы сможем работать над повышением производительности нашего приложения и соответствовать нашим требованиям SLO в будущем.

В мире управления ИТ-сервисами двумя важными показателями, которые используются для измерения производительности и эффективности сервиса, являются MTTR (Mean Time To Recover, среднее время восстановления) и MTTD (Mean Time To Detect, среднее время обнаружения). Эти показатели имеют решающее значение для повышения качества обслуживания, которое мы предоставляем своим клиентам. Сейчас я расскажу о MTTR и MTTD и объясню, почему они важны для управления ИТ-сервисами.

Что такое MTTR?

MTTR - среднее время восстановления. Этот показатель измеряет среднее время, необходимое для восстановления работы системы или сервиса после возникновения сбоя. MTTR важен, поскольку он позволяет оценить, насколько быстро ИТ-команды могут восстановить работу после сбоя или отказа.

MTTR рассчитывается путем деления общего времени простоя на количество инцидентов, произошедших за этот период времени. Например, если система была недоступна в течение 10 часов из-за сбоя, и за этот период времени произошло два инцидента, то MTTR будет равен 5 часам (10 часов / 2 инцидента = 5 часов).

Что такое MTTD?

MTTD - среднее время обнаружения. Этот показатель измеряет среднее количество времени, необходимое для обнаружения сбоя или простоя. MTTD важен, поскольку он позволяет оценить, насколько быстро ИТ-команды могут выявлять проблемы и реагировать на них. Чем меньше MTTD, тем быстрее ИТ-команды смогут реагировать на проблемы и тем меньшее влияние эти проблемы окажут на клиентов.

MTTD рассчитывается путем деления общего времени между возникновением сбоя и его обнаружением на количество инцидентов за этот период времени. Например, если сбой произошел в 12:00 и был обнаружен в 12:30, и за этот период времени произошло два инцидента, MTTD будет равен 15 минутам (30 минут / 2 инцидента = 15 минут).

Почему MTTR и MTTD важны?

MTTR и MTTD являются важными показателями для управления ИТ-сервисами, поскольку они позволяют оценить, насколько быстро ИТ-команды могут реагировать на проблемы и восстанавливать обслуживание клиентов. Отслеживая эти показатели с течением времени, ИТ-команды могут выявлять тенденции и вносить улучшения в свои процессы, чтобы сократить время простоя и повысить удовлетворенность клиентов.

Например, если ИТ-команда замечает, что их MTTR стабильно высок, им, возможно, потребуется улучшить свои процессы реагирования на инциденты или вложиться в более совершенные инструменты для мониторинга и диагностики проблем. Аналогичным образом, если ИТ-команда замечает, что их MTTD стабильно высок, им, возможно, потребуется вложиться в более совершенные инструменты мониторинга или усовершенствовать свои процессы обнаружения инцидентов.

Вывод

Вот несколько замечательных твитов от Michiel van Oudheusden:

В заключение отметим, что MTTR и MTTD являются важными показателями для управления ИТ-сервисами. Отслеживая эти показатели с течением времени, ИТ-команды могут определить области для улучшения и внести изменения в свои процессы, чтобы повысить качество обслуживания, которое они предоставляют клиентам. Помните, что эти показатели эффективны только в том случае, если они регулярно пересматриваются и используются для улучшения процессов управления ИТ-сервисами.

Расчет SLA, SLI и SLO имеет решающее значение для измерения производительности и надежности ИТ-служб. Следуя шагам, описанным в этом руководстве, вы можете установить целевые показатели для своего сервиса и сравнить свою производительность с этими целевыми показателями. Определяя области для улучшения, вы можете работать над постоянным повышением качества обслуживания, которое вы предоставляете своим клиентам. Помните, что SLA, SLI и SLO эффективны только в том случае, если они регулярно пересматриваются и обновляются, чтобы отражать изменения в вашем сервисе и потребностях клиентов.

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

• Как повлияло на клиентов то изменение, которое мы внедрили прошлой ночью?

• Повлияло ли это улучшение производительности на наши коэффициенты конверсии?

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

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

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

Я думаю, что это одна из причин существования SLOs (Service Level Objectives). Они ставят перед собой задачу сосредоточиться на клиентах при создании функций и услуг. Они включают отслеживание действий клиента в продакшне и получение обратной связи для принятия решений.

Не поймите меня неправильно… нам по-прежнему нужен подробный мониторинг инфраструктуры, платформы и приложения, чтобы помочь диагностировать проблемы и понимать, что происходит “под капотом”. Но если вы не знаете, как ведут себя клиенты, и вы не знаете, могут ли они использовать ваши услуги или нет — тогда устранение этого пробела является приоритетом.

Антипаттерн № 2— несогласованность окружений

Многие организации имеют сильно (или не очень) различные конфигурации и различающийся инструментарий для контроля наблюдаемости prod и preprod стендов, это несоответствие может привести к ряду проблем.

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

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

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

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

Антипаттерн № 3 — непонимание вашей экосистемы в целом

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

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

• Непонимание, кто является потребителями ваших услуг и что важно наблюдать (и что не важно).

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

• Отслеживание только метрик на стороне сервера, когда значительную работу выполняют браузеры или мобильные устройства клиентов — это делает вас слепыми к полной надежности, производительности и удобству работы клиентов. Это также может скрыть проблемы, такие, как проблемы с выполнением JavaScript.

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

Антипаттерн № 4 — отсутствие согласованного идентификатора для трассировки

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

Решить эту проблему просто. Просто убедитесь, что компонент верхнего уровня генерирует уникальный токен (trace или correlation ID), который передается на всем пути решения. Обычно он передается как заголовок HTTP. Изучите спецификацию B3 Propagation для примера.

Антипаттерн № 5 — большая и тупая метрика

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

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

Допустим, вы отслеживаете такой показатель, и ваш мониторинг показывает вам, что время отклика 95-го процентиля составляет 780 миллисекунд. Что вы узнали из этого числа? Как это вам помогает? Какое понимание это дает? Какие действия нужно предпринимать сейчас?

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

Другой пример “большой тупой метрики” возникает при мониторинге инфраструктуры. Я часто вижу мониторинг, который смотрит только на одну метрику: общий процент использования CPU. CPU важен, но это не единственный аппаратный ресурс, есть еще три, которые необходимо учитывать — это память, диск и сеть. И даже при отслеживании CPU, иногда нужно знать, какой именно процесс потребляет процессорное время, какие ядра процессора активны в определенный момент времени, или используется ли CPU системными или пользовательскими процессами. Бездумное отслеживание только одной метрики может в конечном итоге навредить.

Антипаттерн № 6 — плохие интервалы выборки

Интервалы выборки похожи на кровати из сказки “Маша и три медведя”. Вы не хотите, чтобы они были слишком большими или слишком маленькими, но хотите, чтобы они были именно такими, как нужно.

Давайте воспользуемся примером % загрузки процессора. Что, если вы решили фиксировать среднюю загрузку CPU на сервере каждые пять минут? В течение этого времени может быть период длительностью в одну минуту, когда нагрузка на CPU составляет 100%, а все остальное время она составляет 5%. Ваш мониторинг показал бы среднюю нагрузку на CPU в 24% за это пятиминутное окно, что верно, но мы не увидим того факта, что был период, когда наши клиенты, скорее всего, пострадали. Использование процессора на уровне 24% также вводит в заблуждение, потому что создается впечатление, что загрузка была довольно постоянной, тогда как на самом деле она происходила скачками.

С другой стороны, что было бы, если бы вы замеряли использование CPU каждую секунду? Статистически, будут периоды в одну секунду, когда использование CPU достигает 100%, но, в зависимости от контекста, это, вероятно, не окажет значительного влияния на пользователей. Что касается загрузки процессора, то речь идет о длительных периодах высокой нагрузки, которые приводят к возникновению очередей. Однажды я работал с командой, которая была зациклена на “максимальной загрузке процессора” как на своем ключевом показателе, что привело к массовой перегрузке инфраструктуры.

Антипаттерн № 7 — неверное понимание метрик

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

Один из примеров, который я вижу постоянно, — это отслеживание “доступной памяти” на сервере и утверждение, что “произошла утечка памяти”, когда уменьшается объем доступной памяти. Доступная память — это действительно “свободная” память, которая еще не выделена ни одному процессу. То, что “свободная” память закончилась, не означает, что на сервере нет доступной памяти для процессов.

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

Приложения часто разрабатываются таким образом, чтобы занимать как можно больше памяти для повышения эффективности; это нормальное поведение, особенно для СУБД. Если вы действительно хотите отслеживать объем памяти, делайте это на уровне платформы или приложения. Например, отслеживайте heap memory usage в JVM.

Еще один пример — это отслеживание использования CPU контейнера. В контексте контейнера, что такое “% загрузки CPU”? Что это значит? В своем выступлении на Neotys PAC 2020 “Видеть — значит знать, измерение CPU throttling в контейнерных средах” Edoardo Varani продемонстрировал (с доказательствами), что % загрузки CPU не является хорошим показателем того, насколько используется контейнер. Он смог создать ситуации, когда загрузка CPU контейнера составляла 100%, но производительность приложения не снижалась, или при 50% загрузке процессора приложение стояло в очереди на процессорное время. При мониторинге контейнеров смотрите на % Throttled Time как на более точный показатель того, насколько используется контейнер.

Антипаттерн № 8 — “ленивые” синтетические транзакции

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

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

1. Перейти на целевую страницу

2. Найти товар

3. Просмотреть товар

4. Добавить товар в корзину

5. Купить товар

“Ленивая синтетическая транзакция” перейдет на страницу… и все. Это легко реализовать, но не дает никакой гарантии, что желаемый результат (покупка клиентом товара) может быть достигнут. Если мы не можем это доказать, мы не выполняем свою работу.

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

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

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

Антипаттерн № 9 — чумовые дашборды

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

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

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

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

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

Антипаттерн № 10 — бесполезные алерты

Если вы не готовы проснуться в три часа ночи и фиксить проблему — то не создавайте на эту проблему алерт!

Каждый алерт, который не требует немедленных действий, учит ваших инженеров не воспринимать их всерьез. Я уверен, вы слышали о мальчике, который кричал “волки, волки!” — вот это и есть платформа мониторинга, которая кричит “крупный инцидент!”.

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

Как и в случае с другими моими замечаниями в этой статье, вернемся к удовлетворенности клиента — если ваши клиенты по-прежнему могут эффективно использовать ваши услуги (и нет угрозы этому в ближайшем будущем), то почему вы паникуете или просыпаетесь посреди ночи?

Антипаттерн № 11 — накопление данных

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

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

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

Антипаттерн № 12 — разобщенные данные

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

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

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

Антипаттерн № 13 — закидывание проблем инструментами

Проблемы решают не инструменты, а люди.

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

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

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

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

Антипаттерн № 14 — обязательные инструменты

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

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

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

Антипаттерн № 15–”избранные”

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

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

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

Более мягкой версией этого, что я видел в практически каждой организации, с которой работал, является то, что наблюдаемость полностью принадлежит инженерам DevOps или SRE, и только они вносят в нее вклад. Разработчики либо не заинтересованы, либо не участвуют в этом. Наблюдаемость так же важна для delivery, как и для эксплуатации. Нам нужно изменить культуру, сделав мониторинг вещью, которой кто-то будет пользоваться.

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

Выводы

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

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

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

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

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