Примите автоматизацию: опережайте в DevOps

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

Обычно думаем о мониторинге как о процессе рядом с этим — его работа: алертить операторов, когда что-то идет не так, помогать анализировать проблемы, подтверждать соответствие SLO. Но лучшая практика — относиться к мониторингу как к важной части ops-автоматизации. Современная полнофункциональная платформа мониторинга может быть мощным автоматизационным движком самим по себе и критическим энейблером для более крупных инициатив автоматизации в управлении жизненным циклом приложений и инфраструктуры и митигации проблем. Она может даже, во многих случаях, работать для обеспечения автономных операций вроде self-scaling и self-healing.

>См. также: IT monitoring: Не мониторь себя в безумие, Opsview

Вот некоторые способы, как ваша система мониторинга может помочь сделать больше, устранить человеческие ошибки и встречать (не просто соответствовать) SLO:

Стреамлайненый, автоматизированный деплой и lifecycle management мониторинга. On-premises решения могут co-reside с мониторимой инфраструктурой; в классических приватных облаках и дата-центрах и в provider-hosted VPCs. Это позволяет соблюдать безопасность, приватность, data governance и другие регуляции; и помогает преодолеть барьеры bandwidth и стоимости, лимитирующие масштабируемость SaaS-мониторинга. Premise-мониторинг должен деплоиться, скейлиться и обновляться — и это может быть daunting для всех, кроме очень простых single-server конфигураций.

Forward-looking makers такого мониторинга начинают эксплуатировать популярные фреймворки деплой-автоматизации вроде Ansible, Puppet, Chef (те же, что DevOps использует для автоматизации инфраструктуры и рутинных операций) для стреамлайнинга деплоя мониторинга в scaled-out, highly-available конфигурациях. Для удобства операторов они прячут сложность deployment-tools за webUI и упрощенными конфигураторами, хотя стандартный тулинг доступен для DevOps-фолков, желающих совместить деплой мониторинга или metrics-collector с инфраструктурными roll-outs — best practice. Детали мониторинга могут быть определены и поддерживаться как часть definitive «infrastructure as code» репозиториев.

>См. также: Ценность видимости в вашем дата-центре

Автоматизированный деплой агентов и регистрация мониторимых объектов через API. Стандартные тулы деплоя вроде Ansible также могут использоваться для инжекта, конфигурации и обновления компонентов мониторинга (endpoint agents, required libraries, etc.) на хостах. Те же тулы могут извлекать факты из деплой-манифестов или напрямую с хостов во время деплоя, затем использовать API мониторинга для быстрой конфигурации мониторинга хост-инфраструктуры и приложений, а также «unmonitor» хостов в конце жизни. Рутинное постановка систем под мониторинг сразу после деплоя позволяет быстрый детект проблем в staging или production, и может использоваться для триггеринга rollbacks, если требуется — важная best-practice для continuous delivery.

CMDB ingestion. Некоторые платформы мониторинга могут ингестить данные из operations management тулов и configuration management databases (CMDBs), таких как от ServiceNow и похожих вендоров. Это позволяет операторам быстро и confidently конфигурировать мониторинг для существующей инфраструктуры, приложений и полных бизнес-сервисов — избегая laborious и error-prone ручной компиляции системных фактов.

>См. также: Какое right storage software нужно для успеха DevOps?

Discovery и auto-monitoring. Sophisticated решения мониторинга используют растущий спектр методов, включая прямой доступ к хостам через SSH и косвенный через конфигурационные репозитории вроде ActiveDirectory и сервисы вроде Windows Discovery, для извлечения фактов из существующей инфраструктуры и ускорения конфигурации мониторинга операторами. Leading-edge продукты теперь движутся к полной автоматизации процесса: создания comprehensive мапов инфраструктуры, приложений, полных бизнес-сервисов и мониторинга этих вещей без необходимости ручного вмешательства или направления.

Обработка алертов, нотификация, эскалация, интеграция. Алертинг — мощная форма автоматизации. Включает decision-making, которое может быть простым (какая-то метрика превысила порог) или значительно более сложным (несколько метрик из отдельных систем вошли в состояния, predictive для определенного вида known failure критического бизнес-сервиса). Включает sophisticated assignment и эскалацию на основе issue, team rotas, time/date и других переменных. Требует outbound интеграцию с коммуникационными методами вроде email, или с multi-mode notification платформами вроде PagerDuty; или более sophisticated интеграцию с issue-management (JIRA) или operations workflow management (ServiceNow) а также коллаборацией (Slack) и другими решениями. Вся эта автоматизация работает вместе, чтобы получить правильный алерт правильному человеку в правильное время, избегая over-alerting и fatigue — сглаживая операции и помогая командам избегать downtime и встречать SLO commitments.

>См. также: Как workload automation может привести DevOps к скорости

Проактивная митигация проблем. Финально, sophisticated решения мониторинга теперь дают способность исполнять скрипты на хостах или триггерить централизованную автоматизацию (Ansible) для выполнения задач на основе мониторимых условий: от ребута упавшего сервера до скейлинга infrastructure cluster. За следующее десятилетие разработки в ML постепенно улучшат способность мониторить системы для дедукции абстрактной структуры и функции бизнес-сервисов, мониторить их автоматически, предсказывать режимы отказа, ремонтировать и оптимизировать производительность — либо автономно, либо через оптимальное выделение ресурсов операторов к задачам.

Автор: Джон Джейншигг, content strategy lead at Opsview