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

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

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

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

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

• Информационный уровень.На этом уровне данные состоят из специфических для конкретной системы действий или же действий, совершаемых пользователем (например, «начало транзакции с использованием кредитной карты»).

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

• Уровень ошибок.На этом уровне собирается информация об ошибках (например, падение при API-вызове или внутренняя ошибка).

• Критический уровень.Данные на этом уровне сообщают нам, когда мы должны прервать работу (например, сетевой агент (так называемый демон) не может подключиться к сетевому соединителю («сокету»)).

Выбор правильного уровня логирования важен. Дэн Норт, бывший консультант компании ThoughtWorks, принимавший участие в нескольких проектах, где были сформированы основные принципы непрерывной поставки ПО, замечает: «Когда вы решаете, должно ли сообщение звучать как ОШИБКА или ПРЕДУПРЕЖДЕНИЕ, представьте, что вас разбудили в четыре утра. Закончился тонер в принтере — это не ОШИБКА».

Чтобы убедиться, что у нас есть вся относящаяся к устойчивой и надежной работе приложения информация, нужно удостовериться, что все потенциально значимые события генерируют логи. Обязательно нужно учесть группы событий, собранные в списке Антона Чувакина, вице-президента по исследованиям, работающего в группе безопасности и риск-менеджмента подразделения GTP (Gartner for Technical Professionals) компании Gartner:

• решения о подтверждении прав доступа/авторизации (включая выход из системы);

• доступ в систему и доступ к данным;

• изменения системы и приложения (особенно изменения, связанные с правами доступа);

• изменения данных, такие как добавление, правка и удаление данных;

• некорректный ввод (возможный ввод вредоносных данных, угрозы и так далее);

• ресурсы (RAM, диск, процессор, пропускная способность соединения и любые другие ресурсы, имеющие жесткие или мягкие ограничения);

• работоспособность и доступность;

• загрузка и завершение работы;

• сбои и ошибки;

• срабатывание автоматического выключателя;

• задержки;

• успешное или неудачное резервное копирование [110].

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

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