Использование телеметрии (то есть снятия статистик с элементов архитектуры предприятия) с моей точки зрения одна из ключевых задач для обеспечения функционирования компании, которая стремится к успеху. Под функционированием я понимаю весь спектр показателей здоровья компании - ее прибыль, непрерывность, доступность, безопасность, качество и другие.
Но сейчас речь не об этом. Перечитывая книгу "Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях" обратила внимание на ряд тезисов, которыми хочу поделиться.
Первый говорил о том, что в одном из докладов 2015 State of DevOps Report было открытие, показывающее что успешные организации решали проблемы в создании программного решения в 168 раз быстрее, чем в других фирмах, а медианное значение измерялось в минутах (MTTR), при этом медиана неуспешных компаний измерялась днями.
И, ключевое, что основными условиями достижения такого успеха было использование контроля версий эксплуатацией ИТ и применение телеметрии и проактивного мониторинга среды.
Обращу внимание - что проактивный - это не реактивный мониторинг, который применяется многими службами эксплуатациями, чтобы ловить проблему, когда, как правило она уже стала заметна клиентам.
В том числе в книге упоминается перечень групп событий, созданный вице-президентом по исследованиям Gartner.
- решения о подтверждении прав доступа / авторизации (и отключения)
- сам доступ в систему / модуль / к данным
- изменения систем и приложений
- изменения данных (удаление, добавление, правка)
- некорректный ввод (возможно вредоносный, угрозы)
- ресурсы (ram, диск, проц, пропускная способность и др)
- работоспособность и доступность
- загрузка и завершение работ
- сбои и ошибки
- задержки
- успешные и неудачные резервные копирования
Так же автор рекомендует для упрощения интерпретации использовать нефункциональные характеристики событиям, такие как качество работы, безопасность и функциональные (такие как поиск, ранжирование).
Отсутствие отрытых данных о работе предприятия - лишний повод напряжения. Отсутствие видения реальной ситуации, возникающие из за этого проблемы и обвинения. Ошибки скрываются, участники защищаются.
Ценность использования достоверных данных о работе систем оказывает кроме положительного влияния на измеряемые параметры компании, но и усиливает сотрудничество между сотрудниками.
Пожалуй, здесь стоит еще раз обозначить уровни показателей. Мне нравится называть их факторами.
Так вот, факторы могут быть следующих уровней:
- бизнес. Здесь мы измеряем бизнес показатели - кол-во поставок, количество сделок, количество счетов, количество регистраций, % оттока, удовлетворенность клиентов, длительность процесса (к примеру, срок с момента обращения клиента до выдачи ему кредита).
- уровень приложений - на данном уровне мы измеряем параметры работы приложений, время транзакции, доступность и непрерывность систем.
- уровень инфраструктуры - здесь мы меряем показатели работы баз данных, ОС, сети, серверов, смотрим загрузку ЦПУ, объем свободного пространства, трафик сервера.
- уровень клиентского ПО (здесь мы смотрим на работу клиентских приложений, время выполнения операций, наличие ошибок, простои сервисов)
- уровень развертывания (здесь показатели показывающие работу процесса развертывания, такие как время развертывания, частота, статус сборки)
Я бы дополнила данный перечень между уровнем бизнес и приложений - уровень сервисов. О чем мы говорим - а о том, что на языке бизнеса не интересно как работают приложения, бизнесу важно как работает процесс в целом. Соответственно возникает еще уровень метрик, на котором мы измеряем работоспособность сервисов обеспечивающих процесс, его доступность, непрерывность, мощность, скорость выполнения этапов и прочие метрики.
Еще стоит заметить, что измерение важно делать не только на рабочей среде, но и на окружении разработчика, тестовом контуре, среде тестирования). Такая телеметрия позволит отсеивать и обнаруживать проблемы до того, как изменение поступит на продуктив.
Еще дополню своим взглядом на категории факторов (показателей):