Повышаем надёжность цифровых сервисов: слияние методологий SRE и DevOps
В современном мире технологий, где надёжность и масштабируемость систем становятся ключевыми факторами успеха, практики Site Reliability Engineering (SRE) и DevOps играют решающую роль. Эти методологии не только способствуют улучшению качества предоставляемых услуг, но и обеспечивают их непрерывную доступность и устойчивость. Рассмотрим, как методология DevOps плавно сплетается с практиками SRE для обеспечения надёжности сервисов, выделим основные различия между ними и отметим результаты работы применения связки SRE+DevOps в организации.
Для начала определимся, что стоит понимать под надёжностью и чем она отличается от производительности? Надёжность цифрового сервиса характеризуется прежде всего его отказоустойчивостью, а производительность — временем отклика. Компаниям важно, чтобы сервис откликался на действия пользователя за минимальное время. Но также важно (а сегодня порой и важнее), чтобы количество инцидентов в его работе было минимальным, а скорость и качество восстановления системы после сбоя были такими, чтобы ситуация не приносила убытков. Поэтому под надёжностью системы понимают и способность к предотвращению инцидента с помощью превентивных мер, и возможность сервиса продолжить работу после инцидента, пусть и с некоторой деградацией. Как влияют на надёжность сервисов DevOps и SRE?
Как сочетаются и в чём различаются DevOps и SRE
DevOps, возникший как движение для улучшения сотрудничества между разработчиками и операционными командами, ставит своей целью ускорение доставки программного обеспечения и повышение его качества. Основные принципы DevOps включают автоматизацию процессов, непрерывную интеграцию и доставку (CI/CD), а также мониторинг и обратную связь.
Site Reliability Engineering представляет собой подход к управлению ИТ-инфраструктурой и операциями, ориентированный на достижение высокой надёжности систем. SRE сочетает в себе элементы архитектуры и ИТ-операций, что позволяет создавать более устойчивые и масштабируемые системы.
Основное различие между SRE и DevOps заключается в их фокусе. DevOps охватывает весь жизненный цикл приложения: от разработки до развертывания и эксплуатации. Его цель — улучшить взаимодействие между разработчиками и операционными командами, чтобы ускорить выпуск новых функций и улучшить качество программного обеспечения.
SRE, с другой стороны, фокусируется на эффективности и стабильности производственной среды. Это включает управление надёжностью, масштабируемостью и производительностью эксплуатируемых систем. Важно отметить, что предприятиям не приходится выбирать между SRE и DevOps — они могут дополнять друг друга. DevOps помогает быстро и эффективно разрабатывать и развёртывать новые функции, тогда как SRE обеспечивает стабильность и надёжность этих функций в производственной среде.
В отличие от SRE, о DevOps написано много. Нам бы хотелось рассказать про инструменты SRE, с помощью которых можно добиться безотказной работы сервиса. Это мониторинг, логирование, описание инфраструктуры кодом и составление постмортемов.
Site Reliability Engineering представляет собой подход к управлению ИТ-инфраструктурой и операциями, ориентированный на достижение высокой надёжности систем. SRE сочетает в себе элементы архитектуры и ИТ-операций, что позволяет создавать более устойчивые и масштабируемые системы.
Основное различие между SRE и DevOps заключается в их фокусе. DevOps охватывает весь жизненный цикл приложения: от разработки до развертывания и эксплуатации. Его цель — улучшить взаимодействие между разработчиками и операционными командами, чтобы ускорить выпуск новых функций и улучшить качество программного обеспечения.
SRE, с другой стороны, фокусируется на эффективности и стабильности производственной среды. Это включает управление надёжностью, масштабируемостью и производительностью эксплуатируемых систем. Важно отметить, что предприятиям не приходится выбирать между SRE и DevOps — они могут дополнять друг друга. DevOps помогает быстро и эффективно разрабатывать и развёртывать новые функции, тогда как SRE обеспечивает стабильность и надёжность этих функций в производственной среде.
В отличие от SRE, о DevOps написано много. Нам бы хотелось рассказать про инструменты SRE, с помощью которых можно добиться безотказной работы сервиса. Это мониторинг, логирование, описание инфраструктуры кодом и составление постмортемов.
Инструменты SRE
Мониторинг и метрики
Мониторинг позволяет отслеживать все события, происходящие в системе, благодаря чему можно понимать причины произошедших аварий и предотвращать возможные инциденты. Работа в этой области заключается в правильном подборе метрик: что и как надо отслеживать в конкретном сервисе, на какие графики смотреть и так далее.
Важно ориентироваться на конкретные метрики производительности и надёжности, а не на субъективные ощущения. Например, вместо того чтобы полагаться на такие субъективные выражения, как «стало медленно работать», SRE использует точные метрики, которые позволяют выявлять время начала деградации сервиса и находить события, повлекшие за собой проблемы. Такой подход способствует более оперативному и точному реагированию на инциденты, улучшая общую устойчивость системы. Для мониторинга мы используем открытое программное обеспечение, стандарт отрасли: Prometheus и Grafana.
Важно ориентироваться на конкретные метрики производительности и надёжности, а не на субъективные ощущения. Например, вместо того чтобы полагаться на такие субъективные выражения, как «стало медленно работать», SRE использует точные метрики, которые позволяют выявлять время начала деградации сервиса и находить события, повлекшие за собой проблемы. Такой подход способствует более оперативному и точному реагированию на инциденты, улучшая общую устойчивость системы. Для мониторинга мы используем открытое программное обеспечение, стандарт отрасли: Prometheus и Grafana.
Логирование
Логирование представляет собой ведение логов (журнала событий) — системных сообщений, которые записывает любая работающая в системе программа. Деятельность SRE-инженеров здесь заключается в правильной организации работы с журналами. Часто поиск причин ошибки или событий в логах разных программ превращается в проблему, поскольку этих программ может быть довольно много и они находятся в разных местах IT-инфраструктуры. Мы применяем специальные инструменты, которые могут собирать логи в единую базу данных и искать нужные события в логах по ключевым словам, проводить статистический анализ событий. Грамотно настроенное логирование ускоряет действия по поиску проблем в инфраструктуре и ошибок в работе сервисов компании.
Инженеры Git in Sky в рамках своей работы не только внедряют логирование, но и обучают разработчиков клиента пользоваться этим инструментарием для того, чтобы быстро и эффективно искать ошибки в системе. В качестве системы централизованного хранения журналов мы предлагаем к использованию ELK/EFK-стэк:
Инженеры Git in Sky в рамках своей работы не только внедряют логирование, но и обучают разработчиков клиента пользоваться этим инструментарием для того, чтобы быстро и эффективно искать ошибки в системе. В качестве системы централизованного хранения журналов мы предлагаем к использованию ELK/EFK-стэк:
- ElasticSearch — для СУБД;
- Logstash/Filebeat/Fluentd — для сбора логов;
- Kibana — для визуализации данных.
Инфраструктура как Код (IaC)
Одним из ключевых элементов, способствующих успешному слиянию DevOps и SRE, является подход «Инфраструктура как код» (IaC). Описание инфраструктуры кодом обеспечивает культуру минимизации человеческого фактора при эксплуатации и изменениях в IT-инфраструктуре. IaC позволяет хранить описание инфраструктуры в виде программного кода в репозиториях с контролем версий. Часто причина отказов в сервисах заключается в том, что кто-то из разработчиков внёс некорректные изменения в настройки сервера, из-за чего сервис перестал работать.
В Git in Sky эта ситуация купируется тем, что мы не настраиваем десятки серверов вручную после внесения правок в код. Мы пишем код один раз, проверяем его на одном сервере, а затем распространяем правку по всей базе серверов. Так мы значительно снижаем вероятность человеческой ошибки. Для описания инфраструктуры кодом мы используем открытую систему управления конфигурациями Ansible. Этот подход заметно улучшает предсказуемость работы инфраструктуры, позволяет иметь полный контроль и историю изменений.
Так же данный подход позволяет иметь полную историю изменений, вносимых в инфраструктуру, что совместно с мониторингом позволяет находить изменения, после которых, например, произошла деградация производительности или участились инциденты.
В Git in Sky эта ситуация купируется тем, что мы не настраиваем десятки серверов вручную после внесения правок в код. Мы пишем код один раз, проверяем его на одном сервере, а затем распространяем правку по всей базе серверов. Так мы значительно снижаем вероятность человеческой ошибки. Для описания инфраструктуры кодом мы используем открытую систему управления конфигурациями Ansible. Этот подход заметно улучшает предсказуемость работы инфраструктуры, позволяет иметь полный контроль и историю изменений.
Так же данный подход позволяет иметь полную историю изменений, вносимых в инфраструктуру, что совместно с мониторингом позволяет находить изменения, после которых, например, произошла деградация производительности или участились инциденты.
Постмортемы
Постмортемы представляют собой отчёты или небольшие статьи, написанные по результатам решения инцидента. Они являются обязательной частью работы SRE и позволяют инженерам делиться важным знанием с командой, помогая избежать подобных ошибок в будущем.
Постмортемы включают описание инцидента, анализ причин и следствий, а также предложения по улучшению процессов и систем для предотвращения аналогичных проблем в будущем. На основании постмортема производится планирование работ по устранению коренных причин инцидента, что способствует непрерывному улучшению надёжности и стабильности системы.
Постмортемы включают описание инцидента, анализ причин и следствий, а также предложения по улучшению процессов и систем для предотвращения аналогичных проблем в будущем. На основании постмортема производится планирование работ по устранению коренных причин инцидента, что способствует непрерывному улучшению надёжности и стабильности системы.
Результаты применения SRE+DevOps
Мы предлагаем своим клиентам внедрить перечисленный выше инструментарий и обучаем разработчиков, DevOps-сотрудников или SRE-специалистов компании-заказчика его правильному использованию. Эта научно-исследовательская работа направлена на улучшение таких параметров сервиса клиента, как отказоустойчивость и производительность. Уровень проводимой работы зависит от бизнес-требований компании и результатов аудита.
Одной из основных трудностей, с которой сталкиваются компании при внедрении SRE, является невозможность наглядно продемонстрировать результаты применения этой методологии. В отличие от разовых мероприятий или проектов, SRE представляет собой непрерывный процесс, направленный на постоянное улучшение надёжности и производительности систем. Это делает поиск ярких примеров достаточно сложным.
SRE не может быть оценено на основе отдельных событий или инцидентов. Вместо этого его эффективность проявляется в долгосрочной перспективе, когда системы становятся более устойчивыми к сбоям, а время простоя сокращается. Ключевые показатели, такие как время восстановления после инцидентов и частота отказов, могут демонстрировать успехи, но они требуют анализа на протяжении длительного времени.
Обычно результат нашей работы выглядит так: вначале — клиент, пришедший с регулярными инцидентами и проблемами, каждая из которых имеет свою, зачастую уникальную причину и решение, а итоговый результат можно описать фразой «всё работает и не ломается».
Одной из основных трудностей, с которой сталкиваются компании при внедрении SRE, является невозможность наглядно продемонстрировать результаты применения этой методологии. В отличие от разовых мероприятий или проектов, SRE представляет собой непрерывный процесс, направленный на постоянное улучшение надёжности и производительности систем. Это делает поиск ярких примеров достаточно сложным.
SRE не может быть оценено на основе отдельных событий или инцидентов. Вместо этого его эффективность проявляется в долгосрочной перспективе, когда системы становятся более устойчивыми к сбоям, а время простоя сокращается. Ключевые показатели, такие как время восстановления после инцидентов и частота отказов, могут демонстрировать успехи, но они требуют анализа на протяжении длительного времени.
Обычно результат нашей работы выглядит так: вначале — клиент, пришедший с регулярными инцидентами и проблемами, каждая из которых имеет свою, зачастую уникальную причину и решение, а итоговый результат можно описать фразой «всё работает и не ломается».
Заключение
Методология DevOps и практики SRE представляют собой важные инструменты для достижения высокой надёжности и масштабируемости систем в условиях современного IT-ландшафта. Слияние этих подходов позволяет компаниям более эффективно управлять своими IT-инфраструктурами, обеспечивая непрерывную доступность и качество услуг. Подход «Инфраструктура как код» улучшает предсказуемость и контроль инфраструктуры, мониторинг и анализ логов позволяют своевременно реагировать на инциденты, а постмортемы помогают командам учиться на ошибках и постоянно улучшать процессы и системы.