Джин Ким - Руководство по DevOps

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

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

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

• Каковы доказательства того, что проблема действительно существует?

• Какие значимые события и изменения в наших приложениях и окружении могли привести к этой проблеме?

• Какие гипотезы мы можем сформулировать, чтобы подтвердить связь между предложенными причинами и следствиями?

• Как мы можем доказать, какие из гипотез верны и ведут к решению проблемы?

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

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

Эта философия привела к разработке одной из самых используемых библиотек показателей StatsD. Она появилась на свет в компании Etsy. Как сказал Джон Оллспоу, «Мы создали StatsD для того, чтобы разработчики больше не говорили: “Добавлять в мой код средства измерения слишком напряжно”. Теперь они могут делать это одной строчкой кода. Нам было важно, чтобы разработчики не считали добавление телеметрии такой же сложной задачей, как изменение схемы базы данных».

Программа StatsD может генерировать таймеры и счетчики с помощью одной строки кода (на Ruby, Perl, Python, Java и других языках), и ее часто используют вместе с Graphite или Grafana, преобразующих события в графики и панели индикаторов.

На рис. 27 приведен пример того, как одна строчка кода создает событие «вход пользователя в систему» (в этом случае строка на PHP: “StatsD:: increment(“login.successes”)). Итоговый график показывает количество успешных и неудачных входов за минуту, а вертикальные линии обозначают моменты, когда происходило развертывание продукта.

Рис. 27. Одна строка кода для генерирования телеметрии с помощью StatsD и Graphite в компании Etsy (источник: Йен Малпасс, Measure Anything, Measure Everything)

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

Среди альтернативных StatsD библиотек, позволяющих разработчикам генерировать легко агрегируемую и анализируемую эксплуатационную телеметрию, можно назвать JMX и codahale metrics. Другие инструменты для сбора показателей — New Relic, AppDynamics и Dynatrace. Для того чтобы добиться схожей функциональности, можно также использовать munin и collectd [112].

Сделайте доступ к телеметрии свободным и создайте распространители информации

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