Главная
»
Блог
»
Повышаем надёжность цифровых сервисов: слияние методологий SRE и DevOps

Повышаем надёжность цифровых сервисов: слияние методологий 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, с помощью которых можно добиться безотказной работы сервиса. Это мониторинг, логирование, описание инфраструктуры кодом и составление постмортемов.

Инструменты SRE

Мониторинг и метрики

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

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

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

Для мониторинга мы используем открытое программное обеспечение, стандарт отрасли: Prometheus и Grafana.

Логирование

Логирование представляет собой ведение логов (журнала событий) — системных сообщений, которые записывает любая работающая в системе программа.

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

Инженеры Git in Sky в рамках своей работы не только внедряют логирование, но и обучают разработчиков клиента пользоваться этим инструментарием для того, чтобы быстро и эффективно искать ошибки в системе. В качестве системы централизованного хранения журналов мы предлагаем к использованию ELK/EFK-стэк:

ElasticSearch — для СУБД;
Logstash/Filebeat/Fluentd — для сбора логов;
Kibana — для визуализации данных.

Инфраструктура как Код (IaC)

Одним из ключевых элементов, способствующих успешному слиянию DevOps и SRE, является подход «Инфраструктура как код» (IaC). Описание инфраструктуры кодом обеспечивает культуру минимизации человеческого фактора при эксплуатации и изменениях в IT-инфраструктуре. IaC позволяет хранить описание инфраструктуры в виде программного кода в репозиториях с контролем версий. Часто причина отказов в сервисах заключается в том, что кто-то из разработчиков внёс некорректные изменения в настройки сервера, из-за чего сервис перестал работать.

В Git in Sky эта ситуация купируется тем, что мы не настраиваем десятки серверов вручную после внесения правок в код. Мы пишем код один раз, проверяем его на одном сервере, а затем распространяем правку по всей базе серверов. Так мы значительно снижаем вероятность человеческой ошибки. Для описания инфраструктуры кодом мы используем открытую систему управления конфигурациями Ansible. Этот подход заметно улучшает предсказуемость работы инфраструктуры, позволяет иметь полный контроль и историю изменений.

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

Постмортемы

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

Результаты применения SRE+DevOps

Мы предлагаем своим клиентам внедрить перечисленный выше инструментарий и обучаем разработчиков, DevOps-сотрудников или SRE-специалистов компании-заказчика его правильному использованию. Эта научно-исследовательская работа направлена на улучшение таких параметров сервиса клиента, как отказоустойчивость и производительность. Уровень проводимой работы зависит от бизнес-требований компании и результатов аудита.

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

Обычно результат нашей работы выглядит так: вначале — клиент, пришедший с регулярными инцидентами и проблемами, каждая из которых имеет свою, зачастую уникальную причину и решение, а итоговый результат можно описать фразой «всё работает и не ломается».

Заключение

Методология DevOps и практики SRE представляют собой важные инструменты для достижения высокой надёжности и масштабируемости систем в условиях современного IT-ландшафта. Слияние этих подходов позволяет компаниям более эффективно управлять своими IT-инфраструктурами, обеспечивая непрерывную доступность и качество услуг. Подход «Инфраструктура как код» улучшает предсказуемость и контроль инфраструктуры, мониторинг и анализ логов позволяют своевременно реагировать на инциденты, а постмортемы помогают командам учиться на ошибках и постоянно улучшать процессы и системы.

Отзывы клиентов

Айри.рф работает как SaaS, обеспечивая ускорение и защиту сайтов. Нам важна 100% доступность серверов и максимальная отказоустойчивость. Нам как специалистам по облакам приятно иметь дело с профессионалами!

— Николай Мациевский, генеральный директор Айри.рф

