По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Можете ли вы представить себе компанию, в которой никто бы не управлял IT-инфраструктурой и операциями? Скорее всего, нет. Вот здесь и начинается SRE (обеспечение надежности информационных систем) и DevOps (автоматизация сборки, настройки и развертывания ПО). В последние годы оба этих направления стали очень популярными в IT-среде, и их распространенность продолжает расти. Но все-таки, DevOps и SRE – это разные вещи или синонимы для одного и того же? Данная статья поможет во всем разобраться.
Что такое DevOps?
DevOps – это подход к разработке ПО. Ключевое отличие данной методологии заключается в том, что DevOps следует принципам Lean (бережливое производство) или Agile (гибкость). DevOps специализируется на постоянном развертывании ПО с частым выходом версий и автоматизированным подходом к разработке программ. DevOps-подход включает в себя набор норм и технологических приемов для быстрого выполнения запланированной работы. Под запланированной работой мы подразумеваем все – от разработки до тестирования и эксплуатации. DevOps преследует следующие цели:
ускорение доставки продуктов на рынок;
сокращение жизненного цикла разработки ПО;
повышение отзывчивости к потребностям рынка.
Так что же такое DevOps? DevOps – это объединение отделов разработки и эксплуатации для максимально быстрого и органичного развертывания кода. Данный подход основан на тесной коммуникации внутри команды в сочетании с высоким уровнем автоматизации. По правилам DevOps команда, пишущая код, отвечает также и за его обслуживание при эксплуатации. Иначе говоря, отделы разработки и эксплуатации, которые принято разделять, должны работать сообща над улучшением версий ПО.
В чем преимущества DevOps?
Во-первых, DevOps улучшает скорость доставки приложений. Это реализуется за счет создания небольших изменений и частого выхода новых версий. Таким образом, компании могут выводить продукты на рынок чаще. Обновления и исправления выполняются быстрее и проще, а стабильность ПО возрастает. Более того, вносить небольшие изменения гораздо проще, и такую систему легко вернуть к предыдущей версии. Еще один плюс: возможности доставки ПО у таких объединенных команд более безопасные.
Что делает DevOps и как?
DevOps – это отличный способ для создания культуры сотрудничества. Центральное место занимает команда, которая вместе работает над развертыванием кода в промышленную среду и его дальнейшим обслуживанием. То есть команда DevOps отвечает за написание кода, исправление ошибок и выполняет любые задачи, связанные с этим кодом. Процесс DevOps основан на 5 ключевых принципах:
Устранение обособленности. Роль команды DevOps заключается в том, чтобы аккумулировать знания со стороны разработки и эксплуатации. Поощряется коммуникация, что помогает лучше разобраться в ситуации.
Быстрое признание ошибок и прекращение. В процессе DevOps определяются методы минимизации риска, а одни и те же ошибки не делаются дважды. С помощью автоматизированного тестирования команда ищет ошибки на ранних стадиях цикла выхода ПО.
Постепенное внесение изменений. Команда DevOps не внедряет крупные изменения в рабочие версии, а регулярно развертывает небольшие поэтапные доработки. Это позволяет лучше проверять изменения и устранять ошибки.
Использование инструментов и автоматизации. Команда создает конвейер развертывания с помощью инструментов автоматизации. Тем самым повышается скорость и точность разработки, а также сводится к минимуму риск ошибок, допущенных человеком. Кроме того, сокращается объем ручной работы.
Измерение всего. DevOps использует данные для измерения результата всех предпринятых действий. Чаще всего для оценки успеха используются 4 главных метрики: время внесения изменений, частота развертывания, время восстановления и частота отказов.
Для эффективной работы команде DevOps необходимо использовать мощные инструменты. К ним относятся: системы управления версиями для всего кода (GitHub, GitLab и т.д.), инструменты непрерывной интеграции (Jenkins, Spinnaker и т.д.), инструменты автоматизации развертывания, инструменты автоматизации тестирования (Selenium и т.д.), а также инструменты управления инцидентами (PagerDuty, Opsgenie и т.д.)
Что такое SRE?
Концепция обеспечения надежности информационных систем (SRE - Site Reliability Engineering) появилась в 2003 году. Изначально она задумывалась как система для поддержки разработчиков, создающих крупномасштабные приложения. В наши дни SRE реализуется опытной командой экспертов, которая умеет применять методы проектирования при решении общих проблем, связанных с запуском систем в промышленную эксплуатацию. SRE – это как бы системный инженер, который отвечает еще и за эксплуатацию. Это сочетание работ по системным операциям с разработкой и проектированием ПО. В зоне ответственности таких сотрудников находится множество задач – от написания и создания кода до его доставки и поддержки в промышленной среде.
Главная цель SRE – разработка сверхнадежных и быстро масштабируемых систем. Раньше проектировщиков ПО и сотрудников эксплуатационного отдела разделяли на 2 отдела с разными зонами ответственности. Такие отделы подходили к решению проблем с разных сторон. SRE выходит за рамки этого ограничения. Принцип сотрудничества, лежащий в основе этой методологии, пришелся по душе многим компаниям.
В чем преимущества SRE?
SRE значительно улучшает период работоспособности. Основной приоритет – поддержание платформы или сервиса в рабочем состоянии, несмотря ни на что. Задачами первостепенной важности являются: предотвращение аварий, минимизация рисков, надежность и запас мощности. Главная цель команды SRE – найти способы по предотвращению проблем, которые могли бы привести к простою. Это критически важно, особенно при сопровождении крупномасштабных систем. Еще одно преимущество SRE заключается в том, что данный подход помогает компаниям отойти от ручной работы в пользу автоматизации. Тем самым у разработчиков высвобождается больше времени на инновационные решения. Любые ошибки быстро и эффективно находятся и устраняются.
Что делает SRE и как
Роль SRE в компании предельно проста и понятна: команда следит за тем, чтобы платформа или сервис были доступны клиентам в любой момент и в любых обстоятельствах.
Чем занимается SRE?
SRE устраняет разобщенность команд немного иначе, чем DevOps. Она помогает разработчикам создавать более надежные системы, поскольку эти сотрудники занимаются не только разработкой, но и эксплуатацией программ. Следовательно, разработчики лучше понимают свои продукты и могут качественнее поддерживать системы в промышленной эксплуатации.
Для улучшения системы SRE использует определенные метрики. Такая оценка надежности систем является решающим фактором, определяющим, попадет ли то или иное изменение в рабочую версию. Ключевые метрики SRE: SLO (цели уровня обслуживания), SLA (соглашение об уровне обслуживания) и SLI (количественная оценка работы сервиса).
SRE решает вопросы, связанные с эскалацией запросов в поддержку. Кроме того, эта система всячески побуждает людей выявлять и сообщать об инцидентах.
Команда SRE определяет и проверяет новый функционал с обновлениями, а также разрабатывает документацию по системе.
В своей работе команда SRE пользуется такими системами, как Kubernetes (один из самых известных оркестраторов контейнеров), облачными платформами (Microsoft Azure, Amazon AWS и т.д.), инструментами планирования и управления проектами (JIRA, Pivotal Tracker), а также системами контроля версий (GitHub и т.д.).
Чем отличаются SRE и DevOps?
Если говорить абстрактно, что DevOps – это написание и развертывание кода, а SRE – это комплексный подход ко всему, поскольку при работе над системой команда примеряет на себя роль конечного пользователя.
При работе над продуктом или приложение команда DevOps использует гибкий подход. Они быстро и качественно создают, тестируют и развертывают приложения. Команда SRE регулярно делится с командой разработчиков обратной связью. Их цель – эффективно использовать данные по эксплуатации и проектированию ПО (в основном, за счет автоматизации операционных задач) и, тем самым, ускорить доставку приложения. В то же время задача команды DevOps – сделать рабочие процессы более эффективными и автоматизированными.
Цель SRE – создать слаженные операционные процессы с помощью методологий, которыми раньше пользовались только разработчики ПО. Основная задача SRE – сделать так, чтобы платформа или приложение были постоянно доступны клиентам. Для этого оцениваются потребности клиентов и анализируются метрики SLA, SLI и SLO. DevOps делает акцент на процессе в целом, и результатом должно стать успешное развертывание ПО. Ниже описаны дополнительные отличия между DevOps и SRE.
Роль команды разработчиков
DevOps объединяет навыки разработчиков и инженеров по эксплуатации ПО. SRE решает проблемы IT-операций с помощью инструментов и парадигмы разработчиков.
Навыки
Команда DevOps работает преимущественно с кодом. Они пишут код, тестируют его и выпускают в промышленную версию. Итогом их работы должна стать программа, которая поможет решить чью-то проблему. Кроме того, они настраивают и запускают сборочный конвейер. SRE-подход немного шире. Команда анализирует, почему что-то пошло не так. Они делают все, чтобы та или иная проблема не повторилась.
Что общего в SRE и DevOps?
Мы разобрали отличия между DevOps и SRE, но есть ли в них что-то общее? По правде говоря, SRE и DevOps между ними много общего, ведь оба подхода – это методологии, которые применяются для анализа промышленных версий и обеспечения того, чтобы управление эксплуатациями работало как нужно. Их общая цель – получить качественный результат для сложных распределенных систем. Оба направления делают акцент на людях, которые работают как единая команда с общей зоной ответственности. DevOps и SRE верят в то, что поддерживать все в рабочем состоянии – это задача каждого. Вовлеченность в процесс должна быть общей – от написания первоначального кода до сборки приложения, развертывания в промышленную версию и обслуживания. Проектировщики DevOps и SRE пишут и оптимизируют код до того, как развертывать его в рабочей среде.
Подводя итог, можно сказать, что для достижения общей цели нужно сочетать DevOps и SRE.
Настройка EIGRP сильно напоминает RIP и состоит из двух шагов:
включения протокола глобальной командой router eigrp ASN_NUMBER;
выбора сетей, которые протокол будет «вещать», для чего используется команда(ы) network;
Первая команда включения говорит сама за себя, но поясним про ASN_NUMBER – это номер автономной системы, и для установления сетевой связности между несколькими маршрутизаторами, использующими EIGRP, данный номер должен быть одинаковым. Вторая команда работает также, как и в RIP по умолчанию – то есть включение протокола на интерфейсе и указание классовых сетей.
Пример настройки EIGRP
В нашей топологии у маршрутизаторов R1 и R2 есть напрямую подключенные подсети.
Нам нужно включить данные подсети в процесс динамической маршрутизации EIGRP. Для этого нам сначала нужно включить EIGRP на обоих маршрутизаторах и затем «вещать» данные сети с помощью команды network. На маршрутизаторе R1 переходим в глобальный режим конфигурации и вводим следующие команды:
router eigrp 1
network 10.0.0.0
network 172.16.0.0
Немного пояснений – сначала мы включаем протокол динамической маршрутизации, затем меняем версию на вторую, затем используем команду network 10.0.0.0 для включения интерфейса Fa0/1 на маршрутизаторе R1. Как мы уже говорили, команда network берет классовую сеть, так что каждый интерфейс с подсетью, начинающейся на 10 будет добавлен в EIGRP процесс. Также нам необходимо получить маршрут между двумя роутерами через EIGRP, для этого добавляем еще одну команду network – с адресом 172.16.0.0.
IP-адреса начинающиеся на 10, по умолчанию принадлежат к классу «А» и и имеют стандартную маску подсети 255.0.0.0.
На R2 настройка выглядит похожей, только с другой подсетью – т.к к маршрутизатору R2 напрямую подключена подсеть 192.168.0.0.
router eigrp 1
network 192.168.0.0
network 172.16.0.0
Вот и все – также просто, как и настроить RIP: главное не забывать указывать одинаковый номер автономной системы. Для проверки работоспособности EIGRP введите команду show ip eigrp neighbors на обоих маршрутизаторах и убедитесь, что там указан адрес другого маршрутизатора. Данная команда показывает список всех EIGRP «соседей», с разнообразной информацией – номером локального интерфейса и т.д Также проверить сетевую связность можно с помощью команды вывода таблицы маршрутизации sh ip route. Маршруты, получаемые по EIGRP будут отмечены буквой «D».
Пример настройки EIGRP 2
Как мы уже говорили, по умолчанию команда network использует классовую сеть, т.е все интерфейсы внутри это классовой сети будут участвовать в процессе маршрутизации. Для включения EIGRP только на нужном вам интерфейсе, необходимо использование обратной маски. То есть команда будет выглядеть следующим образом: network ОБРАТНАЯ_МАСКА
В нашем примере у маршрутизатора R1 есть две напрямую подключенные подсети, 10.0.0.0/24 и 10.0.1.0/24. Наша цель – включить EIGRP только на подсети, подключенной к интерфейсу Fa0/0. Если просто использовать команду network – обе подсети будут добавлены в EIGRP процесс, т.к будет использоваться классовая сеть. Для настройки EIGRP только на интерфейсе Fa0/0, нужно использовать команду network 10.0.0.0 0.0.0.255. Она включит EIGRP только на интерфейсах 10.0.0.Х.
Проверить можно с помощью команды sh ip protocols, что только сеть 10.0.0.0/24 добавлена в EIGRP процесс.
По умолчанию, в дистрибутиве FreePBX Distro большинство лог – файлов Asterisk сконфигурированы на хранение в течение семи дней. Зачастую, пользователи жалуются на технические проблемы (недозвон, короткие гудки, обрыв и так далее) спустя недели, а порой и месяцы. Именно по этой причине, в статье расскажем как настроить хранение лог – файлов на более длительное время и как добавить сжатие для них, чтобы сохранить место на жестких дисках.
Настройка
За длительность хранения отвечает файл /etc/logrotate.d/asterisk. Давайте откроем его редактором vim и увеличим время хранения по нужным файла до 45 дней:
[root@asterisk ~]# vim /etc/logrotate.d/asterisk
И для файла /var/log/asterisk/freepbx_dbug меняем параметр rotate с 7 на 45:
/var/log/asterisk/freepbx_dbug{
daily
missingok
rotate 45 //меняем данное значение для увеличения времени хранения в днях;
notifempty
compress //добавляем параметр compress, для активации сжатия;
sharedscripts
create 0640 asterisk asterisk
}
Важно!: С увеличением времени хранения файлов, увеличивается и его объем, занимаемый на жестких дисках сервера. При добавлении параметра compress в конфигурационную секцию, файл будет сжиматься c помощью утилиты компрессии gzip
Как можно увидеть в нашем примере, для лог – файла /var/log/asterisk/freepbx_dbug выставлен параметр daily (ежедневно), который регламентирует значение параметра rotate. Это означает, что значение 45 будет интерпретировано днями. Если вы хотите указывать значение параметра rotate в месяцах, то укажите здесь вместо daily monthly (ежемесячно).
По завершению настроек сохраните их нажатием :x! + Enter - изменения вступят в силу.