Всем привет, хочу начать вести доступный канал по знаниям и практикам о SRE подходах
Почему, я решился на такой формат на фоне изообилия чатиков? Потому-что сейчас становится все больше и больше курсов для точо чтобы стать "DevOps - инженером" 😔 и SRE
Но на курсах учат в основном только про то, как пользоваться тем или иным инструментом, но не о подходах и практиках
Главное не то, как пользоваться к примеру Helm или Ansible, а главное понимать где и как применить тот или иной инструмент и как это сделать правильнее
Ведь главный фокус SRE специалиста, это Production а именно продукт, его стабильность, отказоустойчивость, доступность и улучшения как с инфраструктурной стороны так и с архитектуры решения
Буду вещать и делиться подходами, историями и кейсами решения)
Почему, я решился на такой формат на фоне изообилия чатиков? Потому-что сейчас становится все больше и больше курсов для точо чтобы стать "DevOps - инженером" 😔 и SRE
Но на курсах учат в основном только про то, как пользоваться тем или иным инструментом, но не о подходах и практиках
Главное не то, как пользоваться к примеру Helm или Ansible, а главное понимать где и как применить тот или иной инструмент и как это сделать правильнее
Ведь главный фокус SRE специалиста, это Production а именно продукт, его стабильность, отказоустойчивость, доступность и улучшения как с инфраструктурной стороны так и с архитектуры решения
Буду вещать и делиться подходами, историями и кейсами решения)
Современные собеседования в больших IT компаниях которые хотят себе "SRE"
Хотел рассказать историю о том, как компании делают ошибки или набирают совсем не тех кто им нужны. К примеру вы откликаетесь на вакансию в которой указано что хотят SRE инженера, вы откликаетесь и потом начинается самое веселое ) Этапы! от 3 до 5 этапов бывает
Так вот поговорим об одном из технических этапов где вы как SRE инженер сталкиваетесь с вопросами, которые были бы разумны для системного администратора или для SysOps инженера 🤷
Примерами таких вопросов могут быть:
- Как устроенно ядро Linux системы
- Вопросы по железу
- Низкоуровневые вопросы работы системы
Безусловно SRE должен знать базу, она нужна при траблшутинге на инцидентах
Но почему-то вас никто не спросит про код ревью, про мониторинг приложений (не системные метрики), про архитектруру
И вот происходит то, что компания после такого собеседования нанимает такого вот матерого системного администратора, который будет ковыряться в консоли при инцидентах, а проблема будет в методе вызова в приложении
Поэтому SRE должен обдладать знаниями разработки, есть даже мнение что сильные SRE те кто пришел из разработки.
И вопросы на собеседованиях должны быть с точки зрения сопровождения продукта на Production, метрики, требования, доступность.
А что вы думаете по этому?
Хотел рассказать историю о том, как компании делают ошибки или набирают совсем не тех кто им нужны. К примеру вы откликаетесь на вакансию в которой указано что хотят SRE инженера, вы откликаетесь и потом начинается самое веселое ) Этапы! от 3 до 5 этапов бывает
Так вот поговорим об одном из технических этапов где вы как SRE инженер сталкиваетесь с вопросами, которые были бы разумны для системного администратора или для SysOps инженера 🤷
Примерами таких вопросов могут быть:
- Как устроенно ядро Linux системы
- Вопросы по железу
- Низкоуровневые вопросы работы системы
Безусловно SRE должен знать базу, она нужна при траблшутинге на инцидентах
Но почему-то вас никто не спросит про код ревью, про мониторинг приложений (не системные метрики), про архитектруру
И вот происходит то, что компания после такого собеседования нанимает такого вот матерого системного администратора, который будет ковыряться в консоли при инцидентах, а проблема будет в методе вызова в приложении
Поэтому SRE должен обдладать знаниями разработки, есть даже мнение что сильные SRE те кто пришел из разработки.
И вопросы на собеседованиях должны быть с точки зрения сопровождения продукта на Production, метрики, требования, доступность.
А что вы думаете по этому?
❓SRE - что вообще оно значит
И так кто такой SRE инженер? Это специалист по надёжности, но в чем проявляется эта его надежность?
И это уже второй вопрос сходу, так и в компаниях.
Сейчас SRE есть в каждой компании и в каждом ларьке (условно) и требования к нему весьма разные, от матерого админа, до скилового разработчика, вот тут и кроется современная проблема. 😔
Почему-то многие считают что SRE - это в первую очередь о инфраструктуре, а потом о приложениях. Хотя на самом деле, давайте откровенно, в нынешних реалиях когда развиты PaaS и SaaS, о инфраструктуре уже не приходится думать как, лет так 10 назад, и можно полностью сфокусироваться на архитектуре сервисов и работе сервисов. Так вот тут как раз и наступает зона SRE, который строит совместно с системным архитектором решение, фокусируется на том как будет мониторится все это и как он будет узнавать о деградациях до момента инцидента, как сделать сервис отказоустойчивым и высокодоступным, даже участвовать в ревью кода, чтобы не допустить моментов которые потенциально могут привести к инциденту. Вот тут и есть SRE
А когда многие компании просят SRE админить кластер кубера, кластера БД, заниматься развертыванием ОС и так далее, то поверьте на стабильность продакшена ему просто не хватит сил, точнее сам сервис не будет надежным, но инфраструктура - да, вот только клиентам пофигу какая инфра, когда нельзя получить свои функции))
Безусловно SRE это очень яркая модель T-shaped специалиста, я бы даже сказал X/V-shaped и это ему нужно при траблшутинге, а для администрирования компаниям стоит выделить SysOps инженеров, а то осталось только в вакансиях добавить пункт смены картриджей в принтере))
#sre
И так кто такой SRE инженер? Это специалист по надёжности, но в чем проявляется эта его надежность?
И это уже второй вопрос сходу, так и в компаниях.
Сейчас SRE есть в каждой компании и в каждом ларьке (условно) и требования к нему весьма разные, от матерого админа, до скилового разработчика, вот тут и кроется современная проблема. 😔
Почему-то многие считают что SRE - это в первую очередь о инфраструктуре, а потом о приложениях. Хотя на самом деле, давайте откровенно, в нынешних реалиях когда развиты PaaS и SaaS, о инфраструктуре уже не приходится думать как, лет так 10 назад, и можно полностью сфокусироваться на архитектуре сервисов и работе сервисов. Так вот тут как раз и наступает зона SRE, который строит совместно с системным архитектором решение, фокусируется на том как будет мониторится все это и как он будет узнавать о деградациях до момента инцидента, как сделать сервис отказоустойчивым и высокодоступным, даже участвовать в ревью кода, чтобы не допустить моментов которые потенциально могут привести к инциденту. Вот тут и есть SRE
А когда многие компании просят SRE админить кластер кубера, кластера БД, заниматься развертыванием ОС и так далее, то поверьте на стабильность продакшена ему просто не хватит сил, точнее сам сервис не будет надежным, но инфраструктура - да, вот только клиентам пофигу какая инфра, когда нельзя получить свои функции))
Безусловно SRE это очень яркая модель T-shaped специалиста, я бы даже сказал X/V-shaped и это ему нужно при траблшутинге, а для администрирования компаниям стоит выделить SysOps инженеров, а то осталось только в вакансиях добавить пункт смены картриджей в принтере))
#sre
От хаоса к порядку
Всем привет, после долгих праздников было сложно вернуться в колею продуктивности.
Но вот вливание произошло (вливание литров кофе) и настало время нового поста)
DevOps, SRE кто как хочет так и называет, но как привести в порядок эти методологии и получить реальную пользу от этого?
Давайте начнем с того что, в компании есть те и те, но у команд нет представления и понимания почему сегодня инженеров называют DevOps, а завтра SRE - что происходит?
И занимаются инженеры всем подряд от доступов на сервер, сборок , релиза на прод и до решения инцидентов.
Попробуем разобраться?
Надо четко определить ответственность и границы команд Ops сопровождения и как это мне видется
Команда Ops инженеров -
Это Ops инженеры которые сопровождают разработчиков на стадии разработки, а именно готовят репозитории, сборки (пайплайны), настраивают хранение и версионирование артефактов и их разворачивающие на стенды. Также подсказывают что не так на этапах сборок и тестов
Команда Deploy -
Эта команда катит релизы, согласно инструкциям от команды Ops инженеров и помогает командам на Stage стендах, то есть команды сфокусированы на деплоях
Команда SRE -
Эта команда которая сфокусирована только на продакшене, они настраивают политики и требования мониторинга, логирования, участвуют в архитектуре и дизайне решения, настраивают политики Quality Gates, требования к безопасности приложения, требования к инфраструктуре и как это влияет на SLA, решают инциденты, также участвуют в самой разработке и сами пишут код
То есть SRE инженер делают все так чтобы клиент-потребитель не страдал)))
Вот именно поэтому лучшие SRE инженеры это программисты) так как только знаний администрирования тут мало)
P.S. Обычно SRE инженеры больше всех прокачивают свой тишейпинг
А вы как считаете?
Всем привет, после долгих праздников было сложно вернуться в колею продуктивности.
Но вот вливание произошло (вливание литров кофе) и настало время нового поста)
DevOps, SRE кто как хочет так и называет, но как привести в порядок эти методологии и получить реальную пользу от этого?
Давайте начнем с того что, в компании есть те и те, но у команд нет представления и понимания почему сегодня инженеров называют DevOps, а завтра SRE - что происходит?
И занимаются инженеры всем подряд от доступов на сервер, сборок , релиза на прод и до решения инцидентов.
Попробуем разобраться?
Надо четко определить ответственность и границы команд Ops сопровождения и как это мне видется
Команда Ops инженеров -
Это Ops инженеры которые сопровождают разработчиков на стадии разработки, а именно готовят репозитории, сборки (пайплайны), настраивают хранение и версионирование артефактов и их разворачивающие на стенды. Также подсказывают что не так на этапах сборок и тестов
Команда Deploy -
Эта команда катит релизы, согласно инструкциям от команды Ops инженеров и помогает командам на Stage стендах, то есть команды сфокусированы на деплоях
Команда SRE -
Эта команда которая сфокусирована только на продакшене, они настраивают политики и требования мониторинга, логирования, участвуют в архитектуре и дизайне решения, настраивают политики Quality Gates, требования к безопасности приложения, требования к инфраструктуре и как это влияет на SLA, решают инциденты, также участвуют в самой разработке и сами пишут код
То есть SRE инженер делают все так чтобы клиент-потребитель не страдал)))
Вот именно поэтому лучшие SRE инженеры это программисты) так как только знаний администрирования тут мало)
P.S. Обычно SRE инженеры больше всех прокачивают свой тишейпинг
А вы как считаете?
Всем привет у кого-то сегодня могли сломаться пайплайны для Docker, а все потому-что https://hub.docker.com теперь не доступен из России. Вот такой вот он свободный мир)))
Есть несколько вариантов сейчас, это настроить в конфиге Docker дополнительные зеркала. Так что настраивайте заранее сегодня, всем удачи)
sudo nano /etc/docker/daemon.json
P.S. Есть еще более забавный проект https://huecker.io/
UPD: Добавил AWS, Yandex
Есть несколько вариантов сейчас, это настроить в конфиге Docker дополнительные зеркала. Так что настраивайте заранее сегодня, всем удачи)
sudo nano /etc/docker/daemon.json
{
"registry-mirrors": [
"https://mirror.gcr.io",
"https://daocloud.io",
"https://c.163.com/",
"https://registry.docker-cn.com",
"https://gallery.ecr.aws",
"https://mirror.yandex.ru/mirrors/docker/"
]
}
P.S. Есть еще более забавный проект https://huecker.io/
UPD: Добавил AWS, Yandex
Всем пятничного настроения 🙏
Хотел сегодня поговорить о AI и его вреде и пользе при работе в IT.
Тема конечно холливарная но все же)
Так как сегодня из каждого уголка говорят про проект от OpenAI то, и поговорим о нем.
Что такое Chat GPT объяснять не надо, по крайней мере тем кто читает этот пост.
Это генеративная модель основанная на принципах работы нейроных сетей, что схоже с работой нашего головного мозга. По факту это поисковая система, с весами которая на основе этого может дать ответ который, в большинстве попадет в список правильных. Также он помогает с кодогенерацией, хотя она еще была и до самого ChatGPT, вот о ней то и поговорим в целом.
Многие не изучая определенного языка и технологии, сразу при возникновении задач бегут к ChatGPT с промтом типа
- создай мне парсер на Java
И получают какой-то снипет, начинают потом пытаться его запустить и дальше с помощью промтов на подобии - "'это не работает, исправь" тратят свое время, без понимания того, что они делают.
Итог, мы получаем не особого опытного и развитого специалиста, но специалиста по промтам)))
На аргумент, почему ты не хочешь изучить и попробовать написать нормально сам, я получал ответ - "зачем мне тратить на это время, ChatGPT сдеает за меня", ну тогда мне легче держать в штате подписку, которая дешевле чем этот инженер)))
Но не все так плохо, не так давно я для себя открыл проект Supermaven для VSC и вот тут я получил буст и всю прелесть от AI и его кодогенерации
А именно, это тот момент когда ты пишешь код и знаешь что делаешь, а при этом плагин сканирует весь проект и на основе твоего проекта помогает писать, генерируя классы и методы с условиями твоего проекта, и аннотаци, и операторы, и переменные.
Я правда получил большой кайф работая с этим подходом)
Так вот, вся боль нашего современного IT, в инструментах, порог вхождения для PET проектов снижается и это здорово, но в Продакшене и больших Энтерпрайзах наступает боль с такими вот инженерами которые умеют писать только промты, но не умеют писать и читать код)
Всем добра и позитива
Хотел сегодня поговорить о AI и его вреде и пользе при работе в IT.
Тема конечно холливарная но все же)
Так как сегодня из каждого уголка говорят про проект от OpenAI то, и поговорим о нем.
Что такое Chat GPT объяснять не надо, по крайней мере тем кто читает этот пост.
Это генеративная модель основанная на принципах работы нейроных сетей, что схоже с работой нашего головного мозга. По факту это поисковая система, с весами которая на основе этого может дать ответ который, в большинстве попадет в список правильных. Также он помогает с кодогенерацией, хотя она еще была и до самого ChatGPT, вот о ней то и поговорим в целом.
Многие не изучая определенного языка и технологии, сразу при возникновении задач бегут к ChatGPT с промтом типа
- создай мне парсер на Java
И получают какой-то снипет, начинают потом пытаться его запустить и дальше с помощью промтов на подобии - "'это не работает, исправь" тратят свое время, без понимания того, что они делают.
Итог, мы получаем не особого опытного и развитого специалиста, но специалиста по промтам)))
На аргумент, почему ты не хочешь изучить и попробовать написать нормально сам, я получал ответ - "зачем мне тратить на это время, ChatGPT сдеает за меня", ну тогда мне легче держать в штате подписку, которая дешевле чем этот инженер)))
Но не все так плохо, не так давно я для себя открыл проект Supermaven для VSC и вот тут я получил буст и всю прелесть от AI и его кодогенерации
А именно, это тот момент когда ты пишешь код и знаешь что делаешь, а при этом плагин сканирует весь проект и на основе твоего проекта помогает писать, генерируя классы и методы с условиями твоего проекта, и аннотаци, и операторы, и переменные.
Я правда получил большой кайф работая с этим подходом)
Так вот, вся боль нашего современного IT, в инструментах, порог вхождения для PET проектов снижается и это здорово, но в Продакшене и больших Энтерпрайзах наступает боль с такими вот инженерами которые умеют писать только промты, но не умеют писать и читать код)
Всем добра и позитива
Давайте сегодня про бюджет ошибок))
часть 1:
Бюджет ошибок в SRE - это концепция, позволяющая оценить допустимое время, когда сервис может работать ниже ожидаемых стандартов качества. Это помогает инженерам SRE сосредоточиться на более серьезных проблемах, игнорируя незначительные инциденты, которые могут возникать регулярно. Например, если инцидент исчерпал 30% бюджета ошибок, он считается серьезным и требует немедленного внимания. Это позволяет SRE-инженерам эффективно распределять ресурсы и время, минимизируя влияние незначительных проблем на работу сервиса.
Чтобы посчитать бюджет ошибок, можно использовать два основных метода:
1. По времени:
оценивается, сколько времени сервис доступен или недоступен. Например, если error budget содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже был недоступен, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски.
2.Per request:
подходит для контроля надежности именно внутри сервисов. Каждый запрос отмечается, как успешный или неуспешный. Соблюдено SLO или нет, уложился ли сервис в те критерии, которые в него вложили? Если сервис не отвечает, значит он не соблюдает свои SLO, следовательно, запрос считается ошибочным. В этом случае одинаково выглядит, отвечает сервис слишком долго либо отвечает ошибкой. После рассчитывается соотношение «хороших» и «плохих» запросов.
Эти методы помогают понять, насколько надежен сервис и как эффективно использовать бюджет ошибок для улучшения его работы.
часть 1:
Бюджет ошибок в SRE - это концепция, позволяющая оценить допустимое время, когда сервис может работать ниже ожидаемых стандартов качества. Это помогает инженерам SRE сосредоточиться на более серьезных проблемах, игнорируя незначительные инциденты, которые могут возникать регулярно. Например, если инцидент исчерпал 30% бюджета ошибок, он считается серьезным и требует немедленного внимания. Это позволяет SRE-инженерам эффективно распределять ресурсы и время, минимизируя влияние незначительных проблем на работу сервиса.
Чтобы посчитать бюджет ошибок, можно использовать два основных метода:
1. По времени:
оценивается, сколько времени сервис доступен или недоступен. Например, если error budget содержит 43 минуты даунтайма в месяц, и 40 минут из них сервис уже был недоступен, то очевидно: чтобы оставаться в рамках SLO, надо сократить риски.
2.Per request:
подходит для контроля надежности именно внутри сервисов. Каждый запрос отмечается, как успешный или неуспешный. Соблюдено SLO или нет, уложился ли сервис в те критерии, которые в него вложили? Если сервис не отвечает, значит он не соблюдает свои SLO, следовательно, запрос считается ошибочным. В этом случае одинаково выглядит, отвечает сервис слишком долго либо отвечает ошибкой. После рассчитывается соотношение «хороших» и «плохих» запросов.
Эти методы помогают понять, насколько надежен сервис и как эффективно использовать бюджет ошибок для улучшения его работы.
Часть 2:
Но это все хорошо, а как донести это бизнесу?
Чтобы донести бизнесу значимость подсчета бюджета ошибок, надо начать с объяснения, что это не просто цифры, а инструмент для повышения эффективности и снижения рисков. Подчеркнув, что бюджет ошибок позволяет:
1. Минимизировать потери от инцидентов: Показывая, сколько денег можно сэкономить, избегая серьезных сбоев, вы демонстрируете практическую пользу бюджета ошибок.
2. Оптимизировать ресурсы: Инвестируя в улучшение надежности, вы экономите на устранении последствий сбоев, сокращая тем самым общие затраты.
3. Повысить удовлетворенность клиентов: Предотвращение сбоев улучшает качество обслуживания, что ведет к увеличению лояльности клиентов.
4. Стимулировать инновации: Позволяя команде разработчиков экспериментировать, не опасаясь серьезных последствий, бюджет ошибок способствует внедрению новых функций и улучшению продукта.
Можно привести конкретные примеры из практик других компаний, чтобы показать, как подсчет бюджета ошибок помог им улучшить бизнес-процессы и повысить доходы.
А вы считаете бюджет ошибок, помогает ли вам эта практика?
Но это все хорошо, а как донести это бизнесу?
Чтобы донести бизнесу значимость подсчета бюджета ошибок, надо начать с объяснения, что это не просто цифры, а инструмент для повышения эффективности и снижения рисков. Подчеркнув, что бюджет ошибок позволяет:
1. Минимизировать потери от инцидентов: Показывая, сколько денег можно сэкономить, избегая серьезных сбоев, вы демонстрируете практическую пользу бюджета ошибок.
2. Оптимизировать ресурсы: Инвестируя в улучшение надежности, вы экономите на устранении последствий сбоев, сокращая тем самым общие затраты.
3. Повысить удовлетворенность клиентов: Предотвращение сбоев улучшает качество обслуживания, что ведет к увеличению лояльности клиентов.
4. Стимулировать инновации: Позволяя команде разработчиков экспериментировать, не опасаясь серьезных последствий, бюджет ошибок способствует внедрению новых функций и улучшению продукта.
Можно привести конкретные примеры из практик других компаний, чтобы показать, как подсчет бюджета ошибок помог им улучшить бизнес-процессы и повысить доходы.
А вы считаете бюджет ошибок, помогает ли вам эта практика?
А какие инструменты вы используете при подсчете бюджета ошибок?
Anonymous Poll
63%
Prometheus
63%
Grafana
38%
Zabbix
25%
ELK (Open search)
0%
Splunk
13%
GrayLog
13%
OpenTelemetry
13%
Самописные решения
25%
У нас ничего нет
Рубрика: #СамыйПопулярныйВопрос
Должен ли SRE инженер уметь писать код?
Да, SRE-инженер должен уметь писать код. Это ключевой навык, который отличает его от классического системного администратора. SRE-инженер пишет код не только для реализации бизнес-логики, но и для повышения стабильности и производительности системы. Умение программировать помогает ему самостоятельно находить и исправлять ошибки в коде, а также разрабатывать утилиты для мониторинга и управления системой.
Должен ли SRE инженер уметь писать код?
Да, SRE-инженер должен уметь писать код. Это ключевой навык, который отличает его от классического системного администратора. SRE-инженер пишет код не только для реализации бизнес-логики, но и для повышения стабильности и производительности системы. Умение программировать помогает ему самостоятельно находить и исправлять ошибки в коде, а также разрабатывать утилиты для мониторинга и управления системой.
А вы как SRE инженер, ипользуете практики программирования в своей работе?
Anonymous Poll
66%
Python📱
40%
Go
8%
Java
6%
.NET
10%
Я не считаю что SRE инженер должет уметь писать код 🤔
6%
Другой язык, напишу в комментариях
Сегодня хочу про мониторинг, поехали
Мониторинг приложений играет важную роль в обеспечении их надежности, доступности и производительности. Вот несколько ключевых причин, почему мониторинг важен:
1. Обеспечение высокой доступности: Мониторинг позволяет обнаруживать проблемы с производительностью или другие проблемы сразу после их возникновения. Это сокращает время обнаружения проблем (TTD) и время устранения неполадок (TTM), что важно для минимизации простоев и обеспечения непрерывной работы приложений.
2. Улучшение качества обслуживания: Мониторинг помогает собирать данные о шаблонах использования приложения, что позволяет оптимизировать его работу и улучшить качество обслуживания пользователей.
3. Управление рисками: Мониторинг предоставляет данные, которые позволяют идентифицировать потенциальные риски и уязвимости в приложении. Это позволяет командам DevOps принимать меры для предотвращения или минимизации рисков.
4. Оптимизация производительности: Мониторинг позволяет отслеживать ключевые метрики производительности приложения, такие как время отклика, загрузка процессора и использование памяти. Это помогает выявлять узкие места и оптимизировать производительность приложения.
5. Тестирование и разработка: Мониторинг может использоваться для проведения искусственного и реального мониторинга пользователей (RUM), что позволяет тестировать новые версии приложений в реальных условиях эксплуатации и получать обратную связь от пользователей.
6. Обучение и улучшение: Мониторинг позволяет отслеживать использование приложения и сравнивать разные версии, что помогает командам делать обоснованные решения о внесении изменений в приложение и улучшать его на основе полученных данных.
Мониторинг приложений играет важную роль в обеспечении их надежности, доступности и производительности. Вот несколько ключевых причин, почему мониторинг важен:
1. Обеспечение высокой доступности: Мониторинг позволяет обнаруживать проблемы с производительностью или другие проблемы сразу после их возникновения. Это сокращает время обнаружения проблем (TTD) и время устранения неполадок (TTM), что важно для минимизации простоев и обеспечения непрерывной работы приложений.
2. Улучшение качества обслуживания: Мониторинг помогает собирать данные о шаблонах использования приложения, что позволяет оптимизировать его работу и улучшить качество обслуживания пользователей.
3. Управление рисками: Мониторинг предоставляет данные, которые позволяют идентифицировать потенциальные риски и уязвимости в приложении. Это позволяет командам DevOps принимать меры для предотвращения или минимизации рисков.
4. Оптимизация производительности: Мониторинг позволяет отслеживать ключевые метрики производительности приложения, такие как время отклика, загрузка процессора и использование памяти. Это помогает выявлять узкие места и оптимизировать производительность приложения.
5. Тестирование и разработка: Мониторинг может использоваться для проведения искусственного и реального мониторинга пользователей (RUM), что позволяет тестировать новые версии приложений в реальных условиях эксплуатации и получать обратную связь от пользователей.
6. Обучение и улучшение: Мониторинг позволяет отслеживать использование приложения и сравнивать разные версии, что помогает командам делать обоснованные решения о внесении изменений в приложение и улучшать его на основе полученных данных.
К неэффективности мониторинга приложений могут привести следующие факторы:
1. Отсутствие четких целей и KPI: Если цели мониторинга не определены или не связаны с конкретными бизнес-целями, то эффективность мониторинга снижается.
2. Недостаточное внимание к настройке: Настройка параметров мониторинга под конкретные потребности приложения может существенно повысить его эффективность.
3. Отсутствие интеграции с системами управления: Интеграция мониторинга с системами управления конфигурациями и изменениями (например, с помощью CI/CD) позволяет быстрее реагировать на инциденты и предотвращать их повторение.
4. Нехватка ресурсов для анализа данных: Анализ собранных данных требует времени и ресурсов. Если эти ресурсы ограничены, эффективность мониторинга может снизиться.
5. Сопротивление изменениям: Сопротивление изменениям со стороны разработчиков и операционных команд может замедлить внедрение улучшений в систему мониторинга.
6. Отсутствие обучения: Недостаток знаний и навыков у персонала, ответственного за мониторинг, может привести к ошибкам в интерпретации данных и неправильным действиям.
7. Негибкость системы мониторинга: Жестко настроенные системы мониторинга могут не адаптироваться к изменяющимся требованиям и условиям эксплуатации приложений, что снижает их эффективность.
8. Отсутствие обратной связи: Без регулярной обратной связи от пользователей и команд разработки сложно понять, насколько эффективен текущий подход к мониторингу и как его можно улучшить.
9. Игнорирование оповещений: Если оповещения о проблемах игнорируются или не обрабатываются своевременно, это может привести к серьезным последствиям для доступности приложения.
10. Использование неподходящих инструментов: Выбор инструментов мониторинга, которые не соответствуют специфике приложения или не предоставляют необходимые данные, может затруднить обнаружение проблем.
1. Отсутствие четких целей и KPI: Если цели мониторинга не определены или не связаны с конкретными бизнес-целями, то эффективность мониторинга снижается.
2. Недостаточное внимание к настройке: Настройка параметров мониторинга под конкретные потребности приложения может существенно повысить его эффективность.
3. Отсутствие интеграции с системами управления: Интеграция мониторинга с системами управления конфигурациями и изменениями (например, с помощью CI/CD) позволяет быстрее реагировать на инциденты и предотвращать их повторение.
4. Нехватка ресурсов для анализа данных: Анализ собранных данных требует времени и ресурсов. Если эти ресурсы ограничены, эффективность мониторинга может снизиться.
5. Сопротивление изменениям: Сопротивление изменениям со стороны разработчиков и операционных команд может замедлить внедрение улучшений в систему мониторинга.
6. Отсутствие обучения: Недостаток знаний и навыков у персонала, ответственного за мониторинг, может привести к ошибкам в интерпретации данных и неправильным действиям.
7. Негибкость системы мониторинга: Жестко настроенные системы мониторинга могут не адаптироваться к изменяющимся требованиям и условиям эксплуатации приложений, что снижает их эффективность.
8. Отсутствие обратной связи: Без регулярной обратной связи от пользователей и команд разработки сложно понять, насколько эффективен текущий подход к мониторингу и как его можно улучшить.
9. Игнорирование оповещений: Если оповещения о проблемах игнорируются или не обрабатываются своевременно, это может привести к серьезным последствиям для доступности приложения.
10. Использование неподходящих инструментов: Выбор инструментов мониторинга, которые не соответствуют специфике приложения или не предоставляют необходимые данные, может затруднить обнаружение проблем.
#наблюдения
Вообще про пункт:
Игнорирование оповещений: Если оповещения о проблемах игнорируются или не обрабатываются своевременно, это может привести к серьезным последствиям для доступности приложения.
Наверное самое частое что губит в целом мониторинг, это когда нет градации по уровням алертов, а также частые False Positive оповещения
И в итоге если это чатик или канал, то его инженер и команда просто мьютит, а также в простыне такого мусора уже сложно понять что действительно важно.
В итоге это все приводит к тому что False Positive, в долгосрочной перспективе может спровоцировать серьезный инцидент или быть цепочко, или его признаком
Поэтому нужно проводить анализ мониторинга, алертов и в целом не страться кидать оповещения на каждое событие, только действительно на то что имеет значение.
Думаю что многие знают такое, как: - "Да просто засапресить нужно это и все"
Вообще про пункт:
Игнорирование оповещений: Если оповещения о проблемах игнорируются или не обрабатываются своевременно, это может привести к серьезным последствиям для доступности приложения.
Наверное самое частое что губит в целом мониторинг, это когда нет градации по уровням алертов, а также частые False Positive оповещения
И в итоге если это чатик или канал, то его инженер и команда просто мьютит, а также в простыне такого мусора уже сложно понять что действительно важно.
В итоге это все приводит к тому что False Positive, в долгосрочной перспективе может спровоцировать серьезный инцидент или быть цепочко, или его признаком
Поэтому нужно проводить анализ мониторинга, алертов и в целом не страться кидать оповещения на каждое событие, только действительно на то что имеет значение.
Думаю что многие знают такое, как: - "Да просто засапресить нужно это и все"