Мы открыли портал на базе системы управления сайтами UMI.CMS. Работая с 1998 года, мы накопили несколько десятков тысяч материалов и статей. В 2010 году мы призвали читателей активно комментировать статьи, и база стала расти еще быстрее. Вместе с ней росло и количество читателей. В определенный момент мы начали испытывать трудности, так как административная панель часто «подвисала», и порой приходилось ждать до нескольких минут, пока статья сохранится или откроется для редактирования. Все это серьезно замедляло нашу работу. Мы обратились к Сергею Житинскому, и уже через неделю «подвисания» исчезли, база стала работать нормально. Скорость работы редакторов с контентом возросла, мы стали размещать больше материалов, перестали тратить время на бесполезное ожидание. Что касается посещаемости ресурса, то она существенно увеличилась. Мы сотрудничаем с Житинским на постоянной основе и теперь стали клиентами его предприятия Git in Sky, хотя русскому уху приятнее официальное название его компании — ООО «Жить в небе».

— Анатолий Степанов, главный редактор портала «Русская народная линия»

Поскольку почтовые рассылки - это один из основных элементов деятельности - к ТП Git in Sky чаще всего обращаемся по поводу каких-то неполадок с почтой, хотя в последнее время они случаются совсем редко - может быть - раз в полгода".

— Денис Каланов, генеральный директор, ООО «АйТи-Событие»

На простом языке наша задача звучала так: «Мы хотим, чтобы сайт не падал, и чтобы ни при каких условиях (сбой, человеческий фактор, наводнение и т.п.) данные наших пользователей не пропали».

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

Также стоит отметить доступность коллег и быстрый отклик, а особенно — наличие "аварийного" чата, где всегда кто-то дежурит и где можно рассчитывать на оперативную поддержку.

— Олег Баша, генеральный директор, Learme

Успешно сотрудничаем с конца 2013 года. Компания Git In Sky помогла нам перенести данные в «облака», оптимизировать инфраструктуру. Оперативно помогает справляться с возникающими сложностями.

— Кузнецов Антон, системный администратор

Айри.рф работает как SaaS, обеспечивая ускорение и защиту сайтов. Нам важна 100% доступность серверов и максимальная отказоустойчивость. Нам как специалистам по облакам приятно иметь дело с профессионалами!

— Николай Мациевский, генеральный директор Айри.рф

Мы открыли портал на базе системы управления сайтами UMI.CMS. Работая с 1998 года, мы накопили несколько десятков тысяч материалов и статей. В 2010 году мы призвали читателей активно комментировать статьи, и база стала расти еще быстрее. Вместе с ней росло и количество читателей. В определенный момент мы начали испытывать трудности, так как административная панель часто «подвисала», и порой приходилось ждать до нескольких минут, пока статья сохранится или откроется для редактирования. Все это серьезно замедляло нашу работу. Мы обратились к Сергею Житинскому, и уже через неделю «подвисания» исчезли, база стала работать нормально. Скорость работы редакторов с контентом возросла, мы стали размещать больше материалов, перестали тратить время на бесполезное ожидание. Что касается посещаемости ресурса, то она существенно увеличилась. Мы сотрудничаем с Житинским на постоянной основе и теперь стали клиентами его предприятия Git in Sky, хотя русскому уху приятнее официальное название его компании — ООО «Жить в небе».

— Анатолий Степанов, главный редактор портала «Русская народная линия»

Поскольку почтовые рассылки - это один из основных элементов деятельности - к ТП Git in Sky чаще всего обращаемся по поводу каких-то неполадок с почтой, хотя в последнее время они случаются совсем редко - может быть - раз в полгода".

— Денис Каланов, генеральный директор, ООО «АйТи-Событие»

На простом языке наша задача звучала так: «Мы хотим, чтобы сайт не падал, и чтобы ни при каких условиях (сбой, человеческий фактор, наводнение и т.п.) данные наших пользователей не пропали».

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

Также стоит отметить доступность коллег и быстрый отклик, а особенно — наличие "аварийного" чата, где всегда кто-то дежурит и где можно рассчитывать на оперативную поддержку.

— Олег Баша, генеральный директор, Learme

Успешно сотрудничаем с конца 2013 года. Компания Git In Sky помогла нам перенести данные в «облака», оптимизировать инфраструктуру. Оперативно помогает справляться с возникающими сложностями.

— Кузнецов Антон, системный администратор