Спонсировал сотовые сопозиции этот пост.
В течение многих лет организации использовали термин «наблюдение» в качестве эволюции мониторинга, дисциплина, практикуемая операционными группами, чтобы понять, работает ли производственное программное обеспечение. Я был раздражен этим, не потому, что это философски неправильно, а потому, что это уменьшает важность наблюдаемости как обобщенной практики разработки программного обеспечения.
Наблюдаемость гораздо больше о разработке программного обеспечения, чем о операциях. Операторы являются пользователями данных об наблюдении для мониторинга и оповещения о системах. Они будут использовать эти телеметрические данные для масштабирования систем или потенциально отлаживать внешнюю внешнюю часть приложений. Напротив, инженеры -программисты являются создателями, дизайнерами, пользователями данных об наблюдении, и они используют эти данные гораздо широко, чем у чистых операторов производственных систем.
Наблюдаемость для всех
Для оператора наблюдаемость заключается в сборе данных сигнала (журналы, метрики, трассировки, профили, исключения, дампы стека и т. Д.), А затем с использованием этих данных, чтобы установить, адекватно ли производственная система действует против предопределенных стандартов.
Для инженера наблюдаемость заключается в создании опыта отладки для себя и других. Этот опыт не ограничивается производственной средой или даже для развертываемого программного обеспечения. Это может быть для местных приложений, таких как тестирование распределенных систем или для промежуточных сред, таких как развернутая среда разработки. Это принцип, который мы строим как часть нашего повседневного развития. Более того, инженеры -программисты делали это на протяжении десятилетий, так как мы впервые начали выдвигать код, который мы пишем пользователям.
Классическая цитата — «Printf — это наблюдаемость OG», и это правильно. Наблюдаемость — это понимание внутреннего состояния нашего программного обеспечения, задавая вопросы извне. Это то, что мы делаем с Printf: вывод некоторой информации о состоянии, поэтому мы понимаем, что происходит внутри выхода, который мы видим. Со временем мы превратили это в более общую практику, называемую «лесозаготовленность», и именно здесь инженеры жили в течение ряда десятилетий. Но принцип такой же: понять, что происходит внутри приложения.
Никто никогда не скажет, что добавление операторов журнала не является частью разработки программного обеспечения. Это было бы смешно. Но каким -то образом мы, кажется, думаем, что другие данные сигнала каким -то образом не являются частью разработки программного обеспечения, отдельными и зарезервированными для эксплуатации программного обеспечения в производстве. Такие сигналы, как отслеживание и метрики, должны быть добавлены только операторами, использующими агентов в производственной среде. Я не могу поверить, что кто -то будет выступать за идею о том, что библиотеки не должны добавлять достаточно данных, чтобы инженеры взаимодействовали с ней, чтобы узнать, что происходит.
Я считаю, что причина этого заключается в том, что существует давняя идея, что «регистрация»-это то, что мы используем, чтобы видеть вещи локально, пока мы развиваемся в режиме реального времени, тогда как метрики полезны только в совокупности, поэтому они полезны только в производстве. Это, вероятно, точные утверждения, но в современном мире регистрация по нескольким системам сложнее — и именно здесь появляется трассировка.
Практики программного обеспечения «Неубедительные»
Мы думаем о разработке программного обеспечения как о определенных принципах, которые не подлежат обсуждению:
- тестирование
- читаемый код
- уменьшение распределения
- Последовательное форматирование
- охрана
Эти принципы устанавливают планку. Мы становимся великими программистами, когда делаем это хорошо, и когда они позволяют нам идти быстрее.
Пришло время добавить инструменты в этот список
Инструментальный код, выполненный хорошо, является множителем силы в разработке программного обеспечения. Это помогает со всем, от того, чтобы сделать код читаемым (подумайте о них как о исполняемых комментариях, которые затем доступны для поиска в использовании производства) до тестирования и запуска кода локально. Кроме того, это заставляет людей думать о том, как будет работать код в производстве, поэтому поощряет разработку программного обеспечения и кода, который является более обслуживаемым.
Чтобы использовать пример: очень часто можно увидеть использование «умного» кода в приложениях, где инженер написал очень сложную операцию в одной строке кода, которая по сути нечитана кем -либо, кроме этого человека. Заманчиво написать строку кода, которая может найти изображение в файловой системе, изменить размер, сжать его, а затем обслуживать его пользователю. Этот код может выглядеть удивительно простым и элегантным, но с точки зрения наблюдаемости производства, это ужасно. Каждый шаг нуждается в телеметрии, поэтому инженеры вынуждены подумать о том, какая информация будет полезна для каждого. Это, в свою очередь, заставляет инженеров разбить эти действия, что в конечном итоге приводит к более читаемому коду.
Хорошо продуманные инструменты-один из наиболее эффективных способов изменить кодовую базу в лучшую сторону, будь то новая кодовая база, которую мы строим, или унаследованная, которую мы взяли во владение. Добавление этого инструментария, чтобы помочь с нашим местным циклом отладки, чтобы увидеть все пути выполнения, изменит правила игры. Выполнение параллельного кода, подвеска пути, вызовы базы данных, которые мы забываем, происходят, потому что они спрятаны за 10 слоями абстракции — это все, что будет вслед за хорошими инструментами.
Является ли доставка кода без возможности наблюдать его приемлемым?
Чтобы определить мастерство разработки программного обеспечения, мы должны спросить себя: где бы мы были, если бы не сделали этого? Кодовые базы, где мы не думали о том, как мы будем наблюдать за вещами в производстве, могут быть хорошими, но, по моему мнению, они редки. Речь идет о моделях, которые мы надеемся увидеть при принятии новой кодовой базы. Это распространяется на то, что мы надеемся увидеть, когда мы поддерживаем эту кодовую базу в производстве.
Выпустить новые функции? Добавьте журналы с контекстом происходящего, добавьте данные в пролеты или создайте новые, и создайте метрики для долгосрочного анализа.
Нам нужно рассмотреть вопрос о том, является ли доставка кода, не имея возможности понять, что происходит внутри (реальное определение наблюдаемости), приемлемым в 2025 году. Это выходит далеко за рамки идеи установки агента в мире APM (мониторинг производительности приложений), чем мы использовали.
Я вижу тенденцию к инженерам, рассматривающим практику обращения с телеметрией, инструментами и наблюдаемостью как первоклассным гражданином в течение всего жизненного цикла разработки программного обеспечения. Я надеюсь, что это превращается в инженеров, которые видят телеметрию как столовые ставки — только часть работы. Операции видели значение в этих данных. Пришло время инженерам понять, почему.
Honeycomb — это платформа наблюдения, которая позволяет инженерным командам находить и решать проблемы, которые они не могли раньше. Insight Partners является инвестором в Honeycomb и TNS. Узнайте больше последних из Honeycomb Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Martin Thwaites — разработчик, оратор и евангелист наблюдения, который в настоящее время работает в отношении отношений разработчиков для honeycomb.io. Узнайте больше от Мартина Туайта